Botpress Breach Exposed Customer Bot Credentials in 16 Workspaces

Botpress disclosed on November 6, 2026 that an attacker read bot configurations in 16 customer workspaces after exploiting a flaw in an internal authentication proxy and using an employee's API credential with administrator access. The configurations can contain third-party secrets, including AI provider API keys, messaging-channel tokens and CRM credentials, and the company cannot determine which of them held valid credentials at the time they were read.

The stakes are concrete for any organization storing integration secrets inside a bot-building platform: Botpress is now asking the affected customers to treat every credential stored in affected bots as exposed. The incident also exposes a structural question about platform trust — why an employee held administrator access to customer workspaces at all.\n By James Calloway

How did the attacker get in?

The intrusion began on October 12, 2026, when someone started probing the authentication proxy protecting several of Botpress's internal tools. A flaw in the proxy's sign-in validation let the attacker enter with sessions that appeared to belong to Botpress staff.

From October 13 through October 21, 2026, the attacker retained access to those tools and some connected systems, using that period to learn how Botpress's systems worked. That access provided visibility into customer account information and internal data, including data related to staff API credentials. The investigation found no evidence that any employee's identity-provider account was itself compromised.

The proxy let forged staff identities through; the employee account did not need to be broken. Takeaway: the weakest link was a validation bug, not a stolen password.

What exactly was read or changed?

On October 21, between 07:44 and 08:23 UTC, the attacker used the employee's API credential and its administrator access to read configurations in 16 workspaces. The employee was a member of those customer workspaces and held administrator access to them.

A bot's configuration includes settings for installed integrations, which can contain:

• AI provider API keys
• Messaging-channel tokens
• CRM credentials and similar third-party secrets

Separately, the attacker exploited weaknesses in some integrations' setup flows to change one integration's settings in each of two other customer workspaces. That brings the total of directly affected customers to 18 — 16 with read configurations, two with modified integration settings.

Botpress knows which bots were read and has contacted the owners of all affected workspaces, supplying lists of affected bots and integrations. For customers not contacted directly, the investigation has produced no evidence that their bots were read or changed. Takeaway: the blast radius is mapped, but the contents of what was read are not.

Why does credential exposure remain uncertain?

Botpress's logs cannot establish exactly which bots contained a valid credential at the moment they were read. The company is therefore asking affected customers to assume the worst and rotate everything.

That admission cuts both ways. It is honest about the limits of telemetry, but it also means customers cannot triage: every secret in every affected bot must be treated as compromised until proven otherwise. The company says it will work with affected customers until their credentials are rotated.

Botpress attributes the intrusion to an effort to obtain AI usage for resale on what it calls AI black markets. The attacker operated a large network of Botpress accounts to consume AI credits before and during the incident, and much of the internal activity served to keep those accounts operating without limits. No ransom demand has been received, and there is no observed sign that customer data was published or offered for sale.

The absence of ransom or published data is a finding as of the disclosure date, not a guarantee. Botpress states the disclosure will be updated if these findings change. Takeaway: the motive appears to be compute theft, with credential exposure as collateral damage — a motive that reduces but does not eliminate data-risk scenarios.

What was not touched?

The investigation also found no evidence of:

• Changes to source code, build pipelines or published packages
• Access to end-user conversations handled by customer bots
• Compromise of any employee's identity-provider account
• Publication or sale of customer data

Botpress does not store full payment card numbers, removing one class of financial exposure from the equation.

Each of these negatives is scoped to what the investigation observed. The company itself flags that the disclosure will be revised if findings change. Takeaway: the clean areas are clean as far as current evidence reaches.

Is the breach contained?

At approximately 16:25 UTC on October 21, Botpress fixed the proxy vulnerability, rotated its secret and revoked the employee credential — roughly eight hours after the workspace reads occurred.

The company then blocked accounts, workspaces and network routes associated with the attacker, hardened ingress rules, restricted and restarted affected tools, and limited how those tools can be reached. It reversed changes to internal settings, strengthened integration-configuration storage and began rotating internal credentials found in files the attacker had read.

Containment was not a single action. The attacker kept attempting access through other routes and new platform accounts after the fix. Botpress says it has closed every route it identified, and attempts observed through November 3, 2026 were rejected. The company states that the internal tools can no longer be reached with a forged identity.

Takeaway: access routes are closed, but persistence by the attacker shows this was an active adversary, not a one-pass scan.

What remediation is still unfinished?

Internal credential rotation is still underway — a process that began on October 21 and remained incomplete at the November 6 disclosure. A hardening initiative is reviewing access to every internal tool and staff-credential permissions, including the question of when employees should hold administrator access to customer workspaces in the first place.

Botpress is also changing the bot API so that stored bot credentials cannot be reached through the same method again. Monitoring for related activity will continue.

The unresolved items are the ones with the longest tail. Credential rotation depends partly on customer action, and the review of staff administrator access touches a design decision — employee membership with admin rights in customer workspaces — that made this incident broader than it otherwise would have been. Had the employee credential carried narrower scope, 16 workspaces would not have been readable in 39 minutes.

Takeaway: the technical hole is patched; the architectural question of privileged staff access to customer environments is still open.

What should affected customers do now?

The guidance from Botpress is unambiguous: customers it contacted directly should treat every credential stored in affected bots as exposed, and rotate them. The company has supplied those customers with lists of affected bots and integrations to scope the work.

Customers not contacted have, on the company's evidence, no indication their bots were read or changed. That assurance rests on the investigation's completeness, and Botpress itself reserves the right to update the disclosure.

The division between the incident's immediate and unresolved phases is clear. Identified access routes have been closed and forged identities no longer work. Credential rotation, the staff-access review and the bot API redesign remain unfinished, and the final word on what the attacker actually obtained — valid keys or empty configuration fields — may never be established from logs alone.