CWE-754
Allowed-with-ReviewImproper Check for Unusual or Exceptional Conditions
Abstraction: Class · Status: Incomplete
The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
1013 vulnerabilities reference this CWE, most recent first.
GHSA-R922-52FR-4X9G
Vulnerability from github – Published: 2024-10-28 21:30 – Updated: 2024-10-29 18:30The issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15. An attacker may be able to view restricted content from the lock screen.
{
"affected": [],
"aliases": [
"CVE-2024-44174"
],
"database_specific": {
"cwe_ids": [
"CWE-754",
"CWE-922"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-28T21:15:05Z",
"severity": "MODERATE"
},
"details": "The issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15. An attacker may be able to view restricted content from the lock screen.",
"id": "GHSA-r922-52fr-4x9g",
"modified": "2024-10-29T18:30:36Z",
"published": "2024-10-28T21:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44174"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121238"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-R9HF-RXJM-GV2F
Vulnerability from github – Published: 2026-01-27 18:32 – Updated: 2026-05-12 15:31Issue summary: A type confusion vulnerability exists in the signature verification of signed PKCS#7 data where an ASN1_TYPE union member is accessed without first validating the type, causing an invalid or NULL pointer dereference when processing malformed PKCS#7 data.
Impact summary: An application performing signature verification of PKCS#7 data or calling directly the PKCS7_digest_from_attributes() function can be caused to dereference an invalid or NULL pointer when reading, resulting in a Denial of Service.
The function PKCS7_digest_from_attributes() accesses the message digest attribute value without validating its type. When the type is not V_ASN1_OCTET_STRING, this results in accessing invalid memory through the ASN1_TYPE union, causing a crash.
Exploiting this vulnerability requires an attacker to provide a malformed signed PKCS#7 to an application that verifies it. The impact of the exploit is just a Denial of Service, the PKCS7 API is legacy and applications should be using the CMS API instead. For these reasons the issue was assessed as Low severity.
The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the PKCS#7 parsing implementation is outside the OpenSSL FIPS module boundary.
OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.
{
"affected": [],
"aliases": [
"CVE-2026-22796"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-27T16:16:35Z",
"severity": "MODERATE"
},
"details": "Issue summary: A type confusion vulnerability exists in the signature\nverification of signed PKCS#7 data where an ASN1_TYPE union member is\naccessed without first validating the type, causing an invalid or NULL\npointer dereference when processing malformed PKCS#7 data.\n\nImpact summary: An application performing signature verification of PKCS#7\ndata or calling directly the PKCS7_digest_from_attributes() function can be\ncaused to dereference an invalid or NULL pointer when reading, resulting in\na Denial of Service.\n\nThe function PKCS7_digest_from_attributes() accesses the message digest attribute\nvalue without validating its type. When the type is not V_ASN1_OCTET_STRING,\nthis results in accessing invalid memory through the ASN1_TYPE union, causing\na crash.\n\nExploiting this vulnerability requires an attacker to provide a malformed\nsigned PKCS#7 to an application that verifies it. The impact of the\nexploit is just a Denial of Service, the PKCS7 API is legacy and applications\nshould be using the CMS API instead. For these reasons the issue was\nassessed as Low severity.\n\nThe FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,\nas the PKCS#7 parsing implementation is outside the OpenSSL FIPS module\nboundary.\n\nOpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.",
"id": "GHSA-r9hf-rxjm-gv2f",
"modified": "2026-05-12T15:31:14Z",
"published": "2026-01-27T18:32:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22796"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/2502e7b7d4c0cf4f972a881641fe09edc67aeec4"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/572844beca95068394c916626a6d3a490f831a49"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/7bbca05be55b129651d9df4bdb92becc45002c12"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/eeee3cbd4d682095ed431052f00403004596373e"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/ef2fb66ec571564d64d1c74a12e388a2a54d05d2"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://openssl-library.org/news/secadv/20260127.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-R9WV-87CR-24PW
Vulnerability from github – Published: 2022-05-24 17:08 – Updated: 2022-05-24 17:08Insufficient policy enforcement in storage in Google Chrome prior to 80.0.3987.87 allowed a remote attacker to bypass site isolation via a crafted HTML page.
{
"affected": [],
"aliases": [
"CVE-2020-6385"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-02-11T15:15:00Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in storage in Google Chrome prior to 80.0.3987.87 allowed a remote attacker to bypass site isolation via a crafted HTML page.",
"id": "GHSA-r9wv-87cr-24pw",
"modified": "2022-05-24T17:08:38Z",
"published": "2022-05-24T17:08:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-6385"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0514"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1035399"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6IOHSO6BUKC6I66J5PZOMAGFVJ66ZS57"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/X3B5RWJQD5LA45MYLLR55KZJOJ5NVZGP"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202003-08"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4638"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-02/msg00015.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-02/msg00025.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RFPC-4J7V-FQJP
Vulnerability from github – Published: 2022-05-24 17:05 – Updated: 2026-05-29 15:30A CWE-754: Improper Check for Unusual or Exceptional Conditions vulnerability exists in Modicon M580, Modicon M340, Modicon Quantum, Modicon Premium (see security notification for specific versions) which could cause a Denial of Service of the controller when reading specific memory blocks using Modbus TCP.
{
"affected": [],
"aliases": [
"CVE-2019-6857"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-01-06T23:15:00Z",
"severity": "MODERATE"
},
"details": "A CWE-754: Improper Check for Unusual or Exceptional Conditions vulnerability exists in Modicon M580, Modicon M340, Modicon Quantum, Modicon Premium (see security notification for specific versions) which could cause a Denial of Service of the controller when reading specific memory blocks using Modbus TCP.",
"id": "GHSA-rfpc-4j7v-fqjp",
"modified": "2026-05-29T15:30:22Z",
"published": "2022-05-24T17:05:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6857"
},
{
"type": "WEB",
"url": "https://www.se.com/ww/en/download/document/SEVD-2019-344-01"
},
{
"type": "WEB",
"url": "https://www.us-cert.gov/ics/advisories/icsa-20-016-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RHMM-FWG9-R5M5
Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2025-08-15 21:31In the CODESYS V2 web server prior to V1.1.9.22 crafted web server requests can trigger a parser error. Since the parser result is not checked under all conditions, a pointer dereference with an invalid address can occur. This leads to a denial of service situation.
{
"affected": [],
"aliases": [
"CVE-2021-34585"
],
"database_specific": {
"cwe_ids": [
"CWE-252",
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-26T10:15:00Z",
"severity": "HIGH"
},
"details": "In the CODESYS V2 web server prior to V1.1.9.22 crafted web server requests can trigger a parser error. Since the parser result is not checked under all conditions, a pointer dereference with an invalid address can occur. This leads to a denial of service situation.",
"id": "GHSA-rhmm-fwg9-r5m5",
"modified": "2025-08-15T21:31:13Z",
"published": "2022-05-24T19:18:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34585"
},
{
"type": "WEB",
"url": "https://customers.codesys.com/index.php?eID=dumpFile\u0026t=f\u0026f=16876\u0026token=a3f1d937f95e7034879f4f2ea8e5a99b168256a7\u0026download="
},
{
"type": "WEB",
"url": "https://www.tenable.com/security/research/tra-2021-47"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RJ39-CV6W-8WV7
Vulnerability from github – Published: 2026-10-15 20:20 – Updated: 2026-10-15 20:20Summary
kin-openapi guards against NaN and Inf values in its built-in schema visitor (visitJSON) by returning ErrSchemaInputNaN / ErrSchemaInputInf when a float64 input violates those constraints. For OAS 3.1 specs, however, Schema.VisitJSON routes through useJSONSchema2020, which hands the value directly to santhosh-tekuri/jsonschema/v6 v6.0.2 without applying the same guard.
Inside jsonschema/v6 v6.0.2, numValidate builds a *big.Rat from the input via big.Rat.SetString(fmt.Sprintf("%v", v)). For NaN/Inf this parse fails silently and returns nil. numValidate then dereferences the nil *big.Rat (in math/big.(*Rat).Cmp), producing a Go runtime panic.
An attacker delivers this by sending an HTTP request with Content-Type: application/yaml (or application/x-yaml) and a YAML body containing .nan, .inf, or -.inf. The YamlBodyDecoder decodes those tokens into math.NaN() / math.Inf(±1) (standard YAML 1.2 behavior), and they propagate to the unguarded useJSONSchema2020 path whenever the schema declares a numeric constraint (minimum, maximum, exclusiveMinimum, exclusiveMaximum, or multipleOf).
Details
Root Cause
The built-in visitor visitJSON at openapi3/schema.go:1968 guards NaN/Inf explicitly:
case float64:
if math.IsNaN(value) {
return ErrSchemaInputNaN
}
if math.IsInf(value, 0) {
return ErrSchemaInputInf
}
For OAS 3.1 specs, VisitJSON dispatches to useJSONSchema2020 (openapi3/schema_jsonschema_validator.go:204), which contains no such guard:
func (schema *Schema) useJSONSchema2020(settings *schemaValidationSettings, value any) error {
validator, err := newJSONSchemaValidator(schema)
if err != nil {
return schema.visitJSON(settings, value)
}
return validator.validate(value) // value handed straight through
}
jsonSchemaValidator.validate calls jsonschema/v6.Schema.Validate (line 146), which reaches numValidate in v6.0.2. There, big.Rat.SetString(fmt.Sprintf("%v", v)) returns (nil, false) for NaN/Inf, and the code dereferences the nil *big.Rat in Rat.Cmp, causing the panic.
Proof of Concept
Environment
- kin-openapi v0.144.0 (tag
v0.144.0, commitf0407d5) - santhosh-tekuri/jsonschema/v6 v6.0.2 (transitive dep)
- Go 1.26.7
Spec
Minimal OAS 3.1 spec (spec.yaml) declaring a YAML body with a numeric constraint:
openapi: '3.1.0'
info: { title: Test, version: '1.0' }
paths:
/test:
post:
requestBody:
required: true
content:
application/yaml:
schema:
type: number
minimum: 0
responses:
'200': { description: OK }
Trigger
A single POST /test with Content-Type: application/yaml and body .nan, .inf, or -.inf. All three variants panic:
=== RUN TestNaNInf
[nan] PANIC (confirms vuln): runtime error: invalid memory address or nil pointer dereference
[inf] PANIC (confirms vuln): runtime error: invalid memory address or nil pointer dereference
[neginf] PANIC (confirms vuln): runtime error: invalid memory address or nil pointer dereference
Panic stack trace (confirms exact chain)
panic: runtime error: invalid memory address or nil pointer dereference
math/big.(*Rat).Cmp(0x0, ...) <- nil *big.Rat dereferenced
C:/Program Files/Go/src/math/big/rat.go:492
github.com/santhosh-tekuri/jsonschema/v6.(*validator).numValidate(...)
.../jsonschema/v6@v6.0.2/validator.go:525
github.com/santhosh-tekuri/jsonschema/v6.(*validator).validate(...)
.../jsonschema/v6@v6.0.2/validator.go:168
github.com/santhosh-tekuri/jsonschema/v6.(*Schema).validate(...)
.../jsonschema/v6@v6.0.2/validator.go:34
github.com/getkin/kin-openapi/openapi3.(*jsonSchemaValidator).validate(...)
openapi3/schema_jsonschema_validator.go:146
github.com/getkin/kin-openapi/openapi3.(*Schema).useJSONSchema2020(...) <- MISSING NaN/Inf guard
openapi3/schema_jsonschema_validator.go:211
github.com/getkin/kin-openapi/openapi3.(*Schema).VisitJSON(...)
openapi3/schema.go:1946
github.com/getkin/kin-openapi/openapi3filter.ValidateRequestBody(...)
openapi3filter/validate_request.go:364
github.com/getkin/kin-openapi/openapi3filter.ValidateRequest(...)
openapi3filter/validate_request.go:96
net/http behavior (severity nuance)
Behind a standard net/http server, the panic is recovered per-connection. The client sees a dropped connection; the server process continues:
Sending POST /test body=.nan against real net/http server...
2026/08/25 http: panic serving 127.0.0.1:40625: runtime error: invalid memory address or nil pointer dereference
CLIENT ERROR (connection dropped): Post ".../test": EOF
Process still alive after request: true
This is a recoverable panic, unlike the recursion finding. recover() catches it (verified by capturing the panic value in a defer in the same goroutine). Non-net/http hosts or validation performed in an application-spawned goroutine are not covered by that recovery and would experience a full-process crash.
Fix verification
Upgrading only the transitive dependency to jsonschema/v6@v6.0.3 (via go get github.com/santhosh-tekuri/jsonschema/v6@v6.0.3) eliminates the panic entirely; all three payloads return a clean validation error:
[nan] Returned normally, err = request body has an error: doesn't match schema: validation failed due to: at '': invalid jsonType float64
[inf] Returned normally, err = request body has an error: doesn't match schema: validation failed due to: at '': invalid jsonType float64
[neginf] Returned normally, err = request body has an error: doesn't match schema: validation failed due to: at '': invalid jsonType float64
This confirms the upstream jsonschema/v6 v6.0.3 release treats the NaN/Inf case as a bug and fixes it at the source. It also confirms useJSONSchema2020 is the reachable path: patching only the transitive dep removes the panic without touching kin-openapi code.
Why This Is a Vulnerability, Not by Design
- The library explicitly refuses NaN/Inf in its own visitor (
ErrSchemaInputNaN/ErrSchemaInputInfatschema.go:1968). The stated policy is: these values are not allowed. - The OAS 3.1 dispatch (
useJSONSchema2020) simply omits the same guard — a coding gap, not a design decision. - Upstream
jsonschema/v6v6.0.3 fixes the same case as a bug. Two independent code owners agree it should not panic. - The trigger is a single HTTP request body an unauthenticated client can send. There is no legitimate content-authoring reason to submit
.nan/.infas a numeric field.
Impact
- Per-request denial of service (net/http hosts). Every crafted request kills its own connection with zero attacker cost. Sustained flooding degrades service reliability and log noise.
- Full-process denial of service (non-net/http hosts or goroutine-spawned validation). No
net/httprecovery wrapper is present; the whole process crashes on a single request. - Attack surface is any OAS 3.1 API that accepts YAML bodies with numeric constraints. These constraints (
minimum,maximum,exclusiveMinimum,exclusiveMaximum,multipleOf) are common on any numeric field with a range.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/getkin/kin-openapi"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.148.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-100352"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-15T20:20:27Z",
"nvd_published_at": "2026-10-15T16:17:31Z",
"severity": "HIGH"
},
"details": "## Summary\n\nkin-openapi guards against `NaN` and `Inf` values in its built-in schema visitor (`visitJSON`) by returning `ErrSchemaInputNaN` / `ErrSchemaInputInf` when a `float64` input violates those constraints. For OAS 3.1 specs, however, `Schema.VisitJSON` routes through `useJSONSchema2020`, which hands the value directly to `santhosh-tekuri/jsonschema/v6` v6.0.2 without applying the same guard.\n\nInside `jsonschema/v6` v6.0.2, `numValidate` builds a `*big.Rat` from the input via `big.Rat.SetString(fmt.Sprintf(\"%v\", v))`. For `NaN`/`Inf` this parse fails silently and returns `nil`. `numValidate` then dereferences the nil `*big.Rat` (in `math/big.(*Rat).Cmp`), producing a Go runtime panic.\n\nAn attacker delivers this by sending an HTTP request with `Content-Type: application/yaml` (or `application/x-yaml`) and a YAML body containing `.nan`, `.inf`, or `-.inf`. The `YamlBodyDecoder` decodes those tokens into `math.NaN()` / `math.Inf(\u00b11)` (standard YAML 1.2 behavior), and they propagate to the unguarded `useJSONSchema2020` path whenever the schema declares a numeric constraint (`minimum`, `maximum`, `exclusiveMinimum`, `exclusiveMaximum`, or `multipleOf`).\n\n## Details\n### Root Cause\n\nThe built-in visitor `visitJSON` at `openapi3/schema.go:1968` guards NaN/Inf explicitly:\n\n```go\ncase float64:\n if math.IsNaN(value) {\n return ErrSchemaInputNaN\n }\n if math.IsInf(value, 0) {\n return ErrSchemaInputInf\n }\n```\n\nFor OAS 3.1 specs, `VisitJSON` dispatches to `useJSONSchema2020` (`openapi3/schema_jsonschema_validator.go:204`), which contains no such guard:\n\n```go\nfunc (schema *Schema) useJSONSchema2020(settings *schemaValidationSettings, value any) error {\n validator, err := newJSONSchemaValidator(schema)\n if err != nil {\n return schema.visitJSON(settings, value)\n }\n return validator.validate(value) // value handed straight through\n}\n```\n\n`jsonSchemaValidator.validate` calls `jsonschema/v6.Schema.Validate` (line 146), which reaches `numValidate` in v6.0.2. There, `big.Rat.SetString(fmt.Sprintf(\"%v\", v))` returns `(nil, false)` for `NaN`/`Inf`, and the code dereferences the `nil` `*big.Rat` in `Rat.Cmp`, causing the panic.\n\n## Proof of Concept\n\n### Environment\n\n- kin-openapi v0.144.0 (tag `v0.144.0`, commit `f0407d5`)\n- santhosh-tekuri/jsonschema/v6 v6.0.2 (transitive dep)\n- Go 1.26.7\n\n### Spec\n\nMinimal OAS 3.1 spec (`spec.yaml`) declaring a YAML body with a numeric constraint:\n\n```yaml\nopenapi: \u00273.1.0\u0027\ninfo: { title: Test, version: \u00271.0\u0027 }\npaths:\n /test:\n post:\n requestBody:\n required: true\n content:\n application/yaml:\n schema:\n type: number\n minimum: 0\n responses:\n \u0027200\u0027: { description: OK }\n```\n\n### Trigger\n\nA single `POST /test` with `Content-Type: application/yaml` and body `.nan`, `.inf`, or `-.inf`. All three variants panic:\n\n```\n=== RUN TestNaNInf\n[nan] PANIC (confirms vuln): runtime error: invalid memory address or nil pointer dereference\n[inf] PANIC (confirms vuln): runtime error: invalid memory address or nil pointer dereference\n[neginf] PANIC (confirms vuln): runtime error: invalid memory address or nil pointer dereference\n```\n\n### Panic stack trace (confirms exact chain)\n\n```\npanic: runtime error: invalid memory address or nil pointer dereference\n\nmath/big.(*Rat).Cmp(0x0, ...) \u003c- nil *big.Rat dereferenced\n C:/Program Files/Go/src/math/big/rat.go:492\ngithub.com/santhosh-tekuri/jsonschema/v6.(*validator).numValidate(...)\n .../jsonschema/v6@v6.0.2/validator.go:525\ngithub.com/santhosh-tekuri/jsonschema/v6.(*validator).validate(...)\n .../jsonschema/v6@v6.0.2/validator.go:168\ngithub.com/santhosh-tekuri/jsonschema/v6.(*Schema).validate(...)\n .../jsonschema/v6@v6.0.2/validator.go:34\ngithub.com/getkin/kin-openapi/openapi3.(*jsonSchemaValidator).validate(...)\n openapi3/schema_jsonschema_validator.go:146\ngithub.com/getkin/kin-openapi/openapi3.(*Schema).useJSONSchema2020(...) \u003c- MISSING NaN/Inf guard\n openapi3/schema_jsonschema_validator.go:211\ngithub.com/getkin/kin-openapi/openapi3.(*Schema).VisitJSON(...)\n openapi3/schema.go:1946\ngithub.com/getkin/kin-openapi/openapi3filter.ValidateRequestBody(...)\n openapi3filter/validate_request.go:364\ngithub.com/getkin/kin-openapi/openapi3filter.ValidateRequest(...)\n openapi3filter/validate_request.go:96\n```\n\n### net/http behavior (severity nuance)\n\nBehind a standard `net/http` server, the panic is recovered per-connection. The client sees a dropped connection; the server process continues:\n\n```\nSending POST /test body=.nan against real net/http server...\n2026/08/25 http: panic serving 127.0.0.1:40625: runtime error: invalid memory address or nil pointer dereference\nCLIENT ERROR (connection dropped): Post \".../test\": EOF\nProcess still alive after request: true\n```\n\nThis is a **recoverable panic**, unlike the recursion finding. `recover()` catches it (verified by capturing the panic value in a `defer` in the same goroutine). Non-`net/http` hosts or validation performed in an application-spawned goroutine are not covered by that recovery and would experience a full-process crash.\n\n### Fix verification\n\nUpgrading only the transitive dependency to `jsonschema/v6@v6.0.3` (via `go get github.com/santhosh-tekuri/jsonschema/v6@v6.0.3`) eliminates the panic entirely; all three payloads return a clean validation error:\n\n```\n[nan] Returned normally, err = request body has an error: doesn\u0027t match schema: validation failed due to: at \u0027\u0027: invalid jsonType float64\n[inf] Returned normally, err = request body has an error: doesn\u0027t match schema: validation failed due to: at \u0027\u0027: invalid jsonType float64\n[neginf] Returned normally, err = request body has an error: doesn\u0027t match schema: validation failed due to: at \u0027\u0027: invalid jsonType float64\n```\n\nThis confirms the upstream `jsonschema/v6` v6.0.3 release treats the NaN/Inf case as a bug and fixes it at the source. It also confirms `useJSONSchema2020` is the reachable path: patching only the transitive dep removes the panic without touching kin-openapi code.\n\n## Why This Is a Vulnerability, Not by Design\n\n- The library explicitly refuses NaN/Inf in its own visitor (`ErrSchemaInputNaN` / `ErrSchemaInputInf` at `schema.go:1968`). The stated policy is: these values are not allowed.\n- The OAS 3.1 dispatch (`useJSONSchema2020`) simply omits the same guard \u2014 a coding gap, not a design decision.\n- Upstream `jsonschema/v6` v6.0.3 fixes the same case as a bug. Two independent code owners agree it should not panic.\n- The trigger is a single HTTP request body an unauthenticated client can send. There is no legitimate content-authoring reason to submit `.nan` / `.inf` as a numeric field.\n\n## Impact\n\n- **Per-request denial of service (net/http hosts).** Every crafted request kills its own connection with zero attacker cost. Sustained flooding degrades service reliability and log noise.\n- **Full-process denial of service (non-net/http hosts or goroutine-spawned validation).** No `net/http` recovery wrapper is present; the whole process crashes on a single request.\n- **Attack surface is any OAS 3.1 API that accepts YAML bodies with numeric constraints.** These constraints (`minimum`, `maximum`, `exclusiveMinimum`, `exclusiveMaximum`, `multipleOf`) are common on any numeric field with a range.",
"id": "GHSA-rj39-cv6w-8wv7",
"modified": "2026-10-15T20:20:27Z",
"published": "2026-10-15T20:20:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getkin/kin-openapi/security/advisories/GHSA-rj39-cv6w-8wv7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100352"
},
{
"type": "WEB",
"url": "https://github.com/getkin/kin-openapi/commit/4487f198ab8be0c37d6ca72c54f5dca4dc25270e"
},
{
"type": "PACKAGE",
"url": "https://github.com/getkin/kin-openapi"
},
{
"type": "WEB",
"url": "https://github.com/getkin/kin-openapi/releases/tag/v0.148.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kin-openapi: YAML NaN/Inf Values Bypass Built-in Guards and Panic via OAS 3.1 Validation Path"
}
GHSA-RJ53-J6JW-7F7G
Vulnerability from github – Published: 2025-07-08 19:09 – Updated: 2025-07-08 19:09Summary
Sending a message that modifies the validator set at the epoch boundary halts the chain.
Impact
Denial of Service - Comos-sdk prevents modifying the validator set from two different modules - https://github.com/cosmos/cosmos-sdk/blob/release/v0.50.x/types/module/module.go#L811. Such an operation leads to panic and chain halt.
Detailed Post mortem
https://boiling-lake-106.notion.site/2025-06-18-Genesis-mainnet-chain-halt-post-mortem-229f60cc1b5f80b7adf5e3ea0541ea87
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/babylonlabs-io/babylon/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-08T19:09:11Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nSending a message that modifies the validator set at the epoch boundary halts the chain.\n\n### Impact\n\nDenial of Service - Comos-sdk prevents modifying the validator set from two different modules - https://github.com/cosmos/cosmos-sdk/blob/release/v0.50.x/types/module/module.go#L811. Such an operation leads to panic and chain halt.\n\n### Detailed Post mortem\n\nhttps://boiling-lake-106.notion.site/2025-06-18-Genesis-mainnet-chain-halt-post-mortem-229f60cc1b5f80b7adf5e3ea0541ea87",
"id": "GHSA-rj53-j6jw-7f7g",
"modified": "2025-07-08T19:09:11Z",
"published": "2025-07-08T19:09:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/babylonlabs-io/babylon/security/advisories/GHSA-rj53-j6jw-7f7g"
},
{
"type": "WEB",
"url": "https://github.com/babylonlabs-io/babylon/pull/1244/files"
},
{
"type": "WEB",
"url": "https://boiling-lake-106.notion.site/2025-06-18-Babylon-Genesis-Chain-Halt-Post-Mortem-229f60cc1b5f80b7adf5e3ea0541ea87"
},
{
"type": "PACKAGE",
"url": "https://github.com/babylonlabs-io/babylon"
},
{
"type": "WEB",
"url": "https://github.com/babylonlabs-io/babylon/releases/tag/v2.1.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H",
"type": "CVSS_V4"
}
],
"summary": "Babylon vulnerable to chain halt when a message modifies the validator set at the epoch boundary"
}
GHSA-RJ67-JFHC-GR45
Vulnerability from github – Published: 2026-09-25 15:31 – Updated: 2026-10-03 12:31In the Linux kernel, the following vulnerability has been resolved:
nvdimm: pmem: keep PREFLUSH before data writes
pmem_submit_bio() records a REQ_PREFLUSH error, but continues to copy the bio data and can later overwrite the error with a successful REQ_FUA flush. That lets data writes run after a failed preflush and can complete the bio successfully despite the failed ordering barrier.
Run the REQ_PREFLUSH flush synchronously before touching the bio data and complete the bio with the flush error if it fails. Keep asynchronous flush chaining for REQ_FUA. At that point, data copy has completed and the parent bio can wait for the chained flush bio.
{
"affected": [],
"aliases": [
"CVE-2026-98161"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-25T14:17:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvdimm: pmem: keep PREFLUSH before data writes\n\npmem_submit_bio() records a REQ_PREFLUSH error, but continues to copy the\nbio data and can later overwrite the error with a successful REQ_FUA flush.\nThat lets data writes run after a failed preflush and can complete the bio\nsuccessfully despite the failed ordering barrier.\n\nRun the REQ_PREFLUSH flush synchronously before touching the bio data and\ncomplete the bio with the flush error if it fails. Keep asynchronous flush\nchaining for REQ_FUA. At that point, data copy has completed and the parent\nbio can wait for the chained flush bio.",
"id": "GHSA-rj67-jfhc-gr45",
"modified": "2026-10-03T12:31:29Z",
"published": "2026-09-25T15:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98161"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72561ca1ab96f0f0f32737a6171641e05a318538"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/770a90c2127220f0fc194ce909ad4f0842e141cb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c644a2f8fef5618fcf453c591177700fd07dd024"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d34c30bc994328d9cf6749b2e9a32aabd08fd076"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RJG6-RV3W-VM28
Vulnerability from github – Published: 2025-08-12 18:31 – Updated: 2025-08-12 18:31Improper check for unusual or exceptional conditions in the Linux kernel-mode driver for some Intel(R) 800 Series Ethernet before version 1.17.2 may allow an authenticated user to potentially enable escalation of privilege via local access.
{
"affected": [],
"aliases": [
"CVE-2025-24303"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-12T17:15:33Z",
"severity": "HIGH"
},
"details": "Improper check for unusual or exceptional conditions in the Linux kernel-mode driver for some Intel(R) 800 Series Ethernet before version 1.17.2 may allow an authenticated user to potentially enable escalation of privilege via local access.",
"id": "GHSA-rjg6-rv3w-vm28",
"modified": "2025-08-12T18:31:28Z",
"published": "2025-08-12T18:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24303"
},
{
"type": "WEB",
"url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01296.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-RJM7-96C8-22JG
Vulnerability from github – Published: 2023-10-13 00:30 – Updated: 2024-04-04 08:37An Improper Check for Unusual or Exceptional Conditions vulnerability in the SIP ALG of Juniper Networks Junos OS on SRX Series and MX Series allows an unauthenticated network-based attacker to cause an integrity impact in connected networks.
If the SIP ALG is configured and a device receives a specifically malformed SIP packet, the device prevents this packet from being forwarded, but any subsequently received retransmissions of the same packet are forwarded as if they were valid.
This issue affects Juniper Networks Junos OS on SRX Series and MX Series:
- 20.4 versions prior to 20.4R3-S5;
- 21.1 versions prior to 21.1R3-S4;
- 21.2 versions prior to 21.2R3-S4;
- 21.3 versions prior to 21.3R3-S3;
- 21.4 versions prior to 21.4R3-S2;
- 22.1 versions prior to 22.1R2-S2, 22.1R3;
- 22.2 versions prior to 22.2R2-S1, 22.2R3;
- 22.3 versions prior to 22.3R1-S2, 22.3R2.
This issue doesn't not affected releases prior to 20.4R1.
{
"affected": [],
"aliases": [
"CVE-2023-44198"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-13T00:15:12Z",
"severity": "HIGH"
},
"details": "\nAn Improper Check for Unusual or Exceptional Conditions vulnerability in the SIP ALG of Juniper Networks Junos OS on SRX Series and MX Series allows an unauthenticated network-based attacker to cause an integrity impact in connected networks.\n\nIf the SIP ALG is configured and a device receives a specifically malformed SIP packet, the device prevents this packet from being forwarded, but any subsequently received retransmissions of the same packet are forwarded as if they were valid.\n\nThis issue affects Juniper Networks Junos OS on SRX Series and MX Series:\n\n\n\n * 20.4 versions prior to 20.4R3-S5;\n * 21.1 versions prior to 21.1R3-S4;\n * 21.2 versions prior to 21.2R3-S4;\n * 21.3 versions prior to 21.3R3-S3;\n * 21.4 versions prior to 21.4R3-S2;\n * 22.1 versions prior to 22.1R2-S2, 22.1R3;\n * 22.2 versions prior to 22.2R2-S1, 22.2R3;\n * 22.3 versions prior to 22.3R1-S2, 22.3R2.\n\n\n\n\nThis issue doesn\u0027t not affected releases prior to 20.4R1.\n\n\n\n",
"id": "GHSA-rjm7-96c8-22jg",
"modified": "2024-04-04T08:37:08Z",
"published": "2023-10-13T00:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44198"
},
{
"type": "WEB",
"url": "https://supportportal.juniper.net/JSA73164"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-3
Strategy: Language Selection
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).
Mitigation
Check the results of all functions that return a value and verify that the value is expected.
Mitigation
If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).
Mitigation MIT-39
- Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
- If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
- Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
- Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-38
If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.
Mitigation
Use system limits, which should help to prevent resource exhaustion. However, the product should still handle low resource conditions since they may still occur.
No CAPEC attack patterns related to this CWE.