Adobe Campaign Classic EUVD-2026-52513

Exploitation requires the attacker to first hold low-privileged authenticated access to Adobe Campaign Classic (CVSS PR:L) - for example any valid ACC operator login or an application/API credential - and network reachability to the vulnerable ACC application server endpoint that constructs the SQL command. No user interaction is required (UI:N) and attack complexity is low (AC:L). The limiting factors that reduce real-world risk are the mandatory authenticated foothold and the need for the ACC API/console surface to be network-accessible to the attacker; deployments that keep ACC off the public internet and tightly govern low-privileged account issuance materially raise the bar. The exact injectable feature/endpoint is not enumerated in the provided data and should be confirmed from Adobe advisory APSB26-120.

This is a genuine high priority, not an inflated high-CVSS artifact. The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H combines network reach, low attack complexity, no user interaction, only low privileges, full confidentiality/integrity/availability impact, and a scope change - the reason the score reaches 9.9. The one meaningful barrier is PR:L: an attacker needs some authenticated foothold (any low-privileged ACC account or an application/API credential), which limits fully anonymous mass exploitation. No EPSS score, KEV listing, SSVC decision, or POC was provided in the input, so real-world exploitation volume cannot be quantified from available data; the absence of a KEV entry means there is no confirmed active exploitation at this time. The realistic risk profile is that of a highly attractive post-authentication target on an internet-facing enterprise system - treat as urgent, but note that exposure is bounded by how broadly low-privileged ACC accounts and APIs are reachable.

An attacker who has obtained any low-privileged Adobe Campaign Classic account or operator/API credential sends crafted input to a network-reachable ACC endpoint whose query is built with unsanitized parameters. The injected SQL manipulates the backing database and is chained to reach arbitrary code execution in the current user's context, crossing into resources outside the original component (scope change). No user interaction is required, and no public POC is confirmed in the available data.