NivoCart EUVD-2026-83724

Requires an authenticated back-office session with at least 'view-only' privileges (PR:L) - not exploitable pre-authentication. The specific trigger is the File Manager multi() upload endpoint, which skips file-extension validation in two cases: (1) when a new filename is supplied, or (2) when the chunks parameter is set to 2 or higher. The target image/data/ directory must be web-accessible (its default state) so the uploaded PHP can be requested and executed. No user interaction and no non-default configuration are needed beyond possessing the low-privilege account; the main limiting factor is that low-privilege back-office access.

This is a genuine high-priority issue where exploitable. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H, 8.7) is internally consistent with the description: a network-reachable, low-complexity flaw requiring only low privileges (view-only back-office access) that yields full remote code execution - the highest-impact outcome. My independent read agrees with the vendor's severity. However, several exploitation-probability signals are ABSENT: no EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation status is 'no public exploit identified at time of analysis.' No SSVC decision data was supplied. The dominant limiting factor is the PR:L requirement - an attacker must already possess a valid (even if minimally-privileged 'view-only') back-office account, which sharply narrows the realistic attacker population and makes this more an authenticated-privilege-escalation-to-RCE than an internet-facing pre-auth compromise. Combined with the product's very small deployment footprint (see prevalence), real-world risk is materially lower than the raw 8.7 suggests, though for any exposed NivoCart instance with untrusted back-office users it is a full-compromise vector.

An attacker holding a low-privileged 'view-only' NivoCart back-office account calls the File Manager multi() upload endpoint and either supplies a new filename with a .php extension or sends the upload with the chunks parameter set to 2 or higher, both of which bypass extension validation. The malicious PHP file lands in the web-accessible image/data/ directory, and the attacker then requests its URL to execute arbitrary code on the server. No public exploit code was identified at the time of analysis.