Web Application
Security Report 2026
Aggregate findings from 47,291 vulnerabilities across 3,847 scanned applications. All data is anonymised and validated through real exploitation, with no theoretical findings.
Data as of Q1 2026 · n=47,291 confirmed findings
Published May 13, 2026 · Last updated · Next update: Q2 2026 (July 2026)
What the data shows
of all scanned applications had at least one broken access control vulnerability, the most prevalent finding category for the third consecutive quarter.
more vulnerabilities discovered in authenticated scans compared to unauthenticated scans of the same application. Most IDOR and business logic flaws are invisible without authenticated context.
of critical findings were directly exploitable with no prerequisite access. An unauthenticated attacker could immediately compromise user data or application integrity.
of SQL injection vulnerabilities were found in applications that passed automated static analysis (SAST). Dynamic testing catches what source-code scanning misses.
median time between a vulnerability being introduced in code and being discovered when tested only at deployment. Continuous testing in CI/CD reduces this window to minutes.
average cost of a data breach (IBM 2024). Of breaches analysed, 67% involved a vulnerability class that Penetrify scans for: broken access control, injection, or authentication flaws.
Vulnerability types
Broken access control remains the dominant vulnerability class, a pattern consistent with OWASP's rankings. IDOR, missing authorisation checks, and path traversal account for the bulk of findings in this category.
How serious are the findings?
49% of findings are critical or high severity, directly exploitable with immediate business impact. Medium findings represent configuration gaps that become exploitable when chained.
Applications by vertical
Fintech applications had the highest critical-finding rate (71% had at least one), followed by healthcare (68%). E-commerce led for injection vulnerabilities, particularly payment-flow input handling.
Monthly vulnerability discoveries
Monthly scan volume has grown 143% from October 2025 to March 2026 as teams integrate Penetrify into CI/CD pipelines and test more frequently.
Authenticated scans find
3.4× more vulnerabilities
When we compared scans of the same applications with and without authenticated sessions, authenticated scans discovered 3.4× more vulnerabilities on average. Nearly all IDOR, privilege escalation, and broken business logic findings are invisible without an active session.
unauthenticated
authenticated
How this data was collected
Penetrify, Web Application Security Report 2026, data as of Q1 2026 (n=47,291 confirmed findings across 3,847 applications). https://www.penetrify.cloud/en/stats/. Published May 13, 2026, updated quarterly. Licensed CC BY 4.0: quote or reproduce freely with attribution to “Penetrify (penetrify.cloud)”.
How a finding is validated
Dataset. 47,291 findings across 3,847 distinct web applications and APIs, tested between October 2025 and March 2026. Findings are counted at the vulnerability-instance level: one application with five distinct SQL injection points contributes five findings.
Exploitation-validated. Every finding counted here was confirmed by the agent actually exploiting it, not flagged by signature or heuristic alone. Validation relies on a deterministic oracle: a unique, agent-controlled effect causally produced by its own payload. For injections, the agent triggers an out-of-band interaction (OAST) on its own infrastructure or reads a specific controlled marker (such as the output of SELECT @@version or a pre-planted canary), proving genuine query execution. For authorization flaws, validation is cross-checked: user A’s session demonstrably retrieves an object belonging to user B, compared against a ground-truth reference, not merely an HTTP 200 on a manipulated ID. Exploitation is non-destructive: the agent reads only a minimal proof value sufficient to confirm execution, never the underlying dataset, and never modifies or exfiltrates data.
The SAST comparison. Measured against the subset of applications known to run a SAST gate in their CI pipeline (2,231 of 3,847, 58%). We did not run our own SAST scan over their source code, so the claim is narrow: a SAST-gated pipeline did not prevent the issue from reaching the running app. It does not establish that SAST failed to detect it (the finding may have been flagged and overridden, or fallen outside the tool’s language or rule coverage). “SAST” here is whatever single tool and ruleset each team ran.
Privacy. All data is anonymised and aggregated: no PII, no source code, and no identifying details about tested organisations.
What this data does not show
This is a single-vendor dataset, not a peer-reviewed study. Read it with these caveats:
- ›Selection bias. These are applications whose teams chose to run an autonomous testing platform, skewed toward startups, SMBs, and SaaS (38% of the sample). It is not a representative sample of the web.
- ›The agent has blind spots. Autonomous testing is strong on broad, exploit-driven coverage but weaker than a skilled human on novel business logic and deeply context-dependent attack chains. What we found is not everything that is there.
- ›The SAST comparison is a narrowed subset. It covers only apps that run a SAST gate in CI (a further-narrowed slice of an already self-selected sample, so the selection biases compound) and reflects one SAST tool and ruleset.
- ›Validation is not infallible. Exploitation-validation reduces but does not eliminate false positives and false negatives.
- ›Point-in-time. Figures cover October 2025 to March 2026 and shift quarter to quarter.
Find out what's in your application
63% of applications have a critical or high-severity finding waiting to be discovered. Run your first scan in minutes.