GHSA-R7R6-CC7P-4V5M

Vulnerability from github – Published: 2025-10-10 22:51 – Updated: 2025-10-13 15:47
VLAI?
Summary
python-ldap has sanitization bypass in ldap.filter.escape_filter_chars
Details

Summary

The sanitization method ldap.filter.escape_filter_chars can be tricked to skip escaping of special characters when a crafted list or dict is supplied as the assertion_value parameter, and the non-default escape_mode=1 is configured.

Details

The method ldap.filter.escape_filter_chars supports 3 different escaping modes. escape_mode=0 (default) and escape_mode=2 happen to raise exceptions when a list or dict object is supplied as the assertion_value parameter. However, escape_mode=1 happily computes without performing adequate logic to ensure a fully escaped return value.

PoC

>>> import ldap.filter

Exploitable

>>> ldap.filter.escape_filter_chars(["abc@*()/xyz"], escape_mode=1)
'abc@*()/xyz'
>>> ldap.filter.escape_filter_chars({"abc@*()/xyz": 1}, escape_mode=1)
'abc@*()/xyz'

Not exploitable

>>> ldap.filter.escape_filter_chars("abc@*()/xyz", escape_mode=1)
'abc@\\2a\\28\\29\\2fxyz'
>>> ldap.filter.escape_filter_chars(["abc@*()/xyz"], escape_mode=0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib64/python3.12/site-packages/ldap/filter.py", line 41, in escape_filter_chars
    s = assertion_value.replace('\\', r'\5c')
        ^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'list' object has no attribute 'replace'
>>> ldap.filter.escape_filter_chars(["abc@*()/xyz"], escape_mode=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib64/python3.12/site-packages/ldap/filter.py", line 36, in escape_filter_chars
    r.append("\\%02x" % ord(c))
                        ^^^^^^
TypeError: ord() expected a character, but string of length 11 found

Impact

If an application relies on the vulnerable method in the python-ldap library to escape untrusted user input, an attacker might be able to abuse the vulnerability to launch ldap injection attacks which could potentially disclose or manipulate ldap data meant to be inaccessible to them.

With Python being a dynamically typed language, and the commonly used JSON format supporting list and dict, it is to be expected that Python applications may commonly forward unchecked and potentially malicious list and dict objects to the vulnerable sanitization method.

The vulnerable escape_mode=1 configuration does not appear to be widely used.

Suggested Fix

Add a type check at the start of the ldap.filter.escape_filter_chars method to raise an exception when the supplied assertion_value parameter is not of type str.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "python-ldap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-61911"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-75",
      "CWE-843"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-10T22:51:28Z",
    "nvd_published_at": "2025-10-10T22:15:37Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe sanitization method `ldap.filter.escape_filter_chars` can be tricked to skip escaping of special characters when a crafted `list` or `dict` is supplied as the `assertion_value` parameter, and the non-default `escape_mode=1` is configured.\n\n### Details\nThe method `ldap.filter.escape_filter_chars` supports 3 different escaping modes. `escape_mode=0` (default) and `escape_mode=2` happen to raise exceptions when a `list` or `dict` object is supplied as the `assertion_value` parameter. However, `escape_mode=1` happily computes without performing adequate logic to ensure a fully escaped return value.\n\n### PoC\n```\n\u003e\u003e\u003e import ldap.filter\n```\n**Exploitable**\n```\n\u003e\u003e\u003e ldap.filter.escape_filter_chars([\"abc@*()/xyz\"], escape_mode=1)\n\u0027abc@*()/xyz\u0027\n\u003e\u003e\u003e ldap.filter.escape_filter_chars({\"abc@*()/xyz\": 1}, escape_mode=1)\n\u0027abc@*()/xyz\u0027\n```\n**Not exploitable**\n```\n\u003e\u003e\u003e ldap.filter.escape_filter_chars(\"abc@*()/xyz\", escape_mode=1)\n\u0027abc@\\\\2a\\\\28\\\\29\\\\2fxyz\u0027\n\u003e\u003e\u003e ldap.filter.escape_filter_chars([\"abc@*()/xyz\"], escape_mode=0)\nTraceback (most recent call last):\n  File \"\u003cstdin\u003e\", line 1, in \u003cmodule\u003e\n  File \"/usr/local/lib64/python3.12/site-packages/ldap/filter.py\", line 41, in escape_filter_chars\n    s = assertion_value.replace(\u0027\\\\\u0027, r\u0027\\5c\u0027)\n        ^^^^^^^^^^^^^^^^^^^^^^^\nAttributeError: \u0027list\u0027 object has no attribute \u0027replace\u0027\n\u003e\u003e\u003e ldap.filter.escape_filter_chars([\"abc@*()/xyz\"], escape_mode=2)\nTraceback (most recent call last):\n  File \"\u003cstdin\u003e\", line 1, in \u003cmodule\u003e\n  File \"/usr/local/lib64/python3.12/site-packages/ldap/filter.py\", line 36, in escape_filter_chars\n    r.append(\"\\\\%02x\" % ord(c))\n                        ^^^^^^\nTypeError: ord() expected a character, but string of length 11 found\n```\n### Impact\nIf an application relies on the vulnerable method in the `python-ldap` library to escape untrusted user input, an attacker might be able to abuse the vulnerability to launch ldap injection attacks which could potentially disclose or manipulate ldap data meant to be inaccessible to them.\n\nWith Python being a dynamically typed language, and the commonly used `JSON` format supporting `list` and `dict`, it is to be expected that Python applications may commonly forward unchecked and potentially malicious `list` and `dict` objects to the vulnerable sanitization method.\n\nThe vulnerable `escape_mode=1` configuration does not appear to be widely used.\n\n### Suggested Fix\nAdd a type check at the start of the `ldap.filter.escape_filter_chars` method to raise an exception when the supplied `assertion_value` parameter is not of type `str`.",
  "id": "GHSA-r7r6-cc7p-4v5m",
  "modified": "2025-10-13T15:47:36Z",
  "published": "2025-10-10T22:51:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/python-ldap/python-ldap/security/advisories/GHSA-r7r6-cc7p-4v5m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61911"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-ldap/python-ldap/commit/3957526fb1852e84b90f423d9fef34c7af25b85a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/python-ldap/python-ldap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-ldap/python-ldap/releases/tag/python-ldap-3.4.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "python-ldap has sanitization bypass in ldap.filter.escape_filter_chars"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

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.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…