Disclosure: this page contains affiliate links. East Bay Cyber may earn a commission if you buy through them, at no extra cost to you. That never changes how we rank products. Editorial policy.
CVE-2026-102489: Zammad Session Fixation RCE
Active exploitation confirmed in the wild. CISA added this to the KEV catalog on 2026-10-02. Federal agencies must patch by 2026-10-05.
TL;DR
- CVE-2026-102489 is a CVSS 9.8 Zammad session-fixation vulnerability that can lead to remote code execution as the
zammaduser.- Zammad 6.3.0 through 6.5.4 are exploitable. Move to a supported release and restrict internet exposure immediately.
- CISA lists the vulnerability in its Known Exploited Vulnerabilities catalog, confirming exploitation in the wild.
Analyst’s Take: Treat an internet-facing Zammad instance in the affected range as both vulnerable and potentially compromised. CISA KEV confirms exploitation, while available research does not provide a complete public exploit procedure or a reliable CVE-specific network signature. Upgrade or remove the instance from public exposure first, then preserve evidence and investigate.
Are You Affected by CVE-2026-102489?
CVE-2026-102489 affects Zammad installations in the 6.3.x through 6.5.4 release range. The issue is classified as CWE-384, Session Fixation. According to the available NVD description, successful exploitation can result in remote code execution under the privileges of the zammad operating-system account.
| Field | Details |
|---|---|
| CVE ID | CVE-2026-102489 |
| Product | Zammad |
| Affected versions | 6.3.0 through 6.5.4 |
| CVSS | 9.8 / 10.0, Critical |
| CVSS vector | Not included in the supplied NVD record |
| Attack vector | Remote application attack path; exact CVSS vector is not published in the supplied record |
| Authentication required | Exact CVSS authentication component is unknown from the supplied record; do not assume authentication makes an exposed instance safe |
| Privileges required | Exact CVSS value is unknown; impact includes code execution as the zammad user |
| Patch available | Yes, through migration to a supported Zammad release; exact fixed version was not supplied |
| CISA KEV status | Yes, added October 2, 2026 |
| Exploitation | Confirmed in the wild through CISA KEV listing |
Zammad 7.0.0 through 7.1.2 reportedly contain the underlying bug but are not exploitable through the described attack chain because of changes in the underlying framework. That distinction does not replace vendor-supported maintenance. Zammad 6.5 and earlier are out of support, so administrators should follow current Zammad release guidance when selecting a target version.
Confirm the Installed Zammad Version
Identify every installation, including package-based deployments, containers, and instances behind a reverse proxy. On Debian- or Ubuntu-based package installations, this command can help identify the installed package version:
dpkg-query -W -f='${Package}\t${Version}\n' zammad 2>/dev/null
For RPM-based systems, use:
rpm -q --queryformat '%{NAME}\t%{VERSION}-%{RELEASE}\n' zammad 2>/dev/null
If the result is between 6.3.0 and 6.5.4, treat the host as vulnerable and potentially compromised. Do not rely only on the web interface version. A reverse proxy, container image, or package repository may not reflect the runtime instance you are investigating.
The Fix, If You’re in a Hurry
Move Zammad 6.3.0 through 6.5.4 to a currently supported Zammad release. The supplied advisory material does not identify a single explicit fixed version for this CVE, so publishing an invented minimum version would be unsafe. Confirm the supported target release in Zammad’s current security and upgrade documentation before deploying it to production.
For a package-managed installation, use the following commands after verifying that the configured repository provides a supported release:
sudo apt-get update
apt-cache policy zammad
sudo apt-get install --only-upgrade zammad
These commands do not guarantee that the resulting version is safe unless the repository metadata has been checked. Confirm the installed version after upgrading and ensure it is no longer within the affected 6.3.0–6.5.4 range.
Container operators should update the image tag to a currently supported Zammad release, recreate the container, and verify the running image rather than only changing a deployment file.
If immediate upgrading is impossible:
- Remove the instance from the public internet.
- Restrict access to trusted administrator networks through firewall rules, VPN access, or an allowlisted reverse proxy.
- Invalidate active sessions after preserving relevant evidence.
- Review authentication activity and application logs.
- Begin forensic triage if compromise is suspected.
Restricting exposure is a temporary risk-reduction measure, not a patch.
# Example temporary host-level restriction; adapt to your approved network
sudo ufw deny 80/tcp
sudo ufw deny 443/tcp
sudo ufw allow from 192.0.2.0/24 to any port 443 proto tcp
Do not apply this example unchanged to a production environment without confirming the management network and firewall policy. Also assess the related CVE-2026-102490, which may allow escalation from zammad to root after exploitation of this issue.
For broader guidance on remote code execution terminology and impact, see our remote code execution (RCE) glossary.
How the Zammad Session-Fixation Vulnerability Works
CVE-2026-102489 is a session-fixation vulnerability. In a session-fixation scenario, an attacker can influence, obtain, or reuse a session identifier or session state in a way that causes a victim’s authenticated activity to become associated with attacker-controlled session material. Once a valid session is available, the attacker may be able to perform actions with the victim’s application context.
For Zammad, the documented impact is more serious than ordinary account takeover. The vulnerability can enable session hijacking followed by remote code execution as the zammad user. That account is typically the application runtime identity, so compromise may expose tickets, credentials stored in application configuration, integration data, and other host-level information available to the process.
Available research does not provide a complete public exploit procedure or establish the precise request sequence. It also does not provide enough information to state the exact authentication preconditions with certainty. Defenders should avoid relying on assumptions about whether an attacker needs a preexisting account, a targeted victim, or a particular deployment configuration. Internet-exposed vulnerable instances should be treated as at risk.
The attack can be more damaging when chained with CVE-2026-102490. That related local privilege-escalation vulnerability may allow the zammad user to obtain root privileges. Investigate both issues together, especially on systems where unexpected root-owned files, services, scheduled tasks, or processes appear after suspicious Zammad activity.
Severity Explained
The vulnerability has a CVSS base score of 9.8 out of 10.0 and is rated Critical. That score indicates a high-impact vulnerability with a potentially broad remote attack path and severe consequences for confidentiality, integrity, and availability.
The exact CVSS vector was not included in the supplied NVD record. Therefore, the precise values for attack vector, attack complexity, privileges required, user interaction, scope, and the confidentiality, integrity, and availability impact components should be retrieved from the current NVD or CVE record before being used in compliance reports or automated risk calculations.
Operationally, the high score is supported by the stated outcome: remote code execution as the application user. Internet exposure increases urgency, but lack of direct internet exposure does not eliminate risk. Internal attackers, compromised administrator workstations, and other systems with network access may still be relevant attack paths.
Is CVE-2026-102489 Being Exploited?
Yes. CISA lists CVE-2026-102489 in its Known Exploited Vulnerabilities catalog. The entry was added on October 2, 2026, with a federal remediation due date of October 5, 2026. This confirms exploitation in real-world attacks rather than merely theoretical exploitability.
CISA marks known ransomware campaign use as unknown. That field does not show that ransomware operators are not using the vulnerability; it means the catalog entry does not confirm such use. CISA also calls for forensic triage, making investigation appropriate even where administrators have not observed obvious compromise.
No verified public proof-of-concept repository was identified in the supplied research. The Zammad community reference concerns active exploitation reporting for the related CVE-2026-102490 and should not be represented as a standalone public exploit for CVE-2026-102489.
The absence of a public proof of concept is not a reason to delay remediation because exploitation is already confirmed through CISA KEV.
Detecting CVE-2026-102489 in Your Environment
Start with asset discovery and version inventory. Search package-management data, container manifests, infrastructure-as-code repositories, backup inventories, and reverse-proxy configurations for Zammad deployments. Prioritize systems with public DNS records, inbound NAT, or internet-facing load balancers.
Review Zammad, reverse-proxy, authentication, and operating-system logs for unusual session activity followed by administrative actions or process execution. The supplied research does not define a reliable CVE-specific network signature, so detection should focus on correlated behavior rather than a single request pattern.
Log and Endpoint Hunting
Search common web and proxy logs for session-related requests and unusual administrative activity. The exact URI and field names vary by Zammad version and deployment, so use this as a triage pattern rather than a definitive signature:
zgrep -hEi \\
'session|login|logout|admin|ticket|websocket' \\
/var/log/nginx/access.log* \\
/var/log/apache2/access.log* 2>/dev/null
Look for:
- Bursts of session creation or reuse from unexpected source addresses.
- Successful authentication followed by rapid administrative changes.
- Requests that precede new processes owned by
zammad. - Unexpected changes to tickets, users, integrations, or configuration.
- New files or processes appearing shortly after suspicious web activity.
- Unexpected root activity near the time of suspicious
zammadprocesses.
On the host, review recent processes and files:
ps -eo user,pid,ppid,lstart,cmd --sort=lstart | grep -E '(^zammad| zammad )'
sudo find /tmp /var/tmp /opt -xdev -type f -user zammad \\
-mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %u %p\\n' 2>/dev/null
These commands do not prove exploitation. They help identify evidence that should be correlated with access logs, shell history, audit records, EDR telemetry, and system timelines.
Preserve logs and, where possible, a disk or virtual-machine snapshot before deleting suspicious files or rebuilding the host. Rotate application credentials, integration secrets, and administrator credentials if unauthorized access is suspected. Organizations that need a password-management platform for rotating and managing credentials can evaluate Try 1Password →, but product selection should follow the organization’s security and compliance requirements.
Invalidate active sessions after evidence collection and coordinate the response with the team responsible for the Zammad database and mail integrations. Endpoint protection or malware analysis tools such as Get Bitdefender → may also support broader host triage, but they should supplement—not replace—preservation of forensic evidence and specialist investigation.
Recommended Response Checklist
Use this sequence when responding to a potentially affected Zammad instance:
- Identify affected assets. Inventory package installations, containers, staging environments, backups, and public-facing instances.
- Confirm versions. Treat Zammad 6.3.0 through 6.5.4 as vulnerable.
- Contain exposure. Remove vulnerable instances from the public internet or restrict them to trusted management networks.
- Preserve evidence. Capture relevant logs, snapshots, process data, and system timelines before rebuilding.
- Upgrade. Migrate to a currently supported Zammad release after validating the target version.
- Invalidate sessions. Revoke active sessions after collecting the evidence needed for investigation.
- Rotate secrets. Reset administrator credentials, integration credentials, API keys, mail credentials, and other secrets accessible to the application.
- Check for privilege escalation. Investigate possible CVE-2026-102490 activity and unexpected root-level changes.
- Monitor after remediation. Watch authentication, administrative, process, and network activity for recurring indicators.
- Document the response. Record affected versions, exposure windows, containment actions, upgrade timing, and investigation results.
References and Further Reading
The NVD record provides the published severity information and affected-version description:
The vendor advisory should be the primary source for supported upgrade guidance and deployment-specific remediation:
Independent coordination and incident context are available from DIVD CSIRT:
CISA’s Known Exploited Vulnerabilities catalog confirms active exploitation and provides remediation expectations:
For the potential privilege-escalation chain, review the related community discussion while keeping its scope separate from the session-fixation vulnerability:
Organizations running Zammad 6.3.0 through 6.5.4 should begin with containment and version confirmation. Remove exposed vulnerable systems from the public internet if they cannot be upgraded immediately, then migrate to a supported release, invalidate potentially compromised sessions, and preserve evidence for forensic triage. The CISA KEV listing means remediation should proceed even without a public proof of concept or a complete exploit procedure.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.