FOG Project EUVD-2026-112150

Not remote-unauthenticated. Concrete prerequisites, all of which must hold: (1) a valid FOG account with uType=1 and uAllowAPI enabled; (2) possession of that user's API token AND the server-wide global FOG API token (both are validated by the API); (3) storage replication must be enabled; and (4) at least one usable Storage Node that FOGImageReplicator will actually contact, so the attacker-controlled user/pass/ftppath values are interpolated into the lftp command. Limiting factors that reduce real-world exposure: the attack requires authentication (PR:L), the global API token is an additional secret beyond the user token, and replication plus a usable node are deployment-dependent rather than universal defaults; command execution is reached only once the replicator runs against the tampered node.

The CVSS 3.1 base of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) captures the core danger: a network-reachable API flaw that lets an authenticated low-privileged user (PR:L) reach root command execution. However, several real-world signals temper the raw score. Exploitation is gated by multiple preconditions that CVSS does not express: the attacker needs a uType=1 account with API access enabled, possession of BOTH the user's API token AND the global FOG API token, storage replication turned on, and a usable Storage Node the replicator will actually contact. No EPSS score and no KEV listing are provided in the input, so there is no evidence of in-the-wild or widespread automated exploitation; the vuln.today decision label is 'this_week' (not act_now/emergency), consistent with a serious but non-emergency item. A detailed reproduction exists in the vendor GHSA advisory (performed only in a disposable lab), so this is a public PoC reference, not confirmed working weaponized exploit code and not confirmed active exploitation - these are distinct signals and should not be conflated. Net: this is a genuine high-severity privilege-escalation-to-root issue worth patching promptly, but the token and configuration prerequisites make it more plausible as a targeted/insider or chained scenario than mass opportunistic exploitation. Note a conflict in the supplied version intelligence (see confidence_notes) that should be resolved before scoping affected estates.

An authenticated FOG user with uType=1 and API access, holding both their own API token and the global FOG API token, sends PUT /fog/storagenode/{id}/edit to write attacker-controlled values into the Storage Node's user, pass, and ftppath fields. With storage replication enabled, the root-running FOGImageReplicator later interpolates those fields into an lftp command run via proc_open(), executing the attacker's injected commands as root. A step-by-step reproduction (lab-only, synthetic node) is published in the vendor GHSA advisory, so a public PoC reference exists; it is not verified as standalone working exploit code.