kin-openapi CVE-2026-73501

Exploitation requires that the target application uses openapi3filter.ValidationHandler as its authentication enforcement point for routes carrying OpenAPI security requirements (API key, OAuth, or other scheme) AND that the developer left the ValidationHandler.AuthenticationFunc field unset, causing the vulnerable Load() default. When those conditions hold, no further prerequisites exist: a remote, unauthenticated attacker sending a normal HTTP request to a protected route is enough, and the fail-closed ErrAuthenticationServiceMissing path is bypassed. What LIMITS exploitation: the flaw does not apply if the application sets a real AuthenticationFunc, enforces auth in a separate middleware layer, defines no security requirements in its spec, or does not use ValidationHandler at all - so exposure is a function of this specific middleware misuse, not of merely importing the library.

The vendor CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1) reflects a network-reachable, low-complexity, unauthenticated bypass with high confidentiality and integrity impact and no availability impact - internally consistent for an auth-bypass class. The critical nuance the raw score understates is a deployment precondition: the flaw only manifests when an application actually relies on ValidationHandler for security enforcement AND omits setting AuthenticationFunc, in which case the insecure default silently applies. There is no EPSS score, no SSVC decision data, and no POC or KEV signal in the provided input, so exploitation probability cannot be quantified; absence of a POC is not evidence of low risk here because triggering requires only a normal unauthenticated HTTP request to a protected route. This is a genuine priority for the subset of downstream Go services that use this middleware as their gate, but it is not a mass-exploitable single-endpoint bug like a public-facing appliance RCE - real-world exposure depends on how many deployments use ValidationHandler for enforcement, which is unknown from the data.

An attacker identifies a Go service whose OpenAPI spec marks certain routes as requiring an API key or OAuth token but which uses ValidationHandler without a configured AuthenticationFunc. The attacker sends an ordinary HTTP request to a protected endpoint with no credentials; the no-op auth callback approves the request and the protected handler executes, returning or modifying data that should have required authentication. No POC is published, but the attack requires only a standard unauthenticated request given the AV:N/AC:L/PR:N/UI:N vector.