5 Famous Security Breaches That Keep Happening (and What AppSec Teams Can Learn)

When you look at the biggest cybersecurity breaches of the past decade, one thing becomes clear: the same issues keep repeating.

Insecure code, outdated dependencies, exposed secrets, misconfigured infrastructure, and unprotected sensitive data have all been exploited again and again — often with devastating consequences.

Despite billions invested in security tools, these root causes remain the Achilles’ heel of modern software. Below are five of the most well-known breaches, what went wrong, and what organizations can learn to avoid becoming the next headline.

1. Insecure Code Patterns – Microsoft (May 2021)

The issue: Insecure coding practices, such as input validation flaws or unsafe object deserialization, introduce vulnerabilities that attackers can directly exploit.

The breach: In May 2021, Microsoft disclosed that attackers exploited a flaw in its Exchange Server software. The vulnerability (CVE-2021-26855) was part of a chain of insecure code patterns that enabled attackers to perform server-side request forgery (SSRF). This allowed them to gain remote access to email accounts and install web shells.

• Impact: Over 60,000 organizations worldwide were affected, including government agencies, healthcare providers, and small businesses. Sensitive emails were stolen, and persistent backdoors were planted.
• Why it happened: The vulnerable code path had been present for years and was only identified once attackers began exploiting it at scale.

More recent case: In 2023, Atlassian’s Confluence Data Center and Server suffered a critical injection vulnerability (CVE-2023-22515). Attackers exploited a similar insecure coding flaw to gain admin privileges and exfiltrate data.

Challenge: Even well-resourced engineering teams struggle to spot subtle insecure patterns across millions of lines of code. Manual code review is not enough, and automated scans often drown teams in noise.

Why it matters: These flaws are “by design” — meaning that once they’re in production, attackers don’t need sophisticated tools to exploit them. The longer they remain, the higher the risk of mass exploitation.

2. Vulnerable Dependencies – Equifax (2017)

The issue: Applications often rely on third-party libraries. If those libraries contain vulnerabilities, every system using them is exposed.

The breach: In 2017, Equifax suffered one of the most infamous breaches in history when attackers exploited a known vulnerability in the Apache Struts framework (CVE-2017-5638). The patch had been available for months, but was not applied.

• Impact: Sensitive data of 147 million people was stolen, including Social Security numbers, birth dates, and addresses.
• Consequences: Equifax paid $700 million in fines and settlements, not to mention irreparable brand damage.

More recent case: In late 2021, the Log4j (“Log4Shell”) vulnerability (CVE-2021-44228) shook the software world. Millions of systems worldwide used Log4j, and attackers immediately weaponized it for remote code execution. Organizations spent months auditing and patching their software.

Challenge: Modern applications depend on thousands of open-source components. Tracking, prioritizing, and patching vulnerabilities across this ecosystem is complex and time-sensitive.

Why it matters: Attackers are quick to weaponize public CVEs. A single overlooked dependency can compromise an entire organization.

3. Exposed Secrets – Uber (2016)

The issue: Hardcoded credentials or exposed API keys in repositories give attackers direct access to sensitive systems.

The breach: In 2016, attackers found AWS credentials in a private GitHub repository used by Uber developers. They used the keys to access Uber’s AWS environment and stole personal information of 57 million customers and drivers. Uber paid attackers $100,000 in an attempt to cover up the breach, which later came to light.

• Impact: Loss of customer trust, legal battles, and lasting reputational harm.
• Why it happened: Developers had embedded credentials directly in source code instead of using secure vaulting mechanisms.

More recent case: In 2022, Toyota disclosed that an access key to a database storing customer information in Japan had been exposed publicly on GitHub for five years. Around 300,000 records were at risk.

Challenge: Secrets sprawl is real. Keys and tokens often end up hardcoded, logged, or stored in insecure places. Detecting and rotating them consistently is a major operational hurdle.

Why it matters: One exposed secret is often enough for an attacker to pivot and gain control of entire systems.

4. Misconfigurations – Capital One (July 2019)

The issue: Misconfigured cloud services or infrastructure leave backdoors open to attackers.

The breach: In July 2019, Capital One revealed that a misconfigured AWS S3 bucket allowed a former AWS employee to exploit a server-side request forgery (SSRF) vulnerability. The attacker accessed sensitive data stored in the cloud.

• Impact: Data of 100 million customers in the U.S. and Canada was stolen, including credit card applications and bank account numbers.
• Consequences: Capital One faced $80 million in fines and lasting reputational fallout.

More recent case: In 2023, researchers discovered misconfigured Microsoft Azure Blob Storage instances that exposed sensitive business data from multiple companies. While not always maliciously exploited, such exposures highlight the persistence of the problem.

Challenge: Cloud environments are complex and dynamic. Simple misconfigurations can remain unnoticed until exploited. Traditional perimeter security does not protect against this.

Why it matters: Misconfigurations are consistently among the top causes of breaches in cloud-native applications. They are both common and preventable.

5. Sensitive Data Exposure – Facebook (April 2019)

The issue: Storing sensitive data in plaintext or failing to enforce proper encryption exposes organizations to large-scale leaks.

The breach: In 2019, Facebook admitted that it had stored hundreds of millions of user passwords in plaintext. While no external exploitation was confirmed, the fact that employees had unnecessary access created significant risk.

• Impact: Up to 600 million users were affected, and the disclosure further eroded trust in Facebook’s handling of user data.

More recent case: In 2022, Twitter disclosed that a bug exposed personal data of 5.4 million users, including phone numbers and email addresses, which were later sold online.

Challenge: Sensitive data needs consistent encryption, tokenization, and access control, but implementing these protections at scale is complex.

Why it matters: Once data is exposed, it cannot be taken back. Regulatory fines (like under GDPR) and customer trust damage are inevitable.

Key Lessons from These Breaches

1. Insecure coding flaws persist for years if not proactively detected.
2. Vulnerable dependencies spread risk across the entire software supply chain.
3. Exposed secrets act as direct entry points for attackers.
4. Misconfigurations in cloud services remain one of the most common failure points.
5. Sensitive data exposure damages trust and is hard to remediate once leaked.

These are not new problems — yet they keep causing new breaches.

Conclusion: How Glev Helps Stop These Breaches from Repeating

The stories above show a frustrating pattern: despite knowing these risks, organizations continue to fall victim because AppSec challenges are systemic.

Traditional tools overwhelm teams with alerts, but rarely help them fix issues in context.

This is where Glev changes the game:

• Contextual triage: Glev analyzes vulnerabilities in the context of your codebase and environment, surfacing only what truly matters.
• Smart remediation: Instead of just flagging problems, Glev generates actionable fixes adapted to your actual code.
• Shift everywhere: Security is embedded across the SDLC, from code to dependencies to infrastructure.
• Developer-first approach: Glev integrates directly in developer workflows, reducing friction and improving adoption.

Breaches like Equifax, Capital One, or Log4j don’t need to keep happening. By equipping teams with contextual, developer-friendly AppSec, Glev helps organizations build software that is secure by default — before attackers can strike.