Nine days inside, 39 minutes of reading
The timeline is the part the headline number hides. The probing of the authentication proxy began on 12 October. From 13 to 21 October, the intruder had access to internal tools and to some of the systems they connect to, and used that time, in Botpress's words, to build an understanding of how the systems work in preparation for the attack. That access also exposed customer account information and internal data, including data related to staff API credentials.
The employee held admin access to several customer workspaces through workspace membership. According to Botpress, the attacker used that employee's API credential and inherited permissions to read bot configurations in 16 workspaces during a 39-minute window. The flaw was fixed the same day, at about 16:25 UTC, the proxy secret rotated and the credential revoked. The disclosure came 16 days later, on 6 November.
A configuration file is a bundle of other people's keys
Sixteen workspaces sounds contained. What was read inside them is not. A bot configuration can contain integration credentials for external services, including AI providers, messaging channels and CRMs. Access to that configuration therefore creates potential exposure beyond Botpress itself. Botpress says its logs cannot establish exactly which affected bots contained valid credentials at the time of access, so it is asking affected customers to treat every credential stored in those bots as exposed.
Botpress says it contacted the owners of the 16 workspaces where configurations were read and the two additional workspaces where integration settings were changed. Each received a list of the bots and integrations involved. Botpress is asking those customers to treat credentials stored in the affected bots as exposed and to rotate them. That instruction should not be expanded to every credential in all 18 workspaces without further evidence.
For customers who were not contacted, Botpress reports no evidence that their bots were read or changed. That is the company's current investigative finding, not an independent guarantee that no access occurred. Its inability to determine credential validity is a separate limitation from its identification of the bots accessed.
Separately from the reading, the intruder changed the settings of one integration in each of two other workspaces, using weaknesses in the setup flow of some integrations. The disclosure does not say what those changes did or when they were made. Botpress says it has strengthened how integration configuration is stored and is changing the bot API so stored credentials cannot be reached this way again.
Botpress Points to AI-Credit Resale as the Motive
Most breach write-ups end at who got in and what they touched. This one states a motive, and the motive explains the shape of the intrusion. Everything Botpress observed, it says, points to a single goal: obtaining AI usage that could be resold on AI black markets. Before and during the intrusion, the attacker ran a large network of accounts on the platform to consume AI credits, and much of the activity inside Botpress's systems was aimed at keeping those accounts running without limits.
Botpress assesses the attacker's objective as obtaining AI usage for resale. It says the attacker operated a large network of platform accounts consuming AI credits and sought to keep those accounts running without limits. That account helps explain the observed activity, but the disclosure does not establish exactly how the customer configurations or credentials were used, whether valid third-party credentials were obtained, or whether any such credentials were subsequently abused. The reported motive does not narrow the potential exposure created by reading the configurations.
There has been no ransom demand, and Botpress has seen no sign that customer data has been published or offered for sale. It does not reduce the rotation work for the customers whose keys sat in those files, and it identifies the standing risk for every agent platform: a service that stores AI keys for thousands of customers is worth attacking for the keys alone.
What this asks of anyone storing keys in an agent platform
If your bots or agents run on any hosted platform, the practical questions come straight from this disclosure. Which of the vendor's staff are members of your workspace, and with what access? Are the credentials your bots use stored in a configuration the vendor's own tools can read in plain form? And if a staff key were used against your workspace, would the vendor's logs be able to tell you afterwards exactly what was taken? Botpress's disclosure shows why these questions matter. A staff credential carried admin permissions into customer workspaces, and the platform's bot API allowed the attacker to reach configurations that could contain third-party credentials. Botpress says it identified the bots accessed, but could not determine which stored credentials were valid. It is now reviewing internal-tool access, staff permissions and how the bot API exposes stored credentials. Those are the right questions. They were also available before October.
Sources
- [1] Botpress, “Security incident disclosure — November 2026,” published 6 November 2026, read in full this run: the authentication proxy flaw and the 12 October probing; the 13–21 October access to internal tools and connected systems, including visibility into customer account information and data related to staff API credentials; the 21 October 07:44–08:23 UTC read of bot configurations in 16 workspaces using an employee's credential and admin access; configurations holding AI provider API keys, messaging channel tokens and CRM credentials; the integration settings changed in two further workspaces via setup-flow weaknesses; the 21 October fix at about 16:25 UTC, the rotated proxy secret and revoked credential, and rejected attempts observed through 3 November; the stated motive of obtaining AI usage for resale on AI black markets, the attacker's account network consuming AI credits, no ransom demand and no sign of customer data published or offered for sale; the limit that logs cannot show which bots held a valid credential, and the instruction to treat all stored credentials in affected bots as exposed; the absence of evidence, so far, of identity-provider compromise, source code, build pipeline or package changes, or access to end-user conversations; and the remediation list, the internal credential rotation still under way, the bot API change, and the review of staff admin access to customer workspaces.Read source
- [2] Secondary coverage, for timing only: Unite.ai, “Botpress Discloses Internal Breach and Customer Credential Risk,” 6 November 2026, and the Precise Impact AI Daily Brief for 7 November 2026, which carries the disclosure among the day's stories. No load-bearing claim in this draft rests on either.