Arc Security Allows Access To Anyone's Browser

Arc Security’s browser was found to allow attackers to hijack other users’ browser customizations (“Arc boosts”) by exploiting how Arc uses Firebase for authentication and how boost data is stored and retrieved. The core issue centers on Firebase security rules and access control: boosts are stored with a “Creator ID,” and that identifier can be manipulated so that a victim’s browser ends up loading a boost created under a different account. If an attacker can obtain a victim’s Creator ID, they can update a boost document to point at that victim, effectively forcing the victim to receive attacker-controlled JavaScript and settings when the victim visits targeted sites.

The investigation begins with Arc requiring an account and using Firebase for authentication. While probing network behavior, the researcher notices that boost-related sharing and viewing doesn’t show up in expected proxy traffic, leading to deeper inspection of how Arc retrieves and applies boosts. The work leans on “Firestore” (Firebase’s database) and its security model, where developers rely on rules to control what queries clients can run. The researcher then uses a “Freda script” (JavaScript with Objective-C bindings) to intercept Objective-C calls and log Firestore queries, revealing that Arc boost retrieval is driven by Creator ID.

A proof-of-concept demonstrates that boosts can be created and then modified so that the Creator ID field points to another user. When the victim visits a site like google.com, the victim receives the attacker’s boost changes—despite the boost being created from the attacker’s account. The attack chain becomes complete once the attacker can learn the victim’s Creator ID. The transcript points to multiple plausible ways to obtain it: Arc user referral data (where referrals can expose user identifiers), Arc’s public boost-sharing surfaces (including boost snapshots), and Arc’s “Easel” feature (whiteboards that can be shared and viewed on the web, potentially leaking identifiers).

Because Arc boosts can contain arbitrary JavaScript and are applied based on Creator ID, the impact is more than cosmetic. The researcher frames this as full arbitrary cross-site scripting in privileged contexts, with potential escalation paths. There’s also mention that boosts may execute for other protocols or settings pages, even when boosts can’t be created directly in the client for those targets—expanding the blast radius.

Arc’s response is described as fast and structured. After initial encrypted contact and a proof-of-concept, details were disclosed and the issue was patched. A CVE was assigned, and a bug bounty payout followed—initially $2,000, later increased to $20,000 after further confirmation. Arc also published a write-up and outlined mitigations: adding client-side controls to disable boosts for users who don’t use them, auditing Firebase ACL rules internally, addressing privacy concerns raised during research, and moving off Firebase for new features and products. An external security audit and a broader bug bounty program were also mentioned as part of the remediation plan.