OWASP Top 10 2026: New Risk Classes and What Changed

What changed, exactly?

First, a precision point that matters for anyone planning a 2026 security roadmap: as of April 6, 2026, the official OWASP web application list is OWASP Top 10:2025, not a separate 2026 edition. That does not make the topic less relevant. It makes the 2025 release the baseline document engineering teams are actually carrying into 2026 budgets, threat models, and architecture reviews.

The big shift is not just rank order. It is category design. OWASP explicitly leaned further into root-cause framing, using a much larger dataset and community input to reorganize risks around the way modern systems are really built. The result is a list that tracks cloud delivery pipelines, dependency sprawl, release automation, and failure-mode engineering more closely than the 2021 edition did.

Five changes matter most:

• A03:2025 Software Supply Chain Failures is new, and it is more expansive than the old Vulnerable and Outdated Components bucket from 2021. OWASP is now treating compromise in build systems, package flows, artifact distribution, and dependency management as a first-class application risk.
• A10:2025 Mishandling of Exceptional Conditions is also new. This category pulls together improper error handling, fail-open behavior, null-driven crashes, privilege mishandling, and abnormal-state logic problems that used to be scattered or dismissed as mere quality defects.
• SSRF, which had its own slot in 2021, was rolled into Broken Access Control. That is an important signal: OWASP is emphasizing the authorization boundary behind the bug, not the request primitive used to reach it.
• Security Misconfiguration rose sharply, reflecting how much application behavior now lives in config, policy, platform metadata, identity bindings, and deployment knobs.
• Authentication Failures and Security Logging and Alerting Failures were renamed for tighter scope and better operational guidance.

That is the through-line for 2026: fewer teams can afford to think only in terms of request/response vulnerabilities in handwritten code. Your attack surface now includes CI runners, release tarballs, plugin ecosystems, exception paths, and every trust decision hidden in the build graph.

CVE summary card

The cleanest representative case for the new OWASP framing is CVE-2024-3094, the xz Utils backdoor. It is not just a memorable incident. It is an almost perfect justification for why OWASP promoted software supply chain failure into the top three.

• CVE: CVE-2024-3094
• OWASP mapping: A03:2025 Software Supply Chain Failures
• CWE: CWE-506 Embedded Malicious Code
• Published: March 29, 2024
• Affected releases: xz 5.6.0 and xz 5.6.1 release tarballs
• Why it matters: The compromise abused trust in maintainership, packaging, and release artifacts, not a classic web input validation bug.

OWASP describes A03:2025 as failures in building, distributing, or updating software. That is exactly what happened here. The compromise was hidden in release artifacts and build logic, creating a path to malicious behavior in downstream systems that trusted the release chain. The lesson is broader than Linux packaging: if your enterprise app consumes SDKs, GitHub Actions, CI plugins, private registries, container bases, or internally re-packed dependencies, the same class of failure applies.

Just as important, this incident shows why a simple “known vulnerable component” model is too narrow. Security programs built around CVE inventory alone are reactive. The xz case was about malicious upstream change insertion, release engineering abuse, and distribution trust. In other words, it was about provenance and integrity before it was about patching.

Vulnerable code anatomy

The 2025 OWASP changes make more sense when you look at code and pipeline shape rather than category names. Consider a stripped-down deployment helper that feels ordinary in many internal platforms:

function fetchDependency(name, version) {
  const url = `https://mirror.example/${name}-${version}.tar.gz`;
  return download(url);
}

function buildRelease() {
  const archive = fetchDependency('libfoo', '5.6.1');
  extractAndCompile(archive);
  publishArtifact();
}

What is missing is the entire trust story. There is no provenance verification, no signature validation, no digest pinning, no reproducible-build check, and no policy separating a source repository from the release artifact actually being compiled. That is the anatomy of A03. The bug is not a line-level coding mistake. It is a system that silently assumes the path between download and trust is safe.

Now contrast that with a second pattern, one that maps to A10:2025 Mishandling of Exceptional Conditions:

async function authorizeTransfer(req) {
  try {
    const policy = await loadPolicy(req.userId);
    return policy.canTransfer === true;
  } catch (err) {
    log.error(err);
    return true;
  }
}

This is the modern fail-open anti-pattern in one line. Under normal conditions, the function enforces policy. Under exceptional conditions, it degrades into implicit approval. Teams often describe this as resilience or graceful fallback. OWASP now treats it correctly: in many contexts, it is a security vulnerability class.

The connective tissue between A03 and A10 is architecture. In both cases, the software makes a hidden trust decision when reality gets messy. Either the build pipeline trusts what it cannot verify, or the runtime approves what it cannot safely evaluate.

Attack timeline

The timeline behind CVE-2024-3094 is a strong case study in why OWASP changed its list. Based on the public xz timeline analysis, the pattern looked like this:

1. Late 2021 to 2023: a contributor built trust over time with benign patches, social presence, and gradual project influence.
2. 2023: commit access and release influence increased, which changed the threat model from outsider risk to trusted-maintainer risk.
3. February 2024: malicious content was introduced into release-related paths and artifacts, including build-time behavior hidden from casual review.
4. March 2024: downstream distributions began ingesting affected versions, creating real exposure through normal package adoption channels.
5. March 28, 2024: abnormal behavior was investigated, the issue was privately reported, and rollback activity began.
6. March 29, 2024: public disclosure followed through the security community and the CVE was published.
7. 2025: OWASP released a Top 10 that explicitly elevated supply-chain compromise from a dependency hygiene problem to a core application risk category.
8. 2026: engineering teams are now using that 2025 framing to justify SBOM controls, provenance checks, CI isolation, and artifact trust policies.

That sequence matters because it was not a smash-and-grab exploit chain. It was patient trust acquisition followed by insertion into normal software movement. Older AppSec programs were better at spotting hostile requests than hostile release flow. OWASP corrected for that.

Exploitation walkthrough

This walkthrough is conceptual only. The point is to explain the class, not to provide a working proof of concept.

For A03 Software Supply Chain Failures, the attacker path usually looks like this:

1. Gain a trusted position by becoming a maintainer, compromising a maintainer account, or taking over an adjacent build or publishing system.
2. Insert a change where review is weakest, such as packaging scripts, release-only files, generated artifacts, CI glue code, installer logic, or transitive dependency updates.
3. Exploit a trust mismatch between what reviewers inspect and what production consumes. The repository may look clean while the tarball, workflow, package, or compiled artifact behaves differently.
4. Ride the legitimate channel. The malicious change ships through the same path defenders have already allow-listed: signed vendor downloads, build mirrors, dependency managers, or internal caches.
5. Trigger behavior downstream only under narrow conditions, which reduces noise and delays detection.

For A10 Mishandling of Exceptional Conditions, the exploitation logic is different but related. The attacker does not need a secret backdoor if the application already contains one in its error path. They probe for missing parameters, timeouts, parser inconsistencies, null-driven branches, resource exhaustion, race windows, and stale state transitions until the system reaches an exceptional branch that bypasses a control or leaks privileged context.

That is why OWASP made A10 explicit. In real incidents, abnormal-state behavior often decides whether a control holds or collapses. A service that authenticates correctly 99.99% of the time but fails open during cache loss, queue lag, or partial rollback is still insecure.

Hardening guide

If you are translating the new OWASP categories into 2026 engineering work, the control set should look more architectural than scanner-centric.

• Verify provenance, not just version numbers. Pin by digest where possible, validate signatures, and record where artifacts came from before they are promoted between environments.
• Separate source trust from release trust. Review the repository, but also verify the tarball, package, container image, generated code, and any build-time fetches. Reproducible builds are valuable precisely because they collapse that gap.
• Harden CI/CD like production infrastructure. Runner isolation, least privilege, short-lived credentials, protected environments, and immutable logs are table stakes for A03.
• Generate and enforce an SBOM. Inventory direct and transitive dependencies, but tie the SBOM to admission policy so it becomes a gate, not a document.
• Use staged rollouts for third-party changes. Canarying dependencies sounds operational, but it is increasingly an application security control.
• Design exception paths to fail closed. When policy, identity, or integrity checks cannot complete, default to deny, rollback, quarantine, or degraded read-only operation.
• Centralize exception handling. Security-sensitive code should not improvise fallback behavior one function at a time. One policy, one handler model, one audit surface.
• Rate-limit abnormal conditions. Many exceptional-state attacks are really pressure attacks on parsers, auth workflows, and retry loops.
• Mask sensitive error data before it reaches logs and support systems. If your exception flows risk exposing tokens, IDs, or customer payloads, validate sanitized examples with TechBytes' Data Masking Tool before standardizing incident and debug pipelines.
• Test the ugly path. Chaos drills and fault-injection tests should include security assertions: no auth bypass on cache failure, no policy bypass on timeout, no secret leakage on stack traces, no partial-write success after rollback failure.

One practical way to operationalize this is to add supply-chain and exception-state checks into the same release review you already use for threat modeling. If a service cannot state what it trusts at build time and what it does under partial failure, it is not ready for production.

Architectural lessons

The real message of the OWASP changes is that application security has become a systems discipline. The application is no longer just the code under /src. It is the CI graph, the artifact path, the package resolver, the feature flag set, the exception policy, the observability stack, and the humans who can change any of them.

That is why A03 and A10 belong together in strategic planning. One asks, what happens when trusted software movement is compromised? The other asks, what happens when the system enters a state the happy path did not model? Mature architectures answer both with explicit trust boundaries, deterministic rollback rules, verifiable provenance, and deny-by-default behavior.

For 2026, the practical lesson is straightforward: stop treating supply chain compromise and exceptional-condition handling as edge concerns owned by separate teams. They are now mainstream web application risk categories in the OWASP model. If your architecture review board, platform team, and AppSec team are not jointly accountable for them, your control design is already behind the list.

Further reading: OWASP Top 10:2025 Introduction, A03:2025 Software Supply Chain Failures, A10:2025 Mishandling of Exceptional Conditions, analysis of the xz attack script, and the NVD record for CVE-2024-3094.