CVE-2026-76197 is an OS command injection flaw (CWE-78) in Adobe Campaign Classic, the on-premise enterprise marketing automation platform. An unauthenticated remote attacker can cause the server to pass attacker-controlled content into an operating system command, yielding arbitrary code execution in the context of the account running the service. Adobe PSIRT, acting as CNA, scores it 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) and shipped the fix on August 25, 2026 in bulletin APSB26-134 at Priority 1, Adobe's highest rating. NVD's record is still in Received status, so the score, the CWE, and the version data are Adobe's own values rather than NVD-analyzed ones.
Two facts govern how this should be handled, and neither is in the severity score.
The first is scope. APSB26-134 states that it "applies only to fully on-premise deployments of Adobe Campaign Classic and to the on-premise components of hybrid deployments," and that Adobe-hosted instances are already remediated with no customer action required. Hybrid customers are the group most likely to conclude wrongly that they are covered: the Adobe-managed side is done, but any mid-sourcing, execution, or tracking component running on your own infrastructure still needs the new build.
The second is cadence. APSB26-134 is the sixth Priority 1 Campaign Classic bulletin since June 9, 2026, and CVE-2026-76197 ships alongside two more CVSS 10.0 siblings in the same bulletin: CVE-2026-76195, a second CWE-78 command injection with an identical vector, and CVE-2026-76193, a server-side request forgery also rated for code execution. Across that eleven-week run the supported build moved from 9394 to 9401, and builds 9397, 9398, 9399 and 9400 were each superseded by a new critical bulletin within 6 to 22 days. For an on-premise ACC estate, a patch level set last month is not current.
Am I vulnerable?
Affected versions
| Product |
Vulnerable range |
Fixed in |
| Adobe Campaign Classic v7 (Windows, Linux) |
7.4.4 build 9400 and earlier |
7.4.4 build 9401 (GA August 25, 2026) |
| Adobe-hosted Campaign Classic instances |
Not in scope |
Already remediated by Adobe, no customer action |
| Hybrid deployments |
On-premise components only |
Patch the components you operate |
Adobe's affected range is expressed as "0 through ACC v7: 7.4.4 build 9400," so the build number, not the marketing version, is the field that decides this. Everything below turns on reading it correctly.
Diagnostic commands
All read-only.
Fastest remote triage, no credentials: Adobe documents /r/test on the redirection and tracking server as an anonymous health endpoint that returns the running build.
curl -4 -sS "https://<acc-tracking-or-app-host>/r/test"
The documented responses take an XML shape (<redir status='OK' date='...' build='9400' host='...'/>) or a JSON shape carrying the same build field. A build of 9400 or lower is affected. Use this to inventory your own estate quickly, and note the second finding: if this endpoint answers from the internet, anyone can read your patch level without authenticating, so it belongs behind an ACL.
Application server build string:
su - neolane
nlserver pdump
Adobe's documented output line reads Application server for Adobe Campaign Classic (7.X YY.R build XXX@SHA1) of DD/MM/YYYY. Read the build field. This reports what is actually loaded in memory, which matters because a host whose package was upgraded but whose nlserver was never restarted will still be running the old build.
Installed package, works with the service stopped:
rpm -qa | grep -i nlserver6 # RHEL / CentOS
dpkg -l | grep -i nlserver6 # Debian / Ubuntu
Campaign Classic ships on Linux as the nlserver6 package with the build embedded in the version string (nlserver6-v7-<BUILD>-...). The default install root is /usr/local/neolane.
Windows and console: open the client console and use Help > About. Adobe's build-upgrade FAQ notes the About box reports the version and build for both the console and the server. There is no vendor-documented registry key for this check, so use the About box or /r/test rather than guessing at an install path.
Finally, sweep for forgotten copies. Test, staging, and demo instances of Campaign Classic run the same code, are patched less often, and frequently sit on the same network as the production database.
Vulnerability
The bug class is CWE-78, improper neutralization of special elements used in an OS command. NVD's description states the flaw "could result in arbitrary code execution in the context of the current user," that "exploitation of this issue does not require user interaction," and that "scope is changed."
That scope-changed flag is the part worth reading twice. In CVSS v3.1 terms it means the impact crosses out of the vulnerable component's own security authority. The application does not merely lose its own integrity; execution reaches the host underneath it, running as the service account. Combined with AV:N, AC:L, PR:N and UI:N, every metric in the vector is at its worst value, which is what produces a 10.0 rather than a 9.8.
Adobe has not disclosed the vulnerable component, the endpoint, or the parameter, and neither has NVD. No security firm has published a technical teardown, which is unsurprising for a CVE one day old. Any claim about which specific request reaches the injection point would be invention, so this write-up does not make one. What can be said from the vector and the CWE is the shape: content arriving over the network, without credentials, reaches a command interpreter on the host.
One structural detail affects how you read the CVE count. Adobe's CNA note in this bulletin states that "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." Under that policy a single ID can cover more than one distinct injection point, so the number of CVEs in APSB26-134 is a floor on the number of code paths fixed, not a count of them.
Threat model
Who would exploit this: Initial-access brokers and data-extortion crews scan for internet-facing enterprise applications offering unauthenticated pre-auth code execution, and Campaign Classic fits that profile: tracking and delivery servers sit on the public internet, the flaw needs no credentials and no user interaction, and the host sits next to customer databases worth extorting or reselling. Mass-scanning affiliates typically join once a working exploit circulates. State-aligned actors are a plausible but lower-frequency consumer, interested less in the platform than in the recipient data it holds and the ability to send mail that recipients trust.
What they are after, roughly in order of likelihood:
- A foothold on an internet-facing host, retained or resold as initial access
- Stored credentials from server configuration and external account definitions, then a pivot to the database, CRM, and file transfer systems they reach
- Recipient and marketing databases (customer PII, email addresses, consent records, segmentation attributes) for extortion or resale
- Persistence on a delivery or tracking tier that is rarely rebuilt and often excluded from endpoint monitoring
- Trusted-sender phishing from the victim's own domain, IP reputation, and signing keys
- Ransomware or destructive action against the campaign database and its backups, usually late-stage
Attack chain: Attackers enumerate internet-exposed tracking and delivery endpoints, identifiable from banner and path characteristics without authentication. A crafted unauthenticated request causes the server to pass attacker-controlled content into an operating system command, yielding execution as the Campaign service account. A typical campaign then reads configuration and external account definitions for stored credentials, enumerates reachable database and file transfer endpoints, plants persistence, and only then chooses between quiet data staging, access resale, or extortion.
Blast radius: A compromised instance exposes the marketing database it exists to serve, frequently covering an entire customer base rather than one business unit, along with the credential material the platform needs to function: database connection strings, SMTP relay credentials, SFTP and object storage keys for data feeds, and CRM or data warehouse API tokens. On Windows the service account is often domain-joined, adding an Active Directory path. Control of the delivery tier also hands over the sending domain, IP reputation, and DKIM signing material, so fraudulent mail leaves with the victim's own authentication intact.
Exploitation status as of August 26, 2026: no public exploit, PoC, or exploit-framework module exists, and Adobe states it is "not aware of any exploits in the wild for any of the issues addressed in this update." This CVE is not in the CISA KEV catalog, and no Adobe Campaign CVE has ever been listed there. For calibration on pace rather than on Campaign history: in Adobe's June 30 batch, the ColdFusion flaw CVE-2026-48282 went from disclosure to confirmed in-the-wild exploitation within days and reached KEV on July 7, 2026, while the Campaign Classic CVE released the same day drew no reported exploitation.
Mitigation
Patch
Update to ACC v7 7.4.4 build 9401. Adobe published no workaround and no configuration mitigation for this bulletin, so the build is the fix.
The release notes add a step that is easy to miss: "a restart of the Adobe Campaign server (nlserver) is required to load the build and complete deployment." An upgraded package on a host that was never restarted is still serving the vulnerable build, which is exactly what nlserver pdump will tell you. Plan for the console upgrade too, since Adobe requires the client console to match the server build, so operators will be prompted after you patch.
Compensating controls
These reduce exposure and impact. None of them is a substitute for build 9401.
- Restrict reachability. Confirm which ACC tiers genuinely need to be internet-facing. The tracking and redirection servers usually do; the application server and its console interfaces usually do not. Put
/r/test behind an ACL so your patch level is not readable by anyone who asks.
- Constrain what the service can execute. Adobe supports restricting external command execution through the
exec node in serverConf.xml, using a blacklistFile allowlist and a dedicated lower-privilege user, available from build 8780 onward. An exec node with neither attribute set means the server can run any command as the service account, which raises the ceiling on any command injection. Review the current setting against Adobe's server configuration documentation before changing it.
- Reduce the service account's reach. Avoid domain-joined or otherwise over-privileged accounts for
nlserver. Scope database credentials in external account definitions to the minimum rights the workflows need.
- Baseline and allowlist egress. ACC servers talk to a predictable set of SMTP, database, and vendor destinations, which makes outbound allowlisting practical here and turns any attacker callback into a visible event.
- Take a file inventory hash baseline now, before you patch, across the ACC web-served directories listed in the detection section. It is the cheapest way to make a later compromise assessment answerable.
- Treat credential rotation as part of incident response, not part of patching. If you conclude an instance was exposed and reachable during the vulnerable window, the credentials stored in its configuration should be considered in scope.
Detection (starter rules, validate before deploying)
These rules are AI-generated starter content. Test against your own telemetry and tune falsepositives before deploying to production. No public exploit or vendor detection guidance existed for this CVE as of August 26, 2026, so neither rule below has been validated against real exploitation. Both are behavioural.
Network and log signals
- Web-tier access logs on the internet-facing vhost: unauthenticated requests to the
/nl/jsp/ and /nms/jsp/ endpoint families from source IPs outside your admin ranges, especially POSTs with unusually large bodies, non-browser User-Agent strings, or a single source cycling through many JSP endpoints in seconds.
- A burst of HTTP 500 responses in the web module log followed by a 200 from the same source and endpoint. Injection probing usually produces errors before it produces working execution.
- ACC module logs directly:
<install>/var/<instance>/log/web.log, tracking.log, and wfserver.log (Linux default /usr/local/neolane/nl6/var/<instance>/log/). Look for external command executions with no corresponding scheduled workflow run.
- New or modified files under web-served and writable directories:
<install>/datakit/nl/eng/jsp, <install>/datakit/nms/eng/jsp, <install>/tomcat-*/webapps, and <install>/var/<instance>/. Any .jsp, .war, .sh, .bat, .exe or .py appearing there outside a documented upgrade window is high signal.
- Writes to the
conf directory: changes to serverConf.xml or config-<instance>.xml, particularly removal or weakening of the exec node allowlist, a changed exec user, or newly permissive urlPermission entries.
- Unexpected outbound connections from the
nlserver host, especially to raw IP literals, non-standard high ports, or paste and tunneling services, and DNS lookups originating from the service account.
- Unexplained
nlserver restarts or module crash-and-restart loops (nlserver6 service stop/start on Windows, systemd or init restarts on Linux). Injection attempts frequently destabilise the web module.
- New
xtk:operator records or privilege grants, and unfamiliar entries in <install>/var/<instance>/logins.log, cross-checked against your change record.
- New or edited workflows containing JavaScript or External command activities, particularly outside business hours or authored by an operator who does not normally write workflows.
execCommand() is the legitimate path to shell execution in ACC and therefore an attractive persistence mechanism.
- Host persistence after the fact: new cron entries or systemd units owned by the
neolane user, new keys in /usr/local/neolane/.ssh/authorized_keys, new scheduled tasks or services on Windows hosts.
- Tracking vhost noise: requests to
/r/ that do not match the normal redirect shape, or a spike in /r/test probes from external sources, which often indicates fingerprinting ahead of targeting.
YARA
rule ACC_Webshell_Or_Dropper_In_Campaign_Web_Root
{
meta:
description = "Starter rule: JSP web shell or command-execution dropper written into an Adobe Campaign Classic web-accessible directory. Behavioural only, no CVE-specific hashes."
author = "CVE Brief (AI-generated starter rule, validate before deploying)"
date = "2026-08-26"
cve = "CVE-2026-76197"
reference = "https://helpx.adobe.com/security/products/campaign/apsb26-134.html"
confidence = "medium"
scan_scope = "Scope to ACC web-served and writable paths only. Linux: /usr/local/neolane/nl6/datakit/nl/eng/jsp, /usr/local/neolane/nl6/datakit/nms/eng/jsp, /usr/local/neolane/nl6/tomcat-*/webapps, /usr/local/neolane/nl6/var/<instance>/. Windows: <install>\\datakit, <install>\\tomcat-*\\webapps, <install>\\var\\<instance>. Not intended for whole-disk scanning."
strings:
$jsp = "<%" ascii
$exec1 = "Runtime.getRuntime" ascii
$exec2 = "ProcessBuilder" ascii
$exec3 = "javax.script.ScriptEngineManager" ascii
$in1 = "request.getParameter" ascii
$in2 = "request.getHeader" ascii
$in3 = "request.getInputStream" ascii
$in4 = "getReader()" ascii
$out1 = "/bin/sh" ascii
$out2 = "/bin/bash" ascii
$out3 = "cmd.exe" ascii
$out4 = "powershell" ascii nocase
$out5 = "getInputStream()" ascii
$obf1 = "Base64.getDecoder" ascii
$obf2 = "sun.misc.BASE64Decoder" ascii
$obf3 = "javax.crypto.spec.SecretKeySpec" ascii
$obf4 = "defineClass" ascii
condition:
filesize < 300KB
and $jsp
and any of ($exec*)
and any of ($in*)
and ( any of ($out*) or 2 of ($obf*) )
}
Sigma
title: Adobe Campaign Classic nlserver Spawning Shell or Download Utility
id: 6b1f2a94-3c7d-4e58-9a02-b7d4c1f8e530
status: experimental
description: |
Detects the Adobe Campaign Classic application server process (nlserver, which hosts
the web, tracking, wfserver and mta modules) spawning a command interpreter, a
download utility or a scripting runtime. OS command injection in the ACC web tier
(CVE-2026-76197, CVSS 10.0, fixed in ACC v7.4.4 build 9401) results in commands being
executed as a child of the nlserver process, so anomalous child processes are the
most reliable host-side signal. Covers Windows (nlserver.exe) and Linux
(/usr/local/neolane/nl6/bin/nlserver) deployments.
author: CVE Brief (AI-generated starter rule, validate before deploying)
date: 2026-08-26
references:
- https://helpx.adobe.com/security/products/campaign/apsb26-134.html
- https://nvd.nist.gov/vuln/detail/CVE-2026-76197
- https://experienceleague.adobe.com/en/docs/campaign-classic/using/installing-campaign-classic/appendices/the-server-configuration-file
tags:
- attack.initial-access
- attack.t1190
- attack.execution
- attack.t1059
- attack.t1059.003
- attack.t1059.004
logsource:
category: process_creation
detection:
selection_parent:
ParentImage|endswith:
- '\nlserver.exe'
- '/nlserver'
- '/nlserver6'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
- '\curl.exe'
- '\net.exe'
- '\whoami.exe'
- '/sh'
- '/bash'
- '/dash'
- '/zsh'
- '/ksh'
- '/nc'
- '/ncat'
- '/netcat'
- '/curl'
- '/wget'
- '/python'
- '/python3'
- '/perl'
- '/ruby'
- '/php'
- '/base64'
- '/whoami'
- '/id'
filter_optional_document_conversion:
Image|endswith:
- '/soffice'
- '/soffice.bin'
- '\soffice.exe'
- '\soffice.bin'
- '/wkhtmltopdf'
- '\wkhtmltopdf.exe'
filter_optional_known_workflow_scripts:
CommandLine|contains:
- 'REPLACE_WITH_YOUR_APPROVED_SCRIPT_PATHS'
condition: selection_parent and selection_child and not 1 of filter_optional_*
fields:
- Image
- CommandLine
- ParentImage
- ParentCommandLine
- User
falsepositives:
- Legitimate ACC workflow activity. JavaScript activities call execCommand() and legacy External command or shell script activities intentionally shell out from nlserver, so scheduled marketing workflows will generate matches. Baseline per instance and allowlist approved script paths in filter_optional_known_workflow_scripts.
- Built-in ACC helper services that invoke external binaries, notably the htmlToPdf and ooconv (OpenOffice or LibreOffice) conversion nodes configured in serverConf.xml.
- Import and export jobs and data-exchange workflows that call gzip, openssl, sftp or customer-supplied ETL scripts as part of file transfer.
- Administrator maintenance, backup, log rotation and package upgrade activity run under the neolane service account.
level: high
Rule notes
Both rules are behavioural rather than payload-specific. The Sigma rule keys on the ACC server process becoming the parent of a shell, scripting runtime, or download utility, which is the common end state of any OS command injection in the ACC web tier. The YARA rule looks for JSP web shell structure (a scriptlet, a Java exec primitive, and attacker-controlled request input) inside ACC web-served directories only.
Known limitations. The Sigma rule will fire on legitimate execCommand() workflow activity and on the htmlToPdf and ooconv converters, so run it as a hunt and baseline per instance before promoting it to an alert. The YARA rule cannot see in-memory or fileless payloads, or a dropped binary carrying no JSP markers, and it should be scoped to the paths in its scan_scope meta rather than run across a whole disk. Every path, process name, and endpoint used in both rules is drawn from Adobe's own documentation, not from observed exploitation. The YARA rule was reviewed by hand for syntax; the Sigma YAML was schema-checked.
References