Vulnerability-Lookup

Vulnerability from cleanstart

Published

2026-07-30 07:10

Modified

2026-07-30 09:30

Summary

Security fixes in airflow-3 3.1.8-r3

Details

Package airflow-3 version 3.1.8-r3 fixes 15 vulnerabilities: CVE-2026-48522, CVE-2026-48523, CVE-2026-48524, CVE-2026-48525, CVE-2026-48526...

References

URL

Type

https://github.com/apache/airflow

WEB

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Alpine",
        "name": "airflow-3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.8-r3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.1.8-r3"
      ]
    }
  ],
  "credits": [],
  "database_specific": {},
  "details": "Package airflow-3 version 3.1.8-r3 fixes 15 vulnerabilities: CVE-2026-48522, CVE-2026-48523, CVE-2026-48524, CVE-2026-48525, CVE-2026-48526...",
  "id": "CLEANSTART-2026-MS00856",
  "modified": "2026-07-30T09:30:11Z",
  "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.1.8-r3",
  "upstream": [
    "CVE-2026-48522",
    "CVE-2026-48523",
    "CVE-2026-48524",
    "CVE-2026-48525",
    "CVE-2026-48526",
    "ghsa-mf9v-mfxr-j63j",
    "ghsa-qccp-gfcp-xxvc",
    "CVE-2026-44431",
    "CVE-2026-44432",
    "CVE-2026-44307",
    "CVE-2026-45309",
    "CVE-2026-40217",
    "ghsa-2h4p-vjrc-8xpq",
    "ghsa-g794-3fmp-753h",
    "ghsa-wxxx-gvqv-xp7p"
  ]
}

GHSA-2H4P-VJRC-8XPQ

Vulnerability from github – Published: 2026-05-06 21:45 – Updated: 2026-05-13 16:43

Summary

Mako vulnerable to path traversal via backslash URI on Windows in TemplateLookup

Details

Summary

On Windows, a URI using backslash traversal (e.g. \..\..\ secret.txt) bypasses the directory traversal check in Template.__init__ and the posixpath-based normalization in TemplateLookup.get_template(), allowing reads of files outside the configured template directory.

Details

The root cause is a mismatch between posixpath (used for URI normalization in get_template()) and os.path (used for file access via os.path.isfile() and validation via os.path.normpath() in Template.__init__). On Windows, os.path is ntpath, which treats \ as a path separator, while posixpath treats it as a literal character.

The vulnerability chain:

get_template() strips only leading / via re.sub(r"^\/+", "", uri) and normalizes with posixpath — backslash \ is treated as a literal character, so \..\ secret.txt passes through with .. undetected.
Template.__init__() validation uses os.path.normpath() — on Windows this resolves \..\ secret.txt to \secret.txt, which does not start with .., so the startswith("..") check passes.
os.path.isfile() on Windows interprets \ as a path separator, resolving the .. traversal and finding files outside the template directory.

Affected code

mako/lookup.py: TemplateLookup.get_template() uses posixpath.normpath/posixpath.join for path construction but os.path.isfile() for existence check
mako/template.py: Template.__init__() URI validation uses os.path.normpath() which on Windows resolves backslash traversal to a form that passes the startswith("..") guard

Impact

If an application passes user-controlled template names or include paths to TemplateLookup.get_template(), an attacker on Windows may be able to load and disclose readable files outside the configured template directory. The primary impact is local file disclosure. If the targeted file contains Mako/Python template syntax, it may also be parsed and executed as a template.

Remediation

The fix should normalize backslashes to forward slashes early in the URI processing pipeline, before any path operations, to ensure consistent behavior across platforms.

Severity

8.7 (High)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.3.11"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "Mako"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44307"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T21:45:16Z",
    "nvd_published_at": "2026-05-12T22:16:37Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nOn Windows, a URI using backslash traversal (e.g. `\\..\\..\\ secret.txt`) bypasses the directory traversal check in `Template.__init__` and the `posixpath`-based normalization in `TemplateLookup.get_template()`, allowing reads of files outside the configured template directory.\n\n\n## Details\n\nThe root cause is a mismatch between `posixpath` (used for URI normalization in `get_template()`) and `os.path` (used for file access via `os.path.isfile()` and validation via `os.path.normpath()` in `Template.__init__`). On Windows, `os.path` is `ntpath`, which treats `\\` as a path separator, while `posixpath` treats it as a literal character.\n\nThe vulnerability chain:\n\n1. `get_template()` strips only leading `/` via `re.sub(r\"^\\/+\", \"\", uri)` and normalizes with `posixpath` \u2014 backslash `\\` is treated as a literal character, so `\\..\\ secret.txt` passes through with `..` undetected.\n2. `Template.__init__()` validation uses `os.path.normpath()` \u2014 on Windows this resolves `\\..\\ secret.txt` to `\\secret.txt`, which does not start with `..`, so the `startswith(\"..\")` check passes.\n3. `os.path.isfile()` on Windows interprets `\\` as a path separator, resolving the `..` traversal and finding files outside the template directory.\n\n### Affected code\n\n- `mako/lookup.py`: `TemplateLookup.get_template()` uses `posixpath.normpath`/`posixpath.join` for path construction but `os.path.isfile()` for existence check\n- `mako/template.py`: `Template.__init__()` URI validation uses `os.path.normpath()` which on Windows resolves backslash traversal to a form that passes the `startswith(\"..\")` guard\n\n## Impact\n\nIf an application passes user-controlled template names or include paths to `TemplateLookup.get_template()`, an attacker on Windows may be able to load and disclose readable files outside the configured template directory. The primary impact is local file disclosure. If the targeted file contains Mako/Python template syntax, it may also be parsed and executed as a template.\n\n## Remediation\n\nThe fix should normalize backslashes to forward slashes early in the URI processing pipeline, before any path operations, to ensure consistent behavior across platforms.",
  "id": "GHSA-2h4p-vjrc-8xpq",
  "modified": "2026-05-13T16:43:11Z",
  "published": "2026-05-06T21:45:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sqlalchemy/mako/security/advisories/GHSA-2h4p-vjrc-8xpq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44307"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sqlalchemy/mako/issues/435"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sqlalchemy/mako/commit/72e10c573ca0fbcbddd4455abca8ce92a61780d7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sqlalchemy/mako"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sqlalchemy/mako/releases/tag/rel_1_3_12"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Mako vulnerable to path traversal via backslash URI on Windows in TemplateLookup"
}

GHSA-G794-3FMP-753H

Vulnerability from github – Published: 2026-05-27 21:35 – Updated: 2026-05-27 21:35

Summary

AsyncSSH `AuthorizedKeysFile %u` path traversal allows attacker-selected authorized keys to authenticate a traversal username

Details

Summary

AsyncSSH 2.22.0 expands the OpenSSH-compatible AuthorizedKeysFile %u token with the raw SSH username during pre-authentication server config reload. A server configured with a documented per-user key pattern such as AuthorizedKeysFile authorized_keys/%u can be made to read an authorized-keys file outside the intended directory when the SSH username contains path traversal segments. If the attacker can place or reference a readable authorized-keys-format file containing their public key, the attacker can authenticate over SSH as the traversal username.

Affected Product

Package: asyncssh
Ecosystem: pip
Affected versions: confirmed on 2.22.0; exact lower bound not finalized
Tested version: 2.22.0
Audit commit/tag: tag v2.22.0, commit af5a81e669633d83d535163f93b6bf3f957c9238
PyPI sdist SHA256: c3ce72b01be4f97b40e62844dd384227e5ff5a401a3793007c42f86a5c8eb537

Vulnerability Details

CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory
Component: AsyncSSH server config reload and public-key authentication (asyncssh/config.py, asyncssh/connection.py, asyncssh/auth_keys.py, asyncssh/misc.py)
Root cause: %u in AuthorizedKeysFile is expanded from the remote username without rejecting path separators or .. segments, and the resulting path is opened without constraining it to the intended authorized-keys directory.
Security boundary violated: the configured authorized-keys directory and public-key authentication trust boundary.
Direct impact: public-key authentication succeeds using an attacker-selected authorized-keys file outside the intended directory.
Chain impact, if any: none claimed; direct authentication impact is primary.

Attack Preconditions

The AsyncSSH server uses a config or equivalent pattern where AuthorizedKeysFile contains %u, for example AuthorizedKeysFile authorized_keys/%u.
Public-key authentication is enabled.
The attacker can place or reference a readable authorized-keys-format file outside the intended directory, such as a file in a world-writable or application-writable location.
The application does not separately reject usernames containing /, \, or .. before AsyncSSH uses the username for key-file selection.

Reproduction

The run-scoped evidence contains a safe localhost proof:

Start the proof harness saved at harness_app.py
Run exploit_proof.py through run_proof.sh
The harness creates sshd_config with AuthorizedKeysFile authorized_keys/%u, writes the attacker's public key to a file outside authorized_keys/, starts a real AsyncSSH server, and attempts two SSH logins.
Expected result: the normal username victim fails, while the traversal username authenticates with the same attacker key.

Observed proof output:

[CONTROL] username=victim success=False
[ATTACK] username=../../../asyncssh-proof-exploit-proof-8b2bd23daeeb.pub success=True
[ATTACK] output=AUTH_BYPASS_SUCCESS username=../../../asyncssh-proof-exploit-proof-8b2bd23daeeb.pub
PASS: traversal username authenticated with attacker-controlled authorized_keys file

Severity

6.9 (Medium)


                  
                    CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "asyncssh"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.22.0"
            },
            {
              "fixed": "2.23.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.22.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45309"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-27T21:35:06Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\nAsyncSSH 2.22.0 expands the OpenSSH-compatible `AuthorizedKeysFile` `%u` token with the raw SSH username during pre-authentication server config reload. A server configured with a documented per-user key pattern such as `AuthorizedKeysFile authorized_keys/%u` can be made to read an authorized-keys file outside the intended directory when the SSH username contains path traversal segments. If the attacker can place or reference a readable authorized-keys-format file containing their public key, the attacker can authenticate over SSH as the traversal username.\n\n## Affected Product\n- Package: asyncssh\n- Ecosystem: pip\n- Affected versions: confirmed on 2.22.0; exact lower bound not finalized\n- Tested version: 2.22.0\n- Audit commit/tag: tag `v2.22.0`, commit `af5a81e669633d83d535163f93b6bf3f957c9238`\n- PyPI sdist SHA256: `c3ce72b01be4f97b40e62844dd384227e5ff5a401a3793007c42f86a5c8eb537`\n\n## Vulnerability Details\n- CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory\n- Component: AsyncSSH server config reload and public-key authentication (`asyncssh/config.py`, `asyncssh/connection.py`, `asyncssh/auth_keys.py`, `asyncssh/misc.py`)\n- Root cause: `%u` in `AuthorizedKeysFile` is expanded from the remote username without rejecting path separators or `..` segments, and the resulting path is opened without constraining it to the intended authorized-keys directory.\n- Security boundary violated: the configured authorized-keys directory and public-key authentication trust boundary.\n- Direct impact: public-key authentication succeeds using an attacker-selected authorized-keys file outside the intended directory.\n- Chain impact, if any: none claimed; direct authentication impact is primary.\n\n## Attack Preconditions\n- The AsyncSSH server uses a config or equivalent pattern where `AuthorizedKeysFile` contains `%u`, for example `AuthorizedKeysFile authorized_keys/%u`.\n- Public-key authentication is enabled.\n- The attacker can place or reference a readable authorized-keys-format file outside the intended directory, such as a file in a world-writable or application-writable location.\n- The application does not separately reject usernames containing `/`, `\\`, or `..` before AsyncSSH uses the username for key-file selection.\n\n## Reproduction\nThe run-scoped evidence contains a safe localhost proof:\n\n1. Start the proof harness saved at \n[harness_app.py](https://github.com/user-attachments/files/27232526/harness_app.py)\n\n2. Run \n[exploit_proof.py](https://github.com/user-attachments/files/27232538/exploit_proof.py)\nthrough \n[run_proof.sh](https://github.com/user-attachments/files/27232545/run_proof.sh)\n\n3. The harness creates `sshd_config` with `AuthorizedKeysFile authorized_keys/%u`, writes the attacker\u0027s public key to a file outside `authorized_keys/`, starts a real AsyncSSH server, and attempts two SSH logins.\n4. Expected result: the normal username `victim` fails, while the traversal username authenticates with the same attacker key.\n\nObserved proof output:\n\n```text\n[CONTROL] username=victim success=False\n[ATTACK] username=../../../asyncssh-proof-exploit-proof-8b2bd23daeeb.pub success=True\n[ATTACK] output=AUTH_BYPASS_SUCCESS username=../../../asyncssh-proof-exploit-proof-8b2bd23daeeb.pub\nPASS: traversal username authenticated with attacker-controlled authorized_keys file\n```",
  "id": "GHSA-g794-3fmp-753h",
  "modified": "2026-05-27T21:35:06Z",
  "published": "2026-05-27T21:35:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ronf/asyncssh/security/advisories/GHSA-g794-3fmp-753h"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ronf/asyncssh"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "AsyncSSH `AuthorizedKeysFile %u` path traversal allows attacker-selected authorized keys to authenticate a traversal username"
}

GHSA-MF9V-MFXR-J63J

Vulnerability from github – Published: 2026-05-11 14:51 – Updated: 2026-06-08 19:52

Summary

urllib3: Decompression-bomb safeguards bypassed in parts of the streaming API

Details

Impact

urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once.

urllib3 can perform decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). When using the streaming API since version 2.6.0, the library decompresses only the necessary bytes, enabling partial content consumption.

However, urllib3 before version 2.7.0 could still decompress the whole response instead of the requested portion in two cases: 1. During the second HTTPResponse.read(amt=N) call when the response was decompressed using the official Brotli library. 2. When HTTPResponse.drain_conn() was called after the response had been read and decompressed partially (compression algorithm did not matter here).

These issues could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This could result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data; CWE-409) on the client side.

Affected usages

Applications and libraries using urllib3 versions earlier than 2.7.0 may be affected when streaming compressed responses from untrusted sources in either of these cases, unless decompression is explicitly disabled:

A response encoded with br is read incrementally with at least two HTTPResponse.read(amt=N) or HTTPResponse.stream(amt=N) calls while using the official Brotli library.
HTTPResponse.drain_conn() is called after response decompression has already started.

Remediation

Upgrade to at least urllib3 version 2.7.0 in which the library: 1. Is more efficient for reads with Brotli. 2. Always skips decompression for HTTPResponse.drain_conn().

If upgrading is not immediately possible, the following workarounds may reduce exposure in specific cases: 1. For the Brotli-specific issue only, switch from brotli to brotlicffi until you can upgrade urllib3; the official Brotli package is affected because of https://github.com/google/brotli/issues/1396. 2. If your code explicitly calls HTTPResponse.drain_conn(), call HTTPResponse.close() instead when connection reuse is not important.

Credits

The Brotli-specific issue was reported by @kimkou2024. HTTPResponse.drain_conn() inefficiency was reported by @Cycloctane.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

8.9 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "urllib3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "2.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44432"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T14:51:45Z",
    "nvd_published_at": "2026-05-13T16:16:57Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nurllib3\u0027s [streaming API](https://urllib3.readthedocs.io/en/2.7.0/advanced-usage.html#streaming-and-i-o) is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once.\n\nurllib3 can perform decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API since version 2.6.0, the library decompresses only the necessary bytes, enabling partial content consumption.\n\nHowever, urllib3 before version 2.7.0 could still decompress the whole response instead of the requested portion in two cases:\n1. During the second `HTTPResponse.read(amt=N)` call when the response was decompressed using the official [Brotli](https://pypi.org/project/brotli/) library.\n2. When `HTTPResponse.drain_conn()` was called after the response had been read and decompressed partially (compression algorithm did not matter here).\n\nThese issues could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This could result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data; CWE-409) on the client side.\n\n\n### Affected usages\n\nApplications and libraries using urllib3 versions earlier than 2.7.0 may be affected when streaming compressed responses from untrusted sources in either of these cases, unless decompression is explicitly disabled:\n\n1. A response encoded with `br` is read incrementally with at least two `HTTPResponse.read(amt=N)` or `HTTPResponse.stream(amt=N)` calls while using the official [Brotli](https://pypi.org/project/brotli/) library.\n2. `HTTPResponse.drain_conn()` is called after response decompression has already started.\n\n\n### Remediation\n\nUpgrade to at least urllib3 version 2.7.0 in which the library:\n1. Is more efficient for reads with Brotli.\n2. Always skips decompression for `HTTPResponse.drain_conn()`.\n\nIf upgrading is not immediately possible, the following workarounds may reduce exposure in specific cases:\n1. For the Brotli-specific issue only, switch from [brotli](https://pypi.org/project/brotli/) to [brotlicffi](https://pypi.org/project/brotlicffi/) until you can upgrade urllib3; the official Brotli package is affected because of https://github.com/google/brotli/issues/1396.\n2. If your code explicitly calls `HTTPResponse.drain_conn()`, call `HTTPResponse.close()` instead when connection reuse is not important.\n\n\n### Credits\n\nThe Brotli-specific issue was reported by @kimkou2024.\n`HTTPResponse.drain_conn()` inefficiency was reported by @Cycloctane.",
  "id": "GHSA-mf9v-mfxr-j63j",
  "modified": "2026-06-08T19:52:23Z",
  "published": "2026-05-11T14:51:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/urllib3/urllib3/security/advisories/GHSA-mf9v-mfxr-j63j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44432"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/urllib3/PYSEC-2026-142.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/urllib3/urllib3"
    }
  ],
  "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:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "urllib3: Decompression-bomb safeguards bypassed in parts of the streaming API"
}

GHSA-QCCP-GFCP-XXVC

Vulnerability from github – Published: 2026-05-11 14:51 – Updated: 2026-05-14 20:35

Summary

urllib3: Sensitive headers forwarded across origins in proxied low-level redirects

Details

Impact

When following cross-origin redirects for requests made using urllib3’s high-level APIs, such as urllib3.request(), PoolManager.request(), and ProxyManager.request(), sensitive headers — Authorization, Cookie, and Proxy-Authorization (defined in Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT) — are stripped by default, as expected.

However, cross-origin redirects followed from the low-level API via ProxyManager.connection_from_url().urlopen(..., assert_same_host=False) still forward these sensitive headers.

Affected usage

Applications and libraries using urllib3 versions earlier than 2.7.0 may be affected if they allow cross-origin redirects while making requests through HTTPConnection.urlopen() instances created via ProxyManager.connection_from_url().

Remediation

Upgrade to urllib3 version 2.7.0 or later, in which sensitive headers are stripped from redirects followed by HTTPConnection.

If upgrading is not immediately possible, avoid using this low-level redirect flow for cross-origin redirects. If appropriate for your use case, switch to ProxyManager.request().

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

8.2 (High)


                  
                    CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "urllib3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.23"
            },
            {
              "fixed": "2.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44431"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T14:51:20Z",
    "nvd_published_at": "2026-05-13T16:16:57Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nWhen following cross-origin redirects for requests made using urllib3\u2019s high-level APIs, such as `urllib3.request()`, `PoolManager.request()`, and `ProxyManager.request()`, sensitive headers \u2014 `Authorization`, `Cookie`, and `Proxy-Authorization` (defined in `Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT`) \u2014 are stripped by default, as expected.\n\nHowever, cross-origin redirects followed from the low-level API via `ProxyManager.connection_from_url().urlopen(..., assert_same_host=False)` still forward these sensitive headers.\n\n### Affected usage\n\nApplications and libraries using urllib3 versions earlier than 2.7.0 may be affected if they allow cross-origin redirects while making requests through `HTTPConnection.urlopen()` instances created via `ProxyManager.connection_from_url()`.\n\n### Remediation\n\nUpgrade to urllib3 version 2.7.0 or later, in which sensitive headers are stripped from redirects followed by `HTTPConnection`.\n\nIf upgrading is not immediately possible, avoid using this low-level redirect flow for cross-origin redirects. If appropriate for your use case, switch to `ProxyManager.request()`.",
  "id": "GHSA-qccp-gfcp-xxvc",
  "modified": "2026-05-14T20:35:49Z",
  "published": "2026-05-11T14:51:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/urllib3/urllib3/security/advisories/GHSA-qccp-gfcp-xxvc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44431"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/urllib3/urllib3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "urllib3: Sensitive headers forwarded across origins in proxied low-level redirects"
}

GHSA-WXXX-GVQV-XP7P

Vulnerability from github – Published: 2026-05-11 16:17 – Updated: 2026-05-11 16:17

Summary

LiteLLM has a sandbox escape in custom-code guardrail

Details

Impact

The POST /guardrails/test_custom_code endpoint runs user-supplied Python inside a hand-rolled sandbox. The sandbox can be escaped using bytecode-level techniques, allowing arbitrary code execution in the proxy process — which runs as root in the default Docker image.

Reaching the endpoint requires a proxy-admin credential in default configurations.

Patches

Fixed in 1.83.11. The hand-rolled sandbox has been replaced with RestrictedPython. Upgrade to 1.83.11 or later.

Workarounds

If upgrading is not immediately possible, block POST /guardrails/test_custom_code at your reverse proxy or API gateway.

References

Patched release: v1.83.10-stable

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

7.5 (High)


                  
                    CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litellm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.81.8"
            },
            {
              "fixed": "1.83.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40217"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-420",
      "CWE-913"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T16:17:23Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThe `POST /guardrails/test_custom_code` endpoint runs user-supplied Python inside a hand-rolled sandbox. The sandbox can be escaped using bytecode-level techniques, allowing arbitrary code execution in the proxy process \u2014 which runs as root in the default Docker image.\n\n**Reaching the endpoint requires a proxy-admin credential** in default configurations.\n\n### Patches\n\nFixed in **`1.83.11`**. The hand-rolled sandbox has been replaced with `RestrictedPython`. Upgrade to `1.83.11` or later.\n\n### Workarounds\n\nIf upgrading is not immediately possible, block `POST /guardrails/test_custom_code` at your reverse proxy or API gateway.\n\n### References\n\n- Patched release: [`v1.83.10-stable`](https://github.com/BerriAI/litellm/releases/tag/v1.83.10-stable)",
  "id": "GHSA-wxxx-gvqv-xp7p",
  "modified": "2026-05-11T16:17:23Z",
  "published": "2026-05-11T16:17:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/BerriAI/litellm/security/advisories/GHSA-wxxx-gvqv-xp7p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40217"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/BerriAI/litellm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BerriAI/litellm/releases/tag/v1.83.10-stable"
    },
    {
      "type": "WEB",
      "url": "https://www.x41-dsec.de/lab/advisories/x41-2026-001-litellm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "LiteLLM has a sandbox escape in custom-code guardrail"
}

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.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.

Action not permitted

Vulnerability from cleanstart

GHSA-2H4P-VJRC-8XPQ

Summary

Details

Affected code

Impact

Remediation

GHSA-G794-3FMP-753H

Summary

Affected Product

Vulnerability Details

Attack Preconditions

Reproduction

GHSA-MF9V-MFXR-J63J

Impact

Affected usages

Remediation

Credits

GHSA-QCCP-GFCP-XXVC

Impact

Affected usage

Remediation

GHSA-WXXX-GVQV-XP7P

Impact

Patches

Workarounds

References

Tags

Sightings

Nomenclature