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.

703 vulnerabilities reference this CWE, most recent first.

GHSA-CXW3-2F59-5P7F

Vulnerability from github – Published: 2024-10-21 18:31 – Updated: 2025-11-04 00:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

static_call: Handle module init failure correctly in static_call_del_module()

Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain.

If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries.

This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod.

The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space:

    union {
            /* bit 0: 0 = mods, 1 = sites */
            unsigned long type;
            struct static_call_mod *mods;
            struct static_call_site *sites;
};

key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set.

As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus.

Cure it by checking whether the key has a sites or a mods pointer.

If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit.

If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing.

A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-50002"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T18:15:20Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nstatic_call: Handle module init failure correctly in static_call_del_module()\n\nModule insertion invokes static_call_add_module() to initialize the static\ncalls in a module. static_call_add_module() invokes __static_call_init(),\nwhich allocates a struct static_call_mod to either encapsulate the built-in\nstatic call sites of the associated key into it so further modules can be\nadded or to append the module to the module chain.\n\nIf that allocation fails the function returns with an error code and the\nmodule core invokes static_call_del_module() to clean up eventually added\nstatic_call_mod entries.\n\nThis works correctly, when all keys used by the module were converted over\nto a module chain before the failure. If not then static_call_del_module()\ncauses a #GP as it blindly assumes that key::mods points to a valid struct\nstatic_call_mod.\n\nThe problem is that key::mods is not a individual struct member of struct\nstatic_call_key, it\u0027s part of a union to save space:\n\n        union {\n                /* bit 0: 0 = mods, 1 = sites */\n                unsigned long type;\n                struct static_call_mod *mods;\n                struct static_call_site *sites;\n\t};\n\nkey::sites is a pointer to the list of built-in usage sites of the static\ncall. The type of the pointer is differentiated by bit 0. A mods pointer\nhas the bit clear, the sites pointer has the bit set.\n\nAs static_call_del_module() blidly assumes that the pointer is a valid\nstatic_call_mod type, it fails to check for this failure case and\ndereferences the pointer to the list of built-in call sites, which is\nobviously bogus.\n\nCure it by checking whether the key has a sites or a mods pointer.\n\nIf it\u0027s a sites pointer then the key is not to be touched. As the sites are\nwalked in the same order as in __static_call_init() the site walk can be\nterminated because all subsequent sites have not been touched by the init\ncode due to the error exit.\n\nIf it was converted before the allocation fail, then the inner loop which\nsearches for a module match will find nothing.\n\nA fail in the second allocation in __static_call_init() is harmless and\ndoes not require special treatment. The first allocation succeeded and\nconverted the key to a module chain. That first entry has mod::mod == NULL\nand mod::next == NULL, so the inner loop of static_call_del_module() will\nneither find a module match nor a module chain. The next site in the walk\nwas either already converted, but can\u0027t match the module, or it will exit\nthe outer loop because it has a static_call_site pointer and not a\nstatic_call_mod pointer.",
  "id": "GHSA-cxw3-2f59-5p7f",
  "modified": "2025-11-04T00:31:44Z",
  "published": "2024-10-21T18:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50002"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2b494471797bff3d257e99dc0a7abb0c5ff3b4cd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4b30051c4864234ec57290c3d142db7c88f10d8a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9c48c2b53191bf991361998f5bb97b8f2fc5a89c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b566c7d8a2de403ccc9d8a06195e19bbb386d0e4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c0abbbe8c98c077292221ec7e2baa667c9f0974c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ed4c8ce0f307f2ab8778aeb40a8866d171e8f128"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    }
  ],
  "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-F266-7P9X-6359

Vulnerability from github – Published: 2022-05-24 17:47 – Updated: 2022-07-13 00:01
VLAI
Details

In the standard library in Rust before 1.52.0, the Zip implementation has a panic safety issue. It calls __iterator_get_unchecked() more than once for the same index when the underlying iterator panics (in certain conditions). This bug could lead to a memory safety violation due to an unmet safety requirement for the TrustedRandomAccess trait.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-28876"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-119",
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-11T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "In the standard library in Rust before 1.52.0, the Zip implementation has a panic safety issue. It calls __iterator_get_unchecked() more than once for the same index when the underlying iterator panics (in certain conditions). This bug could lead to a memory safety violation due to an unmet safety requirement for the TrustedRandomAccess trait.",
  "id": "GHSA-f266-7p9x-6359",
  "modified": "2022-07-13T00:01:15Z",
  "published": "2022-05-24T17:47:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28876"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rust-lang/rust/issues/81740"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rust-lang/rust/pull/81741"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/CZ337CM4GFJLRDFVQCGC7J25V65JXOG5"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TFUO3URYCO73D2Q4WYJBWAMJWGGVXQO4"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VZG65GUW6Z2CYOQHF7T3TB5CZKIX6ZJE"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202210-09"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F2CR-R825-QV2M

Vulnerability from github – Published: 2022-05-24 17:25 – Updated: 2024-03-21 03:33
VLAI
Details

** UNSUPPORTED WHEN ASSIGNED ** An issue was discovered in ReadyTalk Avian 1.2.0. The vm::arrayCopy method defined in classpath-common.h returns silently when a negative length is provided (instead of throwing an exception). This could result in data being lost during the copy, with varying consequences depending on the subsequent use of the destination buffer. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-17361"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-119",
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-12T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "** UNSUPPORTED WHEN ASSIGNED ** An issue was discovered in ReadyTalk Avian 1.2.0. The vm::arrayCopy method defined in classpath-common.h returns silently when a negative length is provided (instead of throwing an exception). This could result in data being lost during the copy, with varying consequences depending on the subsequent use of the destination buffer. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.",
  "id": "GHSA-f2cr-r825-qv2m",
  "modified": "2024-03-21T03:33:55Z",
  "published": "2022-05-24T17:25:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-17361"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ReadyTalk/avian/issues"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2020/Aug/10"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2020/Sep/11"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2020/Sep/13"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2020/Sep/14"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F3HV-32HF-CQW9

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

An unauthenticated remote attacker can send data to RsvcHost.exe listening on TCP port 5241 to add entries in the FactoryTalk Diagnostics event log. The attacker can specify long fields in the log entry, which can cause an unhandled exception in wcscpy_s() if a local user opens FactoryTalk Diagnostics Viewer (FTDiagViewer.exe) to view the log entry. Observed in FactoryTalk Diagnostics 6.11. All versions of FactoryTalk Diagnostics are affected.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-5807"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-29T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "An unauthenticated remote attacker can send data to RsvcHost.exe listening on TCP port 5241 to add entries in the FactoryTalk Diagnostics event log. The attacker can specify long fields in the log entry, which can cause an unhandled exception in wcscpy_s() if a local user opens FactoryTalk Diagnostics Viewer (FTDiagViewer.exe) to view the log entry. Observed in FactoryTalk Diagnostics 6.11. All versions of FactoryTalk Diagnostics are affected.",
  "id": "GHSA-f3hv-32hf-cqw9",
  "modified": "2022-05-24T17:37:29Z",
  "published": "2022-05-24T17:37:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5807"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/research/tra-2020-71"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-F46R-RW29-R322

Vulnerability from github – Published: 2025-04-24 16:31 – Updated: 2025-04-25 14:32
VLAI
Summary
React Router allows a DoS via cache poisoning by forcing SPA mode
Details

Summary

After some research, it turns out that it is possible to force an application to switch to SPA mode by adding a header to the request. If the application uses SSR and is forced to switch to SPA, this causes an error that completely corrupts the page. If a cache system is in place, this allows the response containing the error to be cached, resulting in a cache poisoning that strongly impacts the availability of the application.

Details

The vulnerable header is X-React-Router-SPA-Mode; adding it to a request sent to a page/endpoint using a loader throws an error. Here is the vulnerable code :

Capture d’écran 2025-04-07 à 08 28 20

To use the header, React-router must be used in Framework mode, and for the attack to be possible the target page must use a loader.

Steps to reproduce

Versions used for our PoC: - "@react-router/node": "^7.5.0", - "@react-router/serve": "^7.5.0", - "react": "^19.0.0" - "react-dom": "^19.0.0" - "react-router": "^7.5.0"

  1. Install React-Router with its default configuration in Framework mode (https://reactrouter.com/start/framework/installation)
  2. Add a simple page using a loader (example: routes/ssr)

image

  1. Send a request to the endpoint using the loader (/ssr in our case) adding the following header:
X-React-Router-SPA-Mode: yes

Notice the difference between a request with and without the header;

Normal request Capture d’écran 2025-04-07 à 08 36 27

With the header Capture d’écran 2025-04-07 à 08 37 01 image

Impact

If a system cache is in place, it is possible to poison the response by completely altering its content (by an error message), strongly impacting its availability, making the latter impractical via a cache-poisoning attack.

Credits

  • Rachid Allam (zhero;)
  • Yasser Allam (inzo_)
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.5.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "react-router"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.2.0"
            },
            {
              "fixed": "7.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-43864"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-24T16:31:16Z",
    "nvd_published_at": "2025-04-25T01:15:43Z",
    "severity": "HIGH"
  },
  "details": "## Summary\nAfter some research, it turns out that it is possible to force an application to switch to SPA mode by adding a header to the request. If the application uses SSR and is forced to switch to SPA, this causes an error that completely corrupts the page. If a cache system is in place, this allows the response containing the error to be cached, resulting in a cache poisoning that strongly impacts the availability of the application.\n\n## Details\nThe vulnerable header is `X-React-Router-SPA-Mode`; adding it to a request sent to a page/endpoint using a loader throws an error. Here is [the vulnerable code](https://github.com/remix-run/react-router/blob/e6c53a0130559b4a9bd47f9cf76ea5b08a69868a/packages/react-router/lib/server-runtime/server.ts#L407) :\n\n\u003cimg width=\"672\" alt=\"Capture d\u2019e\u0301cran 2025-04-07 a\u0300 08 28 20\" src=\"https://github.com/user-attachments/assets/0a0e9c41-70fd-4dba-9061-892dd6797291\" /\u003e\n\nTo use the header, React-router must be used in Framework mode, and for the attack to be possible the target page must use a loader.\n\n## Steps to reproduce \nVersions used for our PoC: \n- \"@react-router/node\": \"^7.5.0\",\n- \"@react-router/serve\": \"^7.5.0\",\n- \"react\": \"^19.0.0\"\n- \"react-dom\": \"^19.0.0\"\n- \"react-router\": \"^7.5.0\"\n\n1. Install React-Router with its default configuration in Framework mode (https://reactrouter.com/start/framework/installation)\n2. Add a simple page using a loader (example: `routes/ssr`)\n\n![image](https://github.com/user-attachments/assets/d7d04e86-c549-4f4a-9200-2d1b6ac96aad)\n\n3. Send a request to the endpoint using the loader (`/ssr` in our case) adding the following header:\n```\nX-React-Router-SPA-Mode: yes\n```\n\nNotice the difference between a request with and without the header;\n\n**Normal request**\n![Capture d\u2019e\u0301cran 2025-04-07 a\u0300 08 36 27](https://github.com/user-attachments/assets/da372b70-7c68-41c1-aac1-e5be94f22526)\n\n**With the header**\n![Capture d\u2019e\u0301cran 2025-04-07 a\u0300 08 37 01](https://github.com/user-attachments/assets/98101720-cb5b-44e9-bff5-463c0b4dab2a)\n![image](https://github.com/user-attachments/assets/c16a101e-688c-4757-9e05-61308ed8a2de)\n\n## Impact\nIf a system cache is in place, it is possible to poison the response by completely altering its content (*by an error message*), strongly impacting its availability, making the latter impractical via a cache-poisoning attack.\n\n## Credits\n- Rachid Allam (zhero;)\n- Yasser Allam (inzo_)",
  "id": "GHSA-f46r-rw29-r322",
  "modified": "2025-04-25T14:32:54Z",
  "published": "2025-04-24T16:31:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/remix-run/react-router/security/advisories/GHSA-f46r-rw29-r322"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43864"
    },
    {
      "type": "WEB",
      "url": "https://github.com/remix-run/react-router/commit/c84302972a152d851cf5dd859ff332b354b70111"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/remix-run/react-router"
    },
    {
      "type": "WEB",
      "url": "https://github.com/remix-run/react-router/blob/e6c53a0130559b4a9bd47f9cf76ea5b08a69868a/packages/react-router/lib/server-runtime/server.ts#L407"
    }
  ],
  "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": "React Router allows a DoS via cache poisoning by forcing SPA mode"
}

GHSA-F48H-92JW-FXC4

Vulnerability from github – Published: 2023-07-05 18:30 – Updated: 2024-04-04 05:23
VLAI
Details

In Progress MOVEit Transfer before 2021.0.9 (13.0.9), 2021.1.7 (13.1.7), 2022.0.7 (14.0.7), 2022.1.8 (14.1.8), and 2023.0.4 (15.0.4), it is possible for an attacker to invoke a method that results in an unhandled exception. Triggering this workflow can cause the MOVEit Transfer application to terminate unexpectedly.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-36933"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-05T16:15:09Z",
    "severity": "HIGH"
  },
  "details": "In Progress MOVEit Transfer before 2021.0.9 (13.0.9), 2021.1.7 (13.1.7), 2022.0.7 (14.0.7), 2022.1.8 (14.1.8), and 2023.0.4 (15.0.4), it is possible for an attacker to invoke a method that results in an unhandled exception. Triggering this workflow can cause the MOVEit Transfer application to terminate unexpectedly.",
  "id": "GHSA-f48h-92jw-fxc4",
  "modified": "2024-04-04T05:23:48Z",
  "published": "2023-07-05T18:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36933"
    },
    {
      "type": "WEB",
      "url": "https://community.progress.com/s/article/MOVEit-Transfer-2020-1-Service-Pack-July-2023"
    },
    {
      "type": "WEB",
      "url": "https://www.progress.com/moveit"
    }
  ],
  "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-F4J7-9JJ6-PQQX

Vulnerability from github – Published: 2023-03-24 21:30 – Updated: 2023-03-29 15:30
VLAI
Details

In multiple functions of SnoozeHelper.java, there is a possible failure to persist settings due to an uncaught exception. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-261588851

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-20993"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-24T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "In multiple functions of SnoozeHelper.java, there is a possible failure to persist settings due to an uncaught exception. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-261588851",
  "id": "GHSA-f4j7-9jj6-pqqx",
  "modified": "2023-03-29T15:30:18Z",
  "published": "2023-03-24T21:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20993"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2023-05-01"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/pixel/2023-03-01"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/cve/CVE-2023-20993"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

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"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.