| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A flaw was found in the Pushed Authorization Request PAR implementation of Keycloak. The issue occurs when the silent authentication path prompt=none is used, which allows the authorization process to skip certain steps if a user is already logged in. Due to this bypass, the security rule that ensures a pushed request URI is used only once is not enforced. An attacker could potentially reuse a request URI to obtain multiple authorization codes for a user who is already signed in, violating security standards like FAPI-2. |
| Missing Authorization (CWE-862) in Kibana can lead to unauthorized deletion of data via Exploiting Incorrectly Configured Access Control Security Levels (CAPEC-180). An authenticated user holding Synthetics privileges scoped to a single Kibana space could permanently delete Synthetics monitors that are shared into spaces they have no access to. Where a monitor is associated with a private location, the same operation also destroys the underlying Elastic Agent integration configuration without the authorization checks that Fleet would otherwise apply. |
| CopyAPIView (awx/awx/api/generics.py:873) sets permission_classes =
(IsAuthenticated,), so DRF's get_object() performs no object-level
RBAC. The get() handler (lines 988–991) explicitly guards with
request.user.can_access(obj._class_, 'read', obj) — but post()
(lines 1001–1010) does not. POST only checks:
can_access(model, 'add', create_kwargs_check)
can_access(model, 'copy_related', obj)
For JobTemplate, can_add (awx/awx/main/access.py:1465–1520) gates on
inventory.use_role + project.use_role +
execution_environment.read_role — resource-level roles that do not
imply read on the source JT — and can_copy_related (1522–1534) checks
only credentials.use_role. None of these imply the caller can read the
source JT. |
| When OnlyOffice/Document Editing is available, an unauthenticated remote attacker with access to an existing supported public Briefcase document can abuse unsigned save fields to perform path-traversal writes and execute commands as zimbra. |
| ClawHub (openclaw/clawhub) contains an incorrect authorization vulnerability in the ClawHub application/backend: an organization-owned skill retains the ownerUserId of its original publisher, and transfer and lifecycle authorization checks trust that historical user before requiring current organization privileges. An authenticated user who originally published an organization skill can therefore transfer, delete, or restore that skill — taking control of its trusted name and history — even after their organization privileges have been revoked or downgraded. The issue was confirmed at revision cbfee7343ddc867316dd9b3de6fa8856730f9f41; the complete historical affected range was not established. It is fixed by PR #3680, included in revision 8c2de6c506bb4efabe3f0c2ffb8370b9e23d4650, which was deployed to clawhub.ai on 2026-09-11; self-hosted deployments should update to that revision or a later descendant. The npm CLI and OpenClaw runtime are separate products and are not affected. |
| capgo.app is an over-the-air update platform for Capacitor apps. In all versions prior to a fix, the row-level security UPDATE policy on the public.orgs table permits an organization admin (a user holding org.update_settings) to update the entire row, including the internal billing pointer column customer_id. The official organization update endpoint (supabase/functions/_backend/public/organization/put.ts) allowlists only a small set of editable settings fields and excludes customer_id, and the private Stripe billing route separately requires the org.update_billing permission. By sending an update directly to Supabase PostgREST, an authenticated org admin without org.update_billing can null or corrupt the organization's Stripe customer pointer, causing plan and billing checks that trust orgs.customer_id to fail and moving the organization from a valid paid plan state to unpaid/no-plan behavior. At the time of the advisory no patched version was available. |
| Capgo (capgo.app backend) before 12.127.5 contains an authorization flaw in the PATCH /private/role_bindings/:binding_id endpoint. The handler verifies that the newly assigned role's priority rank does not exceed the caller's own rank, but — unlike the DELETE handler — it never checks the rank of the role currently bound to the target binding. An authenticated user holding the org_admin role (rank 90) can therefore change an org_super_admin binding (rank 95) to a lower-privileged role such as org_member (rank 75). Because the prevent_last_super_admin_binding_delete database trigger fires only BEFORE DELETE and not on UPDATE, an org_admin can demote every org_super_admin, leaving the organization with no super administrator. The issue is fixed in 12.127.5. |
| SiYuan is a self-hosted personal knowledge management system. In versions 3.8.0 through 3.8.3, the MCP file tool's sensitive-path guard (util.IsForbiddenAbsPath(), invoked from resolvePath()) is applied only to the allowed root of recursive operations and not to each resolved descendant path — an incomplete fix for GHSA-c8r8-95hg-mp34. An authenticated administrator using the in-app Agent or the external MCP server can therefore bypass the protected-workspace-file denylist: file.grep can return matching lines from non-hidden protected descendants (for example conf/conf.json, TLS keys, data/snippets/conf.json, data/templates/, data/.siyuan/publishAccess.json, notebook .siyuan internals, or the kernel log), file.copy can copy protected descendants to an ordinary path where file.read can then retrieve them, and unzip can overwrite protected descendants using ordinary, lexically contained ZIP member names. Because file.grep is globally classified as a safe action, it receives no per-call confirmation, and the confirmation cards for file.copy and unzip show only the allowed root arguments. This issue is fixed in version 3.8.4. Suggested title: SiYuan 3.8.0 through 3.8.3 Sensitive-Path Guard Bypass in Recursive MCP File Operations. |
| Lemonldap::NG::Handler versions from 2.0.0 before 2.16.10, from 2.17.0 before 2.21.6, from 2.22.0 before 2.23.4 for Perl allow an equivalent spelling of a path to bypass the locationRules that restrict it.
The handler matches each vhost's locationRules regular expressions against REQUEST_URI, the raw request line, while the web server routes on the path it has already percent-decoded and normalized. A request that percent-encodes a character of the path, inserts dot segments, or doubles a slash therefore reaches the protected resource under a URI that no rule regexp matches, and the vhost's default rule decides access. Deny rules, identity and group conditions, and unprotect and skip rules are bypassed alike.
Only a vhost whose default rule is more permissive than its other rules is affected. An authenticated user then reaches any URL a locationRules regexp was meant to restrict, but gains no more than that default rule already grants. |
| Flowise through 3.1.4 does not enforce authorization on the BullMQ admin dashboard. When the server runs in queue mode with the dashboard enabled and not in cloud mode (MODE=queue, ENABLE_BULLMQ_DASHBOARD=true, and !isCloud()), the /admin/queues mount is protected only by the verifyTokenForBullMQDashboard middleware, which validates the JWT but performs no role, permission, or workspace/organization scoping check; the mount also lies outside /api/v1/* so the global API gate does not apply. As a result, any authenticated user — including the lowest-privileged member of any tenant — can reach the full Bull-Board UI and view all queues and job payloads across the entire instance, including chat inputs and overrideConfig (which may carry credentials and prompts), chatflow.flowData graph definitions with custom function source code, credential IDs and system prompts, chatIds, files, and the originating orgId/workspaceId. The dashboard's write actions (retry, remove, promote, clean) are likewise usable across tenants. No patched version is available as of the advisory. |
| Missing Authorization in the drop handling path of the drag and drop protocol in kitty from 0.47.0 before 0.49.0 allows a program writing to the terminal to obtain the contents of files dragged over the window even when the user never completes the drop, because drop_enqueue_request() in kitty/dnd.c serves a drag data request without first checking the drop state of the window, so a client that issues the request while a drag is merely hovering receives the data offered for the drag. In the same file, drop_left_child(), which runs when the drag leaves the window without a drop having occurred, releases the offered MIME list but retains the pending request state, the open file descriptor and its main loop transfer timer, the directory handles, the URI list and the pending MIME name, so a client can continue to read through a retained directory handle, and an in-flight file transfer continues to stream, when no drag is in progress. The file contents are read from the filesystem by the kitty process itself using the paths the drag source offered. This results in disclosure of the contents of files the user moved over the window without ever releasing them into it. |
| RabbitMQ is a messaging and streaming broker. From 3.13.0 until 4.3.3, 4.2.9 , 4.1.14, 4.0.24, and 3.13.18, Federation upstream in RabbitMQ skips vhost authorization allowing cross-vhost message access. what the bug lets you do. A policymaker on one vhost reads and drains messages out of another vhost it has no permission on. With the default ack-mode the source messages are consumed (deleted), not copied. Why that should not 1. Federation validates the upstream URI without any vhost-access Cross-vhost message read/drain from a per-vhost policymaker, breaking vhost tenancy This issue is fixed in versions 4.3.3, 4.2.9 , 4.1.14, 4.0.24, and 3.13.18. |
| 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. |
| RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.3.3 and 4.2.9 and 4.1.14 and 4.0.23, Incomplete fix for CVE-2026-44838: escaperegexchar/1 does not escape -, leaving room for an MQTT topic permission bypass. the CVE-2026-44838 fix made expandtopicpermission/2 escape regex metacharacters in expanded topic-permission variables (escaperegex(V)), but escaperegexchar/1 escapes \ ^ $ . | ? + ( ) [ ] { } and omits -. When a topic permission template places {clientid} inside a [...] character class A low-privileged authenticated MQTT user controlling its clientid can broaden topic authorization (read and write) when templates embed {clientid} in a [...] This issue is fixed in versions 4.3.3 and 4.2.9 and 4.1.14 and 4.0.23. |
| Bludit CMS through 3.22.0 contains a missing authorization vulnerability that allows authenticated users holding the Author or Editor role to read the full content of private drafts and scheduled posts belonging to any other user, including administrators, by exploiting the content-get-list AJAX endpoint in bl-kernel/ajax/content-get-list.php. Attackers can send an authenticated GET request to the admin AJAX endpoint with the draft parameter set to true, triggering getList() without ownership constraints and returning serialized page objects site-wide, exposing pre-publication material and sensitive notes stored in administrator-owned drafts. |
| Missing Authorization in the askpass escape code handler in kitty from 0.25.0 before 0.49.0 allows a local user other than the one running the terminal to obtain the text typed into a prompt that kitty itself displays, because handle_remote_askpass() in kitty/window.py opens the POSIX shared memory object named in the escape code, parses a prompt definition out of it, and writes the user's answer back into an object of that same name, without at any point checking that the object is owned by the user running kitty or that its permissions exclude other users. The equivalent consumer of the same SharedMemory class in the ssh kitten performs exactly that check; the askpass path did not. The handler is reached through a device control string processed from the byte stream of the window, so the attacker must also cause bytes of their choosing to be displayed by the victim's terminal. Where the POSIX shared memory namespace is shared between the two users, a second local user can create an object with permissions that allow the victim to read and write it, cause the victim's kitty to render a prompt of the attacker's choosing, including a masked password prompt, and read the typed secret back out of the object afterwards. The prompt text is additionally passed to the display without control character sanitisation, so it can overwrite the warning line kitty prints above it. The answer is written by reopening an object of that name when the user answers, rather than through the handle already held. This results in disclosure of a secret typed by the victim to a second local user, and does not require any privilege on the victim's account. |
| RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5, RabbitMQ Management rendered an AMQP authorization-error reason containing an attacker-controlled queue name as HTML when the OAuth management UI was enabled. Exploitation requires an attacker with queue configure permission, a management administrator who can see but cannot read that queue, and the administrator clicking Get Message(s). A queue name containing a base element can then retarget the automatic relative refresh because the Content Security Policy omits base-uri and connect-src, and an attacker endpoint that permits the management origin through CORS can receive the victim's Authorization header. This issue is fixed in versions 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5. |
| Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, summary An issue with permission checks in the knowledge base management area has been identified. Under certain conditions, data validation for linked items was not fully enforced. This could have allowed users with limited read permissions to interact with items outside their assigned access scope. Data access has been strengthened in the current version through additional validation routines. 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, 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. |
| The @payloadcms/storage-vercel-blob storage adapter for Payload contains an improper access control vulnerability that allows authenticated users to bypass collection-level permissions by accessing the client-upload route directly. Attackers can upload files through the client-upload endpoint without possessing the required collection access permissions, circumventing the intended access control enforcement. |
