Adobe Commerce CVE-2026-34649

No special conditions - remote unauthenticated exploitation against default configurations of Adobe Commerce, consistent with CVSS AV:N/AC:L/PR:N/UI:N and the advisory statement that exploitation does not require user interaction. The only real limiting factors are that the target must be an internet-reachable Adobe Commerce instance at one of the affected patch levels (2.4.4-p17 / 2.4.5-p16 / 2.4.6-p14 / 2.4.7-p9 / 2.4.8-p4 / 2.4.9-beta1 or earlier), and that any upstream WAF or rate-limiting proxy could blunt the resource-exhaustion attempt. The specific vulnerable endpoint or parameter is not disclosed in the available data, so the exact request needed to trigger it is unconfirmed.

The signals are moderate and internally consistent for a DoS issue. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) describes a network-reachable, low-complexity, unauthenticated attack with high availability impact but zero confidentiality or integrity impact - a classic resource-exhaustion profile that inflates to 7.5 purely on the availability leg. CISA's SSVC framework aligns: Exploitation is 'none' (no known activity), Technical Impact is only 'partial', but Automatable is 'yes', meaning an attacker could script the exploit at scale once a method is known. EPSS is very low (0.04%) and there is no KEV listing or public POC, so this is not a same-day emergency. The practical priority is moderate: because it is unauthenticated, automatable, and hits availability of a revenue-generating storefront, internet-facing Adobe Commerce operators should patch on a normal-to-expedited cycle, but this is not a data-breach-class critical. Note the input provides no specific triggering endpoint, so the exact ease of exploitation cannot be independently confirmed from the data.

A remote, unauthenticated attacker sends a small number of specially crafted HTTP requests to an internet-facing Adobe Commerce storefront that trigger a disproportionately expensive server-side operation, consuming CPU or memory until the application pool is starved. Because the SSVC assessment marks the issue as automatable, the attacker scripts the requests to sustain the condition, taking the storefront offline. No public POC is currently identified, so exploitation would require the attacker to independently discover the vulnerable code path.