UK charity CRM provider Beacon has confirmed that a copy of the database holding all of its customer data, attachment files included, was made and "likely downloaded in a readable format by the threat actor," according to a company update attributed to CTO David Simpson and reported by The Register on 13 August. Beacon's root cause analysis names a compromised AWS access key, "potentially exposed in public JavaScript build artifacts," as the leading suspect. Customer-count figures differ across coverage: The Register reports Beacon has "more than 1,500 customers," SecurityWeek and the BBC report the incident affects "more than 1,000 charities and organisations" (a figure several affected charities themselves cited), and Infosecurity Magazine headlines "1500+ UK charities," while Third Sector notes Beacon's own LinkedIn profile claims support for more than 1,500 charities. Beacon has not established how many of those customers actually had data taken.
What Happened
Malicious activity began in the early hours of 27 July 2026, matching Beacon's initial estimate of the incident timeline. The Register reports the malicious activity lasted roughly an hour; SecurityWeek reports Beacon observed the earliest malicious activity on 27 July with data transfer likely occurring across 27 and 28 July.
Beacon's evidence for exfiltration is indirect but consistent. The company analysed AWS Cost & Usage reports across May to July 2026 and found "a significant increase in data transfer on 27-28 July 2026," which Simpson said "correlates with the malicious activity" and "supports an assessment that substantial downloads occurred." SecurityWeek quotes Beacon conceding that "specific objects, exact destination of the downloads, and definitive attribution of which objects were accessed cannot be determined from available logs," but that comparing transfer volume against total data stored led to an assessment that "the threat actor exported all data contained within the database."
The public account has firmed up over roughly ten days, and it is worth noting where it shifted. In Beacon's earliest customer communications, reported by Third Sector on 4 August, head of commercial Charlie Gregson said the company's understanding was that "compromised log-in credentials were used to gain access," that copies of database backups were made, and that exfiltration "hasn't yet been confirmed" though the evidence suggested the copies were "likely downloaded." By 5 August, The Register reported Beacon telling customers to assume everything they stored had been downloaded. By 13 August, the language had moved from database backups and unconfirmed exfiltration to a confirmed copy of the full customer database, likely downloaded in readable form, with a specific AWS access key as the suspected entry point. These accounts are better read as an investigation maturing than as a contradiction, but defenders reading only the first statement got a materially softer picture than the one that now stands.
Discovery and notification dates also vary by source. Third Sector reports Beacon became aware of the breach on Wednesday 29 July; The Register cites one affected charity saying the same. Lincoln Cathedral told the BBC that Beacon informed them on Monday 3 August that it had "identified unauthorised access to its systems."
What Was Taken
Beacon's guidance is blunt: anyone with a paid account or free trial created before 27 July should assume all data stored in it, including attachment files, was downloaded. The company told customers it is "highly unlikely" it will ever establish granular detail about which specific records left, and its FAQ instead directs customers to assess exposure by reviewing what they themselves put into their CRM instance.
Because Beacon is a fundraising and supporter-management platform, the practical exposure is donor and beneficiary data. Affected organisations describe names, postal addresses, email addresses, phone numbers, and donation details. Lincoln Cathedral and Magna Vitae, which operates leisure centres in Lincolnshire, told the BBC they stored names, addresses, emails, and phone numbers but not payment or bank account details. SecurityWeek reports several charities explicitly stating that no bank account numbers, sort codes, card numbers, or card security details were exposed because they do not store them.
The sensitivity ceiling is higher than contact details alone. Yorkshire's Brain Tumour Charity told the BBC on 12 August that the unauthorised third party "exported all the data, including names, addresses, as well as information about donations and health." Sheffield Hospitals Charity was also affected. Health-adjacent inference from a brain tumour charity's supporter list is a special category exposure under UK GDPR whether or not a clinical field was involved.
The encryption question is the pivot of this incident. Simpson said Beacon's AWS data was encrypted at rest, but that the compromised access key may have allowed the attacker to retrieve it in readable form. Beacon's earlier 5 August wording was that although customer data is encrypted, "it is possible that the unauthorized third party responsible for this incident was able to decrypt it," and customers should assume the copied information was readable.
No total count of affected individuals has been published. The BBC states plainly that the number of people affected is unclear.
Why It Matters
This is a single-supplier compromise that lands simultaneously on somewhere between one and one and a half thousand organisations, most of them small charities with no security team. The blast radius is not Beacon's balance sheet; it is a thousand separate notification obligations, a thousand supporter bases to warn, and a regulator queue.
The Charity Commission published guidance on 7 August confirming it is monitoring the situation and in contact with the ICO as lead regulator, that a number of affected charities have already filed serious incident reports, and that response times will be longer than usual "due to the volume of such reports expected on this matter." That is a regulator pre-announcing that it is saturated by one vendor's failure.
The encryption-at-rest detail deserves attention from anyone writing a vendor questionnaire. "Data is encrypted at rest" is one of the most commonly claimed and least useful assurances in third-party risk assessment. When the stolen credential is an AWS access key with rights over the data, the storage-layer encryption is transparent to the attacker and provides no barrier at all. Beacon's own framing acknowledges this. Treat at-rest encryption claims as answering only the question of physical media theft unless the vendor can describe key custody separate from the compute identity.
Finally, the quiet part: as of the latest reporting, no known cybercrime group has claimed the intrusion, Beacon says there is no evidence the data has been shared on the dark web, and there has been no ransom demand. That is not reassurance. A full donor database taken quietly, with no extortion attempt and no leak-site posting, is more consistent with data being retained for resale or fraud than with a smash-and-grab. Third Sector reports Beacon is conducting online monitoring; charities should assume the exposure window is open-ended.
The Attack Technique
The suspected root cause is credential exposure in the build pipeline rather than an exploit against Beacon's application. Per Beacon's analysis as reported by The Register, SecurityWeek and Infosecurity Magazine, the threat actor obtained data from an AWS environment using a compromised AWS access key that may have been exposed in publicly available JavaScript build artifacts. Note the hedge in Beacon's own phrasing, "potentially exposed" and "may have been": this is Beacon's leading assessment, not a proven chain.
If that assessment holds, the mechanism is mundane and extremely common. A long-lived IAM access key gets pulled into a frontend bundle through an environment variable, a config object, or a sourcemap, and the resulting artifact is served publicly. Anyone scraping JavaScript from the open web finds it. As The Register observed, if the key really was exposed in public build artifacts, it raises the question of why Beacon's development pipeline and code review controls did not catch it before publication.
The post-access behaviour is equally unglamorous: authenticate with valid credentials, enumerate storage, and bulk transfer. There was no service disruption at any point. Beacon told the BBC it "hasn't experienced any service interruption as a result of this incident and our customers continue to access our platform and services as normal." That is precisely why the intrusion was detected after the fact through billing telemetry rather than in real time.
Beacon's containment steps, across its statements to Third Sector and The Register, included engaging external cyber-security experts, a forensic investigation, working with law enforcement and regulators, online monitoring, resetting every user's password, and imposing stronger password requirements. Yorkshire's Brain Tumour Charity said Beacon "has identified and addressed the vulnerability believed to have caused the incident and has introduced additional security measures."
What Organizations Should Do
1. Scan your own public build output for credentials today. Pull your production JavaScript bundles, sourcemaps, and any published artifacts and grep them for AKIA prefixes, ASIA session keys, bearer tokens, and connection strings. Do this against what is actually served in production, not against your repository, because the leak here was in the build output. Add automated secret scanning as a blocking gate in CI, not an advisory warning.
2. Kill long-lived IAM access keys. Replace static access keys with short-lived credentials from IAM Roles Anywhere, OIDC federation for CI, or instance and task roles. Where a static key is unavoidable, scope it to the minimum resource set, rotate it on a schedule, and attach condition keys restricting source IP or VPC endpoint so a stolen key is useless off-network.
3. Turn billing telemetry into a detection signal. Beacon found this by analysing AWS Cost & Usage reports months after the fact. Data egress spikes, NAT gateway charges, and S3 GET volumes are cheap, high-signal anomaly indicators. Build alerts on them now, and pair them with CloudTrail data events on your sensitive buckets so you have object-level logging when you need it. Beacon's inability to say which records left is a logging gap, not an inevitability.
4. Stop treating "encrypted at rest" as a control against credential theft. Move sensitive fields to application-layer or client-side encryption with keys held outside the compute identity that reads the data, and separate key custody from the role that has data access. If a single stolen key yields plaintext, at-rest encryption is compliance theatre.
5. Inventory what you actually put in your CRM. Beacon's own advice to customers is to assess exposure by reviewing what they stored. Most organisations will find fields nobody intended to keep: free-text notes with health or safeguarding detail, uploaded attachments, legacy imports. Purge what you do not need and set retention limits so the next vendor breach exposes less.
6. If you are a Beacon customer, work the regulatory clock. The Charity Commission directs trustees to file serious incident reports and to consider obligations to the ICO and to affected individuals. Beacon's own guidance is that a personal data breach should be reported to the ICO unless it is unlikely to result in a risk to individuals' rights and freedoms, which for a full donor database is a difficult argument to make. Warn supporters about targeted phishing referencing your organisation, Beacon, or their past donations, echoing the advice Yorkshire's Brain Tumour Charity sent its own supporters.
Sources: AWS key exposed in JavaScript may have lit way to Beacon's charity... | Over 1,000 Charities Hit by Beacon CRM Data Breach - SecurityWeek | UK charities count the cost of Beacon CRM cyberattack | Lincoln Cathedral and leisure centres affected by cyber attack - BB... | Yorkshire's Brain Tumour Charity latest victim of cyber breach - BB... | Exposed AWS Access Key Linked to Data Breach Affecting 1500+ UK Cha... | Guidance for charities affected by the Beacon cyber security incide... | Charities’ data ‘likely’ to have been downloaded in security breach...