FastGPT CVE-2026-68929: a public shareId can hijack a WeChat channel

CVE-2026-68929 is a missing-authorization flaw in FastGPT’s WeChat iLink integration. The server selected channel configuration from a shareId but did not verify an authenticated identity, team or application owner. Anyone who knew the public identifier could take another tenant’s bot offline or bind the victim application to the attacker’s WeChat account.

Versions before FastGPT 4.15.2 are affected. The CVE record published on 28 August carries a CVSS 4.0 score of 9.3 (Critical), while the GitHub Advisory view still labels the issue High. The project advisory is dated 19 August, so today’s development is the formal CVE record and wider distribution rather than the day the fix was produced.

This is not conventional prompt injection. A model does not need to obey an attacker’s instruction, and prompt text is not the source of the decision. The weakness is in the AI platform’s control plane: a public conversation identifier was treated as evidence of permission to modify an integration.

shareId identifies a resource but does not authenticate its owner

FastGPT can publish applications through links, iframes and messaging channels. A shareId is required so a recipient reaches the intended application. It therefore appears in URLs and embeds, and its secrecy cannot be the foundation for protecting administrative operations.

The affected code looked up an outLink by shareId. A function named authOutLinkValid() confirmed only that the object existed. It did not check a logged-in user, teamId, tmbId or application permission. The word “auth” in its name could suggest a security boundary even though the function implemented existence validation only.

This is a recurring multi-tenant mistake. Routing answers “which resource?” whereas authorization answers “may this principal perform this action on that resource?” One identifier can locate a record; it cannot replace the second decision.

First impact: remotely taking the bot offline

The WeChat logout endpoint accepted a shareId, performed the existence check and then set the integration offline while clearing its stored token. An external user did not need a FastGPT session. The identifier exposed in a shared link was sufficient.

The immediate result is a channel availability failure. The bot stops handling conversations and an operator must bind it again. In a customer-facing system, that can mean missed requests, SLA impact and a channel mysteriously entering an offline state rather than merely a technical restart.

The operation may look valid in logs because the application intentionally updates its own record and produces no authorization error. Detection should therefore connect status changes with the operator identity, source address, session and preceding administrative workflow. On a vulnerable release, mutation without any authenticated identity is itself a useful signal.

Second impact: replacing the channel binding

The more serious path involves QR handling. QR generation was protected only by the shareId existence check, while the status endpoint made no authorization call. After confirmation, it wrote bot data—including token, account identifier and base URL—to the outLink selected by the public identifier and started polling.

An organisation’s application could therefore be connected to a channel controlled by someone else. Private answers based on corporate knowledge could reach an external inbox, the legitimate binding would be displaced, and the victim’s AI resources or points would be consumed by the attacker’s interactions.

This does not automatically dump the complete knowledge base. Disclosure depends on questions, application rules, tools and content returned in answers. A hijacked channel is nevertheless a legitimate interface to the application and may reveal information the operator believed was available only through a controlled integration.

Why a QR scan is not consent from the application owner

Scanning a code proves control over the WeChat account being bound. It does not prove that the same person may administer the FastGPT application selected by shareId. The system joined two separate identities without a secure bridge.

A correct flow begins with a logged-in tenant operator. The server creates a short-lived, one-time state bound to that user, team, application and intended action. A callback or poll can complete only that transaction, and the server repeats the permission check before persisting the result.

A random QR code is insufficient when a public parameter still selects the target record. State must not move between tenants, must resist replay and must be invalidated after use. A robust flow also records the approving operator, timestamp and destination channel.

Who is exposed

Exposure applies to FastGPT installations older than 4.15.2 that use the WeChat iLink channel. Merely installing affected code does not guarantee that a useful record exists. There must be a published outLink with a shareId and a configured or configurable integration.

Public links should not be deleted merely to “hide the identifier.” Their purpose is recipient access. Rotating a shareId can temporarily reduce risk, but its replacement becomes public again when shared. The durable fix is proper authorization on mutating operations.

In SaaS deployments, also determine whether a reverse proxy, WAF or SSO layer adds a control. Do not assume it does without testing. An API endpoint may use a different routing policy from the dashboard, and part of the application may ignore the proxy’s trusted identity header.

What to do now

Upgrade to FastGPT 4.15.2 or a newer supported release. After deployment, confirm that logout, QR generation and status checks require an authenticated user authorised for the exact outLink. Negative tests should cover no session, another team’s session, a foreign shareId, an expired QR transaction and reuse of completed state.

If the update must wait, restrict or disable the WeChat management endpoints at the reverse proxy and remove unused channels. Do not block every public chat without assessing business impact. The mitigation should target management operations, not necessarily safe reading of a public application.

Review every existing outLink: owner, status, WeChat account ID, last binding time, base URL and token-change history. Require a new authorised binding for channels whose provenance cannot be confirmed. Store and rotate tokens according to the integration procedure without copying them into tickets or SIEM records.

Hunting for exploitation evidence

The strongest signals are channel mutations without a matching administrator session. Find logout, QR generation and status calls for the same shareId, particularly from new addresses or user agents. Correlate them with changes to app.token, app.accountId, app.baseUrl and app.status.

Another suspicious sequence is QR generation, rapid confirmation, immediate polling and rising AI-point consumption without team-member activity. If responses may have contained internal data, establish which questions and results passed through the foreign channel and which tools or RAG sources the application could use.

Without database change history, combine application, reverse-proxy, container, database, Redis and WeChat-provider logs. Normalise timestamps and do not treat a later legitimate re-binding as proof that the earlier state was valid.

Design lessons for AI agents and integrations

An AI platform has two planes. The data plane handles messages, documents, prompts and tool calls. The control plane decides who publishes an application, attaches a channel, changes a model, adds a secret and bears the cost. Protecting prompts alone leaves the highest-impact management operations outside the threat model.

Every mutating endpoint should evaluate at least subject, tenant, resource, action and current state. Identifiers received from a URL, webhook, callback or QR flow are input data, not permissions. Ownership must come from server-side context rather than a client-supplied field.

Primary facts and Breachroad conclusions

Affected versions, endpoint behaviour, channel impact and the 4.15.2 fix come from the FastGPT advisory and CVE record. Recommendations about transaction-bound QR state, telemetry, proxy mitigations and re-binding are Breachroad’s defensive conclusions. The sources do not report confirmed exploitation at a named organisation.

Primary sources

• GHSA-q4pr-3qpg-9q5v — FastGPT advisory
• FastGPT fix commit 81d3919
• CVE-2026-68929 in NVD
• FastGPT repository

AI security starts with control over channels and tenants before a message reaches the model. Our secure-AI and cybersecurity training shows teams how to design control-plane boundaries, callbacks and integrations. For deployed platforms, web and API penetration testing can cover BOLA, publishing workflows and tenant separation.