01 · The Real Story
A marketing intern's login is the skeleton key to the server room
CVE-2026-104351 is a code-injection flaw in Adobe Campaign Classic (ACC) v7, affecting builds 7.4.4 build 9402 and earlier on both Windows and Linux. A low-privileged authenticated user — any marketer, campaign operator, or developer with valid ACC credentials — can inject and execute arbitrary code in the context of the ACC application server process. The CVSS vector's S:C (Scope Changed) flag is the critical detail: exploitation escapes the ACC application sandbox and reaches the underlying operating system, granting the attacker OS-level command execution. This is not mere application-layer misbehaviour; it is full host compromise from a marketing platform login. The fix is ACC v7 7.4.4 build 9403, released October 27, 2026 under Adobe bulletin APSB26-162.
Adobe rates this CRITICAL at 9.9, and the CVSS math is technically correct for the stated vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). However, the vendor score assumes the worst-case network position — direct attacker-to-application-server connectivity — while real ACC deployments almost universally place the application server (nlserver web) on an internal LAN segment, behind DMZ-hosted frontal/tracking servers. Adobe's own standard deployment guide prescribes exactly this topology. The PR:L prerequisite further narrows the attacker pool to credentialed users or those who have already compromised an ACC account. Combined, these factors make the vendor's 9.9 an overstatement for the median enterprise deployment, though the post-exploitation blast radius — OS-level RCE on a server holding millions of customer PII records — keeps this firmly in HIGH territory. Notably, this is the third consecutive quarterly bulletin with CVSS 9.9+ code-execution flaws in ACC (APSB26-120, APSB26-142, APSB26-162), which points to systemic code-quality issues in the ACC server-side codebase rather than one-off bugs.
"Authenticated ACC users can break out to OS-level code execution; patch within 30 days."
02 · The Attack Path
5 steps from start to impact.
STEP 01
Obtain valid ACC credentials
The attacker needs a valid low-privileged account on the target ACC instance. This could be a compromised marketer account (phishing, credential stuffing, password reuse from a prior breach) or an insider threat. ACC user directories are typically backed by LDAP/AD or internal user tables. In large enterprises, ACC operator counts range from dozens to low hundreds — a meaningful but bounded credential surface.
Conditions required:
- Valid ACC operator credentials (any privilege level)
- Network path to the ACC application server's HTTP/SOAP endpoint
Where this breaks in practice:
- ACC is not a consumer-facing service — no self-registration, no public signup
- Credential-stuffing tools rarely target ACC's SOAP-based login flow
- MFA, if configured on the ACC operator login or upstream SSO, blocks stolen passwords
Detection/coverage: Failed login attempts are logged in ACC's
logins.log; SIEM correlation on ACC auth events can flag brute-force or credential-stuffing patterns.STEP 02
Reach the ACC application server
The attacker must be able to route HTTP/SOAP traffic to the
nlserver web process, which hosts the vulnerable code-injection surface. In Adobe's recommended standard and enterprise deployments, this server sits on the internal LAN and is not directly reachable from the internet — only DMZ frontal servers face external traffic. Standalone deployments are the exception, where the app server is placed in the DMZ. Internal network access (VPN, compromised workstation, or lateral movement) is the typical prerequisite.Conditions required:
- Network connectivity to
nlserver webHTTP listener (typically port 8080 or 443 on the internal segment)
Where this breaks in practice:
- Standard/enterprise ACC topologies isolate the app server from the internet
- Firewall rules and network segmentation restrict access to internal ACC ports
- Standalone deployments are rare in enterprises managing 10k+ hosts
Detection/coverage: Network-layer monitoring (NGFW, IDS) can detect unexpected external traffic to the ACC app server port. Shodan/Censys scans show very few internet-exposed ACC instances compared to products like ColdFusion.
STEP 03
Submit malicious code-injection payload
With authenticated access to the ACC application server, the attacker crafts a request to the vulnerable endpoint — likely a SOAP API call or workflow/script execution interface that fails to sanitize server-side code generation. CWE-94 in ACC's context almost certainly involves JavaScript (ACC's server-side JS engine for workflows) or XSLT/expression-language injection. The attack complexity is Low (
AC:L), meaning no race conditions, special configurations, or timing windows are required — a single crafted request suffices.Conditions required:
- Authenticated session on the ACC app server
- Knowledge of the vulnerable endpoint or parameter (not yet public)
Where this breaks in practice:
- No public PoC or exploit code exists as of October 28, 2026
- The specific vulnerable endpoint is not disclosed in the advisory
- WAF rules inspecting SOAP payloads for code-injection patterns can block common patterns
Detection/coverage: Web application firewalls (WAFs) with SOAP/XML inspection can flag anomalous code patterns. ACC's audit log may capture the triggering API call. No Nuclei template or scanner signature exists yet.
STEP 04
Code execution escapes to OS context
The Scope Changed (
S:C) designation means the injected code breaks out of the ACC application's security boundary and executes at the OS level — running as the nlserver service account (often a dedicated service user, sometimes root/SYSTEM in poorly hardened deployments). This grants the attacker full read/write access to the ACC server's filesystem, network interfaces, and — critically — the database connection credentials stored in ACC's serverConf.xml configuration.Conditions required:
- Successful code injection from Step 3
Where this breaks in practice:
- If the
nlserverprocess runs as a low-privilege service account (Adobe's recommendation), lateral movement requires privilege escalation - AppArmor/SELinux profiles on the ACC process can constrain OS-level actions
- EDR on the ACC server should detect anomalous child-process spawning from
nlserver
Detection/coverage: EDR agents detecting unexpected process trees from
nlserver (e.g., nlserver → bash/cmd.exe). HIDS file-integrity monitoring on ACC configuration files.STEP 05
Pivot to database and lateral movement
With OS-level access, the attacker reads
serverConf.xml to extract database credentials, then directly queries the ACC database containing customer PII, campaign data, delivery logs, and email addresses — potentially millions of records. From the ACC server's network position on the internal LAN, the attacker can also pivot laterally to other internal systems. ACC servers often have broad network access for SMTP delivery, LDAP lookups, and database connectivity, making them attractive pivot points.Conditions required:
- OS-level code execution from Step 4
- Database credentials in
serverConf.xml(present by default)
Where this breaks in practice:
- Database network ACLs may restrict access to specific source IPs
- Database audit logging can detect unusual query patterns
- Network segmentation between the ACC server and other internal segments limits lateral movement
Detection/coverage: Database activity monitoring (DAM) detecting bulk data extraction. Network detection of lateral movement from the ACC server IP to unusual internal destinations.
03 · Compensating Control
1
HIGH 8.5→MEDIUM 5.5
SEVERITY REDUCEDRestrict network access to the ACC application server — Configure firewall rules to limit connectivity to
nlserver web (typically port 8080/443) to only authorized source IPs: admin workstations, the ACC client console subnet, and DMZ frontal servers. Block all other inbound traffic. This breaks Attack Path Step 2 for any attacker without internal network access. Per the noisgate mitigation SLA for HIGH, deploy within 30 days. In practice, this should be an emergency change within the first week given the trivial exploitation complexity.2
HIGH 8.5→MEDIUM 6.0
SEVERITY REDUCEDEnforce MFA on ACC operator authentication — Enable multi-factor authentication for all ACC operator logins, ideally via SSO/SAML integration with your IdP (Okta, Azure AD, Ping). This breaks Attack Path Step 1 by making stolen/phished passwords insufficient. If ACC is using internal authentication, enforce strong password policies and monitor for credential-stuffing patterns. Deploy within 30 days per the noisgate mitigation SLA.
3
HIGH 8.5→HIGH 7.5
Deploy WAF with SOAP/XML inspection on ACC endpoints — Place a web application firewall in front of the ACC application server that inspects SOAP and XML payloads for code-injection patterns (JavaScript, expression language, XSLT injection). This degrades Attack Path Step 3 by blocking common injection payloads even from authenticated sessions. Note: this is defense-in-depth, not a substitute for patching — determined attackers can craft evasion payloads. Deploy within 30 days.
4
HIGH 8.5→HIGH 7.0
Run nlserver under a dedicated low-privilege service account — Ensure the
nlserver process runs as a dedicated low-privilege OS user (not root/SYSTEM) with minimal filesystem and network permissions. Apply AppArmor or SELinux profiles to constrain process capabilities. This limits the blast radius of Attack Path Step 4 by restricting what the attacker can do after code execution. Deploy within 30 days.5
HIGH 8.5→IGNORE 0.0
SEVERITY REDUCEDApply vendor patch — ACC v7 7.4.4 build 9403 — The definitive fix. Upgrade all on-premise and hybrid ACC instances to build 9403. Adobe-hosted instances are already patched. Per the noisgate remediation SLA for HIGH, complete patching within 180 days. Given the recurring critical flaw pattern in ACC, prioritize this in your next maintenance window — ideally within 30 days.
What doesn't work
- Network-level IDS/IPS signature-based detection — No public PoC or signature exists for this specific CVE. Generic code-injection signatures won't match ACC's SOAP-based attack surface without custom rules. You're flying blind on detection until a PoC emerges.
- Disabling the ACC web interface — The
nlserver webprocess is the core of ACC's functionality (console connectivity, SOAP APIs, workflow engine). Disabling it effectively takes ACC offline, which is a business continuity impact, not a compensating control. - Patching only the DMZ frontal servers — The vulnerability is in the application server (
nlserver web), not the frontal/redirection servers. Patching only internet-facing components does not address this flaw.
04 · Intelligence Metadata
The supporting signals.
| In-the-Wild Exploitation | None confirmed. Adobe states it is "not aware of any exploits in the wild" for any issue in APSB26-162. Not listed in CISA KEV. |
|---|---|
| Proof-of-Concept | No public PoC found. Checked pocindex.io, GitHub, and ExploitDB — no repositories or exploit code for CVE-2026-104351 as of October 28, 2026. The specific vulnerable endpoint is not disclosed. |
| EPSS Score | Not yet scored. CVE was published October 27, 2026 — FIRST's EPSS model has not yet ingested it. Expect initial scoring within 1-3 days. Given the PR:L requirement and no PoC, initial EPSS is likely <0.05 (below 90th percentile). |
| CISA KEV Status | Not listed. No known exploitation in the wild. Adobe assigns Priority 2 (not Priority 1, which indicates active targeting). |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — Network-reachable, low complexity, low privileges required, no user interaction, scope changed. The S:C and triple-H impact drives the 9.9. The only thing keeping it from 10.0 is the PR:L (some authentication needed). |
| Affected Versions | Adobe Campaign Classic v7: 7.4.4 build 9402 and all earlier builds, on Windows and Linux. Both on-premise and on-premise components of hybrid deployments are affected. Adobe-hosted (fully managed) instances were remediated server-side. |
| Fixed Version | ACC v7 7.4.4 build 9403 (released October 27, 2026). No distro-level backports — ACC is distributed directly by Adobe. |
| Internet Exposure | Very low. ACC application servers are architecturally internal in standard/enterprise deployments. No significant Shodan/Censys/GreyNoise fingerprinting data exists for ACC's nlserver web listener, unlike widely-scanned products like ColdFusion or Exchange. |
| Disclosure Date | October 27, 2026 — coordinated disclosure via Adobe bulletin APSB26-162. No prior public disclosure or researcher blog post identified. |
| Reporting Researcher | Not attributed. Adobe's bulletin and secondary sources do not credit a specific researcher for CVE-2026-104351. The companion Connect flaw (CVE-2026-48360) was credited to "al." |
Sources.
05 · The Call
Final Verdict
↓ DOWNGRADED to HIGH (8.5/10)
Why this verdict
- PR:L narrows the attacker pool significantly. The attacker must possess valid ACC operator credentials. ACC is not a consumer app with self-registration — accounts are provisioned by admins. This eliminates opportunistic unauthenticated scanning and mass exploitation. Credential compromise is a real but bounded threat, and MFA/SSO integration further reduces it.
- Network position is almost always internal. Adobe's own standard and enterprise deployment guides place the
nlserver webapplication server on the internal LAN, with only tracking/redirection servers in the DMZ. Standalone (DMZ-exposed) deployments are the exception, not the rule. An attacker typically needs internal network access first — meaning they're already post-initial-access — which compounds downward pressure on the severity. - No PoC, no exploitation, no KEV listing. As of one day post-disclosure, there is zero public weaponization. The vulnerable endpoint is undisclosed. While CWE-94 code injection is a well-understood flaw class and reverse engineering the patch delta is feasible for skilled researchers, the current threat level is theoretical, not imminent.
- Role multiplier: ACC is a line-of-business marketing automation platform, not a canonical high-value infrastructure component (not an IdP, DC, hypervisor, PAM, backup system, or network edge appliance). In the typical deployment role, ACC hosts customer PII databases (often millions of records) used for email campaigns — this gives it significant data-tier value, but the blast radius is host + database rather than domain/fleet/supply-chain. In a worst-case scenario, an attacker achieves full OS access on the ACC server and exfiltrates the customer database — a serious data breach but not a fleet-wide compromise. ACC servers do sit on internal networks with broad SMTP and LDAP connectivity, creating lateral movement opportunity, but this is an indirect risk dependent on further exploitation. The installed base of ACC is relatively small (~low thousands of enterprise deployments globally) and does not occupy a high-value infrastructure role by definition. Verdict floor: HIGH based on the data-breach potential and OS-level RCE, but not CRITICAL because the component is not canonically fleet/identity/supply-chain critical.
- Systemic ACC code quality concern amplifies urgency. This is the third quarterly bulletin in 2026 with CVSS 9.9+ RCE flaws in ACC (APSB26-120, APSB26-142, APSB26-162). The pattern suggests ongoing exploitable surface area and increases the probability that researchers or threat actors will invest in ACC-specific tooling.
Why not higher?
CRITICAL would require either active exploitation, a public PoC making mass exploitation imminent, or the affected component being a canonical high-value infrastructure target (IdP, DC, hypervisor, network edge). CVE-2026-104351 has none of these. The PR:L requirement and typical internal-only network position mean the population reachable for opportunistic exploitation is very small. ACC is a marketing platform, not identity or infrastructure plumbing — its compromise does not cascade to domain takeover or fleet-wide impact without additional exploitation steps.
Why not lower?
MEDIUM would undercount the blast radius. Once the two prerequisites are met (credentials + network access), exploitation is trivially low-complexity with no user interaction, and the outcome is OS-level code execution with Scope Changed — full host compromise plus direct access to a database containing potentially millions of customer PII records. The data-breach potential alone keeps this above MEDIUM. Additionally, the recurring pattern of critical ACC flaws in 2026 suggests that PoC development is only a matter of time, which would shift the threat from theoretical to practical.
06 · Verification
Crowdsourced verification payload.
Run this script on each ACC server host (Linux) as any user with read access to the ACC installation directory. It checks the build number from ACC's configuration. Example: bash check_cve_2026_104351.sh /usr/local/neolane (pass the ACC installation root as the first argument). No elevated privileges required.
#!/usr/bin/env bash
# check_cve_2026_104351.sh — Detect CVE-2026-104351 (ACC Code Injection)
# Usage: bash check_cve_2026_104351.sh /path/to/neolane
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -euo pipefail
ACC_HOME="${1:-/usr/local/neolane}"
VULN_BUILD=9402
FIXED_BUILD=9403
# Try to get build number from nlserver
if command -v "${ACC_HOME}/nl/bin/nlserver" &>/dev/null; then
VERSION_OUTPUT=$("${ACC_HOME}/nl/bin/nlserver" -version 2>&1 || true)
BUILD=$(echo "$VERSION_OUTPUT" | grep -oP 'build\s+\K[0-9]+' | head -1)
elif [[ -f "${ACC_HOME}/nl/buildNumber.txt" ]]; then
BUILD=$(cat "${ACC_HOME}/nl/buildNumber.txt" | grep -oP '[0-9]+' | head -1)
elif [[ -f "${ACC_HOME}/conf/serverConf.xml" ]]; then
BUILD=$(grep -oP 'buildNumber="\K[0-9]+' "${ACC_HOME}/conf/serverConf.xml" | head -1)
else
echo "UNKNOWN — Could not locate ACC installation at ${ACC_HOME}"
echo "Provide the ACC install root as the first argument."
exit 2
fi
if [[ -z "$BUILD" ]]; then
echo "UNKNOWN — Found ACC installation but could not extract build number."
exit 2
fi
echo "Detected ACC build: ${BUILD}"
echo "Vulnerable: <= ${VULN_BUILD} | Fixed: >= ${FIXED_BUILD}"
if (( BUILD >= FIXED_BUILD )); then
echo "PATCHED — Build ${BUILD} is >= ${FIXED_BUILD}. CVE-2026-104351 is remediated."
exit 0
else
echo "VULNERABLE — Build ${BUILD} is <= ${VULN_BUILD}. CVE-2026-104351 applies."
echo "Action: Upgrade to ACC v7 7.4.4 build ${FIXED_BUILD} or later."
exit 1
fi