Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as basic customer
-
DeliveryCall external_data_source API
-
ExploitReference another record's ID
-
ExecutionServer skips authorization check
-
ImpactForeign ticket/user/org details disclosed
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V14 - Data Protection Data exposure prevention
MITRE ATT&CK
2 techniques across 2 tactics: Collection, Discovery The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires (1) a Zammad instance older than 7.1.2 with the External Data Source feature configured/used to look up records from an external system, and (2) any authenticated account - including a minimal customer-level account with no special privileges. The attacker must know or guess a target record's numeric ID (ticket, user/customer, group, or organization), which is enumerable. Exploitation is limited to confidentiality (reading others' records); it grants no write or availability impact, requires no user interaction from a victim, and does nothing on instances that do not use the External Data Source feature. |
| Impact | This is a genuine but moderate-severity broken-access-control (IDOR) flaw, not a high-CVSS-but-empty issue, yet several signals keep real-world urgency low. The vendor-assigned CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:N/VC:H, no integrity or availability impact) matches the description exactly - a purely confidentiality-affecting authorization bypass reachable over the network by any authenticated user. PR:L is well-supported: the description explicitly states even a basic customer account suffices, so the barrier is low but non-zero. No EPSS score, KEV listing, or public POC is present in the input, so there is no evidence of active or automated exploitation - this signal is consistent (all three exploitation indicators are absent), meaning the 7.1 rating reflects impact-and-ease, not observed attacks. The commit diff and added RSpec tests confirm the root cause and fix, raising confidence in the technical claim. Net: real and worth patching for Zammad operators, but its niche footprint, requirement for a valid account, and dependence on the External Data Source feature being configured make it a routine-patch priority rather than an emergency. |
| Exploit ScenarioDerived | An attacker registers or already holds a basic customer account on a Zammad instance whose External Data Source feature is enabled. They send an authenticated API request to /api/v1/external_data_source/... supplying another record's ID in search_context (e.g. ticket_id, customer_id, group_id, or organization_id), and the server includes that unauthorized record's details in the render context / outbound external lookup, disclosing foreign tickets, customer accounts, teams, or organizations. No public exploit code is identified at time of analysis, though the fix commit and test cases make the vector straightforward to reproduce. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 25, 2026
An authenticated broken-access-control flaw in Zammad's External Data Source feature lets any logged-in user - including a minimal customer-level account - read records that do not belong to them by supplying another record's numeric ID. The affected component builds a 'render context' from request parameters such as ticket_id, customer_id, user_id, group_id, and organization_id and passes it to the configured external system lookup without first checking whether the requesting user is permitted to see that record, so enumerable IDs leak ticket, user, group, and organization details. The issue affects Zammad versions prior to 7.1.2, where the vendor-released patch (7.1.2) adds an explicit authorization check; no public exploit code or confirmed active exploitation was identified at time of analysis.
RemediationAI
Upgrade to Zammad 7.1.2, which is the vendor-released patch and introduces the authorized_record/authorized?(record, :show?) check on every record pulled into the External Data Source render context; consult the vendor advisory at https://github.com/zammad/zammad/security/advisories/GHSA-jvm2-cr58-4qxp and the fix commit at https://github.com/zammad/zammad/commit/34bdf46273adbea03821ac7157c8beaacde03a4b for verification. If an immediate upgrade is not possible, the most effective compensating control is to disable or remove the External Data Source object lookups that administrators have configured (or block the /api/v1/external_data_source/* endpoints at the reverse proxy); the trade-off is that any form field relying on external lookups stops auto-completing or resolving values, which breaks dependent workflows. Restricting access to those endpoints to trusted internal networks or specific roles limits exposure but does not fix the underlying authorization gap, since the vulnerable code path is still reachable by any authenticated user with network access, and ID values remain enumerable. Because exploitation requires only a valid low-privilege login, audit logs for /api/v1/external_data_source requests containing search_context parameters during the exposure window to identify any records that may have been read, and rotate or restrict anything sensitive that was exposed through a third-party lookup.
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 helpdesk/customer-support platform, and the flaw sits in the External Data Source feature, which lets administrators query records from a third-party system and merge the returned values into Zammad forms. The controller at app/controllers/external_data_source_controller.rb assembled a render context by looking records up directly with model.find_by(id: param_value) for each model referenced in the query string (ticket, user/customer, group, organization), then handed that context to the ExternalDataSource object that issued the outbound lookup. Because no policy check ran between the lookup and the outbound request, the controller effectively acted as an authorization-blind proxy: any object the user could name by ID was resolved and its attributes forwarded. This is CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) realized as an insecure direct object reference / missing function-level access control. The fix replaces the raw lookups with an authorized_record(model, id) helper that returns nil unless authorized?(record, :show?) passes, so unauthorized records are simply omitted from the render context, and the accompanying spec changes confirm the intended behavior for agents without group access, unrelated customers, unrelated organizations, and unrelated users (the last case falling back to the current user). The assessed CVSS:3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N matches the code evidence: pure confidentiality impact, authenticated (PR:L), no user interaction, no scope change, and no integrity or availability effect.
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:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Network-reachable API needing only a low-privilege authenticated (basic customer) account, no user interaction, high confidentiality disclosure of foreign records but no integrity or availability impact.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
Zammad is a web based open source helpdesk/customer support system. Prior to 7.1.2, zammad's External Data Source feature, used to look up records from an external system, did not properly verify whether a user was allowed to see a specific ticket, user, group, or organization before including its details in a request to that external system. An authenticated user, including one with only basic customer access, could exploit this by referencing another record's ID, and thereby view details of tickets, customer accounts, teams, or organizations that did not belong to them. This issue is fixed in version 7.1.2.
Technical POC Analysis
Evidence basis: GHSA-jvm2-cr58-4qxp (published 2026-08-04, reporter r00k1e-sec).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
A broken access control flaw in Zammad's External Data Source feature allows any logged-in user - including the lowest-privilege customer account - to retrieve help desk records belonging to other users and organizations simply by changing a numeric identifier in a request. Because the exposed data spans tickets, users, groups, and organizations, the flaw can leak the full breadth of an organization's support history, customer identities, and internal structure to anyone who can obtain a basic account, and it affects all deployments running Zammad versions prior to 7.1.2. Leadership should treat this as a customer-data confidentiality and contractual/regulatory exposure issue rather than a purely technical defect, since impact scales with the size of the customer base and the sensitivity of ticket content.
Apply vendor patch.
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
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
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-87263
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB