This SQL injection in CiviCRM's contact search carries a CVSS 8.8, but the score obscures the real problem: the vulnerability exists because the codebase treats authenticated staff as an implicit security boundary when they should be treated as any other untrusted input source.

The flaw lives in the RLIKE clause where contact search concatenates raw SQL. A developer working in CiviCRM sees every other code path grant staff full access to contact records through the normal UI—so parameterizing this one query would have felt unnecessary. That's the architectural signal: the application trains developers to trust staff input, then this single function breaks that contract.

What makes this dangerous isn't the technical complexity—it's the operational simplicity. You don't need zero-days or unauthenticated access. Phish a staff account, run one query, and you bypass every application-level audit log. The UI would never permit bulk exfiltration, but the raw SQL path doesn't enforce those limits. Staff credentials are also easier to compromise than achieving unauthenticated RCE through phishing, credential stuffing, or insider threat.

The alpha versioning (6.18.alpha1) is the concerning detail. This code was actively touched during development and survived without flagging. That strongly suggests the same assumption—staff input equals sanitized input—lives in other authenticated code paths across CiviCRM. Hunt for similar patterns: export functions, report builders, and search utilities that may still concatenate SQL when handling staff requests.

For compliance: if you process EU/UK contacts under GDPR or California residents under CCPA, this SQL path creates a data breach trigger that doesn't require an external attacker—just a staff account. The application-level logging that would normally surface bulk data access doesn't apply to raw SQL queries.

Remediate by parameterizing the RLIKE clause immediately. The larger fix is accepting that 'authenticated user' was never a valid security boundary, and your codebase may be actively teaching developers the opposite.