Botpress Incident Turns Bot Configuration Into A Credential Boundary

Botpress says an attacker exploited a sign-in validation flaw in an authentication proxy protecting internal tools, then obtained an employee API credential and used that employee's workspace access to read bot configurations in 16 customer workspaces. The configurations could contain AI provider keys, messaging channel tokens, CRM credentials and similar integration secrets. The attacker also changed one integration setting in each of two other workspaces. Botpress fixed the proxy flaw, revoked the employee credential, restricted internal tools and contacted the affected customers.

The incident did not require compromise of an employee identity-provider account, according to Botpress. It joined three forms of standing authority instead: a staff-looking internal session, an employee credential and customer-workspace membership that carried administrative access. Affected customers should preserve Botpress and provider evidence, replace every credential stored in the identified bots at the service that issued it, update both development and production configurations where applicable, and verify that old credentials fail. Other agent-platform operators should separate human support access from bot secrets and make credential retrieval independently auditable.

Botpress says probing of its internal authentication proxy began on October 12. The proxy had a flaw in how it validated sign-ins, allowing the attacker to enter protected internal tools with sessions that appeared to belong to staff. Botpress explicitly says it found no evidence that the attacker compromised an employee account at its identity provider. The weakness was therefore in the application-layer trust decision in front of the tools, not a confirmed theft of an employee's primary login.

Between October 13 and October 21, the attacker used internal tools and some connected systems to understand the environment. That access exposed customer account information and internal data related to staff API credentials. Botpress says the attacker obtained one employee credential. Because the employee was a member with administrator access in several customer workspaces, that credential carried customer-facing authority as well as internal meaning.

On October 21 from 07:44 to 08:23 UTC, the attacker used the credential to read bot configurations in 16 workspaces. Botpress fixed the authentication flaw at about 16:25 UTC and revoked the employee credential. It says subsequent attempts through other routes and new platform accounts continued until November 3 but were rejected. This timeline separates the short confirmed customer-configuration access window from the longer period of internal discovery and the later unsuccessful reentry attempts.

Botpress integrations connect agents to messaging channels and external services. Its documentation says most integrations require API keys, tokens, webhook URLs or other configuration, and that integration configuration is stored on Botpress servers rather than only in local project files. It also notes that development and production bots can have separate configurations. One bot can therefore become a meeting point for credentials issued by several unrelated providers and environments.

The incident report names AI provider API keys, messaging channel tokens and CRM credentials as examples of values that may be present in bot settings. Those credentials do not all create the same risk. An AI key may authorize billable model use and expose provider logs. A messaging token may let an actor send, receive or administer channel traffic depending on its scope. A CRM credential may expose customer records or workflow actions. Response must follow the actual issuer, scope, environment and recent use of each credential rather than treating them as interchangeable strings.

Botpress says weaknesses in some integration setup flows were used to change one integration setting in each of two additional workspaces. It reversed those changes and strengthened integration-configuration storage. The disclosure does not identify the integrations, the fields changed or any downstream action caused by the changes. Administrators should preserve the affected setting values and change history before cleanup, then use third-party logs to determine whether the modified destination, token or webhook produced an external effect.

Botpress says it knows which bots were read and contacted the owners of the 16 affected workspaces and the two workspaces with changed integration settings. Each received a list of involved bots and integrations. The company also says its logs cannot establish exactly which bots contained a valid credential during the access window. That gap is why its customer instruction is deliberately conservative: every credential stored in an affected bot should be treated as exposed.

Exposure is not the same as confirmed use. The public report does not say that every credential was copied, that every connected provider was accessed or that every bot configuration contained a live secret. It also reports no ransom demand and no sign that customer data was published or offered for sale. Botpress assesses that the attacker wanted to obtain AI usage that could be resold and links the intrusion to a large network of accounts consuming AI credits. That motive should remain labeled as Botpress's assessment until more evidence or an independent attribution is published.

The negative findings matter but have boundaries. Botpress found no evidence of access to employee identity-provider accounts, changes to its source code, build pipelines or published packages, or access to end-user conversations handled by bots. It also says customers it did not contact have no evidence of bot reads or changes. Those statements describe evidence available to the vendor, not proof that no related activity occurred at a third-party provider whose credential was stored in an affected configuration.

Affected customers should first export or record the bot, integration, environment, credential owner, provider, scope and last-known configuration without copying secret values into an ordinary ticket. Preserve Botpress audit records and provider authentication, API, messaging, billing and administrative logs for the period beginning before October 12 and extending beyond the final rejected attempts on November 3. The purpose is to keep a defensible timeline before rotation changes identifiers and creates expected failures.

Replace each implicated credential at the system that accepts it. Revoke the old key or token, issue a narrowly scoped replacement, update the correct Botpress development or production configuration, restart or republish only when the integration requires it, and test both success of the new credential and failure of the old one. Search deployment variables, automation, local developer files and other agent platforms for duplicate copies. A value removed from one bot may remain valid in another consumer until the issuer rejects it.

Then investigate downstream actions using provider-native evidence. Review AI usage and spending by key, messaging administration and outbound activity, CRM exports and workflow changes, and webhook destinations. If an exposed credential could create more credentials or change identity policy, expand the review to those descendants. Rotate from a trusted administrative session and avoid deleting evidence that would distinguish attacker use from ordinary automation.

Botpress documentation describes workspace roles in which an administrator can manage all bots, and its agent access-control documentation says workspace owners and administrators always retain access to every bot in that workspace. In this incident, an employee's membership in customer workspaces made a staff credential useful against customer configurations. The design question is not only whether the employee needed support access at some point, but whether that authority needed to remain standing and whether it needed to include secret retrieval.

Agent platforms should separate support identity, customer impersonation, configuration editing and secret materialization. Time-bound customer approval can activate support access for a named case. A support role can inspect health without reading secret values. A privileged workflow can require a second authorization before exporting or replacing credentials. Independent logs should capture who requested access, which workspace and bot were reached, whether a secret was revealed, and what downstream configuration changed.

NIST's recent agent-identity design tenets recommend identities and credential lifecycles that are distinct from human principals, plus evidence that is independent and tamper resistant. Applied here, a bot should not simply inherit a human administrator's broad, reusable authority. It should have a workload identity tied to an approved environment and purpose, while staff access should be separately issued, short lived and attributable to a support action.

Botpress has disclosed the sequence and customer scope but not the exact proxy validation flaw, the internal tools reached, the permission model on the employee API credential or the integration setup weaknesses used in two workspaces. It has not published provider-level evidence showing whether exposed credentials were exercised outside Botpress. A later postmortem could materially change the response boundary, particularly if it identifies additional credentials, longer retention or a downstream service action.

The company says it restricted and restarted affected internal tools, hardened ingress, rotated internal credentials found in read files and is changing the bot API so stored credentials cannot be reached through the same path. Customers should track that work, but they should not wait for architectural changes before revoking issuer-side credentials named in their notice. Vendor containment cannot invalidate a key that remains active at an AI, messaging or CRM provider.

For operators that were not contacted, the useful action is a control review rather than an incident claim. Inventory which agent configurations hold third-party authority, separate production from development, reduce owner and administrator membership, retain audit data, and test provider-side revocation. The incident shows how an agent platform can concentrate communication and business credentials even when no end-user conversation database is accessed.