CVE-2026-48381

The CVSS 9.0 score paired with an EPSS probability of just 0.00476 creates an analytical puzzle worth solving. A vulnerability this severe typically sees exploitation probabilities in the 0.1-0.4 range; the two orders-of-magnitude gap tells you something important about the exploitation model. The advisory explicitly states exploitation depends on conditions beyond attacker control—that language matters. It signals this SQL injection isn't directly triggerable over the network but requires a specific configuration state, existing workflow data, or environmental condition within the ACC installation to become exploitable. For defenders, that means automated scanning will largely ignore this, but a patient adversary with ACC-specific knowledge won't. The scope change is the detail that should drive your prioritization. In ACC's architecture, the application operates with significant database privileges to support its marketing workflow engine. A SQLi that changes scope implies escaping the application's security context into broader system privileges—including, given ACC's design, potential OS-level command execution. This chains from data exfiltration to arbitrary code execution, which is technically notable because standard SQL injection typically hits a database boundary, not an application boundary. Your patch timeline should account for the fact that this is a high-value target for targeted campaigns, not mass exploitation. The low EPSS score correctly predicts automated bots won't hit it; it says nothing about whether a motivated actor with ACC-specific knowledge is already enumerating configurations in your environment. The 'no user interaction required' claim paired with the 'conditions beyond attacker control' qualifier creates a logical tension worth interrogating: if the exploitable state must already exist, who or what creates it? Either there's an unauthenticated vector creating prerequisites (which should be in scope), or there's an authenticated path that should disqualify the no-user-interaction claim. Adobe hasn't fully resolved this, which leaves you with genuine uncertainty about the true exploitation barrier. Focus your defensive posture on three areas: audit your ACC configurations and workflow states for conditions that could enable exploitation (even if Adobe won't specify what those are), treat downstream integrations—CRM connectors, marketing cloud credentials, email infrastructure—as potentially exposed since the arbitrary code execution inherits those trust relationships, and recognize that exploitation conditions accumulate over time as ACC instances grow more workflows and custom integrations. A vulnerability difficult to exploit at disclosure becomes progressively easier as your system ages. The EPSS model treats conditions as environmental constants; they're not. Your remediation urgency should reflect that this barrier degrades continuously, not because attackers got smarter, but because your own operations built the conditions they need.

Reviewed through automated stages and approved by a human before publication.