Zammad security: helpdesk risk checks

Zammad is open-source helpdesk software that teams use to manage customer service and internal IT support requests. It keeps each request in a ticket, with its conversation history, assigned staff and progress in one place. Businesses can use a hosted service or run the software themselves.

This Zammad security guide is for business owners, support managers and technical providers whose organisation uses the software or connects other systems to it. If you do not know what runs your support portal, ask its administrator or supplier before treating this case as relevant to your installation. If you use another helpdesk, the access and recovery examples may still help you review its connections, but the reported Zammad vulnerabilities do not establish a problem in your product.

The business concern is what a helpdesk can access and what stops working if it becomes unavailable. Tickets can contain customer information, while connected accounts may read or change records in other systems. A version check therefore needs to sit alongside a review of those permissions and a plan for continuing support.

The Dutch Institute for Vulnerability Disclosure, known as DIVD, researches and reports security flaws. Its reported breach provides the case discussed below. Its record still contains conflicting remediation statements, so this guide does not provide a definitive fixed-version recommendation. Use it to identify the connections your helpdesk needs, plan how urgent requests will be handled during disruption and agree what evidence is required before normal operation resumes. The responsible operator must obtain current advice for the exact installation.

What DIVD reported about Zammad

DIVD's case record places its breach on 21 September 2026. It notified the vendor on 24 September and records limited disclosure and owner notification on 26 September. The case was last modified on 1 October. These dates distinguish the intrusion from the later public follow-up. DIVD case DIVD-2026-00015.

DIVD identifies a session-hijacking issue leading to code execution and a local privilege-escalation issue. Its recommendation to move to version 7 or take an instance offline sits alongside a patch status of available and text saying a fix is being developed. That does not establish that every version 7 deployment resolves both issues. Ask the responsible operator to reconcile current guidance with the exact deployed build. DIVD's case details.

This account does not establish that another Zammad customer has been compromised. The review below is practical planning guidance. During a suspected incident, the appointed security and technical owners should direct investigation, containment and recovery. Ordinary users should not run investigation scripts, remove logs or reinstall the service to see whether that resolves the problem.

Establish who operates each part of the service

Start by distinguishing the application owner from the people who maintain it. The support manager may decide how tickets are assigned but have no authority to change server access. A developer may maintain the connection to your customer relationship management system, or CRM, without managing Zammad itself. An external provider may host the system while another supplier handles backups.

For a hosted service, ask the provider to confirm the scope it operates, its current advice and the evidence it can supply. Then identify what your business still configures, including user access, connected accounts, ticket fields and notification settings. Do not assume the hosting contract covers a custom integration that another supplier built.

For a self-managed installation, name the people responsible for the application, operating environment, network access, backups and recovery. A rented server does not tell you who has accepted each of those duties. Obtain a written division of responsibility, including who covers absence and who can approve emergency changes.

Record the deployed build and its evidence date through the operator. Keep it beside the installation identifier and hosting arrangement so advice for one instance is not accidentally applied to another.

A fictional support workflow to review

The example throughout this guide is fictional. It does not describe DIVD's systems or a client engagement.

A small equipment maintenance business accepts service requests through its website. Each request creates a helpdesk ticket. A CRM connector looks up the customer's reference and service entitlement. Support staff then create a job in a separate scheduling application. The operations manager owns customer service, a hosting provider maintains the ticketing application and a developer maintains the connections.

The business needs to keep receiving urgent service requests if the helpdesk is unavailable. It does not need every historical attachment or automated job update to continue that limited operation. Making that distinction lets the team plan a fallback without trying to reproduce the entire helpdesk during an incident.

Map the data and actions behind one ticket

Follow a request through the real workflow with someone who performs the work. Note what the customer submits, what each connection adds and what happens after a member of staff approves an action. Include failed requests and repeated attempts, not only the route shown in a product demonstration.

For each connection, record its source, destination, information, permitted actions and owner. Also identify where credentials are held and who can disable or replace them through the approved process. Record a secure location reference, never the secret itself.

The distinction between information and authority matters. A connector that reads a customer reference might only need access to selected CRM fields. A connector able to edit every customer record or change service entitlements has a different effect if someone misuses it. The technical owner must inspect the configured permissions rather than infer them from the connector's name.

In the fictional business, the team completes this review:

These findings lead to different actions. The first is a permission change to test. The second requires an operating workaround while the design changes. The third needs application behaviour to change. The last belongs to the business owner rather than the developer.

The operations manager gives the CRM connector first priority because its write access can change the authoritative customer record. The developer owns the correction, and the CRM administrator confirms the replacement account's permissions. Staff can perform the required lookup manually, so restoring that connector is not a condition for receiving urgent requests. The scheduler retry defect comes next because it can dispatch duplicate work. The support lead must approve the corrected behaviour before automatic job creation resumes.

Use the same distinction in your review. A list saying "reduce access" is not enough for someone to implement. State which operation the workflow needs, what unnecessary operation must stop and how the team will verify both.

If nobody can explain what a custom connector is allowed to change, include that investigation in the scope of a business system development review. The useful output is a documented permission and failure-handling design that a developer can implement and your team can test.

Decide what stays available when a connection is stopped

A decision to isolate the helpdesk should include the consequences for connected services. Ask the technical owner whether the website queues failed requests, shows an error or reports success without creating a ticket. Ask what happens to pending scheduler jobs when the connector is disabled. Those behaviours determine what staff must check manually.

In the fictional example, the operations manager chooses to suspend automatic ticket and job creation while the technical team investigates. Staff can still use their separately authorised CRM accounts. A pre-agreed fallback telephone route and restricted request register remain available independently of the helpdesk. The team checks that those arrangements do not depend on the same unavailable login or hosting service.

That is a proposed design choice for the example, not an instruction to disable your systems. Your responsible owners need to assess the actual incident, preserve required evidence and decide what can safely continue. Avoid changing permissions or reconnecting services simply to remove an error message while those questions remain open.

For supplier responsibilities or missing assurance evidence, use the ICT supplier risk guide. Keep the application-specific decisions in the helpdesk's operating record so the support team can find them without reading a full supplier review.

Write the fallback procedure staff will actually follow

Define which requests the reduced service will accept and which must wait. The fictional maintenance business accepts urgent service requests through its approved fallback route. It defers routine attachment uploads and automatic scheduling until the relevant connections pass their return checks.

The operations manager prepares the following procedure before any disruption:

1. Confirm that the authorised decision-maker has activated the fallback and record the start time. Staff use the approved customer message and contact route, rather than inventing separate instructions.
2. Give every request a temporary reference. Record when it arrived, a contact route, a brief description, the assigned owner and its current status. Collect only what is needed for the reduced service.
3. Put the request in the restricted register. Do not ask customers to supply passwords, recovery codes or unnecessary confidential attachments. Direct exceptional information needs to the authorised owner.
4. Have the support lead review the register at the interval agreed for the service. Assign unowned requests and check whether urgent work needs escalation. Record the next promised action so another member of staff can take over.
5. Record any work completed outside the helpdesk, including the scheduler's job reference. This record will be needed to avoid duplicate work after recovery.

For a completed example, the fictional support lead records request FALLBACK-014 about a stopped piece of equipment. The register contains its arrival time, an approved customer contact, the reported symptom and the assigned coordinator. The coordinator uses their approved CRM account to check entitlement and creates scheduler job JOB-208 after the usual approval. They record that job reference and its status against FALLBACK-014. Another member of staff can now see that the request already has scheduled work, even though no helpdesk ticket was created.

The procedure needs an owner and a deputy. Both should know where it is stored and how to obtain access when the normal ticketing account is unavailable. The business continuity plan template provides a place to record the activation authority, contact arrangements and exercise results.

Do not promise a response time in the fallback message unless the team can support it. The message should explain the current support route and any necessary limitation without making an unverified claim about the cause or scope of an incident.

Reconcile the work before restarting automation

Restoring the application does not settle what happened to requests while it was unavailable. Some may have reached the helpdesk before isolation. Others may exist only in the fallback register. A scheduler may have created a job even though its confirmation never returned to the helpdesk.

In the example, the support lead reviews each temporary reference against the recovered ticket list and scheduler records. If a matching ticket exists, the lead adds the missing fallback history to that record through the approved process. If there is no ticket, the lead creates one and records the relationship between its new identifier and the temporary reference. A job already completed must not be created again merely because the recovered ticket shows an old status.

For FALLBACK-014, the support lead finds no existing helpdesk ticket but confirms JOB-208 in the scheduler. They create a ticket through the approved process, attach the fallback history and record both references. They mark scheduling as already completed and prevent the restored connector from treating the ticket as a new job request. If the application cannot represent that state, the developer must provide a controlled import or manual route before this record enters automated processing.

Record the outcome for each request: matched to an existing record, created as a new record, or held for investigation. Assign unresolved matches to a person. Reconcile those categories against the fallback register so no request disappears between lists.

The developer and support lead also review queued events and retries. Do not replay the whole queue on the assumption that every event failed. Establish whether each action happened and which replay behaviour the integration supports. Keep automation paused where the team cannot distinguish a missing action from an already completed one.

Retain the fallback record under your organisation's information-handling arrangements. A completed transfer does not itself decide when the temporary records should be deleted or who may continue to access them.

Test the expected result, including failed requests

Use synthetic records in an agreed non-production environment. The application owner should approve the scenarios, while the developer or operator records the technical evidence. Disable real notifications and external actions so the exercise cannot contact customers or alter their records.

A test needs an expected result. For the fictional workflow, the team uses these acceptance cases:

If a test fails, record the observed behaviour, the consequence and the owner of the correction. For example, a duplicate job is a reason to keep automatic replay disabled while the integration changes. It is not resolved by telling staff to watch for duplicates without agreeing who will check and how.

Keep the limitations of the test visible. A controlled exercise demonstrates the workflow under those conditions. It does not prove that an installation was never compromised or that every production failure has been covered.

Agree the conditions for returning to service

After a suspected compromise, the responsible security and technical owners must decide what investigation, remediation and recovery evidence is required. A clean indicator check alone cannot establish that there was no intrusion. The business owner needs a clear account of what the team has verified, what remains unknown and which restrictions still apply.

For the fictional business, the return decision would require the following evidence:

• The operator has recorded the current installation and remediation position, with the technical and security owners' assessment of any unresolved exposure.
• The developer has checked the intended account permissions and completed the agreed handling of affected credentials. The business has not copied unverified account settings back from an old configuration.
• The workflow tests pass, or the owner has explicitly accepted a restricted service that keeps the failing connection disabled.
• Staff have reconciled the fallback requests and identified the queued actions that can resume without duplicating work.
• The support lead and deputy know how to stop the restored connection and return to the fallback if the agreed stop condition occurs.

These are proposed approval requirements for this example, not a claim that DIVD has met them or a universal incident-recovery procedure.

Restore connections in an order that lets the team observe their effects. In the example, the support lead first checks ticket intake, then the permitted CRM lookup, then an approved scheduler action. The developer watches for the failure conditions identified in testing. The operations manager approves wider use only when the recorded results support it.

Questions business owners ask about helpdesk security

Does a hosted helpdesk remove our responsibility for integrations?

Confirm the provider's actual scope. A hosting provider may operate the application while your business or another developer controls user permissions, customer data and connected accounts. Obtain an explicit owner for each part. Include custom website and CRM connections rather than assuming the hosting agreement covers them.

Can we keep receiving support requests while the helpdesk is isolated?

Plan an approved fallback that does not depend on the unavailable service. It needs a request reference, an owner, access controls and a way to record completed work. Decide what reduced service the team can provide, and reconcile those records before normal automation resumes. Do not route confidential requests into an unapproved public channel.

Is upgrading to Zammad version 7 enough to close this case?

The DIVD record reviewed for this guide contains conflicting remediation statements. It does not establish that every version 7 installation resolves both issues. Obtain current advice for your exact build from the responsible operator or supplier, and keep the investigation decision separate from confirmation that an upgrade completed.

What should a developer hand over after changing a helpdesk integration?

Request a current connection map, the intended permissions, configuration ownership, failed-request behaviour and the results of agreed acceptance tests. Include instructions for stopping and restoring the connection, with references to secure credential storage. Your support team also needs to understand how to recognise an incomplete request and who resolves it.

Bring a specific workflow to the development discussion

If your helpdesk connects a website, CRM or scheduling tool, prepare a simple connection map and one example of a request that passes through it. Identify which actions are automatic, where staff approve them and what happens when a connection fails. Keep real customer details and credentials out of the initial example.

Use the business system development service to discuss the changes that need design or implementation. A useful initial scope identifies the connection to change, the permissions it needs, the fallback behaviour and the tests that will demonstrate the result. Bring unresolved hosting responsibilities too, so development work does not assume another provider has already dealt with them.

Contact Daniel to discuss the integration with a brief description of the workflow and the finding you want to resolve. Share redacted examples initially; agree a suitable way to provide detailed configuration or logs if the work requires them.