We actively support the following versions of Zammad MCP Server with security updates:

Note: We recommend always using the latest stable release for production environments.

We take security vulnerabilities seriously. If you discover a security issue, please follow these steps:

Do NOT create a public GitHub issue for security vulnerabilities.

Instead, please use one of these methods:

• GitHub Security Advisories (Preferred): Report a vulnerability via GitHub's private vulnerability reporting
• Email: For urgent security matters, contact repository maintainers directly
• Encrypted Email: For sensitive reports, use GPG encryption (key available on request)

When reporting a vulnerability, please provide:

• Vulnerability Type: (e.g., SSRF, XSS, SQL Injection, Authentication Bypass)
• Affected Components: Full paths of source files and functions
• Description: Clear explanation of the vulnerability
• Steps to Reproduce:
  1. Detailed step-by-step instructions
  2. Include code samples or scripts if applicable
  3. Expected vs actual behavior
• Impact Assessment:
  • Severity (Critical/High/Medium/Low)
  • Potential attack scenarios
  • Affected users or data
• Proof of Concept: Include PoC code if available
• Suggested Fix: Your recommended mitigation (optional)
• Contact Information: For coordinated disclosure

We commit to the following response times:

• Initial Response: Within 48 hours of report (acknowledgment)
• Initial Assessment: Within 7 days (severity determination)
• Fix Development Timeline:
  • Critical (CVSS 9.0-10.0): Within 14 days
  • High (CVSS 7.0-8.9): Within 30 days
  • Medium (CVSS 4.0-6.9): Within 60 days
  • Low (CVSS 0.1-3.9): Within 90 days
• Patch Release: Within 24 hours of fix completion (best-effort)
• Disclosure:
  • Coordinated disclosure with reporter
  • Default: 90 days from initial report
  • May be expedited for actively exploited vulnerabilities

• Use API tokens instead of username/password when possible
• Store tokens securely using environment variables or secure credential storage
• Rotate tokens regularly (recommended: every 90 days)
• Limit token scope to minimum required permissions
• Never commit tokens to version control

# ✅ Good: Use environment variables
export ZAMMAD_HTTP_TOKEN="your-token-here"

# ❌ Bad: Hard-coded in configuration files
ZAMMAD_HTTP_TOKEN=abc123token

{
  "mcpServers": {
    "zammad": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/basher83/zammad-mcp.git", "mcp-zammad"],
      "env": {
        "ZAMMAD_URL": "https://your-instance.zammad.com/api/v1",
        "ZAMMAD_HTTP_TOKEN": "your-api-token"
      }
    }
  }
}

Security Notes:

• Ensure Claude Desktop configuration files have restricted permissions
• Use different tokens for different environments (dev/staging/prod)
• Monitor token usage in Zammad's admin interface

• Use HTTPS in production - the client permits http:// for development and trusted internal environments
• Keep TLS verification enabled - ZAMMAD_INSECURE=true disables TLS certificate verification for the upstream Zammad connection. The client verifies TLS certificates by default. Set ZAMMAD_INSECURE only for trusted self-signed or internal certificate chains.
• Protect the HTTP transport listener - the server has no inbound MCP client authentication. ZAMMAD_* credentials authenticate the server to Zammad only. MCP_HOST defaults to 127.0.0.1. Keep that default, or put the listener behind an authenticated reverse proxy. See the HTTP Transport Deployment Guide.
• Network isolation - run in isolated environments when possible
• Firewall rules - restrict outbound connections to necessary endpoints only

• Input validation - validate all user inputs and API responses
• Error handling - don't expose sensitive information in error messages
• Logging - sanitize logs to prevent credential leakage
• Dependencies - keep dependencies updated and scan for vulnerabilities

# ✅ Good: Sanitized logging
logger.info(f"Request to {url.split('?')[0]}")  # Remove query parameters

# ❌ Bad: Exposing credentials
logger.debug(f"Full request: {url}")  # May contain tokens in URL

• Test with minimal permissions
• Use separate test instances
• Never use production credentials in tests
• Implement security tests in CI/CD pipeline

• Data minimization - only access necessary ticket/user data
• Temporary storage - avoid storing customer data locally
• Memory management - clear sensitive data from memory when possible
• Compliance - follow GDPR, CCPA, and other applicable regulations

# ✅ Good: Clear sensitive data
response_data = api_call()
process_data(response_data)
del response_data  # Clear from memory

# ✅ Good: Limit data exposure
filtered_data = {k: v for k, v in data.items()
                if k not in ['password', 'token', 'secret']}

The server can emit an opt-in audit trail (ZAMMAD_AUDIT_LOG_ENABLED=true) as JSON Lines to stderr, a file, or syslog. It records tool-call outcomes, connection outcomes, and URL security checks for forensic review. It is an operator-controlled aid, not a compliance certification:

• Records contain no tool arguments, Zammad responses, credentials, or full URLs; failures are logged by exception type only, and sensitive-looking details keys are redacted.
• Records are written locally only. Retention, rotation, and access control for file and syslog destinations are the operator's responsibility; treat the audit file as sensitive metadata.
• Audit output never uses stdout, so it cannot corrupt the stdio transport.

• Keep Zammad updated to the latest version
• Use strong authentication methods
• Enable audit logging
• Configure proper user permissions
• Regular security audits

• Create dedicated tokens for MCP integration
• Use descriptive token names (e.g., "MCP-Server-Production")
• Regularly review and rotate tokens
• Monitor token usage in Zammad logs
• Revoke unused or compromised tokens immediately

Recommended minimum permissions for MCP tokens:

• ticket.agent - For ticket operations
• user.agent - For user lookups (if needed)
• organization.agent - For organization data (if needed)
• knowledge_base.reader - Only for the Knowledge Base tools and resources (if needed). It grants read access to internal (unpublished) answers, not only public ones. Restrict the token's role per category in the Knowledge Base permissions so it reads only the categories it needs.
• admin.tag - Only for zammad_list_tags, which lists every tag in the system (if needed). It is an admin permission: it also grants Manage > Tags, where the token can add and delete tags and change whether agents may create tags. Grant it only when the tag listing is required.

The Zammad permissions reference describes each permission.

Avoid granting admin permissions unless absolutely necessary.

1. Immediate Actions

   • Revoke potentially compromised API tokens
   • Change any exposed credentials
   • Check Zammad audit logs for suspicious activity

2. Assessment

   • Determine scope of potential exposure
   • Identify affected systems and data
   • Document timeline of events

3. Notification

   • Report to this project's maintainers
   • Notify your organization's security team
   • Consider customer notification if data was exposed

4. Recovery

   • Implement security fixes
   • Update credentials and tokens
   • Monitor for continued suspicious activity

This project employs multiple layers of security scanning:

• ✅ Bandit: Identifies common security issues in Python code (active in CI)
• CodeQL: GitHub code scanning setting. The repository contains no CodeQL workflow, so the repository security settings show its current state.
• Codacy: Not a CI scan. The tests workflow uploads coverage to Codacy only if you configure CODACY_PROJECT_TOKEN. PR #369 removed the no-op Codacy SARIF workflow.
• ✅ Semgrep: Pattern-based vulnerability detection (active in pre-commit and local quality checks)

• ✅ Dependabot: Security alerts; automated version-update pull requests are disabled in repository configuration
• ✅ pip-audit: Python package vulnerability detection (active in CI)
• ✅ Renovate: Automated dependency management governed by the shared preset

Safety was removed because it introduced NLTK with an unpatched vulnerability (GHSA-8mgp-746c-j5xp). The blocking pip-audit scan covers the installed application and development dependencies locally and in CI, without advisory exclusions.

• ⏳ Trivy: Container image vulnerability scanning (integration pending)
• ⏳ Docker Scout: Supply chain security analysis (integration pending)
• ⏳ Hadolint: Dockerfile best practices (integration pending)

# Run all security checks
./scripts/quality-check.sh

# Individual security scans
uv run pip-audit               # Check for vulnerable packages
uv run bandit -r mcp_zammad    # Static security analysis
prek run semgrep --all-files   # Pattern-based scanning

# Docker image scanning
docker scout cves ghcr.io/basher83/zammad-mcp:latest

The security scanning workflow (security-scan.yml) needs no repository secrets beyond GITHUB_TOKEN:

• GITHUB_TOKEN: Automatically provided by GitHub Actions
• CODACY_PROJECT_TOKEN: Optional. It only enables the coverage upload step in the tests workflow (tests.yml). The security scanning workflow does not use it.
  • Available from your Codacy project settings

The repository includes automated security scanning that runs on:

• Every push to main branch
• All pull requests
• Weekly scheduled scans (Mondays at 09:00 UTC)
• Manual workflow dispatch

Install pre-commit hooks for local security checks:

# Install hooks
mise run hooks-install

# Run manually
mise run pre-commit-run

The hook definitions live in .pre-commit-config.yaml. The security-relevant hook ids are bandit, semgrep, and pip-audit. mise run hooks-install also installs the Infisical secret-scan hook.

Installed hooks run on commits made through Git normally. They can be bypassed explicitly, so CI and branch protection remain the authoritative enforcement boundary.

For qualifying vulnerabilities, we will:

1. Request CVE assignment through GitHub Security Advisories
2. Coordinate with reporter on CVE details
3. Include CVE in release notes and advisories
4. Update this document with CVE references

We use CVSS v3.1 for vulnerability scoring:

• Critical (9.0-10.0): Remote code execution, authentication bypass
• High (7.0-8.9): Privilege escalation, data exposure
• Medium (4.0-6.9): Cross-site scripting, denial of service
• Low (0.1-3.9): Information disclosure, minor issues

For security-related questions or concerns:

• Security Issues: Report via GitHub Security Advisories
• General Security Questions: Create a GitHub Discussion
• Urgent Security Matters: Contact repository maintainers directly

We appreciate security researchers and users who help keep this project secure. Responsible disclosure helps protect all users of the Zammad MCP Server.

Security researchers who have helped improve our security will be acknowledged here (with their permission).

While we don't currently offer monetary rewards, we provide:

• Public acknowledgment (with permission)
• CVE credit for qualifying vulnerabilities
• Contribution recognition in release notes

This security policy may be updated periodically. Major changes will be announced through:

• GitHub Releases
• Repository announcements
• Security advisories (if applicable)

Last Updated: 2026-09-30 Version: 1.2.0

Changelog:

• v1.2.0 (2026-09-30): Fixed CI scanner and secret descriptions, added HTTP listener and TLS verification guidance, replaced the pre-commit excerpt with a link
• v1.1.0 (2025-08-11): Enhanced vulnerability reporting, added CVE process, expanded security tools documentation
• v1.0.0 (2025-07-08): Initial security policy