HortusFox EUVD-2026-95792

Requires an authenticated HortusFox account with access to the plant-attachment feature (PR:L) and the ability to reach /plants/attachments/add; the attacker uploads a file whose client-supplied extension is preserved and stored under the web-served public/attachments/ directory. Stored-XSS exploitation (HTML/SVG) additionally requires a victim user or administrator to open the attachment. The full remote-code-execution path is gated by a specific deployment condition - the .htaccess restrictions in public/attachments/ must be unenforced (e.g., Apache with AllowOverride disabled, or a server such as Nginx that ignores .htaccess), allowing an uploaded .php file to be executed. Limiting factors: valid credentials are mandatory, RCE depends on a non-default/misconfigured web server, and the XSS path depends on victim interaction, all of which narrow realistic exploitation below the raw CVSS score.

The input provides a CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, base 7.7, HIGH). Key signals: attack vector is network (AV:N) with low complexity (AC:L), but exploitation requires low privileges (PR:L) - i.e., an authenticated account - and carries an Attack Requirement (AT:P), which maps directly to the description's caveat that the PHP-to-code-execution path only works 'where .htaccess is unenforced.' No EPSS score was supplied, so exploitation probability cannot be quantified. This is NOT in CISA KEV (no KEV signal in input), so there is no confirmed active exploitation. No exploit-code flag was provided, though a public technical write-up on hackmd documents the stored-XSS path, lowering the practical barrier to reproduction. The signals are internally consistent - the HIGH-impact VC/VI/VA:H reflects the realistic code-execution outcome, but AT:P and PR:L correctly temper it: this is not an unauthenticated internet-wide worm candidate. Net judgment: a genuine but conditional priority - high impact for operators running HortusFox with semi-trusted or multi-user access, materially de-rated by the authentication requirement, the misconfiguration dependency for full RCE, and the product's small deployment footprint. Treat as a 'patch promptly if you run it' issue rather than an emergency fleet-wide item.

An authenticated low-privilege HortusFox user (or an attacker who has obtained any valid account) uploads a crafted SVG or HTML file as a plant attachment via /plants/attachments/add; because the file retains its client-supplied extension and is stored under the web-served public/attachments/ directory, it executes as stored XSS when another user or administrator opens it, enabling session theft or admin takeover. On deployments where .htaccess restrictions are not enforced (e.g., Nginx or Apache with AllowOverride off), the same flaw lets the attacker upload a .php file and achieve remote code execution. A public technical write-up describing the stored-XSS path exists, but no weaponized exploit tool is confirmed in the input.