Help-desk software receives unauthenticated input from strangers as a core feature. Anyone can email a support address, and anyone can usually submit a web form. That makes a customer-support platform an unusually exposed application for something that also holds internal conversation history and customer data.

Zammad had two vulnerabilities, CVE-2026-102489 and CVE-2026-102490, both rated 9.4, added to the Known Exploited Vulnerabilities catalog in early October 2026 based on confirmed exploitation.

The exposure profile of a support platform

A support system is not a generic web application. It has properties that raise the stakes of a compromise:

  • It accepts content from unauthenticated external users by design.

  • It stores the full history of customer conversations, including attachments customers send.

  • It integrates with identity providers, mail systems and sometimes CRM or billing platforms.

  • It often runs on infrastructure shared with internal tooling.

Any one of those would justify attention. Together they make the support desk a junction where external input, customer data and internal credentials meet.

What the pairing suggests

Two vulnerabilities in the same product, disclosed and exploited together at the same 9.4 severity, typically indicate either a shared root cause or a chain where one flaw enables the other. Public technical detail reviewed for this article does not establish which, and it would be a mistake to assert a mechanism that the available reporting does not support.

What can be said with confidence is the operational implication: patching only one of the two is unlikely to close the path, and any assessment of exposure should assume both are relevant until the vendor advisory says otherwise.

Patch, then look for what a support system can hide

A compromised support platform offers unusual places to hide. Ticket content is free-form text that both external users and internal staff write. Attachments are files. Automations run on schedules.

If the platform was internet-reachable while unpatched, the investigation should cover:

  1. 1.

    Administrative account changes. New administrators, modified roles, altered authentication settings.

  2. 2.

    Automation and trigger definitions. A scheduled trigger that executes code or calls an external endpoint is a persistence mechanism that survives a password reset.

  3. 3.

    Integration credentials. Mail, identity and ticketing integrations hold secrets that a compromised application can read.

  4. 4.

    Ticket content for command patterns. Content that later reaches a scheduled job or a rendering path is worth reviewing, because support platforms transform and re-render user text constantly.

  5. 5.

    Outbound connections. A support instance that calls unfamiliar endpoints is not behaving as designed.

Item two deserves emphasis because it inverts a common assumption. Administrators think of automations as configuration. Attackers think of them as scheduled execution with legitimate credentials.

Segmentation as the durable control

Support platforms are frequently placed on internal networks because they need database access and integration with internal systems. That placement often comes with broad reachability, which converts an application compromise into a network position.

The more defensible design:

  • Terminate the public-facing input path at a reverse proxy or a dedicated ingress tier, not on the application server.

  • Restrict the application server's outbound access to a documented allowlist of integration endpoints.

  • Keep administrative access on a management path with separate authentication.

  • Ensure the application server cannot reach databases or internal APIs outside its documented integration set.

None of these require new products. They require accepting that an internet-facing application which accepts anonymous input should not sit inside the trust boundary it is meant to protect.

Rollout notes

Zammad deployments are often managed as containers or packages pinned to a specific release. Before upgrading, confirm the deployed version from the application's own status output, not from the deployment manifest, and verify that the upgrade includes both fixes.

After upgrading, check whether the platform has been running with self-registration or anonymous ticket creation enabled. Those settings determine how easily an unauthenticated party could have reached the vulnerable path — they do not determine whether you were targeted, but they determine how the exposure is scoped.

References