Form Tools CVE-2026-103541

Requires a reachable Form Tools instance (≤3.1.1) and a low-privilege authenticated session (CVSS PR:L) to invoke the Ajax Handler's Files::uploadFile function in global/code/actions.php; no user interaction is needed. Limiting factors: authentication is required, the product is niche and self-hosted, and real-world severity depends on whether uploaded files land in a web-executable directory. No official patch is available because the vendor has not responded to the reported issue, so mitigation currently relies on restricting upload permissions or network access.

Signals are mixed and point to a low-to-moderate, access-gated risk rather than an urgent priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) describes a remotely reachable, low-complexity flaw but requires at least low-level authentication (PR:L), and the vendor-assigned impact is only VC:L/VI:L/VA:L for a 5.3 (Medium) base score. SSVC-style exploitation maturity is E:P (Proof-of-Concept), consistent with the input's 'POC publicly available' flag and the referenced exploit writeup (github.com/wawyw/cve_report). There is no CISA KEV listing and no EPSS value provided, so there is no evidence of active, widespread exploitation - exploitation status is best described as 'publicly available exploit code exists,' which is a distinct and weaker signal than in-the-wild use. One notable tension: CWE-434 unrestricted file upload in a PHP application very commonly enables webshell deployment and full RCE, which would justify C:H/I:H/A:H; the vendor's conservative VC:L/VI:L/VA:L (typical of VulDB scoring) likely understates realistic worst-case impact, so defenders should treat the true technical ceiling as higher than the 5.3 suggests. The product is also niche and self-hosted, limiting the attack surface across most enterprise fleets.

An attacker with a low-privilege authenticated account on a Form Tools installation sends a crafted AJAX request to the Files::uploadFile handler in global/code/actions.php, uploading a file whose type is not properly restricted. Because a public proof-of-concept exists, a malicious PHP file could plausibly be placed in a web-accessible path and then requested to execute code, though the vendor-rated impact is limited to low confidentiality, integrity, and availability effects.