Bubble Incident Makes App Secrets A Shared-Platform Boundary

Bubble's November 3 preliminary root-cause analysis says an attacker exploited a platform application vulnerability on older server infrastructure, obtained temporary internal credentials and used them to reach further credentials and internal systems. The attacker read private plugin data, including credentials saved by plugin developers. Bubble also says some individual apps had data or stored credentials accessed through platform issues even when configured correctly, while other access depended on app settings such as privacy rules. The company says it has contacted app owners it believes need to act.

Bubble says its current review has not shown that internal-system access was used to read the main application databases or app user data, and says an outside forensic firm's preliminary findings are consistent. That statement does not erase confirmed access to some app data and credentials, and the company is still verifying the full timeline and scope. App owners should preserve their notice, separate platform-caused access from configuration exposure, run the security dashboard, review privacy rules, make editor access private, inspect API Connector secrets and rotate only credentials that may have been exposed at their issuing service.

Bubble dates initial production access to October 26. It says an attacker exploited a security vulnerability in the platform and older server infrastructure to obtain temporary internal credentials. Those credentials led to further internal credentials and systems. Monitoring detected unusual use of an internal key that day, after which Bubble closed the initial path, began rotating credentials, updated server infrastructure and engaged an outside forensic firm on October 27.

Through one internal system, the attacker read private plugin data, including credentials that plugin developers had stored in the plugin editor. Bubble emailed affected developers on October 26 and asked them to change those values. This is a specific population and data type. It does not mean that every plugin, every app owner or every end user had a credential exposed. Affected developers need the vendor notice and their own record of values stored in the editor.

Bubble also confirms direct targeting of individual apps from October 28 through October 30. Some access used platform issues that could reach an app's stored credentials or data even when the app was set up correctly. Other access took advantage of app settings, including privacy rules, that allowed access. Bubble says it contacted owners when it believes private data or credentials were reached. That distinction is central: platform remediation and app-configuration remediation solve different parts of the incident.

Bubble says its review has not shown that the attacker's internal-system access was used to read the application databases or data and files inside hosted apps. It says the outside firm's preliminary work is consistent with that conclusion. Later, on October 30 and 31, the attacker used credentials obtained earlier to reach an internal service, read internal configuration containing other credentials and try to sign in to Bubble accounts. Bubble says those sign-in attempts returned no data.

Those statements are important, but they are not a claim that no app data was accessed. The same RCA says the attacker did access data or stored credentials in some individual apps, through both platform-level issues and app settings. The correct interpretation is therefore scoped: Bubble has not found database-wide access through the internal systems it reviewed, while app-specific access is confirmed for customers it is contacting.

The company is still verifying whether relevant activity occurred before October 26 and the full set of accessed material. It says related probing of public-facing platform components may go back to mid-October and describes the attacks as still active. Owners should record unresolved questions and update their assessment when the promised final report arrives. A preliminary absence of evidence should not be converted into a final guarantee.

Bubble's API Connector routes calls through its servers. Marking a parameter private prevents it from appearing in client-side app code and keeps it inaccessible to ordinary end users. That is the correct control for a server-side API secret, but it necessarily places the value inside Bubble's server-side trust boundary. The incident shows why client privacy and provider isolation are related but different properties.

Plugin developers have another trust path. Development credentials saved in a plugin editor may be useful for testing, but they can authorize third-party APIs, cloud resources, payment systems or data stores. Store the least-privileged non-production value possible, give it an expiry where supported and keep an inventory of where it was entered. If Bubble identified that editor as affected, revoke the old value at the API provider, issue a new scoped value and inspect provider logs for use during and after the stated window.

Do not merely replace text in the Bubble editor. Revocation must occur at the authority that validates the credential. Then update every legitimate consumer, test the new connection and search for use of the retired value. If the old credential could create other credentials or access customer data, expand the investigation to those downstream systems. If Bubble did not contact the app and no sensitive value was stored in the implicated location, mass rotation can create outages without addressing a confirmed path.

Bubble recommends running the security dashboard on every app. Treat the result as a starting point, not proof that all business authorization is correct. Review each data type's privacy rules, field visibility, search permission, attached-file access and API modification rights. Bubble's documentation notes that multiple matching rules are additive: if any applicable rule grants access, the object is accessible. Test anonymous users, normal users, cross-tenant users and administrative roles against real data shapes.

Inspect every API Connector call. Confirm authentication values and sensitive headers, body fields and URL parameters are marked private, and remove initialization values that do not need to remain. Bubble's dashboard specifically flags potentially sensitive parameters that are not private. A field that must stay dynamic should not retain a real secret as its sample value. Review logs at the external API because Bubble-side configuration alone cannot show whether an exposed value was exercised.

Set the app editor to Private app unless public viewing is an intentional, reviewed requirement. Bubble warns that public editor access can expose settings, workflows and stored keys. Remove unused collaborators, protect development and live environments with unique credentials, and check file-upload privacy alongside database rules. These controls do not repair the vendor's platform flaws, but they close the app-level paths the attacker also tested.

Preserve Bubble's direct email or support message through a known account, including the app identifier, time range, affected feature, data type, credential location and requested action. Record whether the owner was notified for a platform-control bypass, an app configuration, plugin-editor data or some combination. Do not rely on a forwarded screenshot or an unexpected message asking for credentials. Use the Bubble account or established support channel to verify the case.

Map every potentially exposed value to its issuer, privilege, environment, consumers and logs. Prioritize production secrets, keys with write or administrative access, payment or messaging credentials, database tokens and values that can mint further authority. Revoke and replace in dependency order, then validate background workflows, scheduled jobs, webhooks and integrations. Keep the old identifier in the incident record so later log matches remain attributable.

Review Bubble app logs, external API audit trails, identity-provider events, data exports, collaborator changes, plugin updates, privacy-rule changes and unusual user access. Bubble's service interruptions on October 26 and October 30 can create operational noise, so distinguish failed jobs and retries from unauthorized access. Preserve timestamps and time zones, and document why each event is considered normal, incident-related or unresolved.

Bubble says it closed the initial path, moved applications to newer infrastructure, rotated credentials used by the attacker, narrowed internal-system access and fixed the platform issues involved. It also rebuilt monitoring while attacks continued. Customers cannot independently verify all of those controls from an app dashboard. The final report should clarify the vulnerable component, affected infrastructure, access duration, credential graph, platform-feature paths and evidence supporting the database-wide negative finding.

App owners still control data models, privacy rules, editor rights, connector configuration, collaborator access and third-party credentials. The incident does not make those controls optional, nor does a clean dashboard prove the provider layer is safe. A useful shared-responsibility model identifies the owner, evidence and response procedure for each layer instead of assigning the whole incident to either platform or customer configuration.

NIST's incident-response guidance emphasizes preparation, evidence, communication, recovery and improvement. Apply that approach without outrunning the facts. Track direct notifications and platform updates, rotate only implicated authority, verify downstream use, repair app rules and retain open questions until the outside review is complete. The goal is a defensible exposure map for each app, not a blanket claim that the platform is either wholly compromised or wholly cleared.