Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Package airflow-3 version 3.2.0-r0 fixes 85 vulnerabilities: CVE-2026-44405, CVE-2026-42561, CVE-2026-8838, CVE-2026-41018, CVE-2026-41016...
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "airflow-3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.2.0-r0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"3.2.0-r0"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package airflow-3 version 3.2.0-r0 fixes 85 vulnerabilities: CVE-2026-44405, CVE-2026-42561, CVE-2026-8838, CVE-2026-41018, CVE-2026-41016...",
"id": "CLEANSTART-2026-CW50457",
"modified": "2026-07-30T09:30:18Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apache/airflow"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in airflow-3 3.2.0-r0",
"upstream": [
"CVE-2026-44405",
"CVE-2026-42561",
"CVE-2026-8838",
"CVE-2026-41018",
"CVE-2026-41016",
"CVE-2026-45309",
"CVE-2026-44681",
"CVE-2026-45409",
"CVE-2026-40217",
"CVE-2026-44431",
"CVE-2026-44307",
"CVE-2026-44432",
"CVE-2026-48710",
"CVE-2026-8328",
"ghsa-xqmj-j6mv-4862",
"ghsa-79v4-65xg-pq4g",
"ghsa-r6ph-v2qm-q3c2",
"ghsa-h4gh-qq45-vh27",
"ghsa-m959-cc7f-wv43",
"CVE-2026-26007",
"CVE-2024-12797",
"CVE-2026-34073",
"ghsa-752w-5fwx-jx9f",
"CVE-2026-32597",
"CVE-2026-27459",
"CVE-2026-27448",
"ghsa-5239-wwwm-4pmq",
"CVE-2026-4539",
"ghsa-gc5v-m9x4-r6x2",
"CVE-2026-25645",
"ghsa-c427-h43c-vf67",
"ghsa-p998-jp59-783m",
"ghsa-m5qp-6w8w-w647",
"ghsa-w2fm-2cpv-w7v5",
"ghsa-63hf-3vf5-4wqf",
"ghsa-hcc4-c3v8-rx92",
"ghsa-3wq7-rqq7-wx6j",
"ghsa-2vrm-gr82-f7m5",
"ghsa-mwh4-6h8g-pg8w",
"ghsa-966j-vmvw-g2g9",
"CVE-2026-22815",
"CVE-2026-34513",
"CVE-2026-34514",
"CVE-2026-34515",
"CVE-2026-34516",
"CVE-2026-34517",
"CVE-2026-34518",
"CVE-2026-34519",
"CVE-2026-34520",
"CVE-2026-34525",
"ghsa-53mr-6c8q-9789",
"ghsa-jjhc-v7c2-5hh6",
"ghsa-2g68-c3qc-8985",
"ghsa-f9vj-2wh5-fj8j",
"ghsa-q34m-jh98-gwm2",
"ghsa-hrfv-mqp8-q5rw",
"ghsa-hgf8-39gv-g3f2",
"ghsa-87hc-h4r5-73f7",
"ghsa-29vq-49wr-vm6x",
"CVE-2024-34069",
"CVE-2023-46136",
"CVE-2024-49766",
"CVE-2024-49767",
"CVE-2025-66221",
"CVE-2026-21860",
"CVE-2026-27199",
"ghsa-7f5h-v6xp-fcq8",
"CVE-2025-62727",
"ghsa-fqwm-6jpj-5wxc",
"ghsa-qjxf-f2mg-c6mc",
"ghsa-78cv-mqj4-43f7",
"CVE-2026-31958",
"CVE-2026-35536",
"ghsa-jr27-m4p2-rc6r",
"CVE-2026-30922",
"ghsa-7gcm-g887-7qv7",
"CVE-2026-0994",
"ghsa-mj87-hwqh-73pj",
"CVE-2026-40347",
"ghsa-vfmq-68hx-4jfw",
"CVE-2026-41066",
"ghsa-jj8c-mmj3-mmgv",
"ghsa-v92g-xgxw-vvmm",
"ghsa-68rp-wp8r-4726",
"CVE-2026-27205"
]
}
GHSA-JJ8C-MMJ3-MMGV
Vulnerability from github – Published: 2026-04-16 22:38 – Updated: 2026-06-05 14:29Summary
There is no CSRF protection on the cache feature on most integrations clients.
Details
In authlib.integrations.starlette_client.OAuth, no CSRF protection is set up when using the cache parameter. When not using the cache parameter, the use of SessionMiddleware ties the client to the auth state, preventing CSRF attacks. With the cache, there is no such mechanism. Other integratons have the same issue, it's not just starlette.
The state parameter is taken from the callback URL and the state is fetched from the cache without checking that it is the same client calling the redirect endpoint as was the one that initiated the auth flow.
This issue is documented in RFC 6749 section 10.12: https://datatracker.ietf.org/doc/html/rfc6749#section-10.12
PoC
- Set up a Starlette integration with a cache
- The attacker starts the auth flow up until before the callback URL is followed.
- The attacked sends the redirect URL to the victim
- The victim now completes the authorisation
Impact
This impacts all users that use the cache to store auth state.
All users will be vulnerable to CSRF attacks and may have an attacker's account tied to their own.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "authlib"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41425"
],
"database_specific": {
"cwe_ids": [
"CWE-352"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T22:38:03Z",
"nvd_published_at": "2026-04-24T20:16:27Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThere is no CSRF protection on the cache feature on most integrations clients.\n\n### Details\nIn `authlib.integrations.starlette_client.OAuth`, no CSRF protection is set up when using the cache parameter. When _not_ using the cache parameter, the use of SessionMiddleware ties the client to the auth state, preventing CSRF attacks. With the cache, there is no such mechanism. Other integratons have the same issue, it\u0027s not just starlette.\n\nThe state parameter is taken from the callback URL and the state is fetched from the cache without checking that it is the same client calling the redirect endpoint as was the one that initiated the auth flow.\n\nThis issue is documented in RFC 6749 section 10.12:\nhttps://datatracker.ietf.org/doc/html/rfc6749#section-10.12\n\n### PoC\n- Set up a Starlette integration with a cache\n- The attacker starts the auth flow up until before the callback URL is followed.\n- The attacked sends the redirect URL to the victim\n- The victim now completes the authorisation\n\n### Impact\nThis impacts all users that use the cache to store auth state.\n\nAll users will be vulnerable to CSRF attacks and may have an attacker\u0027s account tied to their own.",
"id": "GHSA-jj8c-mmj3-mmgv",
"modified": "2026-06-05T14:29:21Z",
"published": "2026-04-16T22:38:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/authlib/authlib/security/advisories/GHSA-jj8c-mmj3-mmgv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41425"
},
{
"type": "PACKAGE",
"url": "https://github.com/authlib/authlib"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-25.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Authlib: Cross-site request forging when using cache"
}
GHSA-JJHC-V7C2-5HH6
Vulnerability from github – Published: 2026-04-03 21:59 – Updated: 2026-04-06 23:40Impact
When JWT authentication is enabled (enable_jwt_auth: true), the OIDC userinfo cache uses token[:20] as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters.
This configuration option is not enabled by default. Most instances are not affected.
An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user's cached token. On cache hit, the attacker inherits the legitimate user's identity and permissions. This affects deployments with JWT/OIDC authentication enabled.
Patches
Fixed in v1.83.0. The cache key now uses the full hash of the JWT token.
Workarounds
Disable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "litellm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.83.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35030"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-03T21:59:50Z",
"nvd_published_at": "2026-04-06T17:17:12Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nWhen JWT authentication is enabled (`enable_jwt_auth: true`), the OIDC userinfo cache uses `token[:20]` as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters.\n\nThis configuration option is not enabled by default. **Most instances are not affected.**\n\nAn unauthenticated attacker can craft a token whose first 20 characters match a legitimate user\u0027s cached token. On cache hit, the attacker inherits the legitimate user\u0027s identity and permissions. This affects deployments with JWT/OIDC authentication enabled.\n\n### Patches\n\nFixed in v1.83.0. The cache key now uses the full hash of the JWT token.\n\n### Workarounds\n\nDisable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely.",
"id": "GHSA-jjhc-v7c2-5hh6",
"modified": "2026-04-06T23:40:39Z",
"published": "2026-04-03T21:59:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/BerriAI/litellm/security/advisories/GHSA-jjhc-v7c2-5hh6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35030"
},
{
"type": "PACKAGE",
"url": "https://github.com/BerriAI/litellm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "LiteLLM: Authentication bypass via OIDC userinfo cache key collision"
}
GHSA-JR27-M4P2-RC6R
Vulnerability from github – Published: 2026-03-17 16:17 – Updated: 2026-07-21 15:23Summary
The pyasn1 library is vulnerable to a Denial of Service (DoS) attack caused by uncontrolled recursion when decoding ASN.1 data with deeply nested structures. An attacker can supply a crafted payload containing nested SEQUENCE (0x30) or SET (0x31) tags with Indefinite Length (0x80) markers. This forces the decoder to recursively call itself until the Python interpreter crashes with a RecursionError or consumes all available memory (OOM), crashing the host application.
Details
The vulnerability exists because the decoder iterates through the input stream and recursively calls decodeFun (the decoding callback) for every nested component found, without tracking or limiting the recursion depth.
Vulnerable Code Locations:
1. indefLenValueDecoder (Line 998):
for component in decodeFun(substrate, asn1Spec, allowEoo=True, **options):
This method handles indefinite-length constructed types. It sits inside a while True loop and recursively calls the decoder for every nested tag.
-
valueDecoder(Lines 786 and 907):for component in decodeFun(substrate, componentType, **options):This method handles standard decoding when a schema is present. It contains two distinct recursive calls that lack depth checks: Line 786: Recursively decodes components ofSEQUENCEorSETtypes. Line 907: Recursively decodes elements ofSEQUENCE OForSET OFtypes. -
_decodeComponentsSchemaless(Line 661):for component in decodeFun(substrate, **options):This method handles decoding when no schema is provided.
In all three cases, decodeFun is invoked without passing a depth parameter or checking against a global MAX_ASN1_NESTING limit.
PoC
import sys
from pyasn1.codec.ber import decoder
sys.setrecursionlimit(100000)
print("[*] Generating Recursion Bomb Payload...")
depth = 50_000
chunk = b'\x30\x80'
payload = chunk * depth
print(f"[*] Payload size: {len(payload) / 1024:.2f} KB")
print("[*] Triggering Decoder...")
try:
decoder.decode(payload)
except RecursionError:
print("[!] Crashed: Recursion Limit Hit")
except MemoryError:
print("[!] Crashed: Out of Memory")
except Exception as e:
print(f"[!] Crashed: {e}")
[*] Payload size: 9.77 KB
[*] Triggering Decoder...
[!] Crashed: Recursion Limit Hit
Impact
- This is an unhandled runtime exception that typically terminates the worker process or thread handling the request. This allows a remote attacker to trivially kill service workers with a small payload (<100KB), resulting in a Denial of Service. Furthermore, in environments where recursion limits are increased, this leads to server-wide memory exhaustion.
- Service Crash: Any service using
pyasn1to parse untrusted ASN.1 data (e.g., LDAP, SNMP, Kerberos, X.509 parsers) can be crashed remotely. - Resource Exhaustion: The attack consumes RAM linearly with the nesting depth. A small payload (<200KB) can consume hundreds of megabytes of RAM or exhaust the stack.
Credits
Vulnerability discovered by Kevin Tu of TMIR at ByteDance.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.6.2"
},
"package": {
"ecosystem": "PyPI",
"name": "pyasn1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30922"
],
"database_specific": {
"cwe_ids": [
"CWE-674",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-17T16:17:33Z",
"nvd_published_at": "2026-03-18T04:17:18Z",
"severity": "HIGH"
},
"details": "### Summary\nThe `pyasn1` library is vulnerable to a Denial of Service (DoS) attack caused by uncontrolled recursion when decoding ASN.1 data with deeply nested structures. An attacker can supply a crafted payload containing nested `SEQUENCE` (`0x30`) or `SET` (`0x31`) tags with Indefinite Length (`0x80`) markers. This forces the decoder to recursively call itself until the Python interpreter crashes with a `RecursionError` or consumes all available memory (OOM), crashing the host application.\n\n### Details\nThe vulnerability exists because the decoder iterates through the input stream and recursively calls `decodeFun` (the decoding callback) for every nested component found, without tracking or limiting the recursion depth.\nVulnerable Code Locations:\n1. `indefLenValueDecoder` (Line 998):\n```for component in decodeFun(substrate, asn1Spec, allowEoo=True, **options):```\nThis method handles indefinite-length constructed types. It sits inside a `while True` loop and recursively calls the decoder for every nested tag.\n\n2. `valueDecoder` (Lines 786 and 907):\n```for component in decodeFun(substrate, componentType, **options):```\nThis method handles standard decoding when a schema is present. It contains two distinct recursive calls that lack depth checks: Line 786: Recursively decodes components of `SEQUENCE` or `SET` types. Line 907: Recursively decodes elements of `SEQUENCE OF` or `SET OF` types.\n\n4. `_decodeComponentsSchemaless` (Line 661):\n```for component in decodeFun(substrate, **options):```\nThis method handles decoding when no schema is provided.\n\nIn all three cases, `decodeFun` is invoked without passing a `depth` parameter or checking against a global `MAX_ASN1_NESTING` limit.\n\n### PoC\n```\nimport sys\nfrom pyasn1.codec.ber import decoder\n\nsys.setrecursionlimit(100000)\n\nprint(\"[*] Generating Recursion Bomb Payload...\")\ndepth = 50_000\nchunk = b\u0027\\x30\\x80\u0027 \npayload = chunk * depth\n\nprint(f\"[*] Payload size: {len(payload) / 1024:.2f} KB\")\nprint(\"[*] Triggering Decoder...\")\n\ntry:\n decoder.decode(payload)\nexcept RecursionError:\n print(\"[!] Crashed: Recursion Limit Hit\")\nexcept MemoryError:\n print(\"[!] Crashed: Out of Memory\")\nexcept Exception as e:\n print(f\"[!] Crashed: {e}\")\n```\n\n```\n[*] Payload size: 9.77 KB\n[*] Triggering Decoder...\n[!] Crashed: Recursion Limit Hit\n```\n\n### Impact\n- This is an unhandled runtime exception that typically terminates the worker process or thread handling the request. This allows a remote attacker to trivially kill service workers with a small payload (\u003c100KB), resulting in a Denial of Service. Furthermore, in environments where recursion limits are increased, this leads to server-wide memory exhaustion.\n- Service Crash: Any service using `pyasn1` to parse untrusted ASN.1 data (e.g., LDAP, SNMP, Kerberos, X.509 parsers) can be crashed remotely.\n- Resource Exhaustion: The attack consumes RAM linearly with the nesting depth. A small payload (\u003c200KB) can consume hundreds of megabytes of RAM or exhaust the stack.\n\n### Credits\nVulnerability discovered by Kevin Tu of TMIR at ByteDance.",
"id": "GHSA-jr27-m4p2-rc6r",
"modified": "2026-07-21T15:23:46Z",
"published": "2026-03-17T16:17:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pyasn1/pyasn1/security/advisories/GHSA-jr27-m4p2-rc6r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30922"
},
{
"type": "WEB",
"url": "https://github.com/pyasn1/pyasn1/commit/5a49bd1fe93b5b866a1210f6bf0a3924f21572c8"
},
{
"type": "WEB",
"url": "https://github.com/pyasn1/pyasn1/commit/25ad481c19fdb006e20485ef3fc2e5b3eff30ef0"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:10184"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22970"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22987"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:24761"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:24762"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:37275"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41928"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6309"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6568"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6720"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6912"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6926"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8437"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-30922"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2448553"
},
{
"type": "PACKAGE",
"url": "https://github.com/pyasn1/pyasn1"
},
{
"type": "WEB",
"url": "https://github.com/pyasn1/pyasn1/releases/tag/v0.6.3"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/pyasn1/PYSEC-2026-2263.yaml"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2026/05/msg00001.html"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-30922.json"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:12176"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13508"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13512"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13545"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13553"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13902"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13916"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13917"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:14020"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:16009"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:17083"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:17611"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19138"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19355"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19375"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19712"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20588"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22131"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22132"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22133"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22134"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22135"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22969"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/03/20/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Denial of Service in pyasn1 via Unbounded Recursion"
}
GHSA-M5QP-6W8W-W647
Vulnerability from github – Published: 2026-04-01 21:43 – Updated: 2026-04-06 23:12Summary
A response with an excessive number of multipart headers may be allowed to use more memory than intended, potentially allowing a DoS vulnerability.
Impact
Multipart headers were not subject to the same size restrictions in place for normal headers, potentially allowing substantially more data to be loaded into memory than intended. However, other restrictions in place limit the impact of this vulnerability.
Patch: https://github.com/aio-libs/aiohttp/commit/8a74257b3804c9aac0bf644af93070f68f6c5a6f
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.13.3"
},
"package": {
"ecosystem": "PyPI",
"name": "aiohttp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.13.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34516"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-01T21:43:07Z",
"nvd_published_at": "2026-04-01T21:16:59Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nA response with an excessive number of multipart headers may be allowed to use more memory than intended, potentially allowing a DoS vulnerability.\n\n### Impact\n\nMultipart headers were not subject to the same size restrictions in place for normal headers, potentially allowing substantially more data to be loaded into memory than intended. However, other restrictions in place limit the impact of this vulnerability.\n\n-----\n\nPatch: https://github.com/aio-libs/aiohttp/commit/8a74257b3804c9aac0bf644af93070f68f6c5a6f",
"id": "GHSA-m5qp-6w8w-w647",
"modified": "2026-04-06T23:12:04Z",
"published": "2026-04-01T21:43:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/security/advisories/GHSA-m5qp-6w8w-w647"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34516"
},
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/commit/8a74257b3804c9aac0bf644af93070f68f6c5a6f"
},
{
"type": "PACKAGE",
"url": "https://github.com/aio-libs/aiohttp"
},
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/releases/tag/v3.13.4"
}
],
"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:U",
"type": "CVSS_V4"
}
],
"summary": "AIOHTTP has a Multipart Header Size Bypass"
}
GHSA-M959-CC7F-WV43
Vulnerability from github – Published: 2026-03-27 19:56 – Updated: 2026-06-05 17:51Summary
In versions of cryptography prior to 46.0.5, DNS name constraints were only validated against SANs within child certificates, and not the "peer name" presented during each validation. Consequently, cryptography would allow a peer named bar.example.com to validate against a wildcard leaf certificate for *.example.com, even if the leaf's parent certificate (or upwards) contained an excluded subtree constraint for bar.example.com.
This behavior resulted from a gap between RFC 5280 (which defines Name Constraint semantics) and RFC 9525 (which defines service identity semantics): put together, neither states definitively whether Name Constraints should be applied to peer names. To close this gap, cryptography now conservatively rejects any validation where the peer name would be rejected by a name constraint if it were a SAN instead.
In practice, exploitation of this bypass requires an uncommon X.509 topology, one that the Web PKI avoids because it exhibits these kinds of problems. Consequently, we consider this a medium-to-low impact severity.
See CVE-2025-61727 for a similar bypass in Go's crypto/x509.
Remediation
Users should upgrade to 46.0.6 or newer.
Attribution
Reporter: @1seal
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "cryptography"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "46.0.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34073"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-27T19:56:21Z",
"nvd_published_at": "2026-03-31T03:15:59Z",
"severity": "LOW"
},
"details": "## Summary\n\nIn versions of cryptography prior to 46.0.5, DNS name constraints were only validated against SANs within child certificates, and not the \"peer name\" presented during each validation. Consequently, cryptography would allow a peer named `bar.example.com` to validate against a wildcard leaf certificate for `*.example.com`, even if the leaf\u0027s parent certificate (or upwards) contained an excluded subtree constraint for `bar.example.com`.\n\nThis behavior resulted from a gap between RFC 5280 (which defines Name Constraint semantics) and RFC 9525 (which defines service identity semantics): put together, neither states definitively whether Name Constraints should be applied to peer names. To close this gap, cryptography now conservatively rejects any validation where the peer name would be rejected by a name constraint if it were a SAN instead.\n\nIn practice, exploitation of this bypass requires an uncommon X.509 topology, one that the Web PKI avoids because it exhibits these kinds of problems. Consequently, we consider this a medium-to-low impact severity.\n\nSee CVE-2025-61727 for a similar bypass in Go\u0027s `crypto/x509`.\n\n## Remediation\n\nUsers should upgrade to 46.0.6 or newer. \n\n## Attribution\n\nReporter: @1seal",
"id": "GHSA-m959-cc7f-wv43",
"modified": "2026-06-05T17:51:29Z",
"published": "2026-03-27T19:56:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pyca/cryptography/security/advisories/GHSA-m959-cc7f-wv43"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34073"
},
{
"type": "PACKAGE",
"url": "https://github.com/pyca/cryptography"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/cryptography/PYSEC-2026-35.yaml"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "cryptography has incomplete DNS name constraint enforcement on peer names"
}
GHSA-MJ87-HWQH-73PJ
Vulnerability from github – Published: 2026-04-15 19:45 – Updated: 2026-04-24 20:51Summary
A denial of service vulnerability exists when parsing crafted multipart/form-data requests with large preamble or epilogue sections.
Details
Two inefficient multipart parsing paths could be abused with attacker-controlled input.
Before the first multipart boundary, the parser handled leading CR and LF bytes inefficiently while searching for the start of the first part. After the closing boundary, the parser continued processing trailing epilogue data instead of discarding it immediately. As a result, parsing time could grow with the size of crafted data placed before the first boundary or after the closing boundary.
Impact
An attacker can send oversized malformed multipart bodies that consume excessive CPU time during request parsing, reducing request-handling capacity and delaying legitimate requests. This issue degrades availability but does not typically result in a complete denial of service for the entire application.
Mitigation
Upgrade to version 0.0.26 or later, which skips ahead to the next boundary candidate when processing leading CR/LF data and immediately discards epilogue data after the closing boundary.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "python-multipart"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.26"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40347"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-834"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-15T19:45:44Z",
"nvd_published_at": "2026-04-18T00:16:38Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nA denial of service vulnerability exists when parsing crafted `multipart/form-data` requests with large preamble or epilogue sections.\n\n### Details\n\nTwo inefficient multipart parsing paths could be abused with attacker-controlled input.\n\nBefore the first multipart boundary, the parser handled leading CR and LF bytes inefficiently while searching for the start of the first part. After the closing boundary, the parser continued processing trailing epilogue data instead of discarding it immediately. As a result, parsing time could grow with the size of crafted data placed before the first boundary or after the closing boundary.\n\n### Impact\n\nAn attacker can send oversized malformed multipart bodies that consume excessive CPU time during request parsing, reducing request-handling capacity and delaying legitimate requests. This issue degrades availability but does not typically result in a complete denial of service for the entire application.\n\n### Mitigation\n\nUpgrade to version `0.0.26` or later, which skips ahead to the next boundary candidate when processing leading CR/LF data and immediately discards epilogue data after the closing boundary.",
"id": "GHSA-mj87-hwqh-73pj",
"modified": "2026-04-24T20:51:11Z",
"published": "2026-04-15T19:45:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Kludex/python-multipart/security/advisories/GHSA-mj87-hwqh-73pj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40347"
},
{
"type": "PACKAGE",
"url": "https://github.com/Kludex/python-multipart"
},
{
"type": "WEB",
"url": "https://github.com/Kludex/python-multipart/releases/tag/0.0.26"
}
],
"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"
}
],
"summary": "python-multipart affected by Denial of Service via large multipart preamble or epilogue data"
}
GHSA-MWH4-6H8G-PG8W
Vulnerability from github – Published: 2026-04-01 21:48 – Updated: 2026-04-01 21:48Summary
An attacker who controls the reason parameter when creating a Response may be able to inject extra headers or similar exploits.
Impact
In the unlikely situation that an application allows untrusted data to be used in the response's reason parameter, then an attacker could manipulate the response to send something different from what the developer intended.
Patch: https://github.com/aio-libs/aiohttp/commit/53b35a2f8869c37a133e60bf1a82a1c01642ba2b
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.13.3"
},
"package": {
"ecosystem": "PyPI",
"name": "aiohttp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.13.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34519"
],
"database_specific": {
"cwe_ids": [
"CWE-113"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-01T21:48:24Z",
"nvd_published_at": "2026-04-01T21:17:00Z",
"severity": "LOW"
},
"details": "### Summary\n\nAn attacker who controls the `reason` parameter when creating a `Response` may be able to inject extra headers or similar exploits.\n\n### Impact\n\nIn the unlikely situation that an application allows untrusted data to be used in the response\u0027s `reason` parameter, then an attacker could manipulate the response to send something different from what the developer intended.\n\n-----\n\nPatch: https://github.com/aio-libs/aiohttp/commit/53b35a2f8869c37a133e60bf1a82a1c01642ba2b",
"id": "GHSA-mwh4-6h8g-pg8w",
"modified": "2026-04-01T21:48:24Z",
"published": "2026-04-01T21:48:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/security/advisories/GHSA-mwh4-6h8g-pg8w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34519"
},
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/commit/53b35a2f8869c37a133e60bf1a82a1c01642ba2b"
},
{
"type": "PACKAGE",
"url": "https://github.com/aio-libs/aiohttp"
},
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/releases/tag/v3.13.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "AIOHTTP has HTTP response splitting via \\r in reason phrase"
}
GHSA-P998-JP59-783M
Vulnerability from github – Published: 2026-04-01 21:26 – Updated: 2026-04-06 16:47Summary
On Windows the static resource handler may expose information about a NTLMv2 remote path.
Impact
If an application is running on Windows, and using aiohttp's static resource handler (not recommended in production), then it may be possible for an attacker to extract the hash from an NTLMv2 path and then extract the user's credentials from there.
Patch: https://github.com/aio-libs/aiohttp/commit/0ae2aa076c84573df83fc1fdc39eec0f5862fe3d
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.13.3"
},
"package": {
"ecosystem": "PyPI",
"name": "aiohttp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.13.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34515"
],
"database_specific": {
"cwe_ids": [
"CWE-36",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-01T21:26:36Z",
"nvd_published_at": "2026-04-01T21:16:59Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nOn Windows the static resource handler may expose information about a NTLMv2 remote path.\n\n### Impact\n\nIf an application is running on Windows, and using aiohttp\u0027s static resource handler (not recommended in production), then it may be possible for an attacker to extract the hash from an NTLMv2 path and then extract the user\u0027s credentials from there.\n\n-----\n\nPatch: https://github.com/aio-libs/aiohttp/commit/0ae2aa076c84573df83fc1fdc39eec0f5862fe3d",
"id": "GHSA-p998-jp59-783m",
"modified": "2026-04-06T16:47:09Z",
"published": "2026-04-01T21:26:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/security/advisories/GHSA-p998-jp59-783m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34515"
},
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/commit/0ae2aa076c84573df83fc1fdc39eec0f5862fe3d"
},
{
"type": "PACKAGE",
"url": "https://github.com/aio-libs/aiohttp"
},
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/releases/tag/v3.13.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "AIOHTTP affected by UNC SSRF/NTLMv2 Credential Theft/Local File Read in static resource handler on Windows"
}
GHSA-Q34M-JH98-GWM2
Vulnerability from github – Published: 2024-10-25 19:44 – Updated: 2026-05-20 22:24Applications using Werkzeug to parse multipart/form-data requests are vulnerable to resource exhaustion. A specially crafted form body can bypass the Request.max_form_memory_size setting.
The Request.max_content_length setting, as well as resource limits provided by deployment software and platforms, are also available to limit the resources used during a request. This vulnerability does not affect those settings. All three types of limits should be considered and set appropriately when deploying an application.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.5"
},
"package": {
"ecosystem": "PyPI",
"name": "Werkzeug"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0rc1"
},
{
"fixed": "3.0.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "Quart"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.20.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-49767"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-25T19:44:43Z",
"nvd_published_at": "2024-10-25T20:15:04Z",
"severity": "MODERATE"
},
"details": "Applications using Werkzeug to parse `multipart/form-data` requests are vulnerable to resource exhaustion. A specially crafted form body can bypass the `Request.max_form_memory_size` setting.\n\n\nThe `Request.max_content_length` setting, as well as resource limits provided by deployment software and platforms, are also available to limit the resources used during a request. This vulnerability does not affect those settings. All three types of limits should be considered and set appropriately when deploying an application.",
"id": "GHSA-q34m-jh98-gwm2",
"modified": "2026-05-20T22:24:15Z",
"published": "2024-10-25T19:44:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pallets/werkzeug/security/advisories/GHSA-q34m-jh98-gwm2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49767"
},
{
"type": "WEB",
"url": "https://github.com/pallets/quart/commit/5e78c4169b8eb66b91ead3e62d44721b9e1644ee"
},
{
"type": "WEB",
"url": "https://github.com/pallets/quart/commit/abb04a512496206de279225340ed022852fbf51f"
},
{
"type": "WEB",
"url": "https://github.com/pallets/werkzeug/commit/50cfeebcb0727e18cc52ffbeb125f4a66551179b"
},
{
"type": "WEB",
"url": "https://github.com/pallets/werkzeug/commit/cbb446fdcada7685fce936ded01b76c08dbd6eb5"
},
{
"type": "PACKAGE",
"url": "https://github.com/pallets/werkzeug"
},
{
"type": "WEB",
"url": "https://github.com/pallets/werkzeug/releases/tag/3.0.6"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250103-0007"
}
],
"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:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Werkzeug possible resource exhaustion when parsing file data in forms"
}
GHSA-QJXF-F2MG-C6MC
Vulnerability from github – Published: 2026-03-12 14:19 – Updated: 2026-06-08 19:51In versions of Tornado prior to 6.5.5, the only limit on the number of parts in multipart/form-data is the max_body_size setting (default 100MB). Since parsing occurs synchronously on the main thread, this creates the possibility of denial-of-service due to the cost of parsing very large multipart bodies with many parts.
Tornado 6.5.5 introduces new limits on the size and complexity of multipart bodies, including a default limit of 100 parts per request. These limits are configurable if needed; see tornado.httputil.ParseMultipartConfig. It is also now possible to disable multipart/form-data parsing entirely if it is not required for the application.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.5.4"
},
"package": {
"ecosystem": "PyPI",
"name": "tornado"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.5.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-31958"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-12T14:19:52Z",
"nvd_published_at": "2026-03-11T20:16:16Z",
"severity": "HIGH"
},
"details": "In versions of Tornado prior to 6.5.5, the only limit on the number of parts in `multipart/form-data` is the `max_body_size` setting (default 100MB). Since parsing occurs synchronously on the main thread, this creates the possibility of denial-of-service due to the cost of parsing very large multipart bodies with many parts. \n\nTornado 6.5.5 introduces new limits on the size and complexity of multipart bodies, including a default limit of 100 parts per request. These limits are configurable if needed; see `tornado.httputil.ParseMultipartConfig`. It is also now possible to disable `multipart/form-data` parsing entirely if it is not required for the application.",
"id": "GHSA-qjxf-f2mg-c6mc",
"modified": "2026-06-08T19:51:12Z",
"published": "2026-03-12T14:19:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-qjxf-f2mg-c6mc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31958"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/commit/119a195e290c43ad2d63a2cf012c29d43d6ed839"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tornado/PYSEC-2026-140.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/tornadoweb/tornado"
},
{
"type": "WEB",
"url": "https://github.com/tornadoweb/tornado/releases/tag/v6.5.5"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2026/04/msg00000.html"
}
],
"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",
"type": "CVSS_V4"
}
],
"summary": "Tornado is vulnerable to DoS due to too many multipart parts"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.