Skip to main content
Vulnerability Database/CVE-2026-63205

CVE-2026-63205: Zammad Privilege Escalation Vulnerability

CVE-2026-63205 is a privilege escalation flaw in Zammad helpdesk system that allows channel admins to access restricted attachments through email signature manipulation. This post covers technical details, affected versions, impact, and mitigation.

Published:

CVE-2026-63205 Overview

Zammad is a web-based open source helpdesk and customer support system. A broken access control flaw [CWE-639] in versions prior to 7.1.2 allows channel-admin users to read attachments they should not access. When a user creates or updates an email signature containing inline <img> tags that reference existing attachment IDs, Zammad copies those attachments into signature-owned records without verifying authorization against the original object. The copied attachments then become downloadable through the signature's channel-admin access path. The issue is fixed in Zammad 7.1.2.

Critical Impact

Users holding admin.channel_email, admin.channel_google, admin.channel_microsoft365, or admin.channel_microsoft_graph permissions can exfiltrate ticket and knowledge-base attachments from groups outside their membership.

Affected Products

  • Zammad versions prior to 7.1.2
  • Zammad self-hosted helpdesk deployments
  • Zammad instances exposing email channel administration to delegated admins

Discovery Timeline

  • 2026-09-25 - CVE-2026-63205 published to NVD
  • 2026-09-29 - Last updated in NVD database

Technical Details for CVE-2026-63205

Vulnerability Analysis

The vulnerability resides in Zammad's inline image handling for email signatures. When a signature body is saved, the HTML sanitizer scrubber iterates over <img> tags and resolves any cid: references to records in the Store attachment table. The scrubber loads the attachment by ID and attaches a copy to the signature without checking whether the current user may access the referenced source attachment.

Attachment authorization in Zammad is enforced at the owner level. Since the newly cloned attachment is owned by the signature object, any user with signature-management rights can download it. This design converts the signature into an oracle that returns the contents of any Store record whose numeric ID an attacker can guess or enumerate.

Exploitation requires an authenticated account with one of the four channel-admin permissions. The attacker crafts a signature body containing <img src="cid:..."> tags pointing to attachment IDs owned by tickets, knowledge-base articles, or other objects. After saving, the attacker downloads the signature attachments and recovers the original file content.

Root Cause

The scrubber at lib/html_sanitizer/scrubber/inline_images.rb performed Store.find(attachment_id) without a Pundit policy check. The attachment's show? policy was never evaluated against the acting user, so cross-tenant and cross-group boundaries were not enforced during the copy operation.

Attack Vector

An authenticated channel-admin issues a signature create or update request containing crafted inline image references. No user interaction is required beyond the attacker's own session.

ruby
         cid        = generate_cid
         attachment = Store.find(attachment_id)
 
+        # Check if the current user is present
+        # To allow operations in userless context, e.g. command line
+        if UserInfo.current_user_id
+          Pundit.authorize(UserInfo.current_user, attachment, :show?)
+        end
+
         @attachments_inline.push attachment(attachment.content, attachment.filename, cid, mime_type: attachment.preferences['Mime-Type'], content_type: attachment.preferences['Content-Type'])
         node['src'] = "cid:#{cid}"
       end

Source: GitHub commit f3e4da8 — the patch inserts a Pundit.authorize call that enforces the show? policy on the referenced attachment before the copy proceeds.

Detection Methods for CVE-2026-63205

Indicators of Compromise

  • Signature records created or updated by channel-admin accounts containing inline <img> tags referencing attachment IDs they did not previously author.
  • Unexpected growth in signature-owned entries within the Store attachment table shortly after signature edits.
  • Attachment downloads from the signature endpoint for files whose original source objects belong to restricted groups.

Detection Strategies

  • Audit the Zammad Store table for signature-owned attachments whose filename or content hash matches ticket or knowledge-base attachments outside the signature author's group membership.
  • Review Rails application logs for signature update requests from channel-admin users that reference attachment IDs via cid: src attributes.
  • Compare signature creation timestamps against sensitive-ticket attachment IDs to identify enumeration patterns.

Monitoring Recommendations

  • Alert on repeated signature save operations originating from the same channel-admin user within short time windows.
  • Monitor administrative permission grants for admin.channel_email, admin.channel_google, admin.channel_microsoft365, and admin.channel_microsoft_graph roles.
  • Track outbound downloads from signature attachment URLs and correlate against the acting user's group permissions.

How to Mitigate CVE-2026-63205

Immediate Actions Required

  • Upgrade Zammad to version 7.1.2 or later, which enforces Pundit authorization on referenced attachments.
  • Review all channel-admin role assignments and revoke permissions that are not strictly required for operations.
  • Inspect existing signatures for inline image references that may contain exfiltrated attachment content and remove them.

Patch Information

The fix is delivered in Zammad 7.1.2. Technical details are available in the Zammad GitHub Security Advisory GHSA-pp8r-x7pp-5qj5 and the corresponding patch commit.

Workarounds

  • Restrict the four channel-admin permissions to trusted operators only until the upgrade is applied.
  • Temporarily disable the ability for delegated admins to edit email signatures through role configuration adjustments.
  • Monitor and manually review signature content for suspicious inline image tags referencing arbitrary attachment IDs.
bash
# Verify installed Zammad version and upgrade
zammad run rails r 'puts Version.get'
# Target version: 7.1.2 or later
# Follow https://docs.zammad.org/en/latest/appendix/upgrading.html for the supported upgrade path

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.