Can Prompt Injection Steal A Contentful API Token Through Its MCP Server?

August 19, 2026

Contentful patched an MCP flaw that could redirect a management API token through LLM-controlled migration settings. Here is who is affected and what to do.

Yes—under specific conditions. Contentful says vulnerable versions of its official MCP server could let an LLM-controlled host or proxy value redirect a Content Management API request, including the server's Personal Access Token, to an attacker-controlled endpoint. The issue affects @contentful/mcp-server before 1.7.19 and @contentful/mcp-tools before 0.4.5.

The important qualification is that hostile text alone does not magically steal a token. The documented prompt-injection path requires an AI assistant to read attacker-controlled Contentful content, interpret it as instructions, enable the disabled migration tools, and call export_space or import_space with attacker-chosen network arguments. A person or client with direct MCP tool-call access could also trigger the vulnerable path.

Contentful patched the issue on August 19, 2026. Operators should upgrade both packages, verify the versions actually loaded by every MCP client, disable migration tools when they are not needed, rotate any token that may have traversed the vulnerable path, and review outbound network and Contentful activity. The advisory does not report exploitation in the wild or confirm that a real customer's token was stolen.

What Is Confirmed

GitHub published GHSA-2xhg-73j7-rrgx on August 19, 2026. The reviewed advisory rates the flaw high severity at 7.7 and identifies two affected packages:

Contentful's MCP server connects AI assistants to the Contentful Management API. Its official repository documents tools for reading, creating, updating, publishing, and deleting content, plus tools for managing models, assets, environments, tags, and AI actions. The server is configured with a CONTENTFUL_MANAGEMENT_ACCESS_TOKEN.

The vulnerable migration tools accepted network-routing fields from the MCP tool arguments. The advisory identifies host, proxy, rawProxy, and insecure as the critical path. The application then combined those LLM-controlled arguments with the server-configured management token and passed them to Contentful's export or import libraries.

Those libraries built a request destination from the supplied network fields and attached the token as an Authorization: Bearer header. If the destination pointed at infrastructure controlled by an attacker, that endpoint could receive the bearer token.

Contentful's patch commit makes the trust-boundary change visible in code. It removes management hosts, proxies, raw proxy settings, custom headers, delivery credentials, and config-file paths from the LLM-facing migration schemas. It then sources the Management API host from server configuration, falling back to api.contentful.com, and adds regression tests proving that tool arguments cannot replace it.

The patched MCP server 1.7.19 release and MCP tools 0.4.5 release contain that fix.

What Is Still Unclear

The advisory does not say the flaw was exploited outside testing. It does not name a victim, identify a stolen production token, estimate how many installations used the affected packages, or show how often an assistant would follow the example injected instruction.

It also does not mean every Contentful user, every MCP server, or every AI assistant was vulnerable. The path depends on this official Contentful MCP implementation, the affected package versions, configured credentials, access to the relevant migration tools, and a client or model that actually issues the required calls.

The prompt-injection scenario is conditional. According to the advisory, the migration tools were disabled by default and first had to be enabled through space_to_space_migration_handler. An injected entry would therefore need to induce a multi-step tool sequence, not merely appear in model context. Approval prompts, tool policies, client behavior, and human review can interrupt that sequence.

There is no independent incident report or meaningful press cycle available at publication time. The strongest evidence is the vendor repository, the reviewed advisory, the code change, and the patched releases. That is sufficient to establish the vulnerability and fix, but not to claim real-world compromise.

How Could Prompt Injection Reach A Contentful Token?

The vulnerability is easier to understand as a chain of authority:

1. An MCP process starts with a Contentful management token in its server configuration.
2. An AI assistant can read Contentful entries and invoke approved MCP tools.
3. An untrusted entry contains text that looks like instructions to the assistant.
4. The assistant treats that data as an action request rather than inert content.
5. It enables the migration tools and calls export_space or import_space.
6. In a vulnerable version, the tool accepts an attacker-chosen Management API host or proxy.
7. The downstream client sends an authenticated request to that destination.

The model never needs to print the secret in chat. The application adds the bearer token after the tool call has already selected the wrong destination. That distinction matters because output filters looking for token-shaped strings would not necessarily see the leak.

This is also why calling the issue “just prompt injection” understates it. Prompt injection supplies influence, but the application supplies authority. The security failure appears where untrusted model output crosses into a network configuration field that should belong only to an operator.

Why Is A Contentful Management Token So Sensitive?

Contentful's Personal Access Token documentation says these tokens are tied to the user who creates them and carry that user's permissions across organizations, spaces, and content. Contentful warns that CMA tokens behave similarly to passwords because another person can use one on the owner's behalf.

The Content Management API token reference documents read-only and read/write scopes. A token with content_management_manage can read and write within the access inherited from its owner. That can make token exposure materially different from leaking a public delivery key.

The exact impact therefore depends on the token and user:

• which organizations and spaces the user can access;
• whether the token is read-only or read/write;
• which roles and content policies apply;
• whether the user has access to production environments;
• whether the same token is reused by other automation; and
• how quickly the token is detected and revoked.

A leaked low-privilege token is still a credential incident, but it is not equivalent to a broadly privileged production token. Operators should determine the actual permissions before describing impact.

Why The Fix Is More Important Than A Better Prompt

Prompt wording cannot reliably turn hostile data into trusted data. A model may reject one obvious instruction and follow a paraphrased, encoded, indirect, or contextually plausible version later.

Contentful's patch addresses the enforceable boundary: the model no longer gets to choose the management destination. The server configuration chooses it. That converts an informal instruction—“please use the normal API host”—into a property of the tool interface.

The patch also removes custom headers and config-file paths from these LLM-facing schemas. This is useful defense in depth. A field that is not needed for the assistant's task should not remain available merely because an underlying library supports it.

The broader design rule is simple:

Models may propose business parameters. Operators must own credential destinations, proxies, trust stores, and other security-sensitive transport settings.

An agent can reasonably select a space ID, environment, content type, or migration option after authorization. It should not be able to decide where a privileged bearer token is sent.

What Contentful MCP Operators Should Do Now

Use the BOUND response sequence to contain the immediate issue and reduce the chance of the same pattern returning elsewhere.

B — Build An Exact Inventory

Find every installation of @contentful/mcp-server and @contentful/mcp-tools. Check package-lock files, global npm installs, container images, desktop MCP configurations, CI runners, developer workstations, and remote agent hosts.

Do not assume that changing one configuration updates every client. The repository's current setup examples use npx -y @contentful/mcp-server, while desktop packages and pinned lockfiles may follow different update paths. Record the package version from the running process or resolved dependency tree.

Inventory the configured token at the same time. Identify its owner, scopes, expiration, accessible spaces, environment permissions, and every other workload that uses it.

O — Overwrite Vulnerable Packages With Patched Releases

Upgrade @contentful/mcp-server to 1.7.19 or later and @contentful/mcp-tools to 0.4.5 or later. Rebuild containers and restart long-running MCP clients so an old process does not remain in memory.

Then inspect the tool schema exposed to the client. The migration tools should not advertise LLM-settable management host, proxy, rawProxy, custom-header, or config-file fields. Test in a non-production space that a supplied unknown host is stripped or rejected and that requests still go only to the operator-configured Contentful endpoint.

U — Uncouple Untrusted Content From Privileged Tools

Treat Contentful entries, imported files, URLs, webhook bodies, comments, and external copy as untrusted even when they live inside an approved space. A content record can be legitimate data and still contain adversarial instructions.

Separate read-only analysis from write or migration sessions. Do not expose export, import, publish, delete, environment-management, or AI-action tools when the user only needs search and summarization. Keep migration tools disabled until a specific approved operation needs them, and require confirmation that shows the exact source, destination, space, and environment.

For high-impact workflows, do not let the same automated step both read untrusted content and gain new tool authority. A model should not be able to enable a disabled tool merely because the content it just read told it to.

N — Narrow Credentials And Network Reach

Use the least-privileged Contentful identity and token that can complete the task. Prefer a dedicated automation user over a developer's broadly privileged personal account. Use read-only scope for read-only work, restrict the user's roles and spaces, and avoid sharing one token across unrelated clients.

Contentful recommends expiration dates for Personal Access Tokens. Shorter lifetimes reduce the useful window if a credential escapes. Keep tokens in environment variables or a secret manager rather than in prompts, project files, or chat history.

Add an egress allowlist where practical. The Contentful MCP process normally needs known Contentful API destinations, not arbitrary internet hosts. Network enforcement can prevent a future application bug from turning a model-selected URL into a credential destination.

D — Detect Exposure, Disable Access, And Rotate

Review MCP client logs, process logs, proxy records, DNS history, firewall telemetry, and endpoint activity for export or import calls with unfamiliar hosts, proxies, or redirects. Review Contentful audit and API activity for unexpected reads, writes, publishes, migrations, or environment changes associated with the token owner.

If a vulnerable migration call reached an untrusted destination—or if logs cannot resolve a credible exposure window—revoke and replace the token. Contentful's token guidance documents revocation and notes that the secret value is only shown when created. Update every legitimate workload that used the old token.

Patching removes the known path. It does not invalidate a credential that an attacker may already possess.

What Should Agent Builders Learn From This?

This advisory illustrates five separate controls that are often collapsed into one “AI safety” setting:

No single row replaces the others. Human approval does not help if the confirmation hides the destination. A least-privilege token does not make exfiltration acceptable. An egress filter does not repair a dangerous API schema. Defense comes from making the chain fail in several places.

The incident also shows why model output should not be trusted simply because it is valid JSON. Schema validation can prove that a value is a string. It cannot prove that an attacker-controlled hostname is an authorized Contentful endpoint. Semantic authority must be enforced by application policy.

Does This Mean All MCP Servers Leak Credentials?

No. The advisory concerns specific versions and tools in Contentful's official MCP server. It does not establish a flaw in the MCP protocol, Contentful's hosted APIs generally, every Contentful integration, or every other MCP server.

But it reveals a reusable review question: Can any model-controlled argument change the destination, proxy, headers, credentials, filesystem path, executable, or approval state of a privileged tool?

Audit tool schemas for fields such as:

• host, baseUrl, endpoint, proxy, and redirect;
• headers, authorization, token, and credential;
• command, shell, script, and executable paths;
• local file paths, import sources, and export destinations; and
• flags that disable TLS checks, approvals, sandboxes, or access controls.

Some of these fields can be legitimate in operator configuration. Their presence in an LLM-facing schema is the warning sign.

Where OpenVeil Fits — And Where It Does Not

OpenVeil is a hosted, privacy-focused AI workspace for chat, files, web search, voice, images, and video. It is a practical option for people who want useful AI work without operating an MCP server that holds a Contentful management credential.

That narrower workflow can reduce the amount of autonomous tool authority in the session, but it does not patch Contentful, inspect MCP schemas, revoke leaked tokens, block prompt injection, or secure an unrelated agent deployment. Do not use OpenVeil as a substitute for upgrading, least privilege, outbound controls, or incident response.

OpenVeil is also not fully offline, anonymous, or a zero-log service. Active requests are processed by OpenVeil and necessary providers. Its documented privacy boundary is that normal chat history stays in the browser rather than a normal server-side chat-history record, and prompts, uploads, media, selected local context, and outputs are not used to train foundation models.

If your task is discussion, research, drafting, or file analysis rather than autonomous Contentful administration, removing the privileged connector from that workflow is a meaningful simplification. You can try OpenVeil with ten bounded preview actions and no card, then decide whether a hosted privacy-focused workspace fits better than maintaining an agent with CMS credentials.

For related trust-boundary guidance, read what researchers found inside exported AI reasoning logs, how prompt-driven Flowise agents reached server-side code, and how one link could create a rogue ChatGPT agent.

Frequently Asked Questions

Which Contentful MCP versions are affected?

GitHub's reviewed advisory identifies @contentful/mcp-server versions before 1.7.19 and @contentful/mcp-tools versions before 0.4.5 as vulnerable. Upgrade to those versions or later and confirm the versions loaded by each running client.

Could a Contentful entry steal a token just by being opened?

Not by itself. The documented prompt-injection path requires an assistant to treat content as instructions, enable the migration tools, and call export_space or import_space with attacker-controlled network arguments. Client policy, approvals, tool availability, and model behavior all affect whether the chain completes.

Was a real Contentful token stolen?

No public source reviewed for this article confirms a real-world theft or exploitation. The advisory documents a reproducible path and high potential confidentiality impact, not a victim count.

What did Contentful change in the fix?

The patch removes security-sensitive network fields from the LLM-facing migration schemas, pins the Management API host to server configuration, moves delivery credentials and hosts into operator configuration, and adds regression tests.

Should I rotate my Contentful token after upgrading?

Rotate it if a vulnerable migration tool contacted an unexpected host or proxy, if logs show suspicious tool activity, or if you cannot establish a trustworthy exposure window for a sensitive token. Upgrading prevents the known path but cannot retrieve a secret already sent elsewhere.

Does disabling migration tools solve every prompt-injection risk?

No. It removes the documented trigger path for this vulnerability, but the server exposes many other read and write tools. Keep unnecessary tools unavailable, require clear approvals, minimize token authority, and review every model-controlled field that can change a security boundary.

The Bottom Line

Contentful fixed a real high-severity flaw in its official MCP server: vulnerable migration tools let LLM-controlled network arguments determine where a privileged Management API request—and its bearer token—went. Prompt injection was one possible way to reach that unsafe interface, but the application-level mistake was allowing the model to control a credential destination.

Upgrade to @contentful/mcp-server 1.7.19 and @contentful/mcp-tools 0.4.5 or later. Verify the running versions and schemas, keep migration tools off unless needed, narrow the token and egress policy, inspect the exposure window, and rotate credentials when evidence is incomplete. Treat the advisory as a confirmed vulnerability, not proof that every deployment was compromised.