How Do Companies Prevent Data Breaches? Six Root Causes From Recent Disclosed Incidents, and the One Control That Would Have Addressed Each
The most reliable way to prevent a data breach is to find the ordinary mistake before an attacker does, and recent disclosed incidents show the mistakes are not exotic. Six recent disclosures, five from October and November 2026 and one from October 2025, show the cause was a plain failure each time: a system moved without a security review, an internal tool left on the internet, a key never revoked, a provider's session trusted too much, a secret saved in the wrong place, or a vendor's own build environment reached. This page lists them with the one control that would have addressed each. The accounts are the organizations' own or their reporters', and we have not verified them independently. Apiiro's is research on a product's settings file, not one organization's breach.
What the FBI counted
The FBI's 2025 Internet Crime Report lists personal data breach at 67,456 complaints and $1,314,923,988 in reported losses, against 64,882 complaints and $1,453,296,303 in 2024. That is about 4 percent more complaints and about 10 percent less in reported loss. These are complaints people filed, so they are a floor, and the percentages are our arithmetic.
Six root causes
1. A system moved and nobody reviewed its security. DigiCert reported that an internal archive moved off a VPN-restricted network on February 4, 2025, which exposed a self-registration endpoint built for other purposes. Accounts created through it, with no multi-factor sign-in, read archived data between June 27 and July 2, 2026. DigiCert's own report says the move was treated as an infrastructure change and not a security change, and that the system had no alerts for new accounts or unusual request volume. Control: a security sign-off on any network change, and alerts on new accounts and request volume.
2. An internal tool on the internet with a development credential and no limits. WorkOS said an AI agent run by a researcher pulled records in bulk from an internal sales tool that sat on the public internet, accepted a predictable development credential and had no rate limits. WorkOS noticed on October 30, five days after first access, and says the researcher deleted the data. Control: keep internal tools off the internet, never let development secrets reach production, and rate-limit every API that returns records.
3. A key committed once and never revoked. LiteLLM's root-cause analysis says an administrative key was committed to a public repository on May 27 and deleted three hours later, but never revoked. The attacker used it on October 10, 136 days later, which led to the poisoned 1.107.0 release on October 21. Control: treat any key that was ever in a commit as exposed, and revoke it at the issuer.
4. A provider's session that can move money. BleepingComputer reported on November 7 that attackers stole up to $133 million from Crédit Mutuel Arkéa by getting in through a service provider's platform and then using the bank's own account to send transfers. The bank says it can only validate the order of magnitude and has confirmed no amounts. Control: limit what any provider session can do, and require a second approval for outbound transfers above a threshold you choose.
5. A secret saved where it should not be. Apiiro, as reported by The Hacker News, found secrets in 1,122 of 104,185 public copies of a Claude Code settings file, holding 1,379 distinct secrets. The tool saves the whole approved command, password included, in a project file. Control: scan your repositories and agent settings files for secrets, and rotate before deleting. We published a free scanner, claude-settings-leak-check, that you can run with npx claude-settings-leak-check --root ~/code.
6. A vendor's own development environment. F5 told the SEC that a nation-state actor had long-term access to its BIG-IP development environment, took files including part of the source code, and that it learned of the access on August 9, 2025 and disclosed on October 15, 67 days later. CISA ordered federal agencies to inventory their F5 devices, check that management interfaces were not reachable from the internet, and update. Control: know which vendor products you run, keep management interfaces off the internet, and patch quickly when a vendor discloses.
What these have in common
None of the six needed a clever exploit. Each was a place where something was reachable, trusted or left valid longer than it should have been, and in at least three, nothing was counting what was happening. DigiCert had no alert for new accounts, WorkOS had no rate limit, and LiteLLM's key sat valid for four and a half months.
What to do this week
List your internal tools and ask which are reachable from the internet.
Search your repositories, including history, for keys and revoke any that were ever committed.
Add an alert for new accounts on systems that hold customer data.
Put a second approver on outbound payments initiated through a provider.
Know your vendors' products on your network, and check their management interfaces.
Indicators
None. This is an explainer drawing on incidents we covered separately, so we added nothing to the feed.
Limits
The six accounts are the organizations' own or their reporters', and we verified none independently. The FBI figures are complaints people filed. The controls are our suggestions. Six cases are a sample, not a count of all breaches, so they show common causes and not how often each occurs.
Five percent of this is wrong somewhere. It always is. A follow-up from any of the six could change a date or a detail.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments