Beacon CRM Breach: Never Put Cloud Credentials in Frontend Builds

Charity CRM provider Beacon says the probable root cause of its July 2026 breach was a compromised AWS access key that may have been exposed in public JavaScript build artifacts. Beacon's investigation found that valid cloud credentials were used to reach its AWS environment and that database backups, including attachment files, were probably downloaded in readable form. The company is telling customers to assume that all data stored in Beacon may have been involved.

The careful wording matters. Beacon describes the exposed build artifact as the probable root cause and says the available logs cannot identify every object that was accessed. What is confirmed is unauthorized access and the creation of database-backup copies; the full-data download is Beacon's current assessment based on the activity and transfer volume it observed.

What Beacon currently confirms

Beacon's incident page says the earliest malicious activity found so far began on July 27 at 01:20 UTC and lasted about 87 minutes. AWS cost-and-usage data showed a significant transfer increase on July 27 and 28. Beacon says this timing supports its assessment that substantial downloads occurred and that the attacker likely exported the entire database.

Encryption at rest did not prevent this exposure. According to Beacon, the actor used valid credentials, so AWS would have decrypted authorized reads before making the data available. That distinction is essential: storage encryption protects disks and objects from some forms of direct access; it does not neutralize a credential that the cloud service accepts as legitimate.

Beacon says it reset credentials for services and accounts integrated with AWS, remediated the likely vulnerability, deployed additional endpoint and cloud monitoring, and reported the incident to the UK Information Commissioner's Office. It says it has found no continuing unauthorized access and no indication that the data has been published or misused, but that is not proof that every copy has been recovered or erased.

What affected charities have disclosed

BBC reports from Sheffield and Shropshire show the type of information that individual Beacon customers are assessing. Depending on the charity, potentially affected fields may include names, postal and email addresses, phone numbers, donation or membership details, volunteering and event records, and Gift Aid information. The charities cited by the BBC said payment-card or bank details were not involved and that they had no evidence of misuse at publication.

Those statements should not be generalized into one universal data schema or victim count. Each organization decides what it stores in its CRM and must determine which people and fields were present. A notice from one charity is evidence about that charity's records, not every Beacon customer's database.

Why a secret in frontend JavaScript is already public

Browser code must be delivered to users before it can run. Minification, bundling, source-map removal and obscure variable names can make code less convenient to read, but they do not create a security boundary. A credential compiled into a JavaScript bundle is available to anyone who can download the asset—and old bundles may remain in caches, deployment archives, source maps or third-party scanners after the current release changes.

The safe architecture keeps long-lived cloud credentials on a trusted server-side path. Browser code should call a narrowly scoped application endpoint; the backend then authorizes the user and performs only the required operation. Where direct cloud access is necessary, issue short-lived, task-specific credentials after authentication rather than shipping a reusable key with the application.

Response steps for an exposed cloud access key

Disable or rotate the key immediately. Do this from a known-clean administrative path and revoke related sessions or temporary credentials where applicable.
Preserve evidence before cleanup. Retain CloudTrail, object-access, identity, network, build and deployment logs so the investigation can reconstruct use of the key.
Map the effective permissions. Check every role the identity could assume and every bucket, secret, backup, queue or database it could reach.
Search historical artifacts. Inspect deployed bundles, source maps, CI artifacts, package registries, CDN caches and release archives—not only the current source tree.
Rotate reachable secrets. If the key could read another credential store or backup containing tokens, treat those downstream values as potentially exposed.
Replace permanence with federation. Prefer workload identities, role assumption and short-lived credentials over access keys stored in developer or build environments.

What Beacon customers should do

Affected organizations should first inventory the data they actually placed in Beacon, including free-text notes and attachments. They should preserve the provider's notices, map the records to their own retention and notification obligations, and warn supporters about plausible phishing without directing them to disclose additional personal data.

Teams should also review integrations connected to the CRM. API tokens, webhook secrets, export credentials or shared administrative passwords may require rotation if they were stored in fields, attachments or accessible configuration. Rotation should happen through verified accounts on clean devices, with recipients confirmed separately from any email that references the breach.

Where Secretus fits—and where it does not

Secretus can help an authorized team hand off a replacement password, API token or recovery code without placing the plaintext in a persistent ticket, inbox or incident-room chat. A short-lived one-time link is useful after the recipient and destination have been verified; Team Split can support pre-planned multi-person release of a high-impact recovery value.

Secretus cannot make a frontend-embedded credential private, detect AWS misuse, clean a compromised developer endpoint or replace IAM, logging and key rotation. Do not put donor databases or breach exports into an ad-hoc secret-sharing flow. Its role is narrow: reduce durable copies during an approved credential handoff while the cloud and incident-response controls do the containment work.

What remains unknown

Beacon has not attributed the incident or identified a definitive destination for the downloads. Its public update says exact objects cannot be determined from available logs, and the JavaScript-artifact exposure remains the probable—not conclusively proven—root cause. The final number of affected people depends on the contents and retention practices of more than 1,000 customer organizations, so headline customer counts should not be mistaken for a verified number of individual records.