43% of New CISA Exploited CVEs in 2025 Were API Vulnerabilities — The Gateway Controls That Matter

CISA added 245 vulnerabilities to its Known Exploited Vulnerabilities catalog in 2025 — a 20% increase over the prior year. Of those, 106 were API-related. That is 43% of every newly documented actively-exploited vulnerability, sitting on the API layer.

Wallarm's 2026 API ThreatStats Report puts the full picture into context: APIs accounted for 11,053 of 67,058 published security bulletins in 2025 — 17% of all reported vulnerabilities. They are no longer a niche attack surface. They are the primary one.

The question for every enterprise with an API gateway is not whether their APIs are targeted. It is whether their gateway configuration reflects the actual exploit patterns in the data.

The exploitability problem is worse than the numbers suggest

The CISA count describes vulnerabilities that have been confirmed exploited in the wild. The characteristics of those exploits should change how seriously teams treat their gateway configuration.

From the Wallarm data on API vulnerabilities identified in 2025:

97% are exploitable with a single HTTP request. There is no multi-step reconnaissance needed. The attack is one call.
99% are remotely accessible. No physical access or network adjacency required.
98% are rated easy or trivial to exploit. Low skill floor for attackers.
59% require no authentication at all to execute successfully.
30% already have public exploit code available, meaning weaponization lag is near zero.
67% are rated high or critical severity for business impact.

The 59% no-authentication figure deserves particular attention. It means that for the majority of API attack surface documented in the KEV catalog, a valid credential is not even a prerequisite. The endpoint is exposed, unauthenticated, and callable from the public internet.

Broken authentication: 52% of breaches trace here

When breaches do involve authentication, the failure is almost always in the implementation rather than the cryptographic primitive. The same Wallarm analysis of 60 API incidents disclosed in 2025 found broken authentication was the culprit in 52% of cases.

"Broken authentication" covers a cluster of related failures:

Missing authentication on routes that should require it. The most common pattern. A route exists, handles real data, and was never wired to the auth middleware. Often found on internal-facing endpoints that later became reachable from the public internet, or on v1 paths that pre-date the auth layer.

Token validation gaps. JWTs accepted without signature verification. Tokens that never expire. Tokens validated locally without checking revocation. The token looks valid; the gateway or upstream never confirms it still is.

Scope enforcement absent after authentication. A valid token gets a caller into the system; nothing checks whether the token's scope allows the specific operation. A read-only credential can call a write endpoint because the check was skipped.

Credential sharing and rotation failure. Long-lived API keys shared across teams, embedded in CI/CD configs, or never rotated after an engineer departure. The credential is "authenticated" in the sense that it passes validation — but the control no longer maps to an identifiable human or system.

All four of these are problems a gateway can directly address. Three of them — missing auth, scope enforcement, and credential lifetime controls — are configuration decisions, not product features that require an upgrade.

The inventory problem compounds the auth problem

The authentication failures above assume you know the endpoint exists. For a significant portion of enterprise API surface, that assumption fails.

Research from multiple 2025 sources puts 30–50% of enterprise API endpoints as undocumented or unregistered with the security team. Wallarm estimates shadow APIs represent roughly 40% of total API exposure. CybelAngel's 2025 API threat report found that enterprises managing 10,000+ APIs routinely have 40–50% lacking documentation.

An undocumented endpoint is almost always an unenforced one. If the route is not in the gateway's configuration, auth policies and rate limits never apply. The 59% no-authentication figure for exploited vulnerabilities is partly a product of this inventory gap — routes that were never registered with the gateway are routes that have never had authentication configured.

The relationship is direct: inventory → registration → enforcement. Endpoints outside that chain are the ones being exploited.

MCP servers expanded the API attack surface in 2025

Model Context Protocol adoption created a new category of API attack surface that many enterprise security teams have not yet inventoried. Wallarm's 2026 report identified 315 MCP vulnerabilities as of 2025 — accounting for 14.4% of all AI-related vulnerabilities. Between Q2 and Q3 alone, the count grew by 270%.

MCP servers expose tools — which are API endpoints — to AI agents. The security model is identical to any other API: authentication, scope enforcement, rate limiting, and audit logging apply. But many MCP deployments treat the server as a developer convenience layer rather than a production API, and skip the controls accordingly.

The Webinar covering agentic AI shadow key sprawl highlighted in early 2026 that exposed MCP servers are already leaking agent infrastructure at scale — often with credentials that were provisioned for development and never scoped down. An MCP server without gateway registration has the same problem as any other shadow API: no inventory means no enforcement.

What a gateway configuration should look like given this data

The exploit patterns in the 2025 KEV data imply specific configuration requirements. None of these are novel, but the data makes the priority ordering clearer:

Require authentication on every route without exception. There should be no route in your gateway configuration that returns a 200 to an unauthenticated request unless that response contains no data worth protecting. Default-deny on new routes, not default-allow.

Validate tokens at the gateway, not only at the upstream. JWTs should be verified for signature and expiry at the gateway layer before the request reaches the upstream service. Revocation checks for high-value operations. The upstream may still validate, but the gateway validation catches issues before traffic reaches services that may handle it differently.

Enforce scope per operation, not per service. A valid token with a read:users scope should not be able to call DELETE /users/:id. Scope enforcement at the route level, not the service level, prevents the class of lateral movement that appears in 52% of breaches. Zerq's access profiles apply this per-consumer, not globally.

Inventory before you enforce. Every route that should be under gateway control needs to be registered. This means reconciling what the gateway routes with what actually exists in the upstream — which in practice requires a traffic-based discovery pass alongside spec-first registration. See API inventory is the first step to governance.

Rate-limit independently of authentication. Unauthenticated attacks by definition bypass credential-based rate limits. Rate limiting at the IP, path, and method level provides a secondary control that applies regardless of whether auth validation passes.

Log client identity on every call for post-incident traceability. The CISA KEV data is populated from confirmed exploitation — meaning incidents that were eventually traced and reported. Many are not. A gateway audit trail with client identity, operation, timestamp, and response code is what makes post-incident analysis possible and what turns a "breach" finding into a traceable timeline.

What a gateway does not fix

Honesty matters here. A gateway configuration addresses the authentication, authorization, and visibility layer. It does not fix vulnerabilities inside upstream application logic — deserialization flaws, SQL injection, business logic errors in the service itself. Those 67% of high/critical API vulnerabilities require remediation in the application code.

What the gateway does is enforce the controls that prevent the easiest exploits — the 97% single-request, 59% no-auth, 98% trivial-to-exploit class of vulnerabilities — from reaching services that may be vulnerable. It is a prerequisite, not a substitute, for secure application development.

The 2025 KEV data does not suggest gateway configuration alone closes the API security gap. It suggests that without gateway configuration, the gap cannot close, because the controls most likely to stop the documented attack patterns — authentication, scope enforcement, rate limiting, and audit logging — live at the gateway layer.

Zerq enforces authentication, token validation, per-consumer scope controls, and structured audit logging at the gateway level with no upstream code changes required. The capabilities overview covers auth, rate limiting, and API lifecycle. Request a demo to review your current gateway configuration against the controls the 2025 threat data prioritizes.