Adobe Commerce CVE-2025-54264

Exploitation requires an authenticated high-privileged account (CVSS PR:H) in Adobe Commerce - the attacker must already have elevated back-office access to inject script into the vulnerable form field, which is then stored. It further requires victim user interaction (UI:R): a victim must browse to the specific page that renders the poisoned field for the stored JavaScript to execute in their browser. Limiting factors that reduce real-world risk: the attacker cannot be unauthenticated/external (no PR:N path), the specific vulnerable form field must be reachable and populated by the attacker, and the payload only fires when a victim visits the affected page. Affected versions are 2.4.9-alpha2, 2.4.8-p2, 2.4.7-p7, 2.4.6-p12, 2.4.5-p14, 2.4.4-p15 and earlier; patched builds from Adobe remove the condition.

This is a genuine but conditional risk rather than a drop-everything emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:N, base 8.1 High) tells a consistent story: network-reachable and low-complexity, but it explicitly requires high privileges (PR:H) and victim user interaction (UI:R), which materially constrain real-world exploitability. The scope change (S:C) and C:H/I:H reflect that injected script executes in a victim admin/user browser context enabling session takeover, which is credible for stored XSS. Supporting signals point to lower immediacy: EPSS is only 0.60% (47th percentile), there is no CISA KEV listing, and no public exploit is identified, so there is no evidence of active or widespread exploitation. The signals are not conflicting - they agree this is a meaningful-impact flaw whose exploitation is gated by needing an already-privileged (e.g., admin/merchant-panel) account plus luring a victim to view the poisoned field. Note PR:H means the attacker must already be authenticated with high privileges, so an external unauthenticated actor cannot exploit this directly; the primary threat models are malicious or compromised privileged users and privilege-escalation/lateral movement after an initial foothold. Priority is moderate: patch in normal cycle for most, but treat as higher priority for multi-tenant or large merchant-staff Commerce deployments where many privileged accounts exist.

A high-privileged attacker (e.g., a compromised or malicious back-office/admin user) injects malicious JavaScript into a vulnerable Adobe Commerce form field, where it is stored. When another legitimate user with an active session browses to the page rendering that field, the script executes in their browser and can hijack their session for account/session takeover. No public proof-of-concept exploit has been identified at the time of analysis.