The vulnerability classes every pentest should cover in 2026. Grouped, and tested honestly.
A checklist of class names is easy to publish and easy to fake. What a test is actually worth is whether it reaches each family of weakness your surface exposes — and whether the classes it claims were tested were really exercised, not just listed. Here are the thirty-five classes we drive every run, organised into the families they belong to, with a note on where a signature scanner structurally runs out of room.
The short version: a vulnerability class is not a bug, it is a shape of bug — a rule about how your application can be made to misbehave. Breadth of coverage means reaching every shape your surface can produce, not firing a lot of payloads at the two or three shapes a tool happens to recognise. The classes below group into seven families. Scanners own the left edge of each — the members that look the same on every site — and run out of room at the members that depend on your rules, your identities and your product. Those are the expensive ones, and they are most of the list.
The families at a glance
Thirty-five classes, seven families. The point of the grouping is not taxonomy for its own sake — it is a reachability check. If a test never produced a request as a second identity, the whole authorization family is untested no matter how many injection payloads it fired. Read the map as a set of surfaces that each need their own kind of test, not as a bag of strings to throw.
1 · Access control & authorization
The family where the expensive bugs live: IDOR / BOLA, object & field tampering, mass assignment and the multi-step chains that string several small authorization gaps into one real breach. Every member of this family is about who is allowed to do what, and none of it produces a malformed response — the server answers a valid request with the wrong data for that caller. That is precisely why a signature scanner is blind here: there is no bad string to match in a well-formed JSON object that simply belongs to another tenant. You find these by stating the rule ("an invoice is visible only to its owner," "a role field cannot be set by the client") and replaying a real request as a second identity to see whether the rule holds. No test accounts, no authorization testing — the family goes dark.
2 · Authentication & sessions
The gate in front of everything else: auth & session flaws, OAuth & SSO flaws, token forgery & JWT handling, account takeover chains, and default credentials. Scanners do catch the mechanical members — an unsigned JWT, a well-known default password, a missing Secure flag. They stall on the stateful ones: an OAuth flow that accepts a swapped redirect_uri, a password-reset token that is predictable only when you observe two of them, a session that survives a logout it should have killed. Those depend on sequence and state, which a stateless pattern-matcher does not carry. The test here is a flow, replayed and tampered at each hop, not a single request.
3 · Injection & input handling
The classic family, and the one scanners are genuinely good at: SQL injection, cross-site scripting, DOM-based injection, command injection, template injection, response splitting, prototype pollution and blind detection. The reflected, obvious members are solved problems — a signature matches a payload echoed in the response and the tool is right. The room a scanner runs out of is the blind and second-order variants: an injection whose effect lands in a different request, a log, an async job, or a rendered email minutes later, where there is nothing to match in the immediate response. Those need an out-of-band canary that is actually transmitted and actually observed coming back — if the canary never fires, reporting the class as "checked" is a lie, not coverage.
Why the grouping, not the count, is the honest metric. A tool can advertise "40 checks" and have thirty-eight of them live in family 3, because injection is the family that pattern-matching fits. Breadth is whether families 1, 2, 5 and 7 are reached at all — and those are exactly the ones that require state, identity and your product's own rules. Count the families a test touches before you trust the number of checks it ran.
4 · API contracts & protocols
The surface behind the UI, where a browser-driven scanner never looks: GraphQL, gRPC and OpenAPI endpoints, schema fuzzing, hidden-parameter mining and WebSocket security. Most modern bugs are reachable only through the API, not the rendered page — a mutation the front end never calls, a field the schema exposes but the UI hides, a parameter that silently changes behaviour when you supply it. A scanner that crawls links finds none of this because none of it is linked. The test is to read the contract (or infer it by fuzzing the schema), enumerate what the contract permits, and probe the operations the designers assumed no one would call directly. Real-time transports like WebSockets add a session that stays open and mutates — state a request-at-a-time tool cannot model.
5 · Business logic & abuse
The smallest family by class count and often the largest by impact: business-logic abuse and rate-limit & quota abuse. This is the family a scanner structurally cannot touch, because there is no universal signature for "this is wrong" — the rule being broken is one your product invented. A coupon that applies twice, an order total that goes negative, a quota that resets when you rotate an IP, a race between two concurrent add-to-cart requests: each is a perfectly valid sequence of perfectly valid requests, assembled into an outcome the designers never intended. You find these the way the roadmap describes — write the rule down as a checkable hypothesis, then try to break it under realistic conditions, including concurrency and load. If you cannot state the rule, you cannot test it.
6 · Exposure & configuration
The widest family by raw count — eleven classes, mostly external and mostly about what got left open rather than what got coded wrong: SSRF & cloud metadata, CORS & CSRF, exposed secrets & keys, known CVEs, Kubernetes & buckets, CSP & headers, TLS & cookie flags, exposed .git & source maps, subdomain takeover, supply-chain attacks and dependency confusion. Here the honest-coverage trap is the opposite of family 1: scanners find too much. A version banner matched against a CVE database is a guess, not a finding — the patch may be backported, the path may be unreachable, the metadata endpoint may be firewalled. The work that earns trust is proving reachability and impact: that the SSRF actually reaches the metadata service, that the takeover-able subdomain is actually claimable, that the "vulnerable" version is actually exploitable on this host. A refuted CVE match never counts as a finding.
7 · The AI-agent surface
The family most products added in the last two years and almost no scanner tests: prompt injection & MCP. The named class is a stand-in for a whole new attack surface — the point where untrusted text (a document, a web page, a tool result, another user's message) is read by a model that also holds the authority to call tools. Prompt injection matters here not as a party trick but as the moment that injected text becomes a tool call: a model told to summarise a page instead follows an instruction buried in it and invokes a privileged action. The tests are specific to this surface — does untrusted content cross the instruction-versus-data boundary; can a model be steered past its tool and permission limits; does an MCP server expose an operation the agent should never be allowed to reach; does poisoned memory persist across turns. None of it has a payload signature, because the vulnerability is in a trust boundary, not a byte sequence. We go deeper in AI-agent penetration testing.
Coverage only counts when it is tested honestly
A list of thirty-five class names is marketing until you can say, per class and per run, which was attempted against your surface and which was verified. Those are different numbers and should never be collapsed. A class is attempted when the floor for it actually did the interesting thing — a payload was transmitted, a canary was sent, a request was replayed as a second identity — and it can honestly come back empty. A class is verified only when a candidate it surfaced reproduced from a clean session and carries evidence. The failure modes are symmetric: a floor that reports a class "covered" when it never transmitted anything is faking breadth, and a report that counts a refuted candidate as a finding is faking depth. Both violate honest coverage, and both are why so many reports are long and so few are trusted.
This is also why breadth and rigour are not in tension. The deterministic floors are what guarantee all thirty-five classes get attempted every run — coverage never depends on what the model felt like exploring. The clean-session reproduction and the adversarial critic are what keep the verified count honest. You need both: breadth without verification is a scanner's long list of maybes; verification without breadth is a deep look at a surface you never fully mapped.
Every class, tested and proven
Each class below has a dedicated page: what it is, why a scanner misses it, and how SuperPentest proves it with a controlled test and clean-session reproduction.
FAQ
How many vulnerability classes should a penetration test cover?
The number matters less than the spread. A test that fires a hundred payloads at one class has worse coverage than one that reaches every family of weakness your surface exposes — access control, authentication, injection, API contracts, business logic, exposure, and the AI-agent surface. We drive 35 named classes across those families every run, so breadth is a property of the pipeline, not of what the model chose to explore.
Why do signature-based scanners miss business-logic and access-control bugs?
A scanner recognises a known-bad string in a response. Broken access control and business-logic abuse produce a perfectly valid response that is simply the wrong one for that caller — there is no signature for "this invoice belongs to another tenant," because the rule being broken is yours. You find those by stating the rule and replaying a real request as a different identity.
What does "attempted versus verified" coverage mean?
Attempted is the list of classes a run actually exercised against your surface; verified is the shorter list it proved by reproducing a candidate from a clean session. Reporting a class as "covered" when the floor never transmitted a payload, or counting a refuted candidate as a finding, both lie about coverage. Honest coverage keeps the two numbers separate and holds the unproven back.
Want to see the families mapped to your own surface? Browse the full coverage map, read how we test the AI-agent surface and why an AI pentest reaches classes a scanner cannot, or book a demo.