An issue was discovered by Elastic, whereby the Detection Engine Search API does not respect Document-level security (DLS) or Field-level security (FLS) when querying the .alerts-security.alerts-{space_id} indices. Users who are authorized to call this API may obtain unauthorized access to documents if their roles are configured with DLS or FLS against the aforementioned index.

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.

APM server logs contain document body from a partially failed bulk index request. For example, in case of unavailable_shards_exception for a specific document, since the ES response line contains the document body, and that APM server logs the ES response line on error, the document is effectively logged.

An issue was discovered whereby Elastic Agent will leak secrets from the agent policy elastic-agent.yml only when the log level is configured to debug. By default the log level is set to info, where no leak occurs.

A flaw was discovered in ECE before 3.4.0 that might lead to the disclosure of sensitive information such as user passwords and Elasticsearch keystore settings values in logs such as the audit log or deployment logs in the Logging and Monitoring cluster. The affected APIs are PATCH /api/v1/user and PATCH /deployments/{deployment_id}/elasticsearch/{ref_id}/keystore

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.

A local file disclosure flaw was found in Elastic Code versions 7.3.0, 7.3.1, and 7.3.2. If a malicious code repository is imported into Code it is possible to read arbitrary files from the local filesystem of the Kibana instance running Code with the permission of the Kibana system user.

It was identified that if a cross-cluster API key https://www.elastic.co/guide/en/elasticsearch/reference/8.14/security-api-create-cross-cluster-api-key.html#security-api-create-cross-cluster-api-key-request-body  restricts search for a given index using the query or the field_security parameter, and the same cross-cluster API key also grants replication for the same index, the search restrictions are not enforced during cross cluster search operations and search results may include documents and terms that should not be returned. This issue only affects the API key based security model for remote clusters https://www.elastic.co/guide/en/elasticsearch/reference/8.14/remote-clusters.html#remote-clusters-security-models  that was previously a beta feature and is released as GA with 8.14.0

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.

An issue was discovered by Elastic whereby Watcher search input logged the search query results on DEBUG log level. This could lead to raw contents of documents stored in Elasticsearch to be printed in logs. Elastic has released 8.11.2 and 7.17.16 that resolves this issue by removing this excessive logging. This issue only affects users that use Watcher and have a Watch defined that uses the search input and additionally have set the search input’s logger to DEBUG or finer, for example using: org.elasticsearch.xpack.watcher.input.search, org.elasticsearch.xpack.watcher.input, org.elasticsearch.xpack.watcher, or wider, since the loggers are hierarchical.

An issue was discovered by Elastic whereby Elastic Agent would log a raw event in its own logs at the WARN or ERROR level if ingesting that event to Elasticsearch failed with any 4xx HTTP status code except 409 or 429. Depending on the nature of the event that Elastic Agent attempted to ingest, this could lead to the insertion of sensitive or private information in the Elastic Agent logs. Elastic has released 8.11.3 and 7.17.16 that prevents this issue by limiting these types of logs to DEBUG level logging, which is disabled by default.

An issue was discovered by Elastic whereby sensitive information may be recorded in Kibana logs in the event of an error. Elastic has released Kibana 8.11.1 which resolves this issue. The error message recorded in the log may contain account credentials for the kibana_system user, API Keys, and credentials of Kibana end-users. The issue occurs infrequently, only if an error is returned from an Elasticsearch cluster, in cases where there is user interaction and an unhealthy cluster (for example, when returning circuit breaker or no shard exceptions).

An issue was discovered by Elastic whereby the Documents API of App Search logged the raw contents of indexed documents at INFO log level. Depending on the contents of such documents, this could lead to the insertion of sensitive or private information in the App Search logs. Elastic has released 8.11.2 and 7.17.16 that resolves this issue by changing the log level at which these are logged to DEBUG, which is disabled by default.

An issue was discovered by Elastic whereby Beats and Elastic Agent would log a raw event in its own logs at the WARN or ERROR level if ingesting that event to Elasticsearch failed with any 4xx HTTP status code except 409 or 429. Depending on the nature of the event that Beats or Elastic Agent attempted to ingest, this could lead to the insertion of sensitive or private information in the Beats or Elastic Agent logs. Elastic has released 8.11.3 and 7.17.16 that prevents this issue by limiting these types of logs to DEBUG level logging, which is disabled by default.

An issue was discovered by Elastic whereby sensitive information may be recorded in Kibana logs in the event of an error or in the event where debug level logging is enabled in Kibana. Elastic has released Kibana 8.11.2 which resolves this issue. The messages recorded in the log may contain Account credentials for the kibana_system user, API Keys, and credentials of Kibana end-users, Elastic Security package policy objects which can contain private keys, bearer token, and sessions of 3rd-party integrations and finally Authorization headers, client secrets, local file paths, and stack traces. The issue may occur in any Kibana instance running an affected version that could potentially receive an unexpected error when communicating to Elasticsearch causing it to include sensitive data into Kibana error logs. It could also occur under specific circumstances when debug level logging is enabled in Kibana. Note: It was found that the fix for ESA-2023-25 in Kibana 8.11.1 for a similar issue was incomplete.

A memory disclosure vulnerability was identified in Elasticsearch 7.10.0 to 7.13.3 error reporting. A user with the ability to submit arbitrary queries to Elasticsearch could submit a malformed query that would result in an error message returned containing previously used portions of a data buffer. This buffer could contain sensitive information such as Elasticsearch documents or authentication details.

Improper restriction of environment variables in Elastic Defend can lead to exposure of sensitive information such as API keys and tokens via automatic transmission of unfiltered environment variables to the stack.

In Elasticsearch before 7.9.0 and 6.8.12 a field disclosure flaw was found when running a scrolling search with Field Level Security. If a user runs the same query another more privileged user recently ran, the scrolling search can leak fields that should be hidden. This could result in an attacker gaining additional permissions against a restricted index.

An issue was identified in Kibana where a user without access to Fleet can view Elastic Agent policies that could contain sensitive information. The nature of the sensitive information depends on the integrations enabled for the Elastic Agent and their respective versions.

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.

Elasticsearch before 7.14.0 did not apply document and field level security to searchable snapshots. This could lead to an authenticated user gaining access to information that they are unauthorized to view.

A permission issue was found in Elasticsearch versions before 5.6.15 and 6.6.1 when Field Level Security and Document Level Security are disabled and the _aliases, _shrink, or _split endpoints are used . If the elasticsearch.yml file has xpack.security.dls_fls.enabled set to false, certain permission checks are skipped when users perform one of the actions mentioned above, to make existing data available under a new index/alias name. This could result in an attacker gaining additional permissions against a restricted index.

A flaw was discovered in Kibana, allowing view-only users of alerting to use the run_soon API making the alerting rule run continuously, potentially affecting the system availability if the alerting rule is running complex queries.

Elastic X-Pack Security versions 5.0.0 to 5.4.0 contain a privilege escalation bug in the run_as functionality. This bug prevents transitioning into the specified user specified in a run_as request. If a role has been created using a template that contains the _user properties, the behavior of run_as will be incorrect. Additionally if the run_as user specified does not exist, the transition will not happen.

An error was found in the X-Pack Security 5.3.0 to 5.5.2 privilege enforcement. If a user has either 'delete' or 'index' permissions on an index in a cluster, they may be able to issue both delete and index requests against that index.

An error was found in the permission model used by X-Pack Alerting 5.0.0 to 5.6.0 whereby users mapped to certain built-in roles could create a watch that results in that user gaining elevated privileges.

Nextcloud Server provides data storage for Nextcloud, an open source cloud platform. Starting in version 22.0.0 and prior to versions 22.2.10.13, 23.0.12.8, 24.0.12.4, 25.0.8, 26.0.3, and 27.0.1, a user can access files inside a subfolder of a groupfolder accessible to them, even if advanced permissions would block access to the subfolder. Nextcloud Server versions 25.0.8, 26.0.3, and 27.0.1 and Nextcloud Enterprise Server versions 22.2.10.13, 23.0.12.8, 24.0.12.4, 25.0.8, 26.0.3, and 27.0.1 contain a patch for this issue. No known workarounds are available.

Improper access control in Odoo Community 13.0 and earlier and Odoo Enterprise 13.0 and earlier allows users with deactivated accounts to access the system with the deactivated account and any permission it still holds, via crafted RPC requests.

Pimcore is an Open Source Data & Experience Management Platform. Prior to 12.3.1 and 11.5.14, the application fails to enforce proper server-side authorization checks on the API endpoint responsible for reading or listing static routes. In Pimcore, static routes are custom URL patterns defined via the backend interface or the var/config/staticroutes.php file, including details like regex-based patterns, controllers, variables, and priorities. These routes are registered automatically through the PimcoreStaticRoutesBundle and integrated into the MVC routing system. Testing revealed that an authenticated backend user lacking explicit permissions was able to invoke the endpoint (e.g., GET /api/static-routes) and retrieve sensitive route configurations. This vulnerability is fixed in 12.3.1 and 11.5.14.

Improper access control in Imagine Cup allows an authorized attacker to elevate privileges over a network.

kimai2 is vulnerable to Improper Access Control

Improper access control in mail module of Odoo Community 17.0 and Odoo Enterprise 17.0 allows remote authenticated attackers to extract sensitive information via an oracle-based (yes/no response) crafted attack.

Microsoft SharePoint Server Information Disclosure Vulnerability

OSIsoft PI Vision, All versions of PI Vision prior to 2019. The affected product is vulnerable to an improper access control, which may return unauthorized tag data when viewing analysis data reference attributes.

An improper access control vulnerability exists in GitLab <12.3.3 that allows an attacker to obtain container and dependency scanning reports through the merge request widget even though public pipelines were disabled.

GLPI is a free asset and IT management software package. Versions of the software starting with 9.2.0 and prior to 10.0.8 have an incorrect rights check on a on a file accessible by an authenticated user, allows access to the view all KnowbaseItems. Version 10.0.8 has a patch for this issue.

A vulnerability in the web-based management interface of Cisco Identity Services Engine (ISE) could allow an authenticated, remote attacker to bypass authorization and access sensitive information related to the device. The vulnerability exists because the software fails to sanitize URLs before it handles requests. An attacker could exploit this vulnerability by submitting a crafted URL. A successful exploit could allow the attacker to gain unauthorized access to sensitive information.

Improper Access Control in GitHub repository salesagility/suitecrm prior to 7.14.1.

GLPI is a free asset and IT management software package. Versions of the software starting with 0.68 and prior to 10.0.8 have an incorrect rights check on a on a file accessible by an authenticated user. This allows access to the list of all users and their personal information. Users should upgrade to version 10.0.8 to receive a patch.

DHIS2 Core contains the service layer and Web API for DHIS2, an information system for data capture. Starting in the 2.35 branch and prior to versions 2.36.13, 2.37.8, 2.38.2, and 2.39.0, when the Category Option Combination Sharing settings are configured to control access to specific tracker program events or program stages, the `/trackedEntityInstances` and `/events` API endpoints may include all events regardless of the sharing settings applied to the category option combinations. When this specific configuration is present, users may have access to events which they should not be able to see based on the sharing settings of the category options. The events will not appear in the user interface for web-based Tracker Capture or Capture applications, but if the Android Capture App is used they will be displayed to the user. Versions 2.36.13, 2.37.8, 2.38.2, and 2.39.0 contain a fix for this issue. No workaround is known.

Improper Access Control in GitHub repository nilsteampassnet/teampass prior to 3.0.9.

Improper access control in mail module (channel partners) in Odoo Community 14.0 and earlier and Odoo Enterprise 14.0 and earlier, allows remote authenticated users to subscribe to arbitrary mail channels uninvited.

Improper access control in mail module (notifications) in Odoo Community 14.0 and earlier and Odoo Enterprise 14.0 and earlier, allows remote authenticated users to obtain access to arbitrary messages in conversations they were not a party to.

Jenkins Kubernetes Credentials Provider Plugin 1.208.v128ee9800c04 and earlier does not set the appropriate context for Kubernetes credentials lookup, allowing attackers with Item/Configure permission to access and potentially capture Kubernetes credentials they are not entitled to.

A security vulnerability has been detected in MineAdmin 1.x/2.x. Affected is an unknown function of the file /system/getFileInfoById. Such manipulation of the argument ID leads to information disclosure. It is possible to launch the attack remotely. The attack requires a high level of complexity. The exploitability is told to be difficult. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability in the web UI of Cisco Catalyst SD-WAN Manager could allow an authenticated, remote attacker to retrieve arbitrary files from an affected system. This vulnerability is due to improper validation of parameters that are sent to the web UI. An attacker could exploit this vulnerability by logging in to Cisco Catalyst SD-WAN Manager and issuing crafted requests using the web UI. A successful exploit could allow the attacker to obtain arbitrary files from the underlying Linux file system of an affected system. To exploit this vulnerability, the attacker must be an authenticated user.

A flaw was found in the containerized-data-importer in virt-cdi-cloner, version 1.4, where the host-assisted cloning feature does not determine whether the requesting user has permission to access the Persistent Volume Claim (PVC) in the source namespace. This could allow users to clone any PVC in the cluster into their own namespace, effectively allowing access to other user's data.

The Download Manager WordPress plugin before 3.2.71 does not adequately validate passwords for password-protected files. Upon validation, a master key is generated and exposed to the user, which may be used to download any password-protected file on the server, allowing a user to download any file with the knowledge of any one file's password.

Improper access control in Devolutions Server allows an authenticated user to access unauthorized sensitive data.