dbcve.org
Unrestricted File UploadWeakness · CWE-434

CVE-2026-23697

HIGH · 8.8 CVSS v3.1 Published 2026-07-07
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
94/100
Remediation priority · Urgent
Remotely reachable Zero-click 7 weeks old

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
Vtiger CRM before 8.4.0 contains an authenticated file upload vulnerability that allows low-privileged users to achieve remote code execution by uploading a .phar file containing arbitrary PHP code through the Documents module, bypassing the extension denylist in config.inc.php which omits the .phar extension. The uploaded file is stored with its original .phar extension under the web-accessible storage directory, and a misconfigured .htaccess using Apache 2.2 syntax is silently ignored on Apache 2.4 deployments, allowing unauthenticated HTTP requests to directly execute the uploaded PHP payload.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

Vtiger CRM before 8.4.0 allows authenticated low-privileged users to upload .phar files containing arbitrary PHP code through the Documents module. The extension denylist in config.inc.php omits .phar, allowing bypass. Uploaded files are stored with their original extension in a web-accessible directory. Additionally, a misconfigured .htaccess using Apache 2.2 syntax is ignored on Apache 2.4, enabling unauthenticated remote code execution via direct HTTP access to the uploaded .phar files.

MitigationUpgrade to Vtiger CRM 8.4.0 or later. Immediately add .phar to the extension denylist in config.inc.php and update the .htaccess file to use Apache 2.4-compatible directives to prevent direct execution of uploaded files.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify the installed Vtiger CRM version
    Locate the version file - typically config.inc.php or vtigerversion.php in the CRM root directory, or access the 'About' page in the CRM admin interface. Search for a version number string.
    Affected if The version is lower than 8.4.0 (for example, 8.3.x, 8.2.x, or earlier)
  2. Locate the extension denylist configuration
    Open config.inc.php in the CRM root directory and search for keywords like 'denylist', 'allowed_extensions', 'file_upload', or 'upload_max_extension'. Identify the list of file extensions that are blocked from upload.
    Affected if The denylist exists but does NOT include '.phar' as a blocked extension (the list is missing .phar)
  3. Identify the Documents module upload directory
    Check the modules/Documents/ directory or look for a 'storage' or 'upload' folder within the CRM installation. These directories typically contain user-uploaded files with their original file extensions preserved.
    Affected if The upload directory is accessible via HTTP/HTTPS (web-accessible) and stores files with their original extension intact
  4. Examine .htaccess in upload directories
    Locate any .htaccess files in the upload/storage directories used by the Documents module. Inspect the file for Apache 2.2 directives such as 'Order deny,allow', 'Deny from all', or 'Allow from all' without the 'Require' keyword.
    Affected if The .htaccess uses deprecated Apache 2.2 syntax (Order/Deny/Allow directives) which is ignored by Apache 2.4, allowing direct script execution

You are affected if your Vtiger CRM version is before 8.4.0 AND the .phar extension is not blocked in config.inc.php AND your upload directories have web-accessible .phar files with a non-restrictive .htaccess using deprecated Apache 2.2 syntax.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Upgrade to Vtiger CRM 8.4.0 or later. Immediately add .phar to the extension denylist in config.inc.php and update the .htaccess file to use Apache 2.4-compatible directives to prevent direct execution of uploaded files.

Recommended fix High confidence

8.4.0

  1. 1. Create a complete backup of the Vtiger CRM database and all files.
  2. 2. Download Vtiger CRM version 8.4.0 or later from the official vtiger.com website.
  3. 3. Follow the official Vtiger upgrade documentation to apply the update to your existing installation.
  4. 4. After upgrade, verify that the .phar extension is now properly blocked in the config.inc.php denylist.
  5. 5. Ensure the .htaccess file in the storage directory uses Apache 2.4 compliant syntax (Require all denied) to prevent direct execution of uploaded files.
  6. 6. Test the Documents module upload functionality with non-allowed file types to confirm the fix is effective.
  7. 7. Verify that low-privileged users can no longer upload or execute arbitrary PHP code.

Generated from the published advisory — verify against the referenced sources before acting.

Have this fixed Scoped from the published advisory
  • Consultation3.0 h
  • Implementation6.0 h
  • Testing3.0 h
  • Review / QA2.0 h
14.0 hours of engineering $2,490
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,984.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-23697 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-23697 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data