glpi-project GLPI LDAP filter injection bypasses default filtering in user import

GLPI is a free asset and IT management software package. From 0.70 until 10.0.26 and 11.0.8, an authenticated hotliner or technician can submit crafted criteria through the user import feature to bypass the configured default LDAP filter. This allows access to LDAP objects that the default filter was intended to exclude. This issue is fixed in versions 11.0.8 and 10.0.26.

• glpi-project/glpi versions >= 0.70, < 10.0.26 are affected.
• glpi-project/glpi versions >= 11.0.0, < 11.0.8 are affected.
• The confirmed patched releases are 10.0.26 and 11.0.8.
• The supplied evidence does not establish the status of other branches or release boundaries beyond those listed above.

The affected component is GLPI's LDAP user import path. A criteria value submitted by an authenticated hotliner or technician is used to build an LDAP filter. In the vulnerable code, the value was concatenated directly into the filter; the fixing change applies ldap_escape($value, '', LDAP_ESCAPE_FILTER) before constructing the filter condition. As a result, crafted criteria can alter filter semantics and bypass the configured default LDAP filter. The available evidence identifies the filter-building logic, but does not establish the specific LDAP schema or exact object attributes exposed in a particular deployment.

The flaw is reachable over the network through GLPI's user import feature. An authenticated hotliner or technician account is required, and no separate victim interaction is described. The attacker must submit crafted criteria that affect LDAP filter construction. The normalized record marks public_exploit as false and does not establish known_exploited, so confirmed public or in-the-wild exploitation is not established by the available data.

Successful exploitation can expand the set of LDAP objects returned by GLPI's user import workflow beyond the configured default LDAP filter. The direct effect is broader directory-data access for an authenticated account, not unauthenticated entry into GLPI. If excluded objects contain sensitive identity or group information, the likely consequence is unintended disclosure and a violation of access-control policy. The available evidence does not establish modification of LDAP or GLPI data, service interruption, or escalation to administrator privileges.

Successful exploitation can expand the LDAP objects returned to the user import workflow beyond the configured default filter. This may expose directory data to an authenticated role that was not intended to see those objects. Possible organisational consequences include unintended disclosure of identity or directory information and violation of access-control policy, depending on what the filter excludes. The record does not establish data modification or deletion, service disruption, or GLPI administrator takeover.

1. Upgrade deployments in the 10.x branch to 10.0.26 and deployments in the 11.x branch to 11.0.8; these are the confirmed patched releases for the affected branches.
2. If an upgrade cannot be completed immediately, the record provides no vendor-confirmed workaround. Do not treat changing the LDAP filter configuration alone as a proven fix.
3. After updating, verify the actual running version and test user import with an appropriate LDAP filter that intentionally excludes suitable test objects.
4. Review use of affected systems to determine whether LDAP objects outside the intended filter scope were previously returned.

1. Inventory GLPI deployments and compare their running versions with the affected boundaries in affected_summary.
2. Identify deployments connected to LDAP and determine whether the user import feature is available to hotliner or technician roles.
3. Review application audit logs for user import activity by those roles, especially criteria or result sets that appear unusual. This is a precautionary review, not a confirmed IOC.
4. Where feasible, compare objects returned by the import workflow with the objects that the configured default LDAP filter is intended to exclude.
5. Do not treat the absence of suspicious log entries as proof of safety, because the record does not define a complete logging indicator for this flaw.