Independent analysis by NHI Mgmt GroupSource article: runZero, “How to find Zammad installations on your network” (October 2, 2026)

TL;DR: Remote attackers can hijack Zammad user sessions through CVE-2026-102489 and then reach root through CVE-2026-102490, according to runZero, with both flaws already listed in CISA's KEV catalog. Session integrity and local privilege boundaries fail together, so patch urgency must account for takeover chains rather than single CVEs.


At a glance

What this is: NHI Mgmt Group's analysis, drawing on runZero's report: Zammad session fixation and local privilege escalation vulnerabilities can chain into full host takeover and have already been added to CISA's KEV catalog.

Why it matters: Help desk and ticketing platforms often sit close to authentication workflows and privileged administration, so a session break in this layer can become a broad identity and host compromise path.

By the numbers:

  • CVE-2026-102489 has a CVSS score of 8.7 and affects Zammad versions 6.3.0 through 6.5.4.
  • CVE-2026-102490 has a CVSS score of 8.5 and reportedly affects Zammad versions 1.5.0 through 7.1.0-alpha.
  • Evidence indicates that both vulnerabilities were added to the CISA Known Exploited Vulnerabilities catalog on October 2, 2026.

Context

Session fixation is a control failure where an attacker can force or reuse a session identifier and then inherit the victim's authenticated state. In a help desk platform, that breaks the assumption that session state remains bound to the legitimate user, which is why session handling deserves the same scrutiny as password or MFA design.

Zammad is a self-hosted support system, so the security boundary includes both application sessions and the underlying host account used by the service. When session compromise can lead to local code execution and then privilege escalation, the platform becomes a bridge between account compromise and operating system takeover.


Key questions

Q: How do session fixation attacks hijack an authenticated user session?

A: Session fixation hijacks a session when an attacker forces or predicts a session identifier before authentication, then reuses that same ID after the victim logs in. Defences include issuing a new session ID on successful login, invalidating the pre-authentication token, and binding the session to the authenticated context so the attacker cannot reuse it.

Q: Why does local privilege escalation matter after application compromise?

A: Local privilege escalation matters because an attacker who starts with application-level code execution can move from a low-privilege process to root or SYSTEM and then control the host, steal secrets, and tamper with services. Strong service privilege design limits that jump by running applications with the minimum OS rights, separating accounts, and restricting sudo or service rights.

Q: How should teams manage session security in self-hosted web applications?

A: Teams should manage session security with short-lived session IDs, secure cookie flags, server-side invalidation on logout and privilege change, and reauthentication for sensitive actions. Session discipline also means limiting concurrent sessions, protecting tokens from script access, and expiring idle sessions so stolen cookies and replayed requests have less value.

Q: What should administrators do first when a critical CVE is added to KEV?

A: Administrators should first confirm whether the vulnerable asset is exposed, in scope, and actually affected, then prioritise patching, mitigation, or isolation based on exploitability and business criticality. A KEV listing means a known, real-world exploit path exists, so exposed internet-facing systems and high-value internal services should move to the front of the remediation queue.


Technical breakdown

How session fixation lets an attacker inherit an authenticated help desk session

Session fixation happens when an attacker can influence or preserve a session identifier before the victim authenticates, then reuse that identifier after login. The attacker does not need the password if the application fails to rotate the session token at the authentication boundary. In a ticketing system, that matters because authenticated sessions often expose administrative workflows, customer data, and message-handling functions. Once the attacker rides an authenticated session, downstream actions can occur as if they were the legitimate user, including actions that indirectly open a path to code execution. See the Session Fixation Guide.

Practical implication: Rotate session identifiers on authentication and invalidate any session that predates login.

Why local privilege escalation matters after application compromise

Local privilege escalation converts an application-level foothold into a higher operating-system trust level. In this case, the reported flaw allows the local zammad user to move to root, which means an attacker who reaches code execution in the application context can cross into full host control. That is a different control problem from remote access. The missing boundary is not just authentication, but the separation between service privileges and administrative privileges on the host. See the Workforce Identity Security Guide.

Practical implication: Constrain service accounts so application compromise cannot become root compromise.

Why exploited CVEs in self-hosted support systems create broad exposure

Self-hosted support platforms are high-value because they sit at the intersection of identity, communication, and administration. If a platform flaw is actively exploited, the security concern is not only the code path itself but the operational blast radius: exposed installations, outdated releases, and delayed patching all become part of the attack surface. The mention of end-of-support versions is especially important because unsupported builds remove the last practical recovery option for defenders. See the CVE, CWE and CPE Guide.

Practical implication: Prioritise asset discovery and patch validation for every exposed instance, especially unsupported releases.


Threat narrative

Attacker objective: The attacker aims to convert help desk application access into root-level control of the host system.

  1. Entry occurs when a remote attacker abuses the session fixation flaw in Zammad to take over a user's authenticated session.
  2. Credential access is effectively bypassed because the attacker inherits the victim's trusted application state without knowing the password.
  3. Escalation follows if the attacker uses the local privilege escalation flaw to move from the zammad user context to root on the host.
  4. Impact is full compromise of the help desk server, with potential access to customer communications, administrative functions, and other data on the system.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Session fixation in a support platform is an identity boundary failure, not just a web bug. When a ticketing system can hand an authenticated session to the wrong party, the problem reaches beyond application security into identity assurance and session governance. The risk is amplified in self-hosted tools that sit close to customer communications and privileged administration. Practitioners should treat session rotation and binding as core identity controls, not optional hardening.

Local privilege escalation turns an application flaw into a host governance problem. Once the attacker can move from the service account to root, the original session issue becomes an operating-system compromise. That shift matters because many teams scope remediation around the web layer while leaving service privilege design untouched. The real failure mode is overtrusted service execution, and it is visible long before root access appears.

Help desk systems need the same lifecycle discipline that organisations apply to privileged identities. A self-hosted support platform may look like ordinary application infrastructure, but it often contains customer data, authentication workflows, and admin functions in one place. Linking this class of platform to session hijacking and cookie theft is a reminder that compromise of the session layer can cascade into broader account and host control. Practitioners should inventory these systems as security-critical assets, not routine business apps.

Active exploitation changes the operational priority from patch hygiene to exposure management. Once a flaw is in the KEV catalog, the issue is no longer theoretical: exposed instances become known targets. The practical problem is finding every installation, including unsupported versions, before attackers do. Security teams should assume that internet-facing support platforms will be probed quickly after public disclosure.

What this signals

Session governance is now a host-security issue. When an application session can be hijacked and then chained into local privilege escalation, defenders have to treat identity state as part of the host attack surface. That means authentication events, session rotation, and service-account privilege all belong in the same risk view, not separate teams or separate dashboards.

Unsupported support platforms create a long tail of exposure because attackers do not need many targets, only reachable ones. The most dangerous pattern is a service that is both externally accessible and operationally sticky, where administrators delay upgrades because the platform still works. In practice, exposure management for help desk systems should be aligned with identity controls and host hardening, not just application patching.


For practitioners

  • Rotate and bind application sessions at authentication boundaries Invalidate pre-login session identifiers, require fresh tokens after privilege changes, and test that cookies cannot be reused across authentication events.
  • Separate service privileges from administrative privileges Run the support platform under the least privileged account possible and remove any path from the application account to root-level host control.
  • Find every exposed installation before attackers do Search service inventory for internet-facing Zammad instances, confirm version coverage, and track unsupported releases as urgent exposure even when exploitability is debated.
  • Prioritise KEV-listed flaws over normal patch queues Escalate fixes for vulnerabilities already in the CISA Known Exploited Vulnerabilities catalog and verify remediation on all externally reachable systems.

Key takeaways

  • Zammad's reported flaws show how session compromise can become host compromise when application sessions and local privileges are weakly separated.
  • The article identifies two high-severity vulnerabilities and says both are already in CISA's KEV catalog, which raises the likelihood of active targeting.
  • Administrators should treat exposed and unsupported help desk installations as urgent security assets, because patch delay can leave an attacker one step away from root.

Related NHI Mgmt Group resources: Session Fixation Guide · Workforce Identity Security Guide · Token and Session Security Guide


Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationSession fixation in Zammad is an authentication failure that lets an attacker inherit a trusted session.
NHI-01 — Improper OffboardingUnsupported Zammad versions and lingering sessions create stale trust that attackers can abuse.
Recommendation — Enforce session rotation and token re-issuance so authentication state cannot be reused by an attacker. Remove unsupported instances and revoke stale sessions before they remain reachable in production.
MITRE ATT&CKTA0006;TA0004 — Credential Access; Privilege EscalationThe attack chain combines session takeover with a local move to root.
Recommendation — Map the chain to credential access and privilege escalation to prioritise detection and containment.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementThe session problem sits squarely in authenticator lifecycle management.
Recommendation — Apply authenticator management controls to rotate, invalidate, and bind sessions correctly.
CIS Controls v8CIS-5 — Account ManagementThe host takeover risk depends on weak account and service privilege governance.
Recommendation — Use account management controls to restrict service privileges and remove unnecessary root paths.

Key terms

  • Session Fixation: Session fixation is an attack where an attacker causes a victim to use a session identifier the attacker already knows or controls. In practice, it often succeeds when applications accept an untrusted session value without reissuing or validating the session at authentication time.
  • CWE-384: CWE-384 is a weakness class for session fixation, where an attacker sets or predicts a session identifier before the user authenticates. The flaw appears when an application accepts that pre-existing ID after login instead of issuing a new one, allowing the attacker to ride the authenticated session.
  • Privilege Escalation: An attack technique where a compromised identity, often an NHI with initially limited permissions, exploits vulnerabilities or misconfigurations to gain elevated access rights, typically leading to broader compromise.
  • CVE: Common Vulnerabilities and Exposures is a standard identifier for publicly known software vulnerabilities. It does not measure severity or exploitability on its own. Security teams use CVE IDs to align scanners, advisories, patching workflows, and reporting around the same issue across tools and organisations.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners connect session, privilege, and lifecycle controls across their programmes.
NHIMG Editorial Note
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org