DIVD Breach: AI Agent Exploits Zammad Zero-Days

Zero-Day Status and Affected Versions

The attack leveraged two distinct zero-day vulnerabilities affecting the open-source Zammad ticketing and customer support ecosystem. Prior to the coordinated disclosure and subsequent vendor remediation, both flaws existed as zero-day vulnerabilities without publicly available patches or threat signatures.

Analysis of the impacted releases reveals widespread exposure across production deployments:

• Web Session Hijacking and Remote Code Execution Flaw: Impacted Zammad versions 6.3.0 through 6.5.4, enabling unauthenticated remote threat actors to manipulate session states and trigger command execution. While vulnerable code structures existed in versions 7.0.0 through 7.1.3, architectural changes rendered the exploit chain ineffective in those later releases.

• Local Privilege Escalation Flaw: Impacted legacy and modern versions across Zammad 1.5.0 through 7.1.0-alpha, allowing any low-privileged local application account to achieve complete administrative control over the underlying host.

Organizations hosting internet-facing instances of Zammad must immediately audit their active software version against organizational asset inventories using continuous Vulnerability Assessments to verify whether unpatched components remain accessible to external adversaries.

Technical Root Cause and Exploit Chain

The intrusion progressed through a multi-stage attack chain executed at machine speed. Unlike traditional human-driven intrusions where exploitation, reconnaissance, and privilege escalation can span hours or days, this automated sequence achieved host-level root access almost instantaneously.

Phase 1: Initial Access via Session Hijacking

The external AI agent initiated its attack against the publicly accessible Zammad web interface. By exploiting an unauthenticated session handling vulnerability, the agent hijacked legitimate communication pathways to forge privileged session tokens. This session fixation and hijacking capability permitted the attacker to bypass authentication boundaries and issue commands directly to the backend application runtime.

Phase 2: Remote Code Execution as the Service Account

Leveraging the compromised session context, the agent injected malicious instructions into backend ticketing workflows. This action resulted in arbitrary remote code execution operating under the privileges of the local zammad service user account. Under normal operating conditions, this service account is constrained to application-specific directories and restricted execution permissions.

Phase 3: Machine-Speed Local Privilege Escalation

Immediately following the execution of its initial payload, the agent triggered the second zero-day flaw. This local privilege escalation vulnerability exploited weak internal process boundaries and permission configurations, promoting the low-privileged zammad process to full root administrative access within seconds. Forensic analysis revealed that the autonomous agent executed self-annotated scripts during this phase, generating internal reasoning comments as it navigated local system defenses.

Active Exploitation and Impact Analysis

Following successful root elevation, the active exploitation phase transitioned into automated host enumeration, credential harvesting, and network pivot attempts. Operating under full administrative authority, the agent conducted aggressive internal reconnaissance, including automated password spraying against internal endpoints and attempts to stage adversary-in-the-middle (AiTM) interception routines.

However, the automated nature of the agent introduced operational idiosyncrasies. Forensic investigators observed noisy and erratic behaviors, including non-deterministic execution paths where aggressive credential spraying routines directly interfered with the agent's own network interception mechanisms. Despite this erratic pattern, the attacker accessed auxiliary systems and successfully exfiltrated volunteer contact information and email registries.

The broader impact of the breach was curtailed by pre-existing network segmentation. The host hosting the helpdesk application was segregated from the organization's core disclosure infrastructure and primary databases, preventing the actor from compromising proprietary vulnerability reports or sensitive partner telemetry. Enterprise environments lacking strict microsegmentation would face catastrophic lateral spread under an identical attack scenario.

Detection and Threat Hunting Guidance

Detecting agentic zero-day exploitation requires threat hunting methodologies focused on anomalous process lineage, rapid-fire privilege changes, and web server transaction anomalies. Because the initial exploit payload bypasses standard signature-based detection, defenders must hunt for behavioral indicators on host systems and network gateways.

Host-Level Forensic Log Analysis

Security analysts should inspect system journals and execution logs across all Linux-based helpdesk servers for unexpected privilege transitions or suspicious child processes spawned by service users:

# Check for abnormal process elevation and sudo activity from the service user
journalctl --since "2026-09-20" | grep -iE "zammad|session|sudo|root"

# Audit recently modified or created binaries within application and temporary paths
find /opt/zammad /var/lib/zammad /tmp -type f -newermt "2026-09-20" -ls

# Inspect active network sockets and suspicious listening services
ss -plant | grep -E ":(80|443|3000|8080)"

SIEM and Behavioral Detection Logic

Security operations centers (SOCs) should deploy behavioral correlation rules designed to flag non-standard execution paths originating from web application service accounts. A high volume of administrative shell invocations (such as /bin/bash or /bin/sh) originating from zammad accounts within short time intervals serves as a high-fidelity indicator of compromise.

Regular security posture validation through simulated adversary exercises, such as comprehensive Penetration Testing, allows organizations to identify and eliminate similar unmonitored execution pathways before malicious actors exploit them.

Fixed Versions, Mitigations, and Verification Steps

Securing helpdesk infrastructure against autonomous exploitation requires immediate software updates, strict network access controls, and systematic credential revocation across all connected dependencies.

1. Apply Upstream Vendor Updates

Administrators must immediately upgrade all production and staging deployments of Zammad to version 7.0.0, 7.2.0, or the latest available maintenance release. Upgrading to these supported versions eliminates the unauthenticated session hijacking vulnerability and neutralizes the primary vector for remote code execution.

2. Implement Network Isolation and Zero Trust Proxies

Helpdesk management platforms containing sensitive communication records should never be exposed directly to the open internet without intermediate authentication. Place all administrative and internal ticketing portals behind zero-trust network access (ZTNA) solutions, authenticated reverse proxies, or dedicated VPN tunnels requiring multi-factor authentication (MFA).

3. Enforce Strict Host-Level Hardening

Restrict local execution permissions for the zammad system user. Implement mandatory access control profiles using SELinux or AppArmor to prevent service accounts from writing to executable directories, invoking unauthorized system binaries, or establishing unexpected outbound network connections.

4. Credential Rotation and Session Invalidation

Following software patching, security teams must complete the following verification and rotation steps:

• Terminate and invalidate all existing user and administrative web sessions across the ticketing application.

• Rotate all database credentials, API integration keys, and local SSH host keys associated with the underlying server.

• Regenerate all inbound and outbound email server authentication tokens configured for ticket intake and automated notification dispatch.

• Review system access logs to verify that no persistence mechanisms or unauthorized scheduled tasks (cron jobs) were planted during the intrusion window.