| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3, native MQTT and MQTT over WebSocket behind a trusted PROXY Protocol frontend could lose the proxy-derived client address before the MQTT authentication path checked loopback_users, causing the frontend-to-broker address to be treated as loopback. An attacker who can reach the trusted frontend and has valid credentials for a loopback-restricted account can therefore bypass the source-address restriction; the issue does not bypass password authentication. This issue is fixed in versions 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3. |
| Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, a customer who can view a ticket cannot see internal ticket articles through the article listing API. However, the same customer can directly request an attachment belonging to an internal article via the attachment download endpoint, bypassing article-level authorization. This results in an inconsistency: The article listing hides internal articles from customers. The attachment download only checks the parent ticket, not the article, so the same customer can download the attachment directly. This issue is fixed in version 7.0.2. |
| Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2 and 7.1.0, this issue concerns a lack of discursive validation within the authorization cascade. It has been determined that the system-level enforcement of access restrictions during the initialization of new identity objects exhibits a discrepancy: Under specific conditions, the granular restrictions of the access key being used are overridden by the latent authorization authority of the parent account. Consequently, this means that the intended separation of functional areas is nullified, resulting in an uncontrolled expansion of administrative discretion. Due to this potential integrity breach of the entire trust environment, an immediate evaluation of the authorization hierarchies is imperative. Impact An attacker can create new administrator accounts despite token restrictions. This grants full access to all system data (tickets, customers, configuration) and allows the attacker to take complete control of the Zammad instance. Abuse Scenario The vulnerability stems from a lack of synergy between the token-based authorization logic and the target system's functional authorization hierarchy, which allows for iterative escalation of the privileged access context. This issue is fixed in versions 7.0.2 and 7.1.0. |
| Zammad is a web based open source helpdesk/customer support system. Prior to 7.1.2, zammad's External Data Source feature, used to look up records from an external system, did not properly verify whether a user was allowed to see a specific ticket, user, group, or organization before including its details in a request to that external system. An authenticated user, including one with only basic customer access, could exploit this by referencing another record's ID, and thereby view details of tickets, customer accounts, teams, or organizations that did not belong to them. This issue is fixed in version 7.1.2. |
| InvoicePlane is a self-hosted open source application for managing invoices, clients, and payments. Prior to 1.7.2, InvoicePlane fails to revoke administrative privileges after a role downgrade because Admin_Controller trusts the user_type snapshot stored in an existing session instead of revalidating ip_users.user_type. When one administrator downgrades another account, the target's active session continues to authorize administrative requests. The downgraded user can use Users::form() to set user_type back to 1, restoring the database role and making the privilege escalation persistent. This vulnerability is fixed in 1.7.2. |
| Actual is a local-first personal finance tool. Prior to 26.7.0, Actual Sync Server's CORS proxy is intended to let authenticated users fetch resources only from repositories listed in the official plugin allowlist. When `ACTUAL_GITHUB_TOKEN` is configured, the proxy automatically attaches the server's GitHub token to GitHub requests. The GitHub API allowlist check uses a raw `startsWith()` prefix test for `/repos/{owner}/{repo}` without requiring a path boundary after the repository name. If an allowlisted public plugin repository is `https://github.com/acme/plugin`, the proxy also accepts GitHub API URLs. Those URLs are outside the allowlisted repository but still pass because their API path starts with `/repos/acme/plugin`. The proxy then forwards the request with the server's `ACTUAL_GITHUB_TOKEN`, allowing any authenticated Actual user to read private GitHub resources reachable by that token. Version 26.7.0 fixes the issue. |
| OpenClaw before 2026.7.1 contains an authorization bypass vulnerability in the /voice set command that allows non-owner external-channel senders to persist Gateway voice configuration. Attackers with command access can change the voice used by Talk responses for the configured provider, affecting configuration integrity without exposing credentials or granting additional host capabilities. |
| OpenClaw versions before 2026.7.1 contain a sandbox bypass vulnerability in the browser tool that allows sandboxed sessions to access paired node browser actions despite allowHostControl=false configuration. Attackers with control over sandboxed agent input can select a paired node and perform host browser operations, inspecting or manipulating the connected browser profile and its authenticated state. |
| OpenClaw (npm package 'openclaw') before 2026.7.1 does not enforce the administrator scope requirement on browser control when it is reached through the node.invoke method, although direct browser.request access requires administrator scope. In Gateway deployments that honor caller identity and narrower operator scopes, a write-scoped caller with access to a connected browser-capable node can inspect pages, navigate tabs, or interact with browser-visible applications without the configured admin requirement; practical impact depends on the browser profile and signed-in state. Shared-secret token and password callers are considered fully trusted operators under OpenClaw's security model and are not affected. The issue is fixed in 2026.7.1. |
| OpenClaw versions before 2026.8.1 contain an authorization bypass vulnerability in the sessions.create endpoint that allows operator.write callers to modify session configurations reserved for operator.admin scope. Attackers with write-scoped credentials can change existing session model, provider, thinking level, and auth-profile settings to redirect traffic and bypass administrative access controls. |
| OpenClaw versions before 2026.8.1 contain an authorization bypass vulnerability where Allow Always approvals for exact commands persist as path-only grants on macOS and Linux. Attackers can reuse the same executable with different arguments to execute commands without triggering new approval prompts, potentially accessing files or internal services. |
| OpenClaw versions before 2026.8.1 contain an authorization bypass vulnerability in skill tool dispatch that fails to carry the sender's owner status. Non-owner senders authorized to invoke skill commands can access owner-only tools and server credentials reserved for owners. |
| OpenClaw (npm package openclaw) versions >= 2026.5.2 and < 2026.8.1 contain an incorrect authorization vulnerability in WhatsApp group handling. A group sender who is admitted for ordinary messages but denied by commands.allowFrom or owner command authorization can issue the /new <model> command to reset the shared group session and persist a provider and model override. This allows a command-denied group member to select a provider and model already permitted by the operator for subsequent turns in the shared group session, potentially changing provider routing, cost, data flow, or availability. It does not allow adding a new provider or host command execution. The issue is fixed in version 2026.8.1. |
| OpenClaw versions >= 2026.6.9 and < 2026.8.1 do not declare the native chatId parameter as a delivery target in the Feishu unpin feature, so unpin requests can bypass the shared same-provider cross-context target check. When tools.message.crossContext.allowWithinProvider is disabled, an admitted (authenticated) sender can remove a pin from another Feishu group that the sender and the configured account are otherwise permitted to access, bypassing the intended cross-context message mutation policy. Feishu membership and group authorization still apply, and the demonstrated impact is limited to message mutation (pin removal). The issue is fixed in 2026.8.1. |
| OpenClaw (npm package 'openclaw') before 2026.8.1 does not correctly enforce per-chat tool policies for Codex app-server runtime tools. A conversation-level tools.allow rule filtered OpenClaw tools but did not restrict the shell, process, file, and patch tools owned by the Codex runtime. When a lower-trust conversation was assigned to a Codex runtime and restricted with a per-chat tool allowlist, a participant able to trigger that agent could still reach native command and file tools, bypassing the configured allowlist. The practical impact depends on the runtime's host permissions and sandbox configuration. The issue is fixed in 2026.8.1. |
| OpenClaw (npm package 'openclaw') before 2026.8.1 contains an access-control bypass in the Microsoft Teams integration. When groupPolicy is set to allowlist, a missing or unsupported configured access group produces a denied group-resolution result that is not rejected by the final message-admission check, so a Teams member who is not on the allowlist can still trigger the configured agent despite the administrator's group boundary. The impact depends on the conversations, tools, and data available to that agent. The issue is fixed in version 2026.8.1. |
| OpenClaw (npm package `openclaw`) before 2026.8.1 incorrectly enforces sender tool policies during session-memory filename generation. In affected versions, filename generation created an embedded helper that retained tools which the originating sender's policy had removed. When session-memory filename generation was enabled for an agent reachable by lower-trust senders, model-mediated instructions could cause the helper to invoke tools outside that sender's effective policy; the demonstrated impact was the creation of persistent scheduled work. Exploitability depends on the model acting on the injected instruction and on which tools the helper exposes. The issue is fixed in 2026.8.1; as a workaround, disable session-memory filename generation for agents reachable by lower-trust senders. |
| OpenClaw Feishu before 2026.8.1 fails to validate whether a configured default account is disabled before selecting it for model tool operations. Attackers can exploit multi-account setups where a disabled default account retains credentials to read or modify Feishu resources through a revoked identity. |
| OpenClaw (npm package 'openclaw') before 2026.8.1 fails to revoke memory tool access when an operator hot-disables memory configuration. Existing memory_search and memory_get tool instances retain the enabled configuration captured at creation time because the execution-time resolver treats explicit disablement like an unavailable configuration snapshot and restores the stale authority. As a result, during an already-running agent turn the model can continue searching and reading durable memory after the operator revoked that access, for the remainder of that run. Exploitation requires memory to be disabled while a previously created memory tool remains active. The issue is fixed in 2026.8.1. |
| OpenClaw (npm package 'openclaw') before 2026.8.1 does not apply the originating sender's global or per-agent toolsBySender policy when handling outbound attachments. A sender that has been explicitly denied filesystem read tools can still cause a known local file to be read and returned via a final-response media directive or a message attachment, disclosing local file contents to an admitted requester whose agent turn did not include the read tool. Exploitation requires knowledge or derivation of a useful host path and a delivery flow that accepts local attachments. The issue is fixed in version 2026.8.1. |
