GRR CVE-2026-58256

Exploitation requires GRR administrator privileges AND use of the LDAP connector feature: the attacker must first define an LDAP connector and complete a successful connection (trivially satisfiable by pointing GRR at an attacker-controlled LDAP server), then submit malicious PHP in connector settings parameters such as ldap_filter (also ldap_group_filter and related fields hardened in the fix), which is persisted into /personnalisation/config_ldap.inc.php and executed. Limiting factors: this is not exploitable against default/unauthenticated deployments - it depends on holding the administrator role and on the LDAP connector configuration workflow being reachable; it is effectively a malicious-or-compromised-admin / privilege-to-code-execution issue rather than remote unauthenticated RCE. Fixed in GRR 4.5.0; the vendor patch (input validation via ldap_escape and filter syntax checks) is the remediation.

This is a genuine but access-gated RCE. The provided CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H = 9.1) is driven high by the scope change and triple-high impact, but the PR:H requirement is the dominant limiting factor: exploitation requires existing GRR administrator privileges, so this is not a pre-auth internet-facing bug. The vuln.today Decision label is act_now and a vendor patch exists, which argues for prompt remediation; however, no EPSS score, no CISA KEV listing, and no SSVC decision-point data (automatable, exploitation status) were supplied, so the act_now label cannot be cross-validated against widespread-exploitation signals. No public exploit reference was provided - only the advisory and the fix commit - so there is no evidence of exploit code or active exploitation. The practical risk is best read as post-compromise privilege-to-code escalation: an attacker who already holds (or phishes/steals) admin credentials, or a malicious administrator, converts config access into OS-level code execution. EPSS/KEV absence here is a data gap, not evidence of low risk; prioritize based on how exposed and trusted your GRR admin accounts are.

An attacker who has obtained GRR administrator access opens the LDAP connector configuration, points it at an LDAP server they control so the connection check succeeds, and on the subsequent connector-settings page submits a crafted value in a parameter such as ldap_filter containing PHP code. That input is written into /personnalisation/config_ldap.inc.php, which is later included and executed, yielding remote code execution on the GRR host. No public exploit code was identified in the provided data, though the advisory describes the mechanism in enough detail to reproduce it.