Zammad CVE-2026-56729

Requires an authenticated user holding the knowledge_base.editor permission in at least one KB category, AND a deployment where multiple knowledge base categories exist with DIFFERENT editor roles assigned (granular per-category permissions). Exploitation is via the global quick search feature. Limiting factors: the leak is confined to answer titles and updated_at timestamps - category names are not exposed and opening an answer returns 'Page not found,' so no body content is accessible; single-category or uniform-permission KB setups are not affected. Fixed in Zammad 7.0.2 by removing the editor-role search bypass.

This is a low-priority, high-context issue rather than a genuine threat. The vendor CVSS 4.0 score of 2.1 (AV:N/AC:L/AT:P/PR:H/UI:N/VC:L) already signals minimal impact: confidentiality-only (VC:L), no integrity or availability effect, and the AT:P attack requirement reflects a non-default precondition (multiple KB categories with distinct editor roles). PR:H per the vendor implies elevated privilege, though in practice exploitation needs the knowledge_base.editor role, which is a granted moderate privilege rather than a full admin - I assess PR:L as more accurate. No EPSS score, KEV listing, or public POC is present in the input; per precision rules this is 'no public exploit identified at time of analysis.' The disclosed data is strictly limited - answer titles and updated_at timestamps from categories the user cannot edit, with category names withheld and answer bodies returning 'Page not found.' No signals conflict here; all sources (vendor advisory, commit evidence, low CVSS) consistently point to a minor granular-permission leak. Real-world priority is low: fix on normal patch cadence.

In a Zammad instance where the knowledge base has multiple categories with different editor roles assigned, a user granted knowledge_base.editor in only Category A uses the global quick search and receives matching answer titles and last-updated timestamps from Category B, which they have no editor access to. No public exploit code is identified; the leak is passive and surfaces only fragmentary metadata (titles/timestamps), not full article content.