PictShare EUVD-2026-109784

Exploitation requires the attacker to drive the file-upload path in src/inc/core.php architect() / api.class.php upload() (URL-pull or base64 upload) and to issue concurrent requests whose temp-file names collide - in the vulnerable code the name is derived from user-controlled input such as the basename of the upload URL, producing a predictable ROOT/tmp path. The attacker must then win the TOCTOU race window between the mime/sha1/naughty-list validation and storeFile() so a file is swapped in after it was validated. Limiting factors: the race window is narrow and timing-dependent (AC:H, vendor calls exploitability 'difficult'), the attacker needs upload capability against the instance (vendor rates PR:L; note PictShare may allow anonymous uploads by default, which would lower this), and the practical impact is limited to bypassing upload content checks rather than gaining code execution. Fixed in 3.7.2, which replaces user-derived temp names with getTempFilePath() using random_bytes(16).

This is a low-priority issue despite being remotely reachable. The input CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:L/UI:P) yields a base score of only 1.2, and every impact metric is Low (VC:L/VI:L/VA:L) with no scope change - signals that align with the vuln.today 'monitor' decision label rather than any act_now/emergency urgency. The 'E:P' metric and the description ('The exploit has been published') indicate proof-of-concept maturity, not active exploitation: there is no CISA KEV listing and no EPSS score in the supplied data, so widespread or automated exploitation is not indicated. The key limiting factor is the high attack complexity: the GitHub commit evidence confirms the mechanism is a TOCTOU race where two concurrent requests share a temp-file name derived from user input (the basename of an upload URL) and can swap each other's file between validation and storeFile(). Winning that narrow race window is difficult (AC:H, 'exploitability regarded as difficult'), and the payoff is only bypassing mime/sha1/naughty-list checks on a self-hosted image host, not code execution. Note one tension to verify: the vendor assigns PR:L, but PictShare commonly permits anonymous uploads in default deployments, in which case PR:N would be more accurate - this does not change the low overall severity.

An attacker issues two near-simultaneous upload requests (URL-pull or base64) to a PictShare instance, crafted so both resolve to the same predictable temp-file path in ROOT/tmp. By winning the race between the validation step and storeFile(), the attacker swaps in a file that was never checked, causing an unsupported or naughty-listed file to be stored. A published proof-of-concept and a write-up (xmit.xyz) exist, but the high-complexity timing requirement makes reliable exploitation difficult.