chore(deps): update security updates [security]#116
Conversation
ℹ Artifact update noticeFile name: go.modIn order to perform the update(s) described in the table above, Renovate ran the
Details:
|
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (2)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
✅ Approve — automated reviewThis PR is a routine security-focused dependency update. It bumps several packages (go-openapi/jsonpointer, oasdiff/yaml, oasdiff/yaml3, go.opentelemetry.io/otel/metric, and go.opentelemetry.io/otel/trace) with associated go.sum changes. No reviewers identified any build, runtime, or security regressions introduced by the updates. The changes are mechanical and low-risk. No findings. |
This PR contains the following updates:
v0.134.0->v0.144.0v5.2.5->v5.3.0v1.43.0->v1.44.0kin-openapi: ValidationHandler.Load() Fail-Open Authentication Bypass via NoopAuthenticationFunc Default
GHSA-r277-6w6q-xmqw
More information
Details
Summary
ValidationHandler.Load()ingetkin/kin-openapisilently replaces a nilAuthenticationFuncwithNoopAuthenticationFunc, which always returnsnilwithout performing any credential check. Because this substitution happens unconditionally when the caller omits the field, every OpenAPIsecurityrequirement 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 onValidationHandleras its enforcement middleware.Details
ValidationHandleris an HTTP middleware exported byopenapi3filterthat validates incoming requests and responses against a loaded OpenAPI specification. ItsLoad()method initialises default fields before the handler begins serving:NoopAuthenticationFuncis defined as:It always returns
nil, meaning every security scheme check it handles is automatically approved.When a request arrives,
ServeHTTP→before→validateRequestassembles aRequestValidationInputwith the currentAuthenticationFunc(now the no-op) injected intoOptions:Inside
ValidateRequest, each security requirement callsoptions.AuthenticationFunc:Because
fis the no-op (notnil), theErrAuthenticationServiceMissingguard is never triggered andf(...)returnsnil, clearing the security requirement. Control then proceeds to the protected handler (validation_handler.go:61-62).The critical contradiction is that callers who use
ValidateRequestdirectly with a nilAuthenticationFuncget fail-closed behavior (ErrAuthenticationServiceMissing), while callers who use the higher-levelValidationHandlerwith a nilAuthenticationFuncget fail-open behavior. Since omittingAuthenticationFuncis the natural default, the majority of real-world integrations are vulnerable.Affected source file and line:
openapi3filter/validation_handler.go:47–49(commit30e2923, tagv0.143.0).PoC
Environment
Step 1 — Build the Docker image
From the repository root (parent of
vuln-001/):The
Dockerfilecopies the localkin-openapisource into/kin-openapi/inside the image and builds a Go binary (/poc-binary) frommain.go. Thego.modinside the image uses areplacedirective pointing to/kin-openapi, so no network access to the Go module proxy is required.Step 2 — Run the container
Step 3 (alternative) — Use the Python helper
What the PoC does
main.gocreates a temporary OpenAPI 3.0 spec that declaresGET /secretas protected by anapiKeysecurity scheme:It then constructs a
ValidationHandlerwithout settingAuthenticationFunc, callsLoad(), and sends a request with noX-Api-Keyheader:Expected (vulnerable) output
The contrast block confirms fail-closed behavior when
ValidateRequestis called directly. The exploit block confirms fail-open behavior throughValidationHandler. Status 200 andSECRET_DATAare returned without any credential.Remediation patch
After this change, a nil
AuthenticationFuncpropagates intoValidateRequest, which returnsErrAuthenticationServiceMissingand 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:
openapi3filter.ValidationHandleras its HTTP middleware, andsecurityrequirements in its OpenAPI specification, andAuthenticationFunc,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
ValidationHandleras a drop-in validation layer and rely on OpenAPIsecuritydeclarations 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
Dockerfilepoc.pySeverity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
kin-openapi openapi3filter: unauthenticated nil-pointer panic when validating a request against a
contentparameter whose media type has no schemaGHSA-jpcw-4wr7-c3vq
More information
Details
github.com/getkin/kin-openapi<= 0.143.0(introduced inv0.2.0, PR #90, 2019-05-07; reproduced onHEAD30e2923)Summary
openapi3filter.ValidateRequestcontains a NULL-pointer-dereference denial of service: any unauthenticated client can crash the request-validation path with a single HTTP request. When an operation declares acontentparameter (as opposed to aschemaparameter) whose media type object has noschema, request validation dereferences that missing schema and panics. The document is legal under the OpenAPI Specification — kin-openapi's owndoc.Validate()accepts it — and the defect affects both OpenAPI 3.0.x and 3.1.x. Depending on how the library is wired into the server (see Impact), this ranges from a per-request abort with unbounded panic-log growth to a full remote process crash.Details
The decoder used for
contentparameters when no customParamDecoderis configured (the library default),defaultContentParameterDecoder, dereferences the media-type schema without a nil check.openapi3filter/req_resp_decoder.go, around line 197:The function guards
param.Content == nil,len(content) != 1, andmt == nil, but nevermt.Schema == nil.Why a schema-less content parameter is legal (so the sink is reachable —
doc.Validate()returns no error), in both 3.0.x and 3.1.x:openapi3/parameter.go—Parameter.Validateonly enforces exactly one ofschemaXORcontent; a parameter withcontent(and noschema) satisfies it.openapi3/media_type.go—MediaType.Validatevalidates the schema only when it is non-nil, so an absent schema is not a validation error.Call path to the panic:
Authentication note:
ValidateRequestvalidates security before parameters, but the panic is reachable without credentials whenever the target operation declares no security requirement, or when noAuthenticationFuncis configured (it is opt-in). A single unauthenticated operation anywhere in the served spec is sufficient. If an operation does declare security and a rejectingAuthenticationFuncis wired, that request is rejected before decoding.PoC
Reproduced end-to-end against
HEAD(30e2923) with a realnet/httpserver and a stockhttp.Client.1. Minimal OpenAPI 3.0.3 document (legal —
doc.Validate()passes). Thecfgquery parameter usescontentwith anapplication/jsonmedia type that has noschema:2. A complete, self-contained program. Drop this into a directory inside a checkout of
github.com/getkin/kin-openapiand run it withgo run .. It loads the document above, assertsdoc.Validate()accepts it (proving reachability), serves it behind request validation exactly as the recommended middleware does, and sends one unauthenticatedGET /c?cfg=1:3. Observed result — the request goroutine panics inside validation, and the client's
http.Getreturns an EOF:Swapping the media type for one that carries a schema (
application/json: {schema: {type: object}}) makes the same request return a clean400instead of panicking, confirming the missing schema is the cause.Impact
This is an unauthenticated remote denial of service (CWE-476) against any service that validates incoming requests with
openapi3filterand serves a spec containing at least onecontentparameter whose media type lacks aschema.The precise consequence depends on which goroutine runs the panic and whether a
recover()covers it:net/http?net/http(incl.openapi3filter.ValidationHandler)http: panic servinglog growth.ValidateRequeston an app-spawned goroutine (fan-out,errgroup, async pre-check)recover().net/httphost (fasthttp adaptor, gRPC-gateway shim, CLI, offline/batch spec validator)This is why the suggested CVSS uses
A:L(Base 5.3): under the recommended synchronousnet/httpwiring the panic is recovered per-connection. Reviewers may reasonably raise it toA:H(Base 7.5) for the spawned-goroutine and non-net/httpintegrations, where a single request kills the process.Remediation (suggested)
Add a
mt.Schema == nilguard mirroring the existingmt == nilguard, so a schema-less content parameter yields a clean validation error instead of a panic:The
unmarshalclosure immediately below already tolerates a nil schema (it checksparamSchema != nil), so returning early on nilmt.Schemais consistent with surrounding intent.Workarounds for consumers, pending a patch:
contentparameter in served specs declares aschema, or reject such specs at load time.ParamDecoderthat guardsmt.Schema == nil.recover()— especially if validation runs off the request goroutine or on a non-net/httphost.Notes for the maintainer
This root cause (
mt.Schema == nil) is independent of theItems == nilpanics addressed in30e2923and ofGHSA-mmfr-pmjx-hw9w; no prior fix touched this code path. It affects OpenAPI 3.0.x as well as 3.1.x.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Chi has an IP spoofing vulnerability in middleware.RealIP in github.com/go-chi/chi
GHSA-3fxj-6jh8-hvhx / GO-2026-5774
More information
Details
Chi has an IP spoofing vulnerability in middleware.RealIP in github.com/go-chi/chi
Severity
Unknown
References
This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).
Chi's RealIP Middleware allows IP spoofing via unvalidated X-Forwarded-For header in github.com/go-chi/chi
GHSA-rjr7-jggh-pgcp / GO-2026-5777
More information
Details
Chi's RealIP Middleware allows IP spoofing via unvalidated X-Forwarded-For header in github.com/go-chi/chi
Severity
Unknown
References
This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).
Chi Middleware vulnerable to IP spoofing via X-Forwarded-For header in github.com/go-chi/chi
GHSA-9g5q-2w5x-hmxf / GO-2026-5775
More information
Details
Chi Middleware vulnerable to IP spoofing via X-Forwarded-For header in github.com/go-chi/chi
Severity
Unknown
References
This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).
Opentelemetry-go's baggage parsing no longer caps raw header length in go.opentelemetry.io/otel
CVE-2026-41178 / GHSA-5wrp-cwcj-q835 / GO-2026-5158
More information
Details
Opentelemetry-go's baggage parsing no longer caps raw header length in go.opentelemetry.io/otel
Severity
Unknown
References
This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).
Release Notes
getkin/kin-openapi (github.com/getkin/kin-openapi)
v0.144.0Compare Source
What's Changed
New Contributors
Full Changelog: getkin/kin-openapi@v0.143.0...v0.144.0
v0.143.0Compare Source
What's Changed
New Contributors
Full Changelog: getkin/kin-openapi@v0.142.0...v0.143.0
v0.142.0Compare Source
What's Changed
Full Changelog: getkin/kin-openapi@v0.141.0...v0.142.0
v0.141.0Compare Source
What's Changed
New Contributors
Full Changelog: getkin/kin-openapi@v0.140.0...v0.141.0
v0.140.0Compare Source
What's Changed
Full Changelog: getkin/kin-openapi@v0.139.0...v0.140.0
v0.139.0Compare Source
What's Changed
Full Changelog: getkin/kin-openapi@v0.138.0...v0.139.0
v0.138.0Compare Source
What's Changed
Full Changelog: getkin/kin-openapi@v0.137.0...v0.138.0
v0.137.0Compare Source
What's Changed
cc4f8d9by @fenollp in https://github.com/getkin/kin-openapi/pull/1161Full Changelog: getkin/kin-openapi@v0.136.0...v0.137.0
v0.136.0Compare Source
What's Changed
New Contributors
Full Changelog: getkin/kin-openapi@v0.135.0...v0.136.0
v0.135.0Compare Source
What's Changed
New Contributors
Full Changelog: getkin/kin-openapi@v0.134.0...v0.135.0
go-chi/chi (github.com/go-chi/chi/v5)
v5.3.0Compare Source
What's Changed
New Contributors
SECURITY: middleware.ClientIP, a replacement for middleware.RealIP
@VojtechVitek submitted PR #967, which introduces middleware.ClientIP — a replacement for middleware.RealIP that closes the three open spoofing advisories:
RemoteAddrresolution (convto)middleware.RealIP(Saku0512, Critical / 9.3)It also addresses issues outlined at:
middleware.RealIPis deprecated in this PR with pointers to the new API.The deprecation only adds a
// Deprecated:doc comment; the function keeps working for backward compatibility.Why a new middleware (not "fix RealIP in place")
RealIPhas two unfixable design choices: it mutatesr.RemoteAddr, and it tries to be a one-size-fits-all default by walking a hard-coded list of headers any client can supply. Per adam-p's "The perils of the 'real' client IP" (which calls chi out by name on this), there is no safe default — the user must pick their trust source explicitly.The new API
Four middlewares, two accessors. Pick exactly one middleware based on your
infrastructure, read the result with one of the two accessors:
Example usage:
And in your handler or downstream middleware:
Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Renovate Bot.