Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate to Zammad instance
-
DeliveryLearn victim's pending-upload form_id UUID
-
ExploitPOST to legacy destroy_form on AttachmentsController
-
ExecutionUploadCache records deleted without ownership check
-
ImpactVictim's temporary uploads silently removed before submission
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated account on the affected Zammad instance (PR:L) running a version prior to 7.1.2 with the legacy destroy_form action on AttachmentsController reachable. The decisive limiting factor is that the attacker must know the victim's specific pending-upload form_id UUID, which is not enumerable predictably - this is why CVSS assigns AC:H and why the score is low. Exploitation only affects uploads that are still in the temporary UploadCache stage (not yet committed to a submitted ticket or article), so timing against a victim's in-progress composition is also required. No non-default feature or configuration toggle is needed beyond a standard Zammad deployment. |
| Impact | This is a genuinely low-priority issue whose signals are internally consistent - not a high-CVSS-but-low-real-risk mismatch. The NVD CVSS 4.0 base score of 2.3 (AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L) reflects the reality: exploitation requires authentication (PR:L), succeeds only under high attack complexity (AC:H) because the attacker must first learn a victim's unpredictable pending-upload form_id UUID, and yields no confidentiality impact and only minor integrity/availability harm (deletion of another user's not-yet-submitted temporary attachments). No EPSS score, KEV listing, or public POC is present in the provided data - absence of these is expected for a low-impact vandalism bug and does not indicate suppressed risk. There is no SSVC decision data supplied. The only conflicting metadata is the tag 'Authentication Bypass,' which mischaracterizes a missing-authorization (CWE-862) flaw - the attacker is authenticated and the defect is a broken ownership check, not an auth bypass. Bottom line: real but minor, appropriately scored low; patch during normal maintenance cadence. |
| Exploit ScenarioDerived | An authenticated Zammad user (e.g., another agent or customer on the instance) obtains or guesses another user's pending-upload form_id UUID and sends a request to the legacy destroy_form action on AttachmentsController, which deletes UploadCache Store records matching that form_id without checking ownership. The victim's temporary file uploads silently vanish before they submit their ticket or article, causing lost work and confusion. No public exploit is identified at time of analysis; the practical barrier is discovering the target's UUID, which is why CVSS rates attack complexity high. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 25, 2026
Zammad helpdesk instances prior to 7.1.2 expose a legacy destroy_form action on AttachmentsController that deletes temporary UploadCache store records using only a caller-supplied form_id and performs no ownership verification (CWE-862), so an authenticated user who knows another user's pending-upload UUID can silently wipe that user's in-progress attachments before the ticket or article is submitted. Exploitation requires a valid account on the instance plus knowledge of the victim's non-enumerable form_id UUID and only affects files still in the transient pre-submission cache, which is why the base score is a low 2.3 under CVSS 4.0 (equivalently AV:N/AC:H/PR:L/UI:N/C:N/I:L/A:L on CVSS 3.1). No public exploit code or confirmed active exploitation was identified at time of analysis, and the flaw is fixed in Zammad 7.1.2.
RemediationAI
Upgrade to Zammad 7.1.2 or later; this is a vendor-released patch (7.1.2) and the fix is visible in commit 3b755736fdbee8ff6ddf53661d6912d3d3028325, with details in advisory GHSA-x4f3-367g-m93g. Because the vulnerable legacy destroy_form action remains reachable only until the upgrade is applied, a workaround for environments that cannot patch immediately is to block external requests to that legacy controller action at the reverse proxy or WAF while allowing the standard upload-cache endpoints - the trade-off being that any client or integration still relying on the legacy destroy_form route will fail, so confirm no active usage first. Additional compensating controls with low side effects include restricting helpdesk network exposure to trusted networks or VPN, alerting on destroy_form calls and on upload-cache deletions shortly followed by a user reporting missing attachments, and noting that the attack requires knowing another user's form_id UUID, so treating those identifiers as secrets and avoiding logging or embedding them in shared links measurably raises the bar; rotating or shortening the lifetime of pending upload caches further narrows the window in which the deletion can succeed.
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 application whose attachment workflow stages files in a temporary "UploadCache" (implemented as Store records keyed by an object type and an o_id equal to the form_id UUID) before they are committed to a ticket or article. The vulnerable legacy code path called Store.remove(object: 'UploadCache', o_id: params[:form_id]) directly from AttachmentsController#destroy_form without any authorization check, and the controller's prepend_before_action :authorize! list covered only :show and :destroy - a textbook CWE-862 Missing Authorization, where the object identifier supplied by the client is trusted as a capability token while the server never ties it to the requesting user. The upstream fix (commit 3b755736fdbee8ff6ddf53661d6912d3d3028325) adds :destroy_form to the authorize! callback, introduces an AttachmentsControllerPolicy#destroy_form? that delegates to UploadCachePolicy via Pundit, wraps cache access in a new UploadCache abstraction, and adds a created_by_id scope to Store.list so that cache reads and deletions are constrained to the owning user (with an explicit created_by_id: nil override used only for policy checks). The CPE record cpe:2.3:a:zammad:zammad:*:*:*:*:*:*:*:* reflects that the affected version range is defined by the fixed release rather than a single pinned build.
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:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
Authenticated (PR:L) network attacker must first learn an unpredictable victim form_id UUID (AC:H); deleting another user's pending upload harms integrity and availability only (I:L/A:L), no data read (C:N).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.org
Zammad is a web based open source helpdesk/customer support system. Prior to 7.1.2, the legacy destroy_form action on AttachmentsController deletes UploadCache Store records based solely on a user-supplied form_id without verifying that the requesting user owns those records. An authenticated attacker who learns another user's pending-upload UUID can silently remove temporary file uploads before the victim submits their ticket or article. This issue is fixed in version 7.1.2.
Threat Intelligence Overview
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
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
EUVD-2026-87224
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB