The Breach That Started With a Build Artifact
It started with a single mistake buried in JavaScript. A valid AWS access key was left exposed in public build artifacts — and that was all an attacker needed to walk straight into the CRM systems of roughly 1,500 UK charities.
Beacon, the software provider behind the platform, confirmed the finding in an incident update on August 12. The company admitted the key was likely exposed during routine software development. In other words, this wasn’t a sophisticated nation-state operation. It was a preventable slip-up with outsized consequences.
Once the attacker had the credentials, they didn’t need to break through layers of defense. They simply logged in and downloaded everything: the entire CRM database, including attachment files. Beacon’s assessment is blunt — the full customer base of charitable organizations was impacted.
What Kind of Data Was Taken?
The affected charities operate in some of the most sensitive corners of the sector. Healthcare. Victim support. Rape and sexual abuse services. The data held by these groups isn’t just names and emails — it’s the lifeblood of trust between a charity and its supporters.
Specifically, the breach exposed supporters’ names, email addresses, telephone numbers, and donation records. That combination is a gift for social engineering attacks. Armed with donation history, a scammer can craft a convincing phishing email referencing a past gift. It’s chillingly easy.
There’s some relief, though. Beacon says the CRM system did not hold sensitive patient information, payment card details, or bank account numbers. That limits the damage — but it doesn’t erase it.
Encryption Didn’t Save the Day
Here’s the uncomfortable part: the data was encrypted at rest in AWS. It should have been safe. But because the attacker used valid credentials, AWS decrypted the data on download. So the encryption was effectively a non-factor.
This is a critical lesson for any organization storing data in the cloud. Encryption at rest is a baseline, not a silver bullet. If an attacker has legitimate keys, they get the data in readable form. No exceptions.
Beacon’s own analysis of AWS Cost & Usage reports shows the malicious activity began on July 27 at 01:20:16 UTC and lasted about one hour and 27 minutes. That timing aligns with a sharp spike in data downloads on July 27–28. The attack was quick, targeted, and over before most people even noticed.
Charities Cleared, But Scams Loom
Beacon’s charity customers have all been advised to report the breach to the UK’s Information Commissioner’s Office (ICO). One of the confirmed victims, The Survivor’s Trust, already has. In a statement on August 13, the charity said the ICO reviewed its case and concluded the charity holds no responsibility for the breach.
That’s a small comfort. The charity, which provides specialist rape and sexual abuse support services, has urged supporters to stay alert to potential scams in the coming weeks. Expect phishing emails referencing your donations, your support, your history with the cause. That’s the playbook.
Other charities have gone public with their own disclosures: Shrewsbury and Telford Hospital Charity, the British Deaf Association, and Yorkshire’s Brain Tumour Charity. They join Sheffield Hospital Charity, Priscilla Bacon Hospice Charity, the Clock Tower Sanctuary, and Victim Support in admitting supporter data was compromised.
What Beacon Did Next
Beacon says it has not detected any attempts by the attacker to maintain persistence in its environment. That’s the one piece of good news. The attacker took the data and left — no backdoors, no lingering access.
The company has reset all credentials for services and accounts integrated with AWS to prevent repeat unauthorized access. It’s also monitoring for any signs the stolen data has been published or misused. So far, nothing has surfaced.
But the damage is done. For 1,500 charities, the trust equation has shifted. Supporters who gave their personal details now have to wonder: who’s got my information, and what will they do with it?
The Cloud Security Lesson No One Wants to Learn
This incident is a textbook example of a cloud misconfiguration leading to a data breach in the charity sector. It’s not about sophisticated malware or zero-day exploits. It’s about a developer accidentally leaving a key in a public file.
If you’re responsible for AWS security best practices, take note: credential scanning should be part of your CI/CD pipeline. Secrets should never live in build artifacts. And access keys should be rotated regularly, with least-privilege policies enforced.
Beacon’s customers are now left to deal with the aftermath — notifying supporters, managing reputational fallout, and hoping the ICO doesn’t come knocking with fines. The charities themselves were cleared of responsibility, but that doesn’t help the person whose donation history is now in the hands of a stranger.
One exposed key. 1,500 organizations. Countless individuals. That’s the cost of a single oversight.
