Vtiger CRM CVE-2026-23697

Requires a valid low-privileged Vtiger CRM account (PR:L) with access to the Documents module to perform the upload - the initial step is authenticated, not anonymous. The vulnerability is only exploitable when the config.inc.php extension denylist omits .phar (the default in versions before 8.4.0) AND the server runs Apache 2.4 without mod_access_compat, so the storage directory's Apache 2.2-syntax .htaccess is silently ignored and PHP execution is permitted there. Limiting factors: an attacker must first obtain CRM credentials; deployments on Apache 2.2, or Apache 2.4 with mod_access_compat loaded, or with a corrected .htaccess / disabled PHP handler in the storage path, block the execution step; the final trigger request itself needs no authentication.

This is a genuine priority, not a paper-high score. The vendor-supplied CVSS 4.0 base is 8.7 with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H - network reachable, low complexity, only low privileges required, no user interaction, and full confidentiality/integrity/availability impact on the vulnerable system. Publicly available exploit code exists and the finding comes from a credible source (VulnCheck), which raises real-world exploitability. Note the two-stage nature: PR:L reflects that an attacker needs a low-privileged CRM account to upload, yet the description states the resulting payload is reachable by unauthenticated HTTP requests, so post-upload triggering needs no credentials - a nuance the single vector cannot fully express. No EPSS probability and no KEV status were provided in the input, so widespread automated exploitation cannot be confirmed or ruled out from this data; the low barrier plus public PoC nonetheless argue for prompt patching.

An attacker with any low-privileged Vtiger CRM login opens the Documents module and uploads a .phar file containing a PHP web shell, which passes the incomplete denylist and is saved with its .phar extension in the web-accessible storage directory. Because the Apache 2.4 server ignores the outdated .htaccess, the attacker (or anyone) then requests the file's URL directly over HTTP, and Apache/PHP execute the payload, yielding arbitrary code execution on the server. Public exploit code for this chain is already available.