CodeChecker EUVD-2026-67717

Exploitation requires an authenticated session with the specific 'permission to store analysis runs' within CodeChecker - this is not a default low-privilege user capability and is not exposed to unauthenticated users (PR:H in the CVSS vector). The attack targets the massStoreRun processing path specifically and requires the ability to submit a Base64-encoded zlib payload to that endpoint. No special non-default configuration beyond holding this permission is required; the vulnerable code path is exercised during normal analysis run storage. Exploitation is bounded by: (1) authentication with elevated store permissions, restricting the attacker to insiders or compromised privileged accounts; (2) impact is limited to availability only - no data exfiltration or integrity modification is possible via this path. In environments where automated build or CI accounts hold store permissions by design, the effective attack surface is meaningfully broader than in manually-managed deployments.

The CVSS 4.0 score of 5.5 reflects a medium finding, principally constrained by PR:H - the attacker must be authenticated and hold the specific 'store analysis runs' permission, which is not a default low-privilege capability. The CVSS 4.0 supplemental metric E:P confirms a proof-of-concept exists, and AU:Y indicates the attack can be automated to prevent service recovery. Availability impact on the vulnerable system is high (VA:H) with no confidentiality or integrity component (VC:N/VI:N). The vulnerability is not listed in CISA KEV and EPSS data is absent from available input, so widespread exploitation cannot be confirmed. Recovery is assessed as automatic (R:A) once the process restarts and disk is cleared, limiting persistent impact. Real-world risk is moderate: the high privilege requirement significantly constrains the attacker pool, but in CI/CD pipeline environments where multiple automated accounts hold store permissions, the effective attack surface widens considerably.

A malicious or compromised CI/CD service account holding CodeChecker store-run permissions constructs a small Base64-encoded zlib payload that decompresses to tens or hundreds of gigabytes and submits it to the massStoreRun endpoint. The CodeChecker process attempts to materialize the full decompressed output in RAM before writing to a temporary file, exhausting process or host memory and crashing the service. A proof-of-concept exists, making this straightforward to reproduce and automate for repeated denial-of-service attempts.