Is CVE-2026-102490 (Zammad GmbH Zammad Improper Privilege Management) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2026-102490 to its Known Exploited Vulnerabilities catalogue on 2 October 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Zammad GmbH Zammad contains an improper privilege management vulnerability that can allow the local zammad user to escalate privileges to root.

What makes a KEV listing the practical answer to “is it being exploited in the wild?”

A CVE on CISA’s Known Exploited Vulnerabilities catalogue is not just a theoretical issue. It means CISA has credible evidence that the flaw is being used actively, so the question shifts from “should we watch this?” to “are we exposed, and how quickly can we remove the path?” For this class of issue, treat the KEV entry as an operational signal, not a score.

That is why CISA’s Known Exploited Vulnerabilities Catalog matters more than generic severity alone. If the affected product is present, exposure is immediate until the vulnerable condition is removed or mitigated. If the product is absent, the KEV entry still helps narrow verification to asset inventory and service ownership rather than abstract risk discussion.

How to confirm exposure and reduce blast radius fast

The first task is to confirm whether any Zammad deployment exists in your environment, including unmanaged, forgotten, test, or vendor-hosted instances with administrative pathways into production data. For privilege-management issues, the practical exposure question is not only “is the software installed?” but also “can a local zammad user reach the vulnerable privilege path on any live system?”

Once exposed, the priority is to remove the vulnerable condition using the vendor’s advisory and CISA’s KEV record for authoritative version and mitigation detail. Where patching cannot happen immediately, reduce the reachable attack surface by isolating the system, restricting local access, and removing unnecessary interactive access on the host. For internet-reachable or shared systems, delay is especially costly because active exploitation means the window is already open.

What post-compromise checks matter most for a local-to-root flaw

Because the flaw can let a local zammad user escalate to root, verification should include host-level compromise assessment, not just application logs. Review for unexpected root-owned processes, new privileged users, altered scheduled tasks, modified binaries, suspicious sudo or shell history, and changes to startup or persistence locations that would indicate the attacker moved beyond the original application context.

The investigation should also ask whether the local account, service account, or adjacent credentials were used to pivot after escalation. If the host also stores secrets, deployment tokens, SSH keys, or database credentials, assume the impact may extend beyond the original application boundary and validate whether any of those values were exposed or reused elsewhere.

Risk and Threat Considerations

Local privilege escalation is attractive because it converts a limited foothold into full host control. Once root is available, attackers can tamper with logs, implant persistence, harvest secrets, and use the system as a stepping stone into connected services or data stores.

Failure mechanism: A local zammad user can trigger the privilege-management flaw and obtain root, which defeats normal host separation and undermines any trust placed in the application boundary.

Impact: An attacker with root can exfiltrate data, disable defenses, alter configuration, and prepare follow-on access that is much harder to detect or unwind.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Exploited flaws demand rapid asset confirmation and secure configuration reduction.
Recommendation — Harden or isolate exposed Zammad hosts and remove unnecessary local access until fixed.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The page concerns remediation of a known exploited vulnerability in software.
	AU-6 — Audit Review, Analysis, and Reporting	Root escalation requires reviewing logs and host evidence for prior compromise.
Recommendation — Apply the vendor fix or mitigation and track remediation to closure. Review logs and host telemetry for signs of privilege escalation and persistence.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	Known exploited vulnerabilities require disciplined vulnerability handling and remediation.
Recommendation — Prioritise and remediate the vulnerable Zammad deployment using formal vulnerability handling.
MITRE ATT&CK	T1068 — Exploitation for Privilege Escalation	The flaw is an exploitation path that elevates a local user to root.
Recommendation — Map the event to privilege-escalation detection and hunt for post-exploit activity.

Practitioner Guidance

What to prioritise: Treat KEV-listed exploitation as a containment problem first, then a patching problem. Confirm whether Zammad exists, whether any instance is reachable by a local user, and whether the host already shows signs of privilege escalation before you spend time on broader vulnerability backlog work.

What to verify: Verify the exact deployment owner, host OS, local account model, and whether the application runs with any stored administrative material that would make root escalation materially worse. A root-capable flaw is far more serious on a system that also holds deployment secrets or operational credentials.

Decision rule: If the system is exposed and you cannot patch immediately, isolate it and tighten local access now rather than waiting for perfect change windows. If the host is already suspicious, escalate as a potential compromise, not a routine patch ticket.

Practitioner takeaway: For a KEV-listed privilege escalation, the right question is not whether exploitation is possible in general, but whether any instance is still reachable and trustworthy enough to keep running unchanged.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org