In May 2023, the BBC’s HR department discovered that personal records belonging to current and former employees had been stolen. The records included names, dates of birth, national insurance numbers, home addresses, and salary information. Employees had done nothing wrong. Their passwords were fine. Their accounts hadn’t been phished. The breach had nothing to do with anything they controlled.
The BBC used a third-party payroll and HR data management service. That service used a file transfer tool called MOVEit. MOVEit had a vulnerability: a SQL injection flaw catalogued as CVE-2023-34362. A ransomware group called Clop had been quietly exploiting it before anyone knew the flaw existed. By the time MOVEit’s developer published a patch on May 31st, Clop had already exfiltrated data from hundreds of organizations.
The BBC was one of over 2,700 organizations eventually confirmed as affected. Shell, British Airways, the US Department of Energy, TIAA, and dozens of US state governments were on the same list. Total records exposed: an estimated 93 million. Most of those 93 million people had never heard of MOVEit.
This is the story behind most major data breaches. Not a hacker guessing your password. Not a company careless with your login credentials. A software vulnerability — code behaving unintentionally — exploited silently, your data gone, and you finding out months later.
What a vulnerability actually is
Software is written by humans, which means it contains mistakes. Some of those mistakes are just bugs — the app crashes, a button doesn’t work, a calculation is wrong. But some mistakes create a gap between what the software is supposed to do and what an attacker can make it do. That gap is a vulnerability.
The categories of vulnerability that appear most often in major breaches follow recognizable patterns.
SQL injection happens when software passes user input directly into a database query without checking it first. Say you type a username into a login form and the software constructs a query like SELECT * FROM users WHERE username = '[what you typed]'. An attacker can type something that breaks out of the intended query and runs their own commands against the database. The MOVEit flaw was exactly this. An attacker sends a crafted request to the web application. Instead of just fetching the file they asked for, the database executes their instructions — including copying data out.
Remote code execution (RCE) vulnerabilities let an attacker run arbitrary commands on a machine they have no legitimate access to. They send a specially crafted input, such as a message, a request, or a file, and the target system executes it. Log4Shell, which we’ll cover shortly, was this category. An attacker could send a log message containing a specific string. That caused any Java application using Log4j to fetch and execute code from a server they controlled.
Authentication bypass vulnerabilities let someone skip the login check entirely. The software is supposed to verify who you are before granting access. But a flaw in how it handles a particular request lets an attacker skip that step. They get in as if they’d authenticated, without any credentials at all.
Buffer overflow and memory corruption vulnerabilities are lower-level. Software allocates a fixed block of memory for some data. If an attacker sends more data than that block can hold, the excess spills into adjacent memory. That memory might contain executable code, security controls, or pointers the program uses to decide what to run next. With enough precision, an attacker can overwrite those locations with their own code.
The common thread runs through every category: the software behaves in ways its authors never intended. An attacker who understands that behavior can weaponize it.
CVEs and the gap between disclosure and patch
When a vulnerability is discovered and formally documented, it gets assigned a CVE number — Common Vulnerabilities and Exposures. The CVE system is a public catalog maintained by MITRE Corporation, sponsored by the US Department of Homeland Security. Each entry includes a description of the flaw and a severity score. CVE-2023-34362 is the MOVEit SQL injection. CVE-2021-44228 is Log4Shell. The number tells security teams and researchers what, specifically, they’re dealing with.
The catalog is public. That’s mostly a good thing — it allows defenders to identify and patch known problems. But it also means the catalog is readable by attackers.
Research from Palo Alto Networks’ Unit 42 found that the average time from CVE publication to exploitation in the wild is 12 days. The average time organizations take to patch a known vulnerability is 102 days. That 90-day window between “the flaw is published” and “organizations have patched it” is when most exploitation happens. Attackers scan for vulnerable systems as soon as a CVE is published. Organizations are still scheduling maintenance windows.
Zero-days are different. A zero-day vulnerability is one that the software vendor doesn’t know about yet — or has only just discovered. There is no patch because there has been zero days of opportunity to write one. The MOVEit breach was a zero-day attack: Clop exploited CVE-2023-34362 before MOVEit’s developer Progress Software had any knowledge of the flaw. The moment Progress published the patch, the vulnerability technically became a “known vulnerability,” but Clop had been exploiting it for weeks beforehand.
Zero-days require more skill and resources to discover and exploit. They’re valuable precisely because defenders have no warning. Nation-state intelligence agencies spend significant resources acquiring zero-days for espionage. Criminal groups occasionally find them too, or buy them. But zero-days are the minority of breaches. The majority of successful attacks exploit vulnerabilities that have been public for months — against organizations that simply hadn’t patched yet.
Log4Shell: when a library inside a library breaks everything
On December 9, 2021, a security researcher published proof-of-concept exploit code for a vulnerability in Log4j, a Java logging library. Within hours, active exploitation was observed in the wild. Within days, hundreds of millions of systems were known to be vulnerable.
Log4j is not software that end users install. It’s a library — a reusable piece of code that developers include in their own applications to handle logging. Logging is mundane: when something happens in a program, you write a record of it. Log4j handled that job for an enormous fraction of Java applications. Java runs inside banking systems, healthcare records platforms, Minecraft servers, enterprise software from Cisco, IBM, and VMware, and an incalculable number of internal business applications. CISA estimated that Log4Shell (CVE-2021-44228) affected approximately 3 billion devices.
The vulnerability worked like this: Log4j, in a misguided attempt to be helpful, would interpret special strings inside log messages and act on them. An attacker only had to get their string into a log. That might be as simple as putting it in a username field, a search query, a user-agent header, or a chat message. Log4j would then fetch code from a server the attacker specified and execute it. Completely automatically. No user interaction beyond generating the log entry.
The library was maintained by three volunteer developers working in their spare time. No commercial entity owned it. No security team reviewed it full-time. It was free, well-written for its purpose, and used everywhere. The volunteers responded as fast as anyone could have, pushing a patch within days. The problem was that the library was embedded inside so many other applications. Patching required each application vendor to update their software, then each organization to update their installations. Some organizations didn’t finish that process for months. Some haven’t finished it yet.
The supply chain problem: your data isn’t just at your bank
The BBC employees affected by the MOVEit breach hadn’t given MOVEit anything directly. Their data was at their employer, which used a payroll service, which used MOVEit. The vulnerability was three relationships away from the individuals whose data was taken.
IBM’s Cost of a Data Breach report consistently finds that roughly 60% of major breaches involve a third party. That means a vendor, supplier, contractor, or service provider. Your data doesn’t just sit with the company you gave it to. It flows downstream: to payment processors, cloud infrastructure providers, analytics companies, HR platforms, legal firms, marketing agencies. Each of those downstream entities has its own technology stack, its own patch cadence, and its own vulnerabilities.
You cannot audit your bank’s technology vendors. You cannot check whether your health insurer uses a third-party claims processor running an unpatched server. You cannot know which file transfer tool your mobile carrier’s billing contractor uses. This isn’t a failure of due diligence on your part. There is no mechanism for an individual to investigate this chain.
The implication is uncomfortable. You can make every good personal security decision: strong passwords, two-factor authentication, minimal data sharing. Even then, your information can still be exfiltrated through a system you’ve never interacted with, via a software flaw you couldn’t have known existed.
What attackers do after they’re inside
Getting into a system through a vulnerability is the entry point. What happens next determines how much data gets taken and whether anyone finds out.
After initial access, an attacker typically engages in lateral movement. They explore the network, escalate their privileges, and move from the entry point to the systems holding the most valuable data. A SQL injection in a web application might give access to the web server. From there, an attacker looks for internal network access, finds database servers, cloud storage buckets, backup systems, and authentication directories. The initial vulnerability is the door. Lateral movement is walking through the building.
Dwell time is the gap between when an attacker first gets in and when anyone detects them. Mandiant’s M-Trends report places the global median dwell time at around 16 days, but that median conceals a long tail. Some breaches go undetected for 200 or 300 days. During that time, the attacker can read, copy, and exfiltrate data at will. They can plant persistent backdoors so that even if discovered and removed, they can re-enter. They can watch communications, gather credentials for other systems, and understand exactly what data exists and where it lives.
Exfiltration is quiet. Attackers don’t announce when they’ve copied data. They transfer it gradually, often disguising the traffic as normal activity, sending it to infrastructure they control. By the time a company detects a breach, weeks or months of data has already left the network. The notification you receive — “we detected unauthorized access to our systems” — often describes an event that concluded before anyone knew it began.
What you can actually do
You cannot prevent a vendor you’ve never heard of from running unpatched software. You can significantly limit what someone can do with your data once they have it.
Use different passwords for different services. This is the most important thing on this list. When credentials leak in a breach, attackers test them against every valuable site they can target. This technique is called credential stuffing. Say your password from a breached fitness app is the same one you use for your email, your bank, and your airline account. That one breach effectively becomes all of them. A password manager removes the friction of maintaining distinct credentials everywhere.
Enable two-factor authentication on every account that supports it. Breached passwords are common. Breached passwords plus the code from your authenticator app are much rarer. An attacker with your username and password still hits a wall if they don’t have your second factor. Use an authenticator app rather than SMS where possible, because SIM-swap attacks can intercept text messages.
Freeze your credit. A credit freeze prevents new credit accounts from being opened in your name, even if someone has your full personal information. It’s free in most jurisdictions and takes minutes to do with each credit bureau. You can lift it temporarily when you genuinely need to apply for credit. Given how much personal data is already in circulation from historical breaches, a freeze limits what someone can actually do with it. Our credit freeze vs fraud alert guide covers the details.
Monitor for breach notifications. Services like Have I Been Pwned let you check whether your email address appears in known breach databases. KnytX Vigil is built to alert you when credentials tied to your email show up in newly discovered breach datasets. Vigil isn’t live yet; join the waitlist to turn it on at launch. A notification doesn’t undo the breach. But it tells you which passwords to change and which accounts to review before an attacker exploits them.
Minimize what you share. Data that was never collected cannot be breached. Services often ask for information they don’t need: your date of birth for a loyalty account, your phone number to read an article. Declining reduces your exposure. The less a company holds, the less can leave in a breach.
Know your rights under breach notification law. Under GDPR, organizations have 72 hours to report a breach to their supervisory authority once they become aware of it. US states have their own notification timelines — most require notification within 30 to 90 days of discovery. India’s DPDPA requires notification to the Data Protection Board and affected individuals within a timeframe to be specified by regulation. These laws exist because companies historically didn’t tell affected individuals at all. If you’re affected by a breach and the company notifies you late, that’s a violation you can report.
Watch for CVE advisories affecting services you use. Security researchers and vendors publish CVE notices when vulnerabilities are discovered. Tools and feeds exist that let you track CVEs affecting specific products. If you know your company’s payroll software just received a critical vulnerability disclosure, you can ask whether it’s been patched. You can also decide what data you want stored there while it isn’t.
The practical checklist
These steps don’t require technical expertise. They take an afternoon.
- Freeze your credit at each major bureau in your country (in the UK: Experian, Equifax, TransUnion; in the US: the same three plus ChexSystems; in India: CIBIL, Experian, Equifax, CRIF High Mark)
- Set up a password manager and change the passwords on your email, bank, and any financial account to unique, randomly generated strings
- Enable an authenticator app for your email and financial accounts — not SMS
- Enter your email address at Have I Been Pwned and review what’s already been breached
- Review what data you’ve shared with services you use infrequently; request deletion from ones you no longer use, under GDPR, DPDPA, CCPA, or the applicable law in your jurisdiction
- Check your email’s forwarding and recovery settings — these are what attackers modify immediately after taking over an account
- Enable breach monitoring alerts so you’re notified when new leaks appear with your credentials
- Decline unnecessary data collection when signing up for new services — date of birth, secondary phone number, and physical address are frequently asked for and frequently unnecessary
None of these steps prevent a vendor three relationships from you from running unpatched software. What they do is limit what an attacker can accomplish with whatever comes out.
The BBC’s employees couldn’t have prevented the MOVEit breach. But some of those 93 million people had credit freezes in place, unique passwords per service, and two-factor authentication on their accounts. They were substantially harder to harm, even after their data left the building.