Beacon CRM breach: an AWS key shipped in a JS bundle

The Beacon CRM data breach did not start with a zero-day, a phishing campaign, or a nation-state. It started with an AWS access key sitting in publicly available JavaScript build artifacts. More than 1,000 UK charities are now working out what their supporters lost, and every studio that ships a front-end bundle should spend ten minutes today checking whether it has the same problem.

What actually happened

SecurityWeek reports that the root cause is believed to be a compromised AWS access key exposed in publicly available JavaScript build artifacts. Earliest malicious activity was observed on July 27, 2026, with the data likely transferred on July 27–28. Beacon discovered the intrusion on July 29, began notifying customers on August 3, and confirmed the incident publicly on August 6.

Two details from Beacon's own assessment are worth reading slowly.

First: the customer database backups were encrypted, but Beacon acknowledged the attackers could have decrypted them prior to exfiltration. Encryption at rest protects against a stolen disk. It does not protect against a valid credential to the account holding both the ciphertext and the means to read it.

Second: based on the volume transferred against the total stored, Beacon's assessment is that the threat actor exported everything in the database. Not a sample. Everything. Affected charities have reported names, phone numbers, email addresses, and postal addresses; they don't store bank account numbers, sort codes, or card details, so those weren't in scope. Beacon says it is not aware of the data being published, and no group has claimed it. Beacon reset all user passwords and tightened password requirements.

Why leaked build artifacts matter for your business

Your front end is a published document. Everything in a client bundle is public — the code, the source maps if you ship them, and any environment variable your bundler inlined because its name didn't start with the magic prefix that keeps it server-side. NEXT_PUBLIC_, VITE_, REACT_APP_: those prefixes are the whole safety mechanism, and one mislabeled variable in a CI config puts a live credential on your CDN. Grep your last production build for AKIA, for secret, for your own key patterns. Do it before you read the rest of this.

Long-lived static keys are the real defect. The exposure was the accident; the blast radius was a design choice. An IAM user with a permanent access key and broad S3 read is a skeleton key with no expiry. Short-lived credentials from an OIDC role, scoped to one bucket prefix, would have turned this into a much smaller story. If you can't rotate a key without a deploy, you won't rotate it.

"Encrypted at rest" is not a control against credential theft. It's a compliance checkbox that answers a different threat model. The question worth asking your vendors — and yourself — is: who can call GetObject on the backups, with what credential, and would you see it in the logs if they did? Beacon noted it couldn't determine from available logs exactly which objects were accessed. Enable S3 data events and object-level logging before you need them, not after.

And your vendor's incident is your incident. More than a thousand organizations did nothing wrong here and still had to notify their supporters. When you pick a system of record, you inherit its secret hygiene, its logging, and its disclosure timeline. Ask what happens to the backups. Ask who holds the keys. Small charities and small businesses ask this less often than enterprises do, and they carry the same regulatory duty when it goes wrong.

Sources: SecurityWeek, SC Media.