OWASP top 10 vulnerabilities just got a major overhaul. The 2025 edition dropped in January 2026, and if you’re still referencing the 2021 list in 2026, you’re working with dangerously outdated intel.
Two entirely new categories. One consolidation. Rankings reshuffled. And the data behind it? Over 175,000 CVE records and 589 Common Weakness Enumerations across 248 categories. This isn’t a minor update. It’s a fundamental shift in how we think about application security.
Most “explainer” articles you’ll find are either copy-pasted from OWASP’s own documentation or written by someone who’s never actually exploited these vulnerabilities in a real engagement. Nobody’s breaking down what these actually look like in the wild, why they moved in the rankings, and what you should actually do about them.
So I did.
Table of Contents
- What Changed in the 2026 OWASP Update
- A01: Broken Access Control
- A02: Security Misconfiguration
- A03: Software Supply Chain Failures (NEW)
- A04: Cryptographic Failures
- A05: Injection
- A06: Insecure Design
- A07: Authentication Failures
- A08: Software and Data Integrity Failures
- A09: Security Logging and Alerting Failures
- A10: Mishandling of Exceptional Conditions (NEW)
- OWASP Top 10 Vulnerabilities: 2021 vs. 2025/2026 Comparison
- What This Means For Your Security Program
- FAQ
What Changed in the 2026 OWASP Update
Before we dig into each vulnerability, let’s be real about what actually shifted. This isn’t just shuffling deck chairs.
Two new categories entered the list:
A03: Software Supply Chain Failures expanded from the old “Vulnerable and Outdated Components” to cover the entire dependency ecosystem. Build systems, distribution infrastructure, compromised maintainers, malicious packages. 50% of community survey respondents ranked this their number one concern. Despite having the fewest occurrences in testing data, it carries the highest average exploit and impact scores from CVEs. Translation: it doesn’t happen often, but when it does, it’s devastating.
A10: Mishandling of Exceptional Conditions is brand new. Poor error handling, failing open, verbose error messages leaking secrets, systems that crash unpredictably. 50% of OWASP survey respondents ranked this their top emerging concern. It covers 24 CWEs that were previously scattered across “code quality” issues.
One category got absorbed: Server-Side Request Forgery (SSRF) was consolidated into A01: Broken Access Control. Makes sense. SSRF is fundamentally an access control problem.
Major ranking shifts: Security Misconfiguration surged from #5 to #2. Cryptographic Failures dropped from #2 to #4. Injection fell from #3 to #5. Insecure Design slid from #4 to #6.
A01: Broken Access Control
Still #1. Still the most exploited category. Still the one most developers get wrong.
Broken access control is what happens when users can do things they shouldn’t be allowed to do. Access resources they shouldn’t see. Perform actions beyond their permissions. It sounds simple. In practice, authorization logic is one of the hardest things to get right across complex applications.
What it looks like in the wild:
A regular user changes /api/users/123/profile to /api/users/456/profile and can see another user’s data. That’s an Insecure Direct Object Reference (IDOR). Or an attacker manipulates a JWT token to escalate from “viewer” to “admin” because the app trusts the role claim without server-side verification.
New in the 2026 update: SSRF is now part of this category. An attacker tricks your server into making requests to internal services, cloud metadata endpoints, or other systems it shouldn’t access. Classic example: hitting http://169.254.169.254 on AWS to steal IAM credentials from the metadata service.
How to fix it:
Deny by default. Every endpoint, every resource, every action should require explicit authorization checks. Don’t rely on hiding URLs or client-side controls. Implement server-side access control on every request. Use automated testing to verify that role A can’t access role B’s resources. And log every access control failure because those logs are your early warning system.
A02: Security Misconfiguration
Jumped from #5 to #2. Every single tested application showed some form of misconfiguration. Let that sink in. 100% failure rate in testing.
This category covers the boring stuff that nobody wants to deal with. Default credentials left active. Unnecessary services enabled. Verbose error messages showing stack traces. Missing security headers. Overly permissive cloud storage buckets. Sample applications not removed from production servers.
Why it jumped so dramatically:
Modern applications are insanely configurable. Kubernetes, cloud platforms, microservices, API gateways, CDNs. Each layer adds configuration surface area. Each configuration decision is a potential security hole. The explosion of cloud-native architectures means there are simply more things to misconfigure than ever before.
Real-world example:
An S3 bucket set to public access because the developer needed it accessible during testing and forgot to lock it down. Happens constantly. Capital One’s massive breach in 2019? WAF misconfiguration combined with overly permissive IAM role. Misconfigurations aren’t exotic. They’re mundane. That’s what makes them dangerous.
How to fix it:
Automate your hardening. Use infrastructure-as-code and scan your configurations before deployment. Implement security headers (CSP, HSTS, X-Content-Type-Options) as baseline. Remove all default accounts, sample apps, and unnecessary features. Run configuration audits regularly, not annually. Use tools like ScoutSuite, Prowler, or cloud-native security posture management.
A03: Software Supply Chain Failures (NEW)
This is the scariest new entry on the OWASP top 10 vulnerabilities list.
It expanded from the old “Vulnerable and Outdated Components” into something much broader. We’re not just talking about using a library with a known CVE anymore. We’re talking about compromised maintainers injecting malware into popular packages. Tampered build pipelines. Poisoned distribution infrastructure. Malicious packages with typosquatted names.
Why it matters:
Despite having the fewest occurrences in testing data, this category has the highest average exploit and impact scores from CVEs. When supply chain attacks hit, they hit hard. SolarWinds. Log4Shell. The npm event-stream incident. The XZ Utils backdoor in 2024. These aren’t theoretical.
OWASP now explicitly calls out malware in software ecosystems as a leading threat. Compromised dependencies can move through CI systems, containers, and cloud environments in hours without triggering traditional scanners.
How to fix it:
Maintain a Software Bill of Materials (SBOM) for every application. Pin dependency versions and verify checksums. Use tools like Dependabot, Snyk, or Socket.dev to monitor for malicious packages. Audit your build pipeline for integrity. Don’t blindly trust transitive dependencies. And if you’re not reviewing what your dependencies pull in, you’re trusting thousands of strangers with your production environment.
A04: Cryptographic Failures
Dropped from #2 to #4. Not because crypto got easier. Because other risks got worse.
This is what used to be called “Sensitive Data Exposure.” OWASP renamed it to focus on the root cause (bad crypto) rather than the symptom (leaked data). On average, 3.80% of applications have one or more of the 32 CWEs in this category.
What it looks like:
Transmitting data over HTTP instead of HTTPS. Using deprecated algorithms like MD5 or SHA-1 for password hashing. Storing encryption keys alongside the encrypted data. Hardcoded API keys in source code. Using ECB mode for block ciphers (the penguin problem, if you know, you know). Weak or missing TLS configurations.
The one that gets everyone:
Insufficient randomness in token generation. If your password reset tokens are predictable, an attacker can generate valid tokens and take over any account. I’ve seen this in production applications from companies that should absolutely know better.
How to fix it:
Use TLS 1.2+ everywhere. Hash passwords with bcrypt, scrypt, or Argon2 (never MD5 or SHA-1). Don’t roll your own crypto. Use well-established libraries. Classify your data and apply encryption appropriate to sensitivity level. Rotate keys regularly. And audit your TLS configuration with tools like testssl.sh or SSLLabs.
A05: Injection
Dropped from #3 to #5. Still dangerous. Still everywhere. Still the one with the most CVEs associated with it.**
Injection covers everything from SQL injection to Cross-Site Scripting (XSS) to OS command injection to LDAP injection. The category has 38 CWEs, the most of any category on the OWASP top 10 vulnerabilities list.
The reality:
SQL injection has been a known attack for over 25 years. It should be extinct. It’s not. I find it on pentests regularly. Developers still concatenate user input into database queries. ORMs help but don’t eliminate the problem entirely, especially when developers use raw query methods for “performance.”
XSS is the high-frequency, lower-impact end of injection. SQLi is the lower-frequency, catastrophic-impact end. Both live in this category.
Classic example:
# DON'T DO THIS. EVER.
query = "SELECT * FROM users WHERE id = " + user_input
# DO THIS INSTEAD.
query = "SELECT * FROM users WHERE id = %s"
cursor.execute(query, (user_input,))How to fix it:
Use parameterized queries (prepared statements) for all database operations. No exceptions. Validate and sanitize all user input server-side. Use Content Security Policy headers to mitigate XSS. Employ SAST tools to catch injection patterns in code reviews. And test your APIs, not just your web forms. API injection is the new frontier.
A06: Insecure Design
Slid from #4 to #6. This category is different from implementation bugs. It’s about architectural and design flaws that no amount of perfect coding can fix.
The industry has made noticeable improvements here since 2021, with greater adoption of threat modeling and secure design principles. But design flaws are still endemic and they’re the most expensive to fix later.
Example:
A password reset flow that sends a reset link via email but doesn’t expire the link, doesn’t invalidate previous links, and uses a sequential token. No amount of input validation fixes a fundamentally broken design. Or a discount system that lets users stack unlimited promotions because nobody modeled abuse scenarios during design.
How to fix it:
Incorporate threat modeling into your SDLC. Use abuse case analysis alongside user stories. Define trust boundaries explicitly. Review business logic for manipulation (price tampering, discount stacking, role escalation). Secure design isn’t something you bolt on after development. It’s a mindset that starts before the first line of code.
A07: Authentication Failures
Holds at #7. Slight rename from “Identification and Authentication Failures” to better reflect the 36 CWEs in this category.
Weak authentication remains one of the primary enablers of account takeover, unauthorized access, and data breaches. Even with modern frameworks providing decent defaults, custom implementations and integration gaps create exploitable weaknesses.
What keeps showing up:
Weak password policies that accept “password123.” Missing MFA on admin accounts. Session tokens that don’t expire after logout. Credential stuffing attacks succeeding because there’s no rate limiting. Password reset flows that confirm whether an email exists (enabling account enumeration).
How to fix it:
Use proven authentication libraries. Don’t build your own auth. Enforce MFA for all privileged operations. Implement rate limiting and account lockout. Use secure session management (HttpOnly, Secure, SameSite cookies). And never confirm or deny the existence of accounts in error messages.
A08: Software and Data Integrity Failures
Holds at #8. This focuses on failures to verify the integrity of code, libraries, data, or configurations within your system.
Distinct from supply chain failures (A03), this is about what happens inside your own pipeline. Unsigned software updates. Deserialization of untrusted data. CI/CD pipelines without integrity checks. Loading unverified plugins.
The deserialization angle is particularly nasty. If your application deserializes data from untrusted sources without validation, an attacker can achieve remote code execution. Java’s ObjectInputStream has been behind some of the most devastating enterprise breaches.
How to fix it:
Verify digital signatures and checksums on all updates. Don’t deserialize untrusted data (or use safe serializers). Audit your CI/CD pipeline for integrity controls. Sign your artifacts. Verify plugin sources. Use Subresource Integrity (SRI) for external resources loaded in browsers.
A09: Security Logging and Alerting Failures
Holds at #9. Note the name change from “Security Logging and Monitoring Failures” to emphasize alerting and action, not just collecting logs.
Logs without alerts are useless. You can have terabytes of logs, but if nobody’s watching and nothing triggers when an attacker is brute-forcing your login endpoint at 3 AM, those logs are just expensive storage.
The gap:
Most organizations can tell you what happened after a breach. Very few can detect one in progress. The average breach lifecycle is 241 days (IBM, 2025). That’s eight months of an attacker living in your systems before you notice.
How to fix it:
Log all authentication events, access control failures, and input validation failures. Centralize logs in a SIEM. Create alerts for anomalous patterns (impossible travel, bulk data access, privilege escalation attempts). Test your alerting with regular purple team exercises. And make sure your incident response team actually responds to alerts, not just acknowledges them.
A10: Mishandling of Exceptional Conditions (NEW)
Brand new for the 2026 update. This one flew under the radar for years and it’s about time it got its own category.
This covers what happens when your application encounters something unexpected. An input it didn’t anticipate. A resource shortage. A timeout. An internal failure. How your system fails matters as much as how it runs.
The risks:
Verbose error messages leaking stack traces, database connection strings, or API keys. Fail-open logic where authentication bypasses occur on error. Null dereference crashes that enable denial of service. Unhandled exceptions that expose internal system architecture.
Why it matters:
These flaws fly under the radar in standard vulnerability scans because they only manifest under stress or edge cases. But attackers specifically probe for error conditions because error responses are goldmines of information.
How to fix it:
Define secure failure modes. Always fail closed, not open. Use consistent error-handling frameworks across your application. Log detailed errors internally but return generic messages to users. Handle every exception explicitly. Never expose stack traces in production. And test your error handling paths with the same rigor you test your happy paths.
OWASP Top 10 Vulnerabilities: 2021 vs. 2025/2026 Comparison
Here’s the complete side-by-side comparison of OWASP top 10 vulnerabilities rankings showing how the list evolved.
| 2025 Rank | 2025 Category | 2021 Rank | Change |
|---|---|---|---|
| A01 | Broken Access Control (now includes SSRF) | A01 | ⬜ Holds #1, absorbed SSRF |
| A02 | Security Misconfiguration | A05 | 🔺 Up 3 spots |
| A03 | Software Supply Chain Failures | NEW (expanded from A06:2021) | 🆕 New category |
| A04 | Cryptographic Failures | A02 | 🔻 Down 2 spots |
| A05 | Injection | A03 | 🔻 Down 2 spots |
| A06 | Insecure Design | A04 | 🔻 Down 2 spots |
| A07 | Authentication Failures | A07 | ⬜ Holds #7 (renamed) |
| A08 | Software and Data Integrity Failures | A08 | ⬜ Holds #8 |
| A09 | Security Logging and Alerting Failures | A09 | ⬜ Holds #9 (renamed) |
| A10 | Mishandling of Exceptional Conditions | NEW | 🆕 New category |
| Removed | SSRF (A10:2021) | A10 | 🔀 Merged into A01 |
What This Means For Your Security Program
The 2025 OWASP top 10 vulnerabilities list sends a clear message heading into 2026. Application security isn’t just about code anymore. It’s about the entire ecosystem: design, configuration, dependencies, and how your systems fail.
Three takeaways for developers:
1. Your supply chain is your attack surface. Every npm install, every pip install, every Docker image pull brings third-party code into your trust boundary. Treat it accordingly. Audit, pin, verify.
2. Configuration is a security discipline now. Misconfiguration surged to #2 for a reason. Cloud-native architectures multiplied the configuration surface area exponentially. Automate your hardening or accept the risk.
3. Test how your app fails, not just how it runs. The new A10 category is a direct call-out that error handling is a security concern. If your QA team only tests happy paths, your error paths are wide open for attackers.
For security teams and CISOs:
Use the updated OWASP top 10 vulnerabilities as a training framework. Map your existing controls against the 2025 categories. Identify gaps, especially in supply chain security (A03) and error handling (A10), where most organizations have minimal coverage. And remember that OWASP themselves say this is an awareness document, not a complete standard. Pair it with OWASP ASVS for verification and SAMM for maturity assessment.
FAQ
What are the OWASP top 10 vulnerabilities in 2026?
The 2025 list is: A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures (new), A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software and Data Integrity Failures, A09 Security Logging and Alerting Failures, A10 Mishandling of Exceptional Conditions (new).
What’s new in the OWASP Top 10 2025 compared to 2021?
Two new categories were added: Software Supply Chain Failures (A03) and Mishandling of Exceptional Conditions (A10). SSRF was consolidated into Broken Access Control. Security Misconfiguration jumped from #5 to #2. Injection dropped from #3 to #5. The analysis covered 175,000+ CVE records and 589 CWEs.
Is the OWASP Top 10 a security standard?
No. OWASP explicitly states it’s an awareness document, not a comprehensive standard. It highlights the most critical risks but doesn’t cover everything. For a testable security standard, use OWASP ASVS (Application Security Verification Standard). For maturity modeling, use OWASP SAMM.
How often does the OWASP Top 10 get updated?
Historically every 3 to 4 years. The previous versions were 2017 and 2021. The 2025 edition was released in late 2025/early 2026 and is the current standard heading into 2026. Each update incorporates new data, CVE analysis, and community feedback to reflect the evolving threat landscape.
How does the OWASP Top 10 relate to penetration testing?
Most penetration testing methodologies reference the OWASP Top 10 as a baseline for web application testing. Compliance frameworks like PCI DSS and SOC 2 expect testing against OWASP categories. Any competent pentest provider should test for all 10 categories and document findings accordingly.
The list got smarter. Supply chain risks and error handling finally got the attention they deserve. If your security program still treats OWASP as a checkbox exercise in 2026, you’re missing the point. Use it as a starting framework, test against every category, and build from there.