Adobe Campaign Classic CVE-2026-48449: the Same CVSS 10.0, a Third Time

On 29 July 2026 Adobe published APSB26-114, a Priority 1 bulletin for Adobe Campaign Classic. It fixes CVE-2026-48449 — CWE-863, Incorrect Authorization, arbitrary code execution, CVSS 3.1 base score 10.0, vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Unauthenticated, no user interaction, scope changed, everything high.

That is the third maximum-severity authorization bypass Adobe has shipped for the same product in 50 days. Not three bugs in a family of related products — three bulletins for Adobe Campaign Classic v7, each patching one more route through the same broken assumption, each fix arriving as the next bulletin's vulnerable version. If your vulnerability management process consumes CVE IDs and compares version strings, this product has spent two months proving that neither of those is a control.

Three Adobe Campaign Classic bulletins, one authorization model

The sequence, taken verbatim from Adobe's own advisories:

Bulletin	Published	CVE	Category	CVSS	Affected build	Fixed build
APSB26-66	9 Jun 2026	CVE-2026-48303	Incorrect Authorization (CWE-863)	10.0	≤ 7.4.3 build 9394	9396
APSB26-66	9 Jun 2026	CVE-2026-47938	Incorrect Authorization (CWE-863)	10.0	≤ 7.4.3 build 9394	9396
APSB26-69	30 Jun 2026	CVE-2026-48286	Incorrect Authorization (CWE-863)	10.0	≤ 7.4.3 build 9396	9397
APSB26-114	29 Jul 2026	CVE-2026-48449	Incorrect Authorization (CWE-863)	10.0	≤ 7.4.3 build 9397	9398
APSB26-114	29 Jul 2026	CVE-2026-48448	SQL Injection (CWE-89)	8.6	≤ 7.4.3 build 9397	9398

All three bulletins carry Priority 1. All three carry the same note: the advisory applies to fully on-premise deployments and to the on-premise components of hybrid deployments, because Adobe-hosted instances "have already been remediated and require no customer action." All four code-execution entries share an identical CVSS vector, character for character.

One detail worth flagging for accuracy: Adobe's advisory table classifies CVE-2026-47938 as CWE-863 leading to arbitrary code execution, while NVD records it as CWE-918 (server-side request forgery) leading to privilege escalation. Same score, same vector, two different stories about what the bug is. Hold onto that — it becomes the point later.

The acknowledgements are as informative as the vulnerabilities. APSB26-66 thanks a named external researcher, Jamie Parfet, for CVE-2026-48303 alone. The other four entries across the three bulletins carry no external credit at all, which is what internally discovered findings look like on an Adobe bulletin.

What CVE-2026-48449 actually reaches

"Arbitrary code execution in the context of the current user" is a flat sentence that hides an unusually bad blast radius, because of what Adobe Campaign Classic is.

ACC on-premise is not a website. It is a marketing execution platform, and per Adobe's own server configuration reference the nlserver process runs a set of modules on one box: web (a Tomcat instance, port 8080 by default), wfserver (the workflow engine), mta (the mail transfer agent that actually sends your campaigns), tracking, inMail, and syslogd. On Linux those run as the dedicated neolane user out of /usr/local/neolane.

Stack that up and the code execution lands next to three things at once:

• The recipient datamart. The marketing database is the highest-cardinality customer PII store most organisations own — names, addresses, phone numbers, consent flags, behavioural history, segmentation attributes. It is usually a fuller picture of a customer than the CRM.
• The ability to send mail as the brand. The MTA is configured with your relays and, in most deployments, with the signing material for your sending domains. Code execution on the MTA host does not produce phishing that looks like your brand; it produces mail that authenticates as your brand, to your own opt-in list, from your own infrastructure.
• A documented command-execution surface. Adobe's security configuration guidance tells administrators to restrict external commands to a dedicated Unix user — because the workflow engine is designed to run external commands and JavaScript. An attacker who reaches the workflow engine with operator rights does not need to drop a web shell to have a scheduler, a script host, and an exfiltration path. Those are product features.

CVE-2026-48448, the SQL injection rated 8.6, is the quiet one in the same bulletin. NVD describes it as arbitrary file system read. On an ACC server the interesting files are not user documents — they are serverConf.xml and config-<instance>.xml, which hold database connection details and internal account material. A file read on this product is a credential harvest.

The build that fixed you in June is the build that failed you in July

Read the affected/fixed columns again as a timeline rather than a table.

Build 9396 was the remedy Adobe told customers to install on 9 June. On 30 June, build 9396 was the vulnerable version. Build 9397 was the remedy on 30 June. On 29 July, build 9397 was the vulnerable version. Twice in a row, an organisation that patched immediately and correctly — inside Adobe's own 72-hour guidance — was running a maximum-severity unauthenticated RCE within three weeks, through no failure of its own.

"We're on the latest build." "As of when? Because your compliance evidence says 9397, your last scan says 9397, and 9397 has been a CVSS 10.0 since the twenty-ninth."

This is what a class defect looks like from the outside. When the same CWE, the same impact and the same CVSS vector recur across consecutive builds of one product, the honest reading is not "three unrelated bugs were found." It is that the authorization model has a systemic weakness and each bulletin closes one more path through it. The CVE-per-endpoint stream is the symptom; the fix is not in the CVE list.

The practical consequence: a version check answers "have I applied the last known fix," which is a strictly weaker question than "is this endpoint reachable and does it enforce authorization." Between the two, only the second one survives the next bulletin.

SAP shipped this same shape in 2023

This pattern has precedent, and it is worth naming because it tells you what to expect next.

In March 2023, SAP published a run of advisories against NetWeaver Application Server for Java 7.50 whose descriptions are nearly interchangeable. CVE-2023-24526 (CWE-306, CVSS 5.3): the Classload Service "does not perform any authentication checks for functionalities that require user identity." CVE-2023-26460 (CWE-284, CVSS 5.3): the Cache Management Service, same sentence. Same product, same version, same day, different service — one CVE each.

Two things generalise from it. First, when a platform's authorization is enforced per-service rather than centrally, the finding count scales with the number of services someone bothered to look at, not with the number of defects in the design. Second, the scores fragment: those SAP entries landed at 5.3 individually, which is a "next quarter" number, while the underlying condition — unauthenticated access to internal services on a middleware host — is not a 5.3 problem. Adobe's version of this is scoring at 10.0 each time, which at least fails loudly.

Adobe is about to stop counting them separately

Now the footnote. At the bottom of APSB26-114, under the vulnerability table, Adobe added this:

"Effective August 11, 2026, Adobe may assign a single CVE identifier to internally discovered vulnerabilities with the same severity rating and CWE category when a release includes systemic fixes."

Eight days from this article, the exact signal that made the Campaign Classic pattern visible — three CVE IDs, same CWE, same severity, consecutive builds — becomes one CVE ID by policy. The same five entries in the table above would, under the new rule, plausibly compress to two.

This is not Adobe breaking the rules. The CVE Program's CNA rules require separate IDs for independently fixable vulnerabilities and explicitly instruct that where a CNA is uncertain whether two issues are independently fixable, it should assign a single ID. A release containing systemic fixes to one authorization model is a defensible single-ID call. And Adobe is not hiding it — the policy is published in the bulletin and in Adobe's security blog, which states plainly: "some releases may not have individual CVEs assigned to each vulnerability when the release contains widespread fixes."

The reason it is happening is the part worth sitting with. That same post explains why Adobe moved to twice-monthly bulletins on 14 July 2026:

"Frontier AI models and agentic analysis tooling now uncover flaws across large codebases far faster than traditional methods could. Adobe is applying those same capabilities continuously to help accelerate vulnerability discovery across our products at machine scale... the window between public vulnerability disclosure and active exploitation is compressing from days to hours."

So the chain is: AI-assisted discovery raises the internal find rate, the find rate outgrows a monthly bulletin, the bulletin cadence doubles, and the CVE ID — one per independently fixable defect — stops being a workable unit when a single release fixes a whole class at once. Adobe is not distorting a metric here so much as demonstrating that the metric was always a proxy for engineering effort, not for risk.

Everyone downstream should notice, because that proxy is load-bearing. "Critical CVEs open" is on security dashboards. "CVEs remediated this quarter" goes in board packs. Patch SLAs are written per-CVE. Vendor risk questionnaires count CVEs per product per year. Every one of those numbers is about to move for at least one major vendor without any underlying change in risk — and it will move down, which is the direction nobody audits.

Two corollaries follow:

• A falling CVE count is not evidence of improving product security, and from 11 August it is not even evidence of a falling defect count. If your metric can be changed by someone else's editorial policy, it was never your metric.
• CVE-to-CWE ratio is now a broken proxy for depth. One merged CVE covering a systemic fix and one CVE covering a single-endpoint bug will look identical in a feed. Only the bulletin text distinguishes them, and bulletin text is not machine-consumed by most vulnerability management pipelines.

The defensible unit of measurement was never the CVE. It is whether a specific path on a specific asset in your estate is reachable and exploitable right now.

Remediation

Priority 1, no known exploitation as of Adobe's 29 July bulletin — which is a window, not an absence. For calibration: when Adobe shipped ColdFusion CVE-2026-48282 on 1 July, it was under active attack within hours of disclosure. We wrote that one up here. Same vendor, same month, same "not aware of any exploits" wording in the bulletin.

1. Am I affected?

Three conditions, all of which must be checked — the version is only the first.

Deployment type. Adobe-hosted instances are already remediated. This affects fully on-premise deployments and the on-premise components of hybrid deployments. Hybrid is the trap: teams that migrated the console and reporting to Adobe-hosted often still run an on-premise MTA or mid-sourcing box, and that box is in scope.

Build number. Per Adobe's installation documentation, nlserver pdump reports the version and build of a running server:

# On the Campaign server (Linux, as the neolane user)
nlserver pdump          # -> "Application server for Adobe Campaign Classic (7.X YY.R build XXXX@SHA1)"

# Cross-check from the package manager — build number is in the package name
rpm -qa | grep nlserver # -> nlserver6-v7-<build>-0.x86_64.rpm

Anything at build 9397 or below is vulnerable to CVE-2026-48449 and CVE-2026-48448. Anything at 9396 or below was already vulnerable to CVE-2026-48286 and has been since 30 June — check your patch history, not just your current state.

Reachability. Test from outside your perimeter, from a host that is not on the management VLAN and not in any allow-listed range. What you are looking for is whether the web tier answers at all to an unauthenticated caller:

# From an external vantage point, not from inside the estate
curl -skI https://<campaign-host>/            # does the app tier answer?
curl -skI http://<campaign-host>:8080/        # is the Tomcat module directly exposed?

A reverse proxy in front does not by itself make you safe here, but a Campaign web module answering directly on 8080 from the internet is an emergency independent of any CVE.

2. Patch — exact fixed versions

Product	Fixed version	Platform	Priority
Adobe Campaign Classic	ACC v7: 7.4.3 build 9398	Windows, Linux	1

Adobe's guidance on the ColdFusion round of Priority 1 fixes was to patch "as soon as possible (for example, within 72 hours)." Apply the same clock here. And schedule the next one: Adobe now publishes on the second and fourth Tuesday of each month.

3. Can't patch now? Compensating controls

All of these are documented Adobe configuration, in serverConf.xml and config-<instance>.xml in the conf directory of the installation. None of them are a substitute for build 9398; they narrow who can reach the vulnerable code.

• Security zones. ACC ships a security zone model with public, vpn and lan zones and subNetwork elements carrying IP masks. Audit which zone the internet-facing path resolves to and what that zone permits. Set sessionTokenOnly where user/password authentication is not required, force allowDebug off in production, and set allowUserPassword to true only for the zones and integrations that genuinely need it.
• Bind sessions to source IP. Set checkIPConsistent="true" in the authentication node, and cut sessionTimeOutSec and securityTimeOutSec down from the 86400-second defaults. A day-long session token on an internet-facing marketing server is a day-long window.
• Put a real web server in front. Adobe's own recommendation is a dedicated web server as the sole HTTP entry point when the Campaign host is internet-reachable. Terminate TLS there, allow-list the paths your tracking, mirror pages and integrations actually need, and drop everything else — including the HTTP methods Adobe documents as a risk on nlserver port 8080 (DELETE, OPTIONS).
• Constrain the SSRF surface. ACC governs outbound URL access from JavaScript in three modes — blocking (allow-list only, the default), permissive, and warning. Confirm you are in blocking mode. Deployments drift to permissive during an integration project and stay there; CVE-2026-47938 is exactly the class of bug that turns that drift into privilege escalation.
• Constrain uploads and external commands. Enforce serverConf/shared/datastore/@uploadAllowlist with a tight file-type regex, and confirm external workflow commands run as a dedicated, low-privilege Unix user distinct from the account owning the application and its configuration.

4. Hunt for compromise

Assume nothing about dwell time: build 9396 has been exploitable since 30 June and build 9394 since 9 June. Your hunt window starts in early June, not on 29 July.

Stage	ATT&CK	What to look for
Initial access	T1190	Unauthenticated requests to application endpoints in the web-tier access logs — especially POSTs that precede a session appearing without a login event
Execution	T1059	Workflow activities that invoke external commands or JavaScript, created or modified outside change windows
Persistence	T1505.003	New or modified files under the web root and the upload datastore; timestamps that do not match a deployment
Persistence	T1136 / T1078	Operator accounts created in the Campaign schema, or existing operators granted admin rights, with no ticket behind them
Credential access	T1552.001	Reads of serverConf.xml / config-<instance>.xml — the target of the CVE-2026-48448 file read
Collection	T1213	Bulk queries or exports against the recipient tables; unexplained workflows with an export or file-write activity
Exfiltration	T1041 / T1567	Outbound sessions from the application user to destinations outside the known integration set
Impact	T1566	Deliveries that do not correspond to an approved campaign; sudden changes in target segment size or sending domain

Two Campaign-specific signals most generic hunts miss. First, check the delivery log against the campaign plan. A mailing sent from your infrastructure to your list with your signing keys is invisible to every anti-phishing control you own; the only place it looks wrong is next to the marketing calendar. Second, check the tracking and MTA volume baselines. Exfiltration of a recipient database from a host whose entire job is high-volume outbound traffic hides inside the noise floor by design.

Server logs are managed by the syslogd module and rotate — the documented default is 10 MB per file. Copy them off the host before you upgrade.

5. Eradicate and verify

Order matters. Do not patch first if you have any indication of compromise, because the upgrade will churn the evidence.

1. Preserve. Snapshot the host and copy the log tree and conf directory off the box before any upgrade.
2. Patch to build 9398.
3. Rotate what the bug could read. CVE-2026-48448 is an arbitrary file read and CVE-2026-48449 is code execution as the application user, so treat as exposed: the database credentials referenced in the dbcnx configuration, the internal account material under the authentication node, operator passwords, SMTP relay credentials, and any Experience Cloud or AEM integration tokens. If the instance holds DKIM signing keys for your sending domains, rotate those too — that is the one credential whose compromise is invisible to the recipient and expensive to unwind.
4. Diff the configuration against a trusted baseline: security zone definitions, IP masks, the outbound URL mode, the upload allow-list. An attacker who widens a zone leaves a change that survives your patch.
5. Re-verify from outside. Repeat the reachability test from an external vantage point after the change, not from a jump host inside the allow-list.
6. Rebuild if you found execution artefacts. Given a workflow engine that runs external commands as a product feature, "we removed the web shell" is not a conclusion you can defend.

One legal note for EU operators: the recipient datamart is personal data at scale. If your hunt finds evidence of access rather than just exposure, the GDPR Article 33 clock and any NIS2 reporting obligation start from awareness — which means the quality and timestamping of your hunt evidence is itself part of the deliverable.

Where Zero Hunt fits

Everything above converges on one question that a CVE feed structurally cannot answer: on my instance, today, is this path reachable and does it enforce authorization? Adobe just spent 50 days demonstrating that "we're on the latest build" has a shelf life measured in weeks, and from 11 August the CVE count that most programmes report against stops being a stable unit.

That is the gap Zero Hunt's 10-agent AI swarm is built for. The Recon and Web agents establish what is actually reachable on your perimeter rather than what the CMDB claims, and the Exploit agent generates a per-target exploit chain with a local LLM instead of replaying a PoC that may not match your deployment — which matters acutely for a product where hybrid topologies mean two organisations on the same build number have completely different exposure. Every skill is backtested in the AI Gym against Vulhub and Vulhub-Bench before it touches production, and every finding is ECDSA-signed at write time, so what you hold afterwards is a dated, verifiable statement that a specific endpoint was or was not exploitable — evidence, not a version string. Change-triggered campaigns close the rest of the gap: on a twice-monthly vendor bulletin cadence, a scheduler that re-validates within the hour of a perimeter change is the difference between a three-week exposure and a same-day one.

The compliance side matters here more than usual, because this article is partly about a metric quietly changing underneath everyone. Zero Hunt's continuous mapping of findings across 32 frameworks — NIS2, ISO 27001, DORA, GDPR and the rest — is scored on severity-weighted, validated findings from your own estate, not on counts of vendor-issued identifiers. When an auditor asks what your Adobe Campaign exposure was between 9 June and 3 August, the answer should be a signed evidence chain from the Trust Center with dates on it, not a CVE tally whose counting rules changed in the middle of the period.

If you run Campaign Classic on-premise: patch to 9398 today, then go and find out what else on that host answers to an unauthenticated caller. The fourth bulletin is a question of when, not whether.

Zero Hunt is a 100% on-premise appliance — no cloud callbacks, no external LLM APIs, air-gap supported. See how the platform works or get in touch.