Zammad KEV chain — session fixation as an RCE precursor and an unfixed service-user-to-root LPE¶

Sources: CISA KEV 2026.10.02 additions CVE-2026-102489 (session fixation → RCE as the zammad user) and CVE-2026-102490 (zammad user → root), added 2026-10-02, due 2026-10-05, both flagged for forensics triage. Companion GHSA for the LPE: GHSA-hgff-g8g3-4xr8. Related existing pages: Sept 21 management-plane page, June 22 monitoring/control-plane boundaries.

Why this is durable operator content: KEV explicitly marks both CVEs as chained, CISA lists the privilege-management bug as reported actively exploited, and the LPE advisory states all versions including the latest alpha enable it — meaning internet-exposed helpdesk instances are exploitable end-to-end (unauthenticated foothold → service-user RCE → root) regardless of patch level on the LPE leg at publication time. Helpdesk/ticketing platforms are credential-dense targets: agents routinely paste credentials, tokens, and internal URLs into tickets.

Confirmed source facts¶

Operator lessons¶

1. Session fixation is the underrated auth-entry primitive — and KEV now says it leads to RCE¶

Fixation (pre-setting a victim's session identifier rather than stealing a fresh one) is rarely KEV-listed; when it is, and the KEV also names RCE as the outcome, treat the product as having a post-auth code path reachable from any session an attacker can plant. Durable validation battery for any session-authenticated web app (lab only):

1. Obtain a session cookie/ID from an anonymous visit, then authenticate a victim-owned account from a second browser/profile carrying that pre-set ID; check whether the authenticated session accepts the pre-auth identifier (fixation) instead of rotating.
2. Check rotation in both directions: login must issue a new identifier; logout/expiry must invalidate the old one; password change and 2FA enrollment must revoke all sessions.
3. On a helpdesk specifically, the post-auth surface behind a fixed agent session is the prize: ticket macros, triggers, webhooks, integrations, and import/scheduled-job features are the RCE-capable legs (the KEV description confirms at least one such path exists in Zammad's zammad-user context).

Reporting heuristic: title as session fixation at login → agent-context access → named code-execution feature, and prove only the fixation transition plus one marker action as your own second account. Do not demonstrate the RCE leg on anything but a disposable instance.

2. An unfixed local-to-root on the service user converts any foothold into host ownership¶

The LPE's "all versions, including latest alpha" admission is the operator-relevant fact: patching the web leg does not remove the local leg. For authorized appliance/apppliance-like validation runs, once you legitimately land as the app's service user (disposable lab only), check what the service user can reach — writable unit files/timers, app-owned directories on PATH or load paths, sudo entries, setuid helpers, group memberships, app-managed cron, and world-writable config the root-owned daemon re-reads. Evidence = id, a marker file, a denied-vs-writable inventory table. On production: do not attempt; record service-user inventory only if the engagement scope includes post-exploitation.

3. Helpdesk platforms are a recon target class worth their own sweep¶

A helpdesk instance aggregates: internal URLs and screenshots, password-reset traffic, API tokens pasted into tickets, SSO configuration, and webhook endpoints. On red-team engagements, enumerate helpdesk subdomains (support., helpdesk., tickets., zammad.) during recon and fingerprint them by Rails fingerprint plus Zammad-specific routes/assets; their integrations page is a map of the org's internal systems. Keep reads to what your scope grants.

Validation boundaries¶

• Version/route evidence: public login surface, /api route banners, asset-version fingerprints — no authenticated access without scope.
• Fixation proof: two disposable accounts you own on a lab instance, pre-auth identifier reuse across login, session-rotation decision table.
• LPE proof: owned disposable instance, marker-only, no credential reads, no persistence.
• Report the chain as three separately-proven edges (fixation → agent session → named feature → user-level code exec; service user → root locally) and do not claim root on a host you have not independently and permissively tested.