Incorrect Authorization

Improper access control in the role membership management endpoint in Devolutions Server allows an authenticated non-administrative user holding the user-group membership management permission to escalate privileges to administrator via a crafted API request. This issue affects : * Devolutions Server 2026.2.4.0 through 2026.2.12.0 * Devolutions Server 2026.1.23.0 and earlierShow less

A security flaw has been discovered in AstrBotDevs AstrBot up to 4.25.5. Affected by this vulnerability is the function _build_handoff_toolset of the file AstrBot/astrbot/core/astr_agent_tool_exec.py of the component Subagent. The manipulation results in incorrect authorization. The attack may be launched remotely. The exploit has been released to the public and may be used for attacks. The patch is identified as d23011262e8e75e1ec41b0f1f0091493a022327e. A patch should be applied to remediate this issue.Show less

A vulnerability was identified in AstrBotDevs AstrBot up to 4.25.5. Affected is an unknown function of the file astrbot/core/astr_main_agent.py. The manipulation of the argument req.func_tool leads to incorrect authorization. The attack may be initiated remotely. The exploit is publicly available and might be used. The identifier of the patch is d23011262e8e75e1ec41b0f1f0091493a022327e. It is suggested to install a patch to address this issue.Show less

An Incorrect Authorization vulnerability in Progress Software LoadMaster, ECS Connection Manager, Object Scale Connection Manager, and MOVEit WAF allows an authenticated attacker with low privileges to escalate privileges to root on the affected appliance, potentially resulting in full system compromise.Show less

A flaw was found in pki-core. The certificate authority (CA) renewal request path does not perform the realm-based authorization check that the enrollment path performs, allowing an authenticated user entitled to one realm to cause a certificate belonging to a different realm to be renewed without that realm's authorization.Show less

In Eclipse BaSyx Go Components versions up to and including 1.0.0, ABAC-enabled deployments are vulnerable to an authorization bypass caused by inconsistent trailing-slash handling between the ABAC middleware and the HTTP router. The shared router configuration used Chi's `middleware.StripSlashes`, so a request such as `GET /shells/` was dispatched to the registered `GET /shells` route. However, the ABAC middleware evaluated the original request path including the trailing slash. If ABAC route lookup did not find a matching slash-suffixed route, the request was passed onward and the router then stripped the slash and executed the protected handler without the intended ABAC authorization decision and without the expected ABAC query filters. An unauthenticated or unauthorized network attacker could append a trailing slash to protected API routes to reach handlers that should have been denied by ABAC policy. Depending on the exposed component, HTTP method, and deployed policy, this could allow unauthorized read, create, update, delete, or upload operations. The issue affects ABAC-enabled deployments of services that use the shared router and ABAC middleware, including AAS Repository, Submodel Repository, AAS Registry, Submodel Registry, Concept Description Repository, Discovery, AAS Environment upload, and related services. The issue is fixed in Eclipse BaSyx Go Components v1.0.1.Show less

A non-global organization admin in one tenant can bypass tenant boundaries to delete, create, or modify resources in any other tenant by exploiting a mismatch between authorization (based on ?id=) and action (based on request body).Show less

An authenticated user holding cursor termination privileges on one database may incorrectly be permitted to terminate active cursors on a separate database, disrupting ongoing query operations for other users. The behavior stems from an authorization check that does not correctly scope privileges to the appropriate namespace.Show less

When PROXY protocol v2 is used on the Unix domain socket path, roles derived from X.509 client certificates may not be validated against the configured tlsCATrusts allow-list. This can result in unintended role assignments following MONGODB-X509 authentication. Affected scenarios require local access to the proxy Unix domain socket and a valid X.509 certificate issued by a trusted certificate authority.Show less

An authenticated user may be able to view session metadata belonging to other users on the system through the $listSessions aggregation stage. This information is normally restricted to users with cluster-level administrative privileges, and includes active session identifiers, associated usernames, and activity timestamps.Show less

An authenticated user with limited read privileges may be able to access documents from collections they are not authorized to read, due to an inconsistency in how the $graphLookup aggregation stage is evaluated during authorization and during execution. Affected scenarios involve collections referenced within existing view pipeline definitions.Show less

Traefik 3.6.0 through 3.6.22 and 3.7.0 through 3.7.6 fail to enforce the crossProviderNamespaces allowlist for IngressRouteTCP service serversTransport references (the allowlist was only enforced for HTTP serversTransport references). A low-privileged Kubernetes user in a namespace not listed in crossProviderNamespaces can set serversTransport: foo@file on an IngressRouteTCP service, causing Traefik to accept the forbidden cross-provider reference and use a file-provider TCPServersTransport — including privileged backend mTLS client certificates, SPIFFE identity, or PROXY-protocol settings. This is fixed in 3.6.23 and 3.7.7.Show less

Traefik versions 3.7.0 through 3.7.6 contain a namespace confusion vulnerability in the Kubernetes Gateway API provider. When resolving HTTPRoute.spec.rules[].backendRefs[].filters[].extensionRef, Traefik used the backend Service namespace instead of the HTTPRoute namespace. A low-privileged route author holding a ReferenceGrant for a cross-namespace Service could therefore bind a Traefik Middleware from the backend namespace without a separate grant for that middleware, potentially injecting trusted reverse-proxy identity headers into downstream requests. The issue is fixed in version 3.7.7.Show less

n8n before 1.123.64, 2.29.8, and 2.30.1 fails to enforce the "Allowed HTTP Request Domains" restriction on HTTP-based credentials (Header Auth, Basic Auth, Query Auth, OAuth) in the GraphQL node, unlike the HTTP Request node. An authenticated user able to create or edit workflows can point the node's endpoint at a server they control and exfiltrate restricted credentials. Only instances where a credential has "Allowed HTTP Request Domains" configured and is usable by non-owner users are affected.Show less

n8n before 2.29.8 and 2.30.x before 2.30.1 (affected from 2.27.0, when the OAuth 2.1 consent and token-issuance flow was introduced) does not verify that the authenticated user has access to the workflow referenced as the OAuth resource. On instances with at least one active MCP Server Trigger workflow configured with n8n OAuth2 authentication, a member-level user can register an OAuth client, self-approve consent for another user's workflow, and obtain a valid token. The workflow then runs in the owner's project context with the owner's stored credentials, and the attacker can set tool inputs and read outputs (potentially including data from the owner's connected integrations), breaking user and project isolation.Show less

n8n versions before 2.30.1 contain a privilege escalation vulnerability in the AI Agents feature where the node-execution tool lacks proper authorization checks. A Project Viewer user can escalate privileges by chatting with an agent that has node tools enabled, executing arbitrary nodes and accessing credential secrets without proper authorization verification.Show less

Incorrect Authorization (CWE-863) in Kibana can lead to integrity compromise of Machine Learning audit and notification records via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). A vulnerability exists in Kibana's Machine Learning functionality where a Machine Learning management endpoint performs an insufficient authorization check. The endpoint validates only a coarse privilege level but does not verify that the requesting user has access to the specific Machine Learning job or notification resources provided in the request. As a result, a low-privileged user with Machine Learning access in any Kibana space can manipulate Machine Learning audit and notification records for arbitrary jobs—including jobs in other spaces or belonging to other users—by leveraging Kibana's internally elevated credentials to write to restricted Machine Learning system indices that the user cannot access directly.Show less

Incomplete List of Disallowed Inputs (CWE-184) in Kibana can allow an authenticated attacker with access to the Reporting feature to bypass outbound request restrictions configured by an administrator, causing the reporting service to send requests to network destinations that should be denied by the configured security policy.Show less