Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
ldap.dn.escapednchars() escapes \x00 incorrectly by emitting a backslash followed by a literal NUL byte instead of the RFC-4514 hex form \00. Any application that uses this helper to construct DNs from untrusted input can be made to consistently fail before a request is sent to the LDAP server (e.g., AD), resulting in a client-side denial of service. Details Affected function: ldap.dn.escapednchars(s) File: Lib/ldap/dn.py Buggy behavior: For NUL, the function does: s = s.replace('\000', '\\\000') backslash + literal NUL This produces Python strings which, when passed to python-ldap APIs (e.g., adds, modifys, renames, or used as search bases), contain an embedded NUL. python-ldap then raises ValueError: embedded null character (or otherwise fails) before any network I/O. With correct RFC-4514 encoding (\00), the client proceeds and the server can apply its own syntax rules (e.g., AD will reject NUL in CN with result: 34), proving the failure originates in the escaping…
Recommended action: Upgrade to 3.4.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The sanitization method ldap.filter.escapefilterchars can be tricked to skip escaping of special characters when a crafted list or dict is supplied as the assertionvalue parameter, and the non-default escapemode=1 is configured. Details The method ldap.filter.escapefilterchars supports 3 different escaping modes. escapemode=0 (default) and escapemode=2 happen to raise exceptions when a list or dict object is supplied as the assertionvalue parameter. However, escapemode=1 happily computes without performing adequate logic to ensure a fully escaped return value. PoC Exploitable Not exploitable 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…
Recommended action: Upgrade to 3.4.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
https://github.com/python-ldap/python-ldap/issues/424 Impact The LDAP schema parser of python-ldap 3.3.1 and earlier are vulnerable to a regular expression denial-of-service attack. The issue affects clients that use ldap.schema package to parse LDAP schema definitions from an untrusted source. Patches The upcoming release of python-ldap 3.4.0 will contain a workaround to prevent ReDoS attacks. The schema parser refuses schema definitions with an excessive amount of backslashes. Workarounds As a workaround, users can check input for excessive amount of backslashes in schemas. More than a dozen backslashes per line are atypical. References CWE-1333 For more information If you have any questions or comments about this advisory: Open an issue in python-ldap tracker
Recommended action: Upgrade to 3.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.