Beacon CRM Data Breach: AWS Key Exposes 1,000+ Organizations

A single forgotten access key – and the data of more than 1,000 organisations is potentially in the wrong hands. That's exactly what happened at British CRM provider Beacon. The attacker needed no sophisticated vulnerability, no zero-day exploit, but simply a valid AWS access key that was apparently publicly discoverable in the web application's program code. According to Beacon, this key presumably allowed the attacker to download the entire database including all attachments – in readable form. Anyone using Beacon or who has transmitted data to it must now act. And all other website operators should treat this case as a wake-up call.

What happened?

Beacon CRM is a British SaaS provider (Software-as-a-Service, i.e. software you rent and use in the browser instead of installing it yourself) for charities and non-profit organisations. On 4 August 2026, the company published a detailed update confirming a data breach. On 12 August 2026, Beacon then specified the suspected cause: a compromised AWS access key that may have been exposed in publicly accessible JavaScript build artefacts of the application.

The timing can be pinpointed fairly precisely. According to Beacon, the earliest observed malicious activity began on 27 July 2026 at 01:20:16 UTC and lasted around one hour and 27 minutes. AWS cost and usage reports showed a conspicuous spike in data transfer on 27 and 28 July – an indication of a large-scale download.

The crucial and uncomfortable message: which specific objects were downloaded and to where can no longer be reliably determined from the available logs. Beacon CTO David Simpson put it this way:

„Specific objects, exact destination of the downloads, and definitive attribution of which objects were accessed cannot be determined from available logs.“
(David Simpson, Chief Technology Officer, Beacon – beaconcrm.org/incident)

Because the transferred data volume was so high relative to the total storage, Beacon assesses an export of the entire database as likely. For affected customers, this means in case of doubt: all information stored in Beacon, including attachments, could have been exfiltrated.

The technical background – explained clearly

To understand why this incident is so dangerous, two things need to be kept separate. This was not a classic software vulnerability. There is no CVE number (the standardised identifier for publicly documented security flaws), no published exploit, and no affected software version that could simply be patched. Instead, this is a case of the misuse of valid cloud credentials.

The likely access path: an AWS Access Key – a digital key used to access Amazon cloud services – was apparently present in the application's JavaScript build artefacts. These are the browser files that every web application delivers to its visitors. The key point: anything that ends up in the browser is in principle retrievable by anyone. A secret in such a file is therefore no longer a secret.

Particularly insidious: so-called encryption at rest (the data is stored encrypted on the servers) was of no help at all in this case. Because the attacker used valid credentials. For an authorised access, AWS automatically delivers the data decrypted. Encryption protects against theft of the hard drive – not against an attacker with a valid key.

At least: according to its own statements, Beacon found neither persistence mechanisms (i.e. permanently installed backdoors) nor could it attribute the incident to a threat group. And as of 12 August, according to Beacon's online monitoring, there was no indication of publication or misuse of the data:

„There has been no indication from online monitoring that data associated with the incident has been published, disclosed or otherwise misused.“
(Beacon, Incident Update of 12 Aug 2026)

That's good news – but no all-clear. A lack of demonstrable misuse neither invalidates the possible data breach nor your own obligation to carry out a risk assessment.

Who is affected?

According to media reports, Beacon has more than 1,500 customers. The BBC initially reported more than 1,000 potentially affected organisations. A figure for affected individuals or records has not been published.

For German SMEs, the following applies: Simply operating a website does not make you affected. Specifically affected or potentially affected is anyone who used Beacon before the 27 July 2026 cut-off date or transmitted data to a Beacon instance. Publicly affected organisations named the following data categories, among others:

• Names of supporters and donors
• Email and postal addresses
• Phone numbers
• Details of donations, volunteering or events

Exactly which of your data could be affected depends entirely on your own data holdings in Beacon.

How to check whether you are affected

1. Check your supplier and processing register. Was there a Beacon account, a trial access, or a CRM/website integration on or before 27 July 2026 that transmitted personal data to Beacon? Without such usage, there is no specific Beacon exposure according to the available sources.
2. If Beacon was used: Treat all data stored at that time, including attachments, as potentially exported. Beacon cannot conclusively narrow down which objects were exfiltrated.
3. Determine the affected data holdings. Beacon recommends filtering the people list by a creation date before 28 July or drawing on your own backups from that time. Document data categories, number of people, special categories, minors, and information with potential for misuse.
4. Inventory all integrations. API keys, forms, webhooks, payment and marketing services – everything connected to Beacon.
5. Even without using Beacon: Check your own delivered JavaScript bundles, source code repositories (including history!), CI/CD variables, and collaboration tools for accidentally committed secrets. This assesses your own, similar risk – it does not prove Beacon exposure.

What you need to do now, concretely

Important note on the timeline: There is no CVE patch and no version update you would need to apply. Beacon states that it has fixed the suspected cause, reset all credentials of AWS-integrated services and accounts, and introduced EDR (Endpoint Detection and Response – security monitoring on endpoints, in this case SentinelOne) and cloud-native security. Your tasks as a customer:

1. Reset Beacon passwords immediately. Change the passwords of all Beacon users to long, unique values. Beacon explicitly calls for this.
2. Revoke old Beacon API keys and reissue them. Disconnect all connected services according to each provider's process and reconnect them with new keys. Beacon names, among others, Mailchimp, JustGiving, FundraiseUp, Dotdigital, SendGrid, MuchLoved, Enthuse, GoCardless and Zapier.
3. Start your data protection process. Create an incident log, determine the scope of data and affected individuals, review the data processing agreement, and involve your data protection officer and management.
4. Check reporting obligations. Controllers must in principle report to the supervisory authority within 72 hours of becoming aware, where there is a risk. Even where there is no reporting obligation, the incident must be documented.
5. Prepare notification of affected individuals. Where a high risk is likely, affected individuals must be informed without undue delay, clearly and comprehensibly.

For your own systems

Even if you've never used Beacon, the core technical lesson is valuable:

• No long-term credentials in client code. Never deliver AWS keys or other secrets in JavaScript bundles, repositories, or build logs.
• Disable and rotate exposed keys immediately – not just delete them from the code. A key that has once become public remains compromised, even if it disappears from the visible code.
• Temporary credentials instead of long-term ones. AWS explicitly recommends IAM roles with short-lived credentials: „Where possible, we recommend relying on temporary credentials instead of creating long-term credentials such as access keys.“ (AWS IAM Best Practices)
• MFA, least privilege and regular reviews. Multi-factor authentication, minimal privilege assignment, and the regular review of unneeded credentials are standard practice.
• Improve monitoring. Investigate CloudTrail access and cost/data-transfer anomalies, set up alerts for unusual data movements, and review public and cross-account access – for example with the IAM Access Analyzer.

How widespread the underlying problem is, is shown by the GitGuardian Report 2026: in 2025 alone, 28,649,024 new secrets were counted in public GitHub commits – up 34% year-on-year. Of the valid secrets found in 2022, 64% were still active four years later. GitGuardian puts it succinctly: „The problem isn't detection. It's remediation.“ So the problem is not detecting them, but cleaning them up consistently.

GDPR classification: what applies in Germany?

For German controllers who used Beacon for customer, donor, member, or prospect data, the incident is typically a processor case. Exactly who is the controller and who is the processor must be checked in the specific contract.

The legal situation at a glance:

• Art. 33(2) GDPR: The processor (here Beacon) must inform the controller without undue delay.
• Art. 33(1) GDPR: The controller reports the breach to the competent supervisory authority without undue delay and where feasible within 72 hours of becoming aware, where a risk is likely.
• Art. 34 GDPR: Where a high risk is likely, affected individuals must be notified without undue delay and clearly.
• Art. 33(5) GDPR: There is a documentation obligation in any case – even where no report is required.

Important: a mere claim that "the data was encrypted" is not sufficient here as an exemption. At the time of actual access, the data was readable. Your risk assessment must take into account the specific data categories, groups of affected individuals, and likely consequences. The Lower Saxony Data Protection Authority (LfD Niedersachsen) also points out that a preliminary report can meet the deadline – you may submit missing details later.

Whether an individual case is reportable therefore does not automatically follow from the mere use of Beacon, but from a documented risk assessment.

Liability risk

Art. 83(4) GDPR provides in principle for fines of up to EUR 10 million or 2% of the previous year's worldwide turnover for breaches of security obligations (Art. 32 falls under this) – whichever is higher. A relevant German example is the 1&1 case: the Federal Commissioner for Data Protection (BfDI) initially imposed EUR 9.55 million for inadequate access security; in 2020, the Bonn Regional Court confirmed the Art. 32 breach and set the fine at EUR 900,000. The case is not technically identical to Beacon, but it shows how seriously German authorities and courts take inadequate access controls.

The UK Charity Commission is also aware of the case and is in contact with the country's data protection authority, the ICO:

„Given the nature of this incident and the number of charities that may be affected, the Commission has been actively monitoring the situation and is in contact with the Information Commissioner’s Office (ICO).“
(UK Charity Commission)

A note on the chronology

There is a discrepancy in the sources that we're keeping transparent: Beacon's own incident guide dates the discovery to Wednesday, 29 July 2026. A BBC report of 5 August, by contrast, names Monday, 3 August, as the discovery date. According to Beacon, customers were informed from 3 August onwards.

Conclusion

The Beacon incident is a lesson in secret management and cloud security. No spectacular exploit, but a single key in the wrong place endangered the data of more than 1,000 organisations. For active Beacon customers before 27 July 2026, the risk is high: Beacon itself considers an export of all database contents likely, the data was retrieved in readable form using valid credentials, and the exact scope cannot be reconstructed. Names, contact and context data are ideal ingredients for targeted phishing and social engineering.

If you use Beacon: reset passwords now, rotate all API keys, and start your data protection process – the 72-hour deadline runs from the moment you become aware. If you don't use Beacon: take this case as an opportunity to search your own JavaScript bundles and code repositories for hidden secrets. Because as this case shows, a single forgotten key can become costly – legally and for the trust of your customers.