EUVD-2026-87222Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege user
-
DeliveryOpen websocket/long-polling connection
-
ExploitSend crafted client_id with ../ sequences
-
ExecutionFile store resolves path outside session dir
-
ImpactArbitrary file/directory deletion on server
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V5 - File Handling Path canonicalization, traversal prevention
MITRE ATT&CK
2 techniques across 2 tactics: Discovery, Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires (1) the file-based session store, which is Zammad's DEFAULT configuration - instances using the Redis-based session store are NOT affected; and (2) a valid low-privilege authenticated session. Given those, exploitation is a single crafted websocket or long-polling request whose client/session identifier embeds path-traversal sequences; no user interaction and no elevated privileges are needed. Limiting factors: authentication is mandatory (contradicting the input's PR:N), and Redis-backed deployments are immune. |
| Impact | This is a genuine, actionable priority for Zammad operators running the default file-based session store, but the raw 8.8 headline overstates ease of access. The CVSS 4.0 vector claims PR:N (unauthenticated), yet the description explicitly states exploitation 'requires only a low-privilege authenticated session' - a direct contradiction that should be resolved in the vendor's favor: this is authenticated (PR:L), not open to anonymous attackers. Impact is real and severe: the fix and description confirm arbitrary file/directory deletion, so this is an integrity/availability flaw (VI:H/VA:H) with no confidentiality exposure (VC:N) - a full-system-destruction primitive against the Zammad host filesystem, consistent with SSVC Technical Impact 'total'. SSVC also rates it Automatable:yes (a single crafted request, no user interaction), but Exploitation is 'none' - no active exploitation observed. There is no EPSS score, no CISA KEV listing, and no public exploit code referenced (only the advisory and two fix commits), so this is not confirmed exploited in the wild. Net: real, easily-triggered post-authentication destructive bug that patch-management should treat as high priority for exposed Zammad instances, tempered by the authentication requirement, the default-config gating, and Zammad's modest deployment footprint. |
| Exploit ScenarioDerived | An attacker with any low-privilege Zammad account (e.g., a self-registered agent or customer) opens a websocket or long-polling connection and submits a session/client identifier containing path-traversal sequences (e.g., ../../). Because the client-supplied identifier is used to build a file path in the default file-based session store without validation, the crafted single request causes Zammad to delete files or directories outside the intended session storage location, potentially destroying application data or configuration. No public proof-of-concept is referenced, but the two fix commits reveal the exact vulnerable path-construction code. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 25, 2026
Authenticated path traversal in the websocket/long-polling session handling of Zammad 7.0.2 and 7.1.0 allows a low-privilege logged-in user to delete arbitrary files and directories on the server with a single crafted request. The client-supplied session (client) identifier is insufficiently validated before being interpolated into internal filesystem paths, so traversal sequences escape the session storage directory - but only on instances using the default file-based session store, since Redis-backed deployments are not affected. Confirmed impact is integrity and availability loss (arbitrary deletion, no read/exfiltration per the assessed vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H); there is no confirmed active exploitation (CISA SSVC exploitation: none) and no public exploit identified at time of analysis, though the flaw is fully automatable. Note that the published CVSS 4.0 score of 8.8 carries PR:N, which overstates ease of access - the independent assessment confirms authentication is mandatory.
RemediationAI
Vendor-released patch: upgrade to Zammad 7.0.3 (for the 7.0.x line) or 7.1.1 (for the 7.1.x line), which add the Sessions.valid_client_id? allowlist and the safe_session_path containment check - see the advisory at https://github.com/zammad/zammad/security/advisories/GHSA-xp9w-hhf3-vfxx and the fixing commits cf3425712e8fae1bd40fa5814a49dc318dc84006 and f78ef2434fd8aad6c2fb8a702788f6e3f33565f6. If upgrade cannot be performed immediately, the most effective workaround is to reconfigure the instance to use the Redis-based session store instead of the default file-based store, which removes the vulnerable path-construction code path entirely; the trade-off is that Redis becomes a required, availability-critical dependency that must itself be hardened and monitored. Because exploitation requires a valid low-privilege authenticated session, reduce the attack surface in the interim by limiting and auditing accounts that can authenticate (disable or de-provision unused agents/customers, enforce strong authentication), and by rate-limiting or blocking websocket/long-polling endpoints at a reverse proxy for untrusted sources - this throttles automated exploitation but does not fix the flaw and can degrade legitimate real-time chat behaviour. Also harden the host as a blast-radius control: run the Zammad application process under an unprivileged account whose write/delete permissions are confined to the session and upload directories it genuinely needs, so that even a successful traversal cannot destroy OS, configuration or database files; verify with file-permission audits that the web user cannot delete files outside /opt/zammad and its data directories, accepting that overly tight permissions may break legitimate cleanup, uploads or log rotation. Finally, monitor request logs for websocket/long-polling parameters containing '../', encoded traversal sequences or non-hex/non-UUID client identifiers, and maintain offline backups to recover quickly from destructive deletions.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Zammad is a Ruby on Rails-based open-source helpdesk/customer-support platform that pushes near-real-time updates to browsers over websocket and HTTP long-polling connections. Those transports are backed by the Sessions module (lib/sessions.rb) and a pluggable store; the default store is file-based (lib/sessions/store/file.rb), while a Redis-backed store is an alternative configuration. The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory / path traversal): the store built paths by simple string interpolation, e.g. "#{@path}/#{client_id}", "#{@path}/tmp/#{client_id}" and "#{@path}/#{client_id}/session", using the identifier supplied by the client in the websocket/long-poll request. Because that identifier was never constrained to a safe character set, values such as ../../ sequences resolved to locations outside the session directory, and the deletion code paths (session destroy / idle-session cleanup) then removed the referenced files or directories. The upstream fix introduces a strict allowlist validator Sessions.valid_client_id? applying the regex \A[a-f0-9-]+\z (matching the UUID/HMAC-style identifiers Zammad itself generates via SecureRandom.uuid) and is enforced in every Sessions entry point, including client_id_verify in app/controllers/long_polling_controller.rb. As defense-in-depth the file store also gained safe_session_path, which raises ArgumentError for invalid identifiers and then uses File.expand_path followed by a start_with?("#{@path}/") containment check to guarantee the resolved path cannot leave the storage root. The affected component is therefore the session-persistence layer plus its websocket/long-polling entry points, and the vulnerability class is a classic unvalidated-path-construction issue; because confidentiality is unaffected (C:N), the practical damage vector is destructive file/directory removal rather than data theft.
Know when Zammad gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
Remotely reachable with a single request (AV:N/AC:L), but requires a low-privilege authenticated session per the description (PR:L, not PR:N); arbitrary file deletion gives I:H/A:H, no data disclosure so C:N.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
DescriptionCVE.org
Zammad is a web based open source helpdesk/customer support system. In 7.0.2 and 7.1.0, zammad's session management for websocket and long-polling connections is susceptible to a path traversal attack. Session identifiers supplied by the client are insufficiently validated before being used to construct internal file paths. When the file-based session store is active (the default configuration), an authenticated attacker can manipulate the session identifier to reference locations outside the intended storage directory, leading to the deletion of arbitrary files and directories on the server. Exploitation requires only a low-privilege authenticated session and a single crafted request. Instances configured to use the Redis-based session store are not affected. This issue is fixed in versions 7.0.3 and 7.1.1.
Technical POC Analysis
CWE-22 (Improper Limitation of a Pathname to a Restricted Directory).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Zammad 7.0.2 and 7.1.0 are affected by a high-severity authenticated path traversal that allows a low-privilege logged-in user to delete arbitrary files and directories on instances using the default file-based session store, threatening the integrity and availability of the support platform. Leadership should care because a single malicious or compromised low-privilege account can disrupt ticket operations and delete critical data, though Redis-backed deployments are not affected. No public exploit identified at time of analysis, and no vendor-released patch identified at time of analysis.
No vendor-released patch identified at time of analysis; interim mitigations include migrating to a Redis-backed session store (unaffected), restricting low-privilege authenticated accounts, and monitoring for anomalous file or directory deletions.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Path traversal exploits occur when applications use user-controlled input to construct file system paths without proper validation.
Session hijacking in self-hosted Zammad 6.3.0 through 6.5.4 allows remote, unauthenticated attackers to take over a legi
Local privilege escalation in Zammad lets an attacker who already controls the unprivileged 'zammad' service account ele
An issue was discovered in Zammad before 1.0.4, 1.1.x before 1.1.3, and 1.2.x before 1.2.1. Rated critical severity (CVS
An issue was discovered in Zammad before 1.0.4, 1.1.x before 1.1.3, and 1.2.x before 1.2.1, caused by lack of a protecti
Zammad 5.2.0 is vulnerable to privilege escalation. Rated critical severity (CVSS 9.8), this vulnerability is remotely e
An issue was discovered in Zammad before 4.1.1. Rated critical severity (CVSS 9.8), this vulnerability is remotely explo
An issue was discovered in Zammad before 4.1.1. Rated critical severity (CVSS 9.8), this vulnerability is remotely explo
An issue was discovered in Zammad before 3.4.1. Rated critical severity (CVSS 9.8), this vulnerability is remotely explo
An issue was discovered in Zammad before 6.3.0. Rated critical severity (CVSS 9.1), this vulnerability is remotely explo
Zammad's SSO auto-linking logic can be abused to take over any existing local account, including agent and administrator
An access control issue in Zammad v5.0.3 allows attackers to write entries to the CTI caller log without authentication.
An issue was discovered in Zammad before 4.1.1. Rated critical severity (CVSS 9.1), this vulnerability is remotely explo
Exploit-DB