phpwcms EUVD-2026-98822

Exploitation requires that the target site actually deploys a phpwcms front-end article content form (cnt23) with file upload enabled - this is the specific feature that must be configured for the vulnerable POST_name handler to be reachable. The pre-patch code only rejected a short extension blocklist (php,asp,php3,php4,php5,aspx,cfm,js,exe,com,bat,app,sh,jar,java), so exploitation succeeds by choosing a server-executable type outside that list (e.g. .phtml, .phar, .pht, .inc, .cgi, .pl, .py). A key LIMITING factor is the content/form/ directory .htaccess, which already denied *.php execution; where that control is enforced (Apache with the Deny/FilesMatch rules active) impact is confined to storing arbitrary files, whereas on servers that ignore .htaccess (e.g. Nginx) or where it is missing, the same upload can lead to code execution. No attacker authentication is indicated by the CVSS vector (PR:N).

This is a CWE-434 unrestricted file upload in phpwcms' article content form (cnt23.article.inc.php, 'Extension Check'), reachable remotely. The VulDB CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes network, low-complexity, unauthenticated exploitation, which per the rules means no attacker authentication is required. However, the vendor impact metrics are all Low (VC:L/VI:L/VA:L, score 6.9), which conflicts with the usual expectation that an unrestricted upload yields remote code execution (High impact). The source diff explains this: uploads land in content/form/, whose pre-existing .htaccess already denied *.php execution, so a dropped PHP shell would typically not execute - the patch merely hardens that .htaccess and adds extension/MIME/content filters. Thus the realistic impact is bounded to writing arbitrary non-whitelisted files rather than guaranteed RCE, matching the Low ratings. No EPSS score, no CISA KEV listing, and no public exploit are present in the input, so there is no signal of active or imminent widespread exploitation; this appears to be a VulDB-reported issue in niche software rather than a top-priority emergency. Net: real but moderate - patch on a normal cycle, and verify the content/form/ .htaccess is actually enforced in your deployment, since a misconfigured or Nginx-based server (which ignores .htaccess) could elevate this to code execution.

An anonymous visitor finds a phpwcms site hosting a front-end article form (cnt23) that accepts file uploads, then submits a file whose extension evades the limited blocklist (e.g. a server-side script type not in the old exclude list, or a PHP variant like .phtml/.phar). The crafted file is stored on the server; if the content/form/ directory's .htaccess protection is absent or ineffective (e.g. Nginx), the uploaded script can be executed, otherwise impact is limited to arbitrary file storage. No public proof-of-concept is identified at time of analysis.