The 2026 attack surface, by category
Attacking web applications stopped being craft work. What runs against your site today is an industrial process: targets enumerated automatically, ranked by return per unit of effort, and hit by tooling that never gets bored and never goes home.
The OWASP Top 10 for 2025 redrew the map. Two categories are new, one absorbed a vulnerability class that used to stand on its own, and the reordering says something specific about where the industry is actually losing. This piece is about the threats only. What to do about them is a separate question, and a longer one.
A01: Broken access control, now including SSRF
Still first, on average across tested applications 3.73% carried at least one of the 40 CWEs in this category. The 2025 revision folds Server-Side Request Forgery into it, alongside BOLA and BFLA - broken object level and function level authorisation, the two failure modes that dominate API security.
The shape never changes: the server trusts a value the client controls. An object id in a URL nobody re-checks ownership on. A callback address in a webhook payload. A role claim read once at login and assumed for the rest of the session.
SSRF belongs here for the same reason. The attacker does not reach the internal network - they persuade your server, which is already inside it, to make the request on their behalf.
A02: Security misconfiguration
Up from fifth in 2021 to second, present in 3.00% of tested applications. Exposed development environments, containers running with more privilege than the workload needs, storage readable by anyone who guesses the bucket name, admin interfaces on default credentials.
The reason it climbed is worth sitting with: deployment got continuous, and scanning did not. Every deploy opens a window. The window closes when something checks - and if nothing checks on the same cadence as the deploys, the windows accumulate.
A03: Software supply chain failures, new
A new category, and it arrived carrying the highest incidence rate of anything on the list. It replaces and widens the old "Vulnerable and Outdated Components": the whole chain counts now - dependencies, build pipeline artefacts, CI/CD service accounts, and the SaaS integrations holding tokens into your systems.
This is the risk that bypasses your code entirely. You can review every line you wrote and still ship someone else's compromise, because you trusted a package, a build step or an integration that was itself trusted by somebody who got it wrong.
Over-privileged integrations are the multiplier. One compromised API inside a third-party service reaches everything that service was granted, which in practice is a good deal more than anyone remembers granting.
A10: Mishandling of exceptional conditions, new
Also new, 24 CWEs. This one is about what an application does when something goes wrong: uncaught exceptions, race conditions, error paths with no policy behind them, and systems that fail open rather than closed.
A verbose stack trace is a free architecture diagram - environment variables, database structure, internal paths, library versions. The worse case is the fail-open one, where the error path grants access the success path would have refused. Nobody writes that deliberately; it appears when the happy path gets all the review attention and the catch block gets none.
Agentic AI on the attacker's side
Reconnaissance and vulnerability discovery no longer wait for a human being to be interested. Agents map an application, find the endpoint missing input validation, write a payload, try it, and adjust - continuously, across every target they can reach, at a per-attempt cost that keeps falling.
This does not create new vulnerability classes. What it removes is the filter that used to protect small sites: being too unimportant to be worth somebody's afternoon. That filter is gone. A five-page site for a joinery in Čakovec is now probed on the same schedule as a bank, because the marginal cost of including it is close to zero.
Session token theft
Multi-factor authentication is no longer the thing attackers try to defeat. It is the thing they step around.
Infostealer malware on an endpoint harvests live, authenticated session tokens straight from the host. Injected into the attacker's own browser, the token is the session: MFA already happened, and nothing asks again. Every admin panel behind a "protected by MFA" checkbox is exactly as protected as the least careful laptop that signs into it.
Hyper-volumetric denial of service
Botnet-driven floods now routinely exceed the hardware capacity of ordinary hosting. There is no clever application-level answer to a request volume that saturates the link before anything reaches your code - the resource exhausted is upstream of everything you control.
Reading the list
Four of the seven items above are not vulnerabilities in your code at all. They are failures of what you depend on, how you deploy, what happens when something errors, and who is holding a valid session. That distribution is the actual finding: the code review is necessary and it is nowhere near sufficient.
What to do about all this is the subject of the next piece, which starts by refusing the premise that any of it can be finished.