CVE Vulnerability Catalog

In Zammad versions 7.0.2 and 7.1.0, session management for websocket and long-polling connections is susceptible to a path traversal attack. Session identifiers supplied by the client are insufficiently validated before being used to construct internal file paths. When the file-based session store is active (the default configuration), an authenticated attacker can manipulate the session identifier to reference locations outside the intended storage directory, leading to the deletion of arbitrary files and directories on the server. Exploitation requires only a low-privilege authenticated session and a single crafted request. Instances configured to use the Redis-based session store are not affected. This issue is fixed in versions 7.0.3 and 7.1.1.

In Zammad prior to versions 7.0.2 and 7.1.0, there is a lack of validation within the authorization cascade. Under specific conditions, the granular restrictions of the access key are overridden by the latent authorization authority of the parent account, nullifying the intended separation of functional areas and resulting in uncontrolled expansion of administrative discretion. An attacker can create new administrator accounts despite token restrictions, gaining full access to all system data (tickets, customers, configuration) and complete control of the Zammad instance. This issue is fixed in versions 7.0.2 and 7.1.0.

In Zammad prior to version 7.0.1, a low-privilege authenticated user may inject arbitrary HTML markup, including JavaScript event handlers, into a ticket title via the standard ticket creation workflow. The title is persisted without sanitization. This issue is fixed in version 7.0.1.

In Zammad prior to version 7.0.2, in inbound PGP email processing, the return value of the gpg verification call was silently discarded. Regardless of whether gpg reported a valid, invalid, or missing signature, the handler unconditionally wrote sign: { success: true, comment: "Good signature" } to the article's security preferences. Any sender could tamper with the body of a multipart/signed PGP email, or craft a message with an entirely fabricated or mismatched signature, and Zammad would display it to the recipient as cryptographically verified with a "Good signature" label. Users and agents relying on Zammad's signature indicator to confirm message authenticity and integrity would be misled into trusting modified or forged content. The vulnerability affects all inbound PGP-signed emails processed while the PGP integration is enabled. This issue is fixed in version 7.0.2.

In Zammad prior to version 7.0.2, an unauthenticated request to POST /api/v1/import/otrs/import_check blocks a Zammad request worker for roughly two minutes. The import_check and import_status actions are missing the setup_done_response guard that other actions in the same controller carry, so they execute on fully set-up production instances. The action enters a retry loop against a blank OTRS endpoint, sleeping for 30 s + 45 s between attempts. An unauthenticated remote attacker denies service to a production Zammad instance. Each request costs almost nothing and forces ~115 seconds of server-side blocking. A few requests per second saturate the Puma worker pool. This issue is fixed in version 7.0.2.

Vulnerability in StarTraining up to 3.8.1 in the anonymous function of /druid/index.html of the Druid Console component. Missing authentication allows remote attack. Exploit is publicly available.

Vulnerability in StarTraining up to 3.8.1 in the UserLoginService.createToken function of application.yml in the JWT Token Handler component. Manipulation of user_id/company_id causes use of hard-coded password. Remote attack, public exploit.

Vulnerability in Zhonglun CloudPos up to 3.0.1.76 in the OpenLocalBrowser function of ZlPos/ZlPos/Bizlogic/JSBridge.cs in the JSBridge component. Manipulation of the url argument leads to code injection. Remote attack, public exploit.

A vulnerability in golang.org/x/playground allows a malicious txtar file to escape the intended execution context and force arbitrary writes to the playground host's trusted filesystem. Additionally, one of the paths to invoke 'go vet' did not correctly restrict the execution environment, allowing a read of an environment configuration file from the host's $HOME. Together, these can lead to remote code execution on the playground host.

Vulnerability in NetworkManager-iodine, the iodine VPN plugin for NetworkManager. An unprivileged local user can exploit the processing of the 'nameserver' setting when establishing an iodine VPN connection. Embedding shell metacharacters in the 'nameserver' value allows arbitrary command injection and execution with root privileges before dropping elevated permissions.

Vulnerability in BerriAI LiteLLM before 1.101.0-rc.1, allowing tenant isolation bypass in the semantic cache layer. Authenticated users can read other tenants' cached responses by exploiting a metadata key mismatch between _get_semantic_cache_tenant_scope() and _get_metadata_variable_name(). Attackers with a valid virtual key can submit semantically similar prompts to retrieve cached responses containing other tenants' PII, financial data, or source code, and can cause agentic front-ends to auto-execute attacker-supplied tool calls under victim credentials.

Federation upstream in RabbitMQ skips vhost authorization, allowing cross-vhost message access. A policymaker on one vhost can read and drain messages from another vhost it has no permission on, and with the default ack-mode the source messages are consumed rather than copied.

Native MQTT and MQTT over WebSocket behind a trusted PROXY Protocol frontend in RabbitMQ can lose the proxy-derived client address before the MQTT authentication path checks loopback_users, causing the frontend-to-broker address to be treated as loopback. An attacker with valid credentials for a loopback-restricted account can bypass the source-address restriction.

Vulnerability in RabbitMQ from 4.2.0 until 4.3.3 and 4.2.9, exposing the OAuth2 client secret via an unauthenticated JavaScript endpoint. When OAuth2 authentication is enabled for the RabbitMQ Management UI with a client secret, the oauthclientsecret value is included in JavaScript served by the unauthenticated endpoint /js/oidc-oauth/bootstrap.js. Any user who can reach the management UI port can retrieve the OAuth2 client secret.

Incomplete fix for CVE-2026-44838 in RabbitMQ: escaperegexchar/1 does not escape the - character, allowing an MQTT topic permission bypass. When a topic permission template places {clientid} inside a [...] character class, a low-privileged authenticated MQTT user can broaden topic authorization.

The Web STOMP WebSocket handler in RabbitMQ enforces neither max_frame_size nor login_timeout before authentication, allowing an unauthenticated client to keep a connection alive with a slow stream of small frames and accumulate unbounded pre-authentication state. The rabbitmq_web_stomp plugin must be enabled.

RabbitMQ versions from 3.13.0 until 3.13.15, 4.0.20, 4.1.11, and 4.2.6 have a vulnerability in the stream protocol where the FrameMax value negotiated during the Tune handshake is stored but not compared with an inbound frame's declared length before buffering. A remote client can cause excessive memory pressure and denial of service by declaring an oversized frame.

RabbitMQ versions in the 3.13, 4.0, 4.1, 4.2, and 4.3 lines have a vulnerability where fill/2 substitutes ${username} into user_dn_pattern without RFC 4514 DN escaping, allowing a crafted username to alter the LDAP bind DN. Exploitation requires rabbitmq_auth_backend_ldap with a user_dn_pattern containing ${username}, a suitable directory layout, and a valid password. Fixed versions are conflicting across sources.

Zammad before version 7.0.2 has an issue with permission checks in the knowledge base management area. Under certain conditions, data validation for linked items was not fully enforced, potentially allowing users with limited read permissions to interact with items outside their assigned access scope.

Zammad before version 7.0.2 allows a customer who can view a ticket to not see internal ticket articles through the article listing API, but the same customer can directly request an attachment belonging to an internal article via the attachment download endpoint, bypassing article-level authorization. The attachment download only checks the parent ticket, not the article, so the same customer can download the attachment directly.