Adobe shipped a patch on July 29 for CVE-2026-48449, an incorrect authorization flaw in Campaign Classic v7 carrying the maximum possible CVSS score of 10.0. The vulnerability affects both Windows and Linux builds at version 7.4.3 build 9397 or earlier, and could allow an unauthenticated attacker to execute arbitrary code in the context of the current user without requiring any user interaction whatsoever — no phishing click, no social engineering, nothing beyond network access to a vulnerable instance. The fix, delivered under bulletin APSB26-114, brings affected deployments to ACC v7.4.3 build 9398. Adobe says it isn't aware of active exploitation yet, but a maximum-severity, no-interaction-required RCE in a marketing automation platform is exactly the kind of vulnerability that moves from "not yet exploited" to "actively exploited" fast once a public proof-of-concept circulates, which is a near-certainty for a CVSS 10.0 finding this widely covered.
Why "incorrect authorization" is worse than it sounds here
CVE-2026-48449 is classified as an incorrect authorization flaw rather than a memory corruption bug or an injection vulnerability, which matters for how you should think about its exploitability. Authorization flaws of this kind typically mean the application fails to properly verify that a request is coming from a permitted source before executing a privileged action — in this case, one severe enough to enable code execution without any authentication step at all. That's a fundamentally simpler attack path than a buffer overflow or a complex injection chain: there's no memory layout to defeat, no encoding to bypass, just a request that the application should have rejected and didn't. Simpler exploitation paths generally correlate with faster and more reliable weaponization once details become public, which is part of why CVSS scoring weighs "no user interaction required" so heavily in the final severity number.
The bundled SQL injection flaw matters for your patch scope
Adobe's same update also resolves CVE-2026-48448, a high-severity SQL injection flaw (CVSS 8.6) that could enable arbitrary file reads, in the same Campaign Classic release. Treating these as two separate, independently prioritizable issues would be a mistake for most organizations — since both are fixed in the same build, there's no operational reason to patch one without the other, and an attacker chaining the SQL injection flaw's file-read capability with the authorization bypass could plausibly extend their reach beyond what either vulnerability alone would allow. Any patch validation testing your team runs on this release should explicitly confirm both CVEs are addressed, not just the higher-profile CVSS 10.0 finding.
Why marketing automation platforms are an underrated attack surface
Campaign Classic is marketing automation and customer communication infrastructure — the kind of system that often sits outside the direct ownership of security or core IT teams, managed instead by marketing operations staff who may not be plugged into the same vulnerability disclosure and patch management processes that cover customer-facing production infrastructure. That organizational gap is a real risk multiplier: a maximum-severity vulnerability in a system your security team doesn't actively monitor for patch compliance can sit unpatched far longer than the same severity finding in a system under direct security team ownership. Marketing and customer engagement platforms frequently have access to customer contact databases, campaign content systems, and sometimes broader CRM integrations — meaning a compromise here isn't limited to defacement risk, it's a potential path to customer data and further lateral movement into connected systems.
Why Windows and Linux both being affected matters for your patch rollout
CVE-2026-48449 affects Campaign Classic v7 on both Windows and Linux, which is worth flagging explicitly because organizations sometimes assume a vulnerability disclosed for one platform doesn't apply if they run the other. That assumption doesn't hold here, and it's worth double-checking your own patch rollout plan covers every platform your Campaign Classic deployments actually run on, rather than assuming a single platform-specific patch cycle addresses the full scope of your exposure. Mixed-platform environments — common in organizations that have grown through acquisition or that run different business units on different infrastructure standards — are exactly where this kind of scope gap tends to slip through, since the team patching the Windows instances and the team patching the Linux instances may not be the same team, and neither may have full visibility into whether the other has completed their half of the rollout.
What to actually do this week
-
Identify every Campaign Classic instance in your environment, including any deployment managed by marketing, agency partners, or business units outside your core IT asset inventory. This is the step most likely to be incomplete, since Campaign Classic ownership often sits with marketing operations rather than IT.
-
Patch to ACC v7.4.3 build 9398 immediately rather than scheduling it into a routine maintenance window — a CVSS 10.0, no-interaction-required RCE warrants emergency patch treatment regardless of which team owns the affected system.
-
Check whether your Campaign Classic instance is internet-facing at all, and if remote access is required for legitimate business reasons, ensure it's gated behind a VPN or equivalent access control rather than directly exposed, pending the patch rollout.
-
Review recent logs on any unpatched instance for signs of exploitation, particularly around the disclosure window, since attackers frequently begin scanning for vulnerable, unpatched instances of a newly disclosed CVSS 10.0 finding within days of public disclosure.
-
Extend this patch verification to any third-party agency or vendor that manages Campaign Classic on your behalf. If a marketing agency runs your instance, confirm directly with them that the patch has been applied — don't assume it has been, given how often ownership ambiguity delays patching on outsourced marketing infrastructure specifically.
The pattern worth flagging to your security leadership
This is Adobe's second round of CVSS 10.0 disclosures in quick succession this cycle, following an earlier batch of seven maximum-severity flaws across ColdFusion and Campaign Classic. Two maximum-severity clusters from the same vendor in close proximity is worth flagging as a pattern rather than treating each disclosure in isolation — it suggests either a broader architectural review currently underway at Adobe surfacing a backlog of similar issues, or a shared underlying weakness across related product lines that hasn't been fully addressed yet. Either way, organizations running any Adobe Experience Cloud or Campaign product family software should treat upcoming Adobe security bulletins with elevated attention for the next several release cycles, rather than assuming this cluster of findings is now fully resolved.
What "not aware of exploitation in the wild" actually tells you, and doesn't
Adobe's statement that it isn't aware of active exploitation is worth reading precisely rather than as blanket reassurance. It reflects Adobe's own visibility into exploitation attempts, which is necessarily limited to what gets reported back to them or observed through their own telemetry — it doesn't mean no attacker has begun probing for vulnerable instances, and it definitely doesn't predict how long that will remain true once public interest in a CVSS 10.0 finding inevitably produces detailed technical writeups and, likely, proof-of-concept exploit code. Historically, the gap between "no known exploitation" and "active exploitation observed" for maximum-severity, no-interaction vulnerabilities in widely deployed software has been measured in days to a couple of weeks once technical details circulate publicly, not months. Treating this specific claim as a reason to deprioritize the patch would be a mistake — it's accurate information about the current moment, not a forecast about how much time you have to act.
How to verify your patch actually took effect
Given the severity here, it's worth building in an explicit verification step after patching rather than assuming a successful update process means the vulnerability is closed. Confirm the running build number on every instance matches 7.4.3 build 9398 specifically, rather than trusting that an update process completed without error — patch deployment failures that leave a system on a partially updated or rolled-back version are common enough in enterprise environments that a build-number spot check is a reasonable use of ten minutes per instance, particularly for a finding at this severity level. For any instance managed by a third party, request the same explicit build-number confirmation rather than accepting a general assurance that "we've patched everything," since ownership ambiguity is precisely the condition that makes verification worth the extra step.
Why this is a good moment to audit patch ownership generally
Beyond the immediate patch action, CVE-2026-48449 is a useful trigger for a broader question worth asking this month: which systems in your organization have unclear or split ownership between IT/security and a business function like marketing, sales, or HR — and does your vulnerability management process actually reach those systems with the same rigor it applies to core infrastructure? Marketing automation, HR platforms, and sales enablement tools are common blind spots precisely because they're business-owned rather than IT-owned, even though they frequently hold sensitive data and increasingly integrate deeply with the rest of your technology stack. A maximum-severity vulnerability disclosure is a low-cost opportunity to test whether your patch management process actually has visibility into those systems, before a less forgiving incident forces the same discovery.