Incorrect Authorization (CWE-863) in Elastic Defend can lead to unauthorized information disclosure via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). Under certain conditions, a low-privileged authenticated user can access response action data that they are not authorized to view.

An issue was discovered in the Windows Network Drive Connector when using Document Level Security to assign permissions to a file, with explicit allow write and deny read. Although the document is not accessible to the user in Network Drive it is visible in search applications to the user.

In Elastic Cloud Enterprise (ECE) versions prior to 1.1.4 it was discovered that a user could scale out allocators on new hosts with an invalid roles token. An attacker with access to the previous runner ID and IP address of the coordinator-host could add a allocator to an existing ECE install to gain access to other clusters data.

An issue was discovered when using Document Level Security and the SPO "Limited Access" functionality in Elastic Sharepoint Online Python Connector. If a user is assigned limited access permissions to an item on a Sharepoint site then that user would have read permissions to all content on the Sharepoint site through Elasticsearch.

Improper Authorization (CWE-285) in Kibana can lead to privilege escalation (CAPEC-233) by allowing an authenticated user to change a document's sharing type to "global," even though they do not have permission to do so, making it visible to everyone in the space via a crafted a HTTP request.

Improper Authorization (CWE-285) in Kibana can lead to privilege escalation (CAPEC-233) by allowing an authenticated user to bypass intended permission restrictions via a crafted HTTP request. This allows an attacker who lacks the live queries - read permission to successfully retrieve the list of live queries.

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.

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.

Improper Access Control (CWE-284) in Kibana can lead to unauthorized modification of Entity Analytics Watchlist configuration and potential information disclosure. A low-privileged authenticated user with read-only Security Solution access could perform write operations on watchlist data that should require elevated privileges. Under specific deployment conditions, this could also allow such a user to access data beyond their authorized scope.

Unintended Proxy or Intermediary ('Confused Deputy') (CWE-441) in Kibana can lead to unauthorized information exposure via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). Under certain conditions, a lower-privileged user can cause data from sources they are not authorized to access to be processed using another user's privileges.

Incorrect Authorization (CWE-863) in Kibana can lead to information disclosure via Privilege Abuse (CAPEC-122). A user with limited Fleet privileges can exploit an internal API endpoint to retrieve sensitive configuration data, including private keys and authentication tokens, that should only be accessible to users with higher-level settings privileges. The endpoint composes its response by fetching full configuration objects and returning them directly, bypassing the authorization checks enforced by the dedicated settings APIs.

Incorrect Authorization (CWE-863) in Kibana can lead to cross-space information disclosure via Privilege Abuse (CAPEC-122). A user with Fleet agent management privileges in one Kibana space can retrieve Fleet Server policy details from other spaces through an internal enrollment endpoint. The endpoint bypasses space-scoped access controls by using an unscoped internal client, returning operational identifiers, policy names, management state, and infrastructure linkage details from spaces the user is not authorized to access.

Improper Authorization in Elastic Cloud Enterprise can lead to Privilege Escalation where the built-in readonly user can call APIs that should not be allowed. The list of APIs that are affected by this issue is: post:/platform/configuration/security/service-accounts delete:/platform/configuration/security/service-accounts/{user_id} patch:/platform/configuration/security/service-accounts/{user_id} post:/platform/configuration/security/service-accounts/{user_id}/keys delete:/platform/configuration/security/service-accounts/{user_id}/keys/{api_key_id} patch:/user post:/users post:/users/auth/keys delete:/users/auth/keys delete:/users/auth/keys/_all delete:/users/auth/keys/{api_key_id} delete:/users/{user_id}/auth/keys delete:/users/{user_id}/auth/keys/{api_key_id} delete:/users/{user_name} patch:/users/{user_name}

Incorrect authorization in Kibana can lead to privilege escalation via the built-in reporting_user role which incorrectly has the ability to access all Kibana Spaces.

Incorrect Authorization issue exists in the API key based security model for Remote Cluster Security, which is currently in Beta, in Elasticsearch 8.10.0 and before 8.13.0. This allows a malicious user with a valid API key for a remote cluster configured to use the new Remote Cluster Security to read arbitrary documents from any index on the remote cluster, and only if they use the Elasticsearch custom transport protocol to issue requests with the target index ID, the shard ID and the document ID. None of Elasticsearch REST API endpoints are affected by this issue.

An issue was discovered where improper authorization controls affected certain queries that could allow a malicious actor to circumvent Document Level Security in Elasticsearch and get access to documents that their roles would normally not allow.

A document disclosure flaw was found in Elasticsearch versions after 7.6.0 and before 7.11.0 when Document or Field Level Security is used. Get requests do not properly apply security permissions when executing a query against a recently updated document. This affects documents that have been updated and not yet refreshed in the index. This could result in the search disclosing the existence of documents and fields the attacker should not be able to view.

grist-core is a spreadsheet hosting server. Prior to version 1.7.7, a user with only partial read access to a document could still access endpoints listing hashes for versions of that document and receive a full list of changes between versions, even if those changes contained cells, columns, or tables to which the user was not supposed to have read access. This was fixed in version 1.7.7 by restricting the `/compare` endpoint to users with full read access. As a workaround, remove sensitive document history using the `/states/remove` endpoint. Another possibility is to block the `/compare` endpoint.

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.8.11, the ydoc:document:join Socket.IO handler checks note ownership only when the document_id starts with note: (colon). However, the YdocManager storage layer normalizes all document IDs by replacing colons with underscores (document_id.replace(":", "_")). An attacker can join a document room using note_<id> (underscore) instead of note:<id> (colon), bypassing the authorization check entirely while accessing the same underlying Yjs document. The server then returns the full document state, leaking the victim's private note contents. This vulnerability is fixed in 0.8.11.

Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.83.39, a missing authorization directive on the GET /api/v1/stable/dags/tasks endpoint caused Hatchet's tenant-membership check to be skipped for this route. A user authenticated to any tenant on the same Hatchet instance could query the endpoint with another tenant's UUID and a DAG UUID belonging to that tenant, and receive task metadata for that DAG. This vulnerability is fixed in 0.83.39.

In the AWS Secrets Manager and SSM Parameter Store secrets backends of `apache-airflow-providers-amazon` prior to 9.28.0, the team-scoping logic could resolve a `conn_id` containing a `/` (e.g. `"my_team/conn"`) to the same path as another team's team-scoped secret when the caller had no team context. A privileged caller without team context could therefore retrieve another team's secret by crafting a colliding `conn_id`. Fixed in 9.28.0 by switching the team-scope separator to `--` and rejecting team-shaped `conn_id`s when team context is absent. Affects the experimental multi-tenant teams feature only. Users are recommended to upgrade to `apache-airflow-providers-amazon` 9.28.0, which fixes the issue.

n8n is an open source workflow automation platform. Prior to versions 2.6.4 and 1.123.23, an authenticated user without permission to list external secrets could reference a secret by the external name in a credential and retrieve its plaintext value when saving the credential. This bypassed the `externalSecret:list` permission check and allowed access to secrets stored in connected vaults without admin or owner privileges. This issue requires the instance to have an external secrets vault configured. The attacker must know or be able to guess the name of a target secret. The issue has been fixed in n8n versions 1.123.23 and 2.6.4. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Restrict n8n access to fully trusted users only, and/or disable external secrets integration until the patch can be applied. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

GitLab has remediated an issue in GitLab EE affecting all versions from 13.11 prior to 18.11.6, 19.0 prior to 19.0.3, and 19.1 prior to 19.1.1 in which incorrect authorization in DAST site profile management could allow a user with Developer role to exfiltrate DAST site profile secrets under certain conditions.

An issue was discovered in GitLab-EE starting with version 13.3 before 17.1.7, 17.2 before 17.2.5, and 17.3 before 17.3.2 that would allow an attacker to modify an on-demand DAST scan without permissions and leak variables.

HCL Launch could allow an authenticated user to obtain sensitive information in some instances due to improper security checking.

Pomerium is an open source identity-aware access proxy. In affected versions changes to the OIDC claims of a user after initial login are not reflected in policy evaluation when using `allowed_idp_claims` as part of policy. If using `allowed_idp_claims` and a user's claims are changed, Pomerium can make incorrect authorization decisions. This issue has been resolved in v0.15.6. For users unable to upgrade clear data on `databroker` service by clearing redis or restarting the in-memory databroker to force claims to be updated.