Elastic
Monthly
Authorization bypass in Elasticsearch's Remote Cluster Security (RCS) 2.0 cross-cluster search path lets an authenticated principal holding a cross-cluster API key for one index send a crafted request that is authorized against that permitted index while actually executing against a different, unauthorized index, exposing that index's document contents, field mappings and other metadata, and in limited cases permitting modification of retention-lease state on it. The flaw is an authenticated authorization-boundary bypass (CVSS 7.1, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N), so the real-world risk is concentrated in multi-tenant or shared clusters that issue cross-cluster API keys to less-trusted tenants, while single-tenant clusters without shared cross-cluster keys are not meaningfully exposed. No public exploit code has been identified at time of analysis.
Incorrect authorization in Elasticsearch 8.x and 9.x allows an authenticated, already-privileged user (CVSS PR:H) who has been granted a non-default, delegated role-management privilege to escalate privileges within a cluster. By abusing a role-definition setting that expands the set of indices matched against a delegated index-scoped privilege, the holder can modify their own assigned role and reach indices that should remain restricted, including internal security data, and from there potentially obtain full administrative control of the cluster. Exploitation is only possible when the cluster has the configurable delegated role-management privilege explicitly enabled and granted with a broadly-scoped index pattern; default deployments that never delegate this capability are not affected. No public exploit code has been identified at time of analysis and the flaw is not confirmed as actively exploited (not in CISA KEV). Vendor-released patches are available in Elasticsearch 8.19.22, 9.4.7, and 9.5.4.
Authorization bypass in Kibana's Fleet package installation process lets an authenticated user who holds delegated Fleet package-management privileges - but no direct Elasticsearch administrative rights - claim a data stream identifier already in use by another tenant sharing the same deployment. Because Fleet does not verify ownership of that identifier before applying the uploaded package's generated index and ingest-pipeline settings to pre-existing infrastructure, an attacker can redirect a victim tenant's subsequent data through infrastructure they control, achieving unauthorized disclosure and modification of that data and preventing it from reaching its intended destination (CVSS 8.8, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Exploitation requires a multi-tenant Kibana deployment with delegated Fleet privileges and valid authenticated access; it is impossible in single-tenant setups, and no public exploit identified at time of analysis.
Privilege escalation in Elastic Kibana's Agent Builder feature lets an authenticated non-administrative user who can edit a shared agent cause privileged operations to run under the identity of a higher-privileged user who later interacts with that agent (CWE-441 confused deputy). Rated CVSS 7.3 High (AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N), the flaw requires the Agent Builder feature to be enabled with at least one shared agent, the attacker to hold edit privileges on it, and a privileged victim to interact with the tampered agent; if the attacker can also author workflows, escalation to full Kibana and Elasticsearch cluster administrative control is possible. No public exploit identified at time of analysis, and vendor patches are available in Kibana 9.4.7 and 9.5.0.
Maliciously crafted on-chain account names processed by Klever-Go prior to 1.7.20 are spliced into Elasticsearch _bulk request bodies without JSON escaping, allowing an attacker who can submit a SetAccountName transaction to inject forged bulk actions that create, overwrite, or delete documents in any index the indexer can write to. Because the name is stored in consensus account state, the poisoned value is replayed by new and historical indexers, and no access to the indexing host or the Elasticsearch port is required. Severity is rated 8.4 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:L; our independent assessment CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H), exploitation requires an authenticated low-privilege on-chain account plus a deployment that actually runs the Elasticsearch indexer, and the issue is fixed in 1.7.20; no public exploit identified at time of analysis, though the upstream fix ships a regression test that reproduces the advisory's injection construction.
Authenticated attackers can read arbitrary Elasticsearch indices in zlt2000 microservices-platform through 6.0.0 by supplying any index name in the POST /search/{indexName} or GET /agg/requestStat/{indexName}/{routing} endpoints, bypassing authorization checks. This exposes sensitive data such as the sys_user index containing user records and password hashes; the vulnerability has a CVSS 4.0 base score of 7.1 and an assessed CVSS 3.1 vector of AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, meaning high confidentiality impact with no integrity or availability effect. Publicly available exploit code exists (no CISA KEV confirmation), and exploitation requires only a valid low-privilege session on a network-reachable search-center service.
Missing authorization in zlt2000 microservices-platform through 6.0.0 lets any authenticated account - including one with zero assigned roles - invoke administrative APIs for user management, role assignment, password resets by user ID, and Elasticsearch index deletion, because the shipped default of zlt.security.auth.urlPermission.enable is false and suppresses all permission checks once authentication succeeds. Exploitation is not pre-auth: it requires a valid low-privilege session against a deployment running the out-of-the-box configuration, and publicly available exploit code exists (VulnCheck-reported PoC scripts covering role-granting, user enumeration, password reset, and ES index deletion), though no confirmed active exploitation (CISA KEV) has been recorded. Assessed severity is high (CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 8.8; vendor-published CVSS 4.0 score 8.7) because a zero-role user obtains both read and write access to sensitive administrative functions.
Incorrect authorization in Apache Syncope (3.0.0-M0 through 3.0.16, 4.0.0-M0 through 4.0.7, and 4.1.0-M0 through 4.1.2) allows an authenticated principal that holds a search entitlement to retrieve identity and entity records outside its authorized realms by issuing a non-recursive search request. The Realms filter that normally constrains results to the requester's permissions can be rendered empty for non-recursive queries, effectively removing the privilege restriction before the search is translated into SQL, Neo4j, or Elasticsearch/OpenSearch queries; recursive searches are not affected. The exposure is backend-agnostic but gated by authentication and an existing search entitlement, so it is a data-confidentiality bypass rather than anonymous remote code execution - no public exploit code has been identified at time of analysis, EPSS is low (0.48%, ~40th percentile), and there is no CISA KEV listing. Vendor fixes are available in 4.0.8 and 4.1.3.
Stored cross-site scripting in Amundsen Frontend through 4.3.0 allows authenticated users with description-write access to inject arbitrary JavaScript into table, dashboard, and feature description fields, executing attacker-controlled code in the browser of every user who subsequently views search results. The root cause is React's dangerouslySetInnerHTML used without any HTML sanitization in ResourceListItem components (TableListItem and siblings), meaning payloads such as img elements with onerror handlers stored via the metadata service or Elasticsearch persist and fire on each page load. No public exploit code has been identified at time of analysis, but the attack pattern is elementary for anyone with metadata write access.
Incorrect authorization (CWE-863) in Elastic Kibana allows authenticated users holding only low-privilege accounts to modify configurations that should be restricted to higher-privilege roles, bypassing Kibana's access control enforcement. The CVSS vector (AV:N/AC:L/PR:L/UI:N, C:H/I:H/A:N) confirms the flaw is network-exploitable with minimal complexity and yields high confidentiality and integrity impact against Kibana's configuration plane. Elastic has released patched versions across the 8.x and 9.x release trains under advisory ESA-2026-178; no public exploit has been identified and the vulnerability is not listed in CISA KEV.
Privilege escalation in Kibana's Fleet management component allows any user holding Fleet management privileges to mint arbitrarily elevated Elasticsearch cluster credentials - up to full cluster administration - for every Elastic Agent enrolled in a targeted policy. Elasticsearch cluster privilege declarations sourced from integration packages were not validated before being used to generate agent credentials (CWE-863: Incorrect Authorization), enabling an attacker to inject overprivileged credentials across an entire agent fleet. No public exploit has been identified at time of analysis, and CISA KEV status is not confirmed, but the impact is laterally broad: a single privileged user can compromise all agents and the Elasticsearch cluster they authenticate to.
Path traversal in Kibana's Fleet feature enables a low-privileged attacker with Fleet Settings write access to plant a malicious pathname in settings that, when subsequently acted upon by an administrator, causes deletion of privileged internal resources including user accounts and organizational assets. All Kibana versions prior to 8.19.18, 9.3.6, and 9.4.3 are affected per ESA-2026-158. No public exploit code or active exploitation has been confirmed; the two-party nature of the attack - requiring both attacker write access and administrator interaction - moderates opportunistic exploitability despite the High CVSS rating.
Local privilege escalation in Elastic Agent on Windows enables a low-privileged local user to achieve SYSTEM-level code execution by exploiting overly permissive access controls (CWE-732) on resources created during unprivileged-mode installation. The agent service, running as SYSTEM, will execute attacker-controlled binaries placed via the CAPEC-642 binary replacement technique. Vendor-released patches 8.19.21, 9.4.6, and 9.5.2 are available per advisory ESA-2026-150; no public exploit identified at time of analysis.
Second-order path traversal in Kibana allows a low-privileged user with tag creation rights to cause an administrator's routine tag management action to operate on an unintended privileged resource, resulting in permanent deletion of administrator accounts or other organizational assets. Affected versions span the Elastic Stack deployment across the 8.x and 9.x series, with patches released in Kibana 8.19.16, 9.3.5, and 9.4.2. No public exploit has been identified and the vulnerability is not in the CISA KEV catalog, but the potential to delete administrative accounts elevates this beyond a typical medium-severity finding in multi-tenant deployments.
Missing authorization in Elasticsearch's custom inference service allows a low-privileged user holding only inference execution rights to redirect outbound inference traffic to an attacker-controlled endpoint, causing administrator-provisioned credentials to leak to that destination. Affected across the 8.x and 9.x branches (Elasticsearch 8.0.0 through 8.19.18, 9.0.0 through 9.3.7, 9.4.0 through 9.4.3, and 9.5.0), this is a privilege-abuse path where an underprivileged internal user effectively hijacks admin-level secrets without requiring elevated permissions. No public exploit or active exploitation has been identified; EPSS sits at 0.17% and SSVC rates technical impact as partial.
Remote code execution in Elasticsearch's machine learning component allows an authenticated user with ML model deployment privileges to execute arbitrary attacker-controlled logic on the Elasticsearch host node by supplying a crafted trained model artifact. The flaw stems from unsafe deserialization (CWE-502) of model artifact data during the ML inference loading process, granting the attacker a broader OS system-call surface than the ML subsystem is intended to expose. Elastic has released fixed versions 8.19.2, 9.4.5, and 9.5.1 via ESA-2026-114; no public exploit code or CISA KEV listing has been identified at time of analysis.
Privilege escalation in Kibana allows an authenticated user holding workflow edit permissions to cause scheduled workflow executions to run under the privileges of a higher-privileged user, granting unauthorized read and write access to data outside their authorization scope. The flaw (CWE-863, Incorrect Authorization) stems from Kibana's workflow scheduling subsystem failing to enforce authorization boundaries when executing scheduled jobs - a pattern classified under CAPEC-180. No public exploit exists at time of analysis, but the CVSS 8.3 (High) score with a network-accessible, low-privilege attack vector reflects genuine impact for any multi-user Kibana deployment. Elastic's advisory ESA-2026-61 references Kibana 9.4.3 as the fix release.
Log injection in @logtape/syslog allows network-accessible attackers to forge arbitrary syslog records in downstream collectors such as rsyslog, Splunk, and Elastic Stack. The escapeStructuredDataValue() function omits C0 control character escaping, so a literal newline embedded in a log property value terminates the current RFC 6587 TCP syslog frame and begins a new one; if the attacker-supplied bytes constitute a valid RFC 5424 header, the downstream collector accepts them as a separate, authentic-looking record. A second injection path exists through unvalidated SD-NAME keys, which can prematurely close structured-data elements. Both paths require the non-default SyslogSinkOptions.includeStructuredData: true setting. Publicly available proof-of-concept code exists; no CISA KEV listing at time of analysis.
Elasticsearch API key leakage in Kibana Fleet exposes enrolled agent credentials to any low-privileged authenticated user through a filter-based side channel. Fleet's agent listing endpoint accepts caller-supplied filter expressions evaluated under Kibana's own elevated internal Elasticsearch privileges rather than the caller's, and the match count in each response functions as a boolean oracle, enabling character-by-character reconstruction of the full API key value across all Kibana versions prior to 8.19.20, 9.4.5, and 9.5.1. No public exploit code has been identified and the vulnerability is not listed in the CISA KEV catalog at time of analysis, but the CVSS 7.1 (C:H) rating reflects the severity of full credential exfiltration via an authenticated, network-reachable, low-complexity attack.
Privilege escalation in Kibana Fleet allows an authenticated low-privileged user to bypass integration-scoped authorization controls by exploiting a logic flaw in how policy update requests are validated (CWE-863). An operator holding only the Elastic Defend endpoint policy management role can craft a Fleet API update request that substitutes a different integration type into an existing endpoint policy they control, because Fleet evaluates the authorization check against the stored policy's original integration rather than the replacement integration supplied in the request. No public exploit code has been identified at time of analysis, but the vendor (Elastic) has issued advisory ESA-2026-127 with patched releases.
Cross-space authorization bypass in Kibana allows authenticated users to access trained machine learning model inference outputs, and stop or modify active model deployments, in Kibana Spaces they are not authorized to access. The vulnerability arises because API endpoints for ML model inference and deployment management accept user-controlled resource identifiers without enforcing space-level ACL boundaries, enabling privilege escalation across the Space isolation boundary. No public exploit code has been identified and Elastic has released fixed versions 8.19.20, 9.4.5, and 9.5.1 per advisory ESA-2026-126.
Incorrect authorization in Kibana Agent Builder allows authenticated users to access, modify, or delete private agents they do not own when sharing a username with another principal across different Elasticsearch authentication realms. The flaw stems from a fallback ownership check that compares usernames - which are not unique across realms - rather than stable user identifiers, enabling cross-realm identity confusion. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis, but the low attack complexity and network accessibility make this a credible insider or multi-tenant threat.
Heap corruption and potential remote code execution in Elasticsearch's native ML inference engine can be triggered by any user holding the low-privilege ML model upload and deploy permission. By crafting a model that embeds an operation computing a memory address from an attacker-controlled offset, a low-privileged authenticated user can cause the native inference subprocess to read and write outside its allocated heap, reliably crashing that process or, under controlled heap layout conditions, executing arbitrary code within it. No active exploitation or public proof-of-concept has been identified at time of analysis, but the CVSS 8.8 rating, network-accessible vector, and explicit RCE potential in the vendor description place this in the urgent-remediation tier for any organization running Elasticsearch with ML features delegated to non-admin users.
Privilege escalation in Kibana arises from insufficient CSRF protection in the Vega visualization engine, affecting all versions prior to 8.19.20 and 9.4.5. Any Kibana user with visualization creation rights can embed a specially crafted Vega specification that, when rendered by a higher-privileged user's browser, silently issues authenticated HTTP requests to Kibana under the victim's session credentials. No public exploit code has been identified and no CISA KEV listing exists at time of analysis, though the low attack complexity and widely deployed nature of the product make this a meaningful remediation priority.
Missing Authorization in Kibana's Elastic Security module permits authenticated users holding detection rule authoring privileges to execute Osquery live queries and Elastic Defend response actions against enrolled managed endpoints without possessing the specific Osquery or Elastic Defend privileges that normally govern those capabilities. The CVSS 8.1 score reflects a network-accessible, low-complexity attack path with high confidentiality and integrity impact against enrolled host infrastructure. No active exploitation has been confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis, but patch versions 8.19.20 and 9.4.5 are available per Elastic Security Advisory ESA-2026-96.
Relative path traversal in Kibana's Fleet component allows an authenticated low-privileged user to delete arbitrary Kibana resources by supplying a crafted Fleet Server host configuration identifier containing traversal sequences. Elastic has confirmed the flaw in ESA-2026-94 and released patched versions 8.19.17, 9.3.6, and 9.4.3. No public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Server-side code injection in Elastic Fleet Server (8.5.0-8.19.19, 9.0.0-9.4.4, and 9.5.0) lets an actor who can define an output configuration in Kibana smuggle script syntax through an output identifier that is never restricted to safe characters. Because Fleet Server later concatenates that identifier into a script it builds during routine agent policy processing, embedded script fragments execute on the server rather than being treated as inert data, yielding attacker-controlled code execution (CWE-94). No public exploit identified at time of analysis and EPSS is low (0.36%), but SSVC rates technical impact as total.
Kibana's Machine Learning subsystem fails to enforce space-level authorization, allowing any authenticated low-privilege user in one Kibana space to read ML data from all other spaces and make unauthorized modifications across the entire deployment. The root cause is that ML operations execute with elevated internal Elasticsearch permissions while a subset of ML functionality omitted the per-request space isolation filter that enforces tenancy boundaries. No public exploit has been identified, but the attack requires only a standard user account, making it a realistic internal threat in multi-tenant or shared Kibana deployments. Fixed versions 8.19.20 and 9.4.5 are referenced in the Elastic security advisory ESA-2026-92.
Elastic Kibana's Elastic Security endpoint policy editor exposes sensitive Elastic Defend telemetry through a privilege escalation in the field value suggestion feature. Authenticated users holding Kibana Elastic Security feature privileges - but lacking Elasticsearch index-level read access to Elastic Defend event indices - can retrieve field values including process command line arguments, which routinely contain credentials, API tokens, and connection strings harvested from protected endpoints. No public exploit has been identified at time of analysis, but the low attack complexity and scope change across the Kibana-to-Elasticsearch authorization boundary make this straightforward to abuse by any user with a qualifying Kibana role.
Missing authorization on Kibana's Observability Onboarding API routes allows any authenticated low-privilege user sharing a Kibana space to enumerate, read, and overwrite the onboarding flow state of other users in that space. Affected installations include all Kibana versions prior to 8.19.19 and 9.4.5 across both self-managed and Elastic Cloud deployments. No public exploit code has been identified at time of analysis and this vulnerability is not listed in the CISA KEV catalog; however, the CVSS high integrity impact (I:H) reflects an attacker's ability to corrupt another user's onboarding progress and trigger persistent server errors in the victim's Observability Onboarding view.
Privilege escalation in Elastic Kibana's Agent Builder component (versions 9.4.0-9.4.3) allows authenticated low-privileged users to create and execute Agent tools that invoke Kibana features they are not authorized to access, bypassing the platform's feature-level access controls. The Agent Builder omits authorization verification against the target feature's required privilege set before tool creation and execution, enabling cross-feature privilege escalation and potential disclosure of sensitive data. No public exploit code exists and EPSS is 0.25%, but SSVC rates technical impact as total, making this a meaningful risk in multi-tenant or role-segmented Kibana deployments.
Local privilege escalation to full product takeover in Oracle Communications BRM - Elastic Charging Engine (versions 15.0.0.0.0, 15.0.1.0.0, 15.1.0.0.0, 15.2.0.0.0) lets a low-privileged attacker with logon access to the host running the ECE infrastructure compromise the Diameter Gateway and SDK component. Per Oracle's CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N), exploitation is authenticated and local but easily performed, yielding high confidentiality, integrity, and availability impact (base 7.8). No public exploit identified at time of analysis, and the CVE is not listed in CISA KEV.
Unauthorized information disclosure and case-attachment tampering in Elastic Kibana lets a low-privileged authenticated user with limited file-management permissions read, alter, or delete case attachments belonging to feature areas they should not reach, including sensitive Security Solution cases. The flaw stems from Kibana's file-access authorization check and its resource retrieval using two different resolution mechanisms, allowing the authorization gate to be bypassed. No public exploit identified at time of analysis; not listed in CISA KEV, and EPSS was not provided.
Authorization bypass and information disclosure in GeoNetwork 4.x (4.0.0-alpha.1 through 4.4.10) lets an unauthenticated remote user retrieve restricted metadata records through the Elasticsearch-backed search API. Under certain request conditions the proxy layer skips the step that injects GeoNetwork's access-control filters, so requests reach the index without group-visibility, ownership, draft-exclusion, or portal filtering applied. There is no public exploit identified at time of analysis, but the flaw is unauthenticated and network-reachable on any public-facing instance, making disclosure of non-public catalog records trivial once the triggering condition is known.
Log injection in Elastic Kibana (fixed in 7.17.15 and 8.11.1) allows an attacker with low-privilege access to embed unneutralized control characters in input that Kibana writes verbatim to its log files; when an operator later views those logs in a terminal that interprets ANSI/control sequences, the injected payload can forge, hide, or rewrite displayed log content. The issue is tracked as CWE-117 (Improper Output Neutralization for Logs) and carries a vendor CVSS of 8.0. There is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Denial of service in Elastic Fleet Server (versions 8.0.0-8.19.10 and 9.0.0-9.2.4) allows remote attackers to exhaust memory by sending a specially crafted request to an upload endpoint, driving excessive allocation until the server becomes unresponsive. The flaw is a resource-throttling failure (CWE-770) with availability-only impact and no confidentiality or integrity loss. No public exploit identified at time of analysis; EPSS is low (0.30%, 22nd percentile) and CISA SSVC records no observed exploitation.
Authentication bypass in Daytona prior to 0.184.0 allows attackers to join organizations via pending invitations using unverified email addresses. The invitation accept and decline paths failed to enforce email verification (unlike organization creation), so on OIDC identity providers permitting self-service signup with pre-verification sessions, an attacker registering an email matching a pending invite can claim it and inherit the assigned role - up to Owner. No public exploit identified at time of analysis, but the path to full Owner-level organization takeover makes this a high-priority fix.
Unauthenticated NoSQL operator injection in Budibase server <= 3.39.0 allows anonymous attackers to read or modify all documents in any MongoDB, CouchDB, Elasticsearch, DynamoDB-PartiQL, or REST-with-JSON-body datasource when a builder has published a query with a PUBLIC role. By injecting JSON metacharacters through query parameters, an attacker can override the intended filter, bypass authentication, and exfiltrate sensitive data or mass-update records in a single HTTP request. Exploit code is publicly available, though no active exploitation is confirmed, and the vulnerability has been patched in version 3.39.12.
Server-side request forgery in Open WebUI versions 0.9.5 and earlier allows authenticated OAuth users to read arbitrary internal HTTP responses by abusing the `_process_picture_url` function in `backend/open_webui/utils/oauth.py`, which validates only the initial URL and then permits aiohttp's default 10-redirect follow chain to reach internal addresses. The decoded response body is stored in the attacker's `profile_image_url` and retrievable via `GET /api/v1/auths/`, yielding cloud metadata credentials and access to localhost-bound services. Publicly available exploit code exists (detailed sentinel-verified PoC supplied by the reporter); no public exploit identified at time of analysis in the form of weaponized tooling, and the CVE is not on the CISA KEV list.
NoSQL/query injection in Spring AI Vector Stores (1.0.0-1.0.8 and 1.1.0-1.1.7) allows remote unauthenticated attackers to inject special characters into vector-store inputs and force execution of arbitrary queries against Elasticsearch, OpenSearch, and GemFire VectorDB backends. The flaw resides in the spring-ai-elasticsearch-store, spring-ai-opensearch-store, and spring-ai-gemfire-store components, enabling information disclosure and limited integrity/availability impact against any application embedding Spring AI's vector-store abstraction. No public exploit identified at time of analysis, but the CVSS 8.6 (scope unchanged here, network vector, no privileges) makes this a high-priority patch for any Spring AI deployment ingesting untrusted text.
Server-Side Request Forgery in Elastic Kibana 9.3.0 through 9.3.2 lets an authenticated user holding connector management privileges override the operator-configured connector allowlist and force the Kibana server to make outbound requests to destinations that egress controls were meant to block. Because the request originates from the trusted server, an attacker can reach internal or otherwise restricted network services and exfiltrate their responses. EPSS is very low (0.03%, 9th percentile) and there is no public exploit identified at time of analysis, but the scope-changing CVSS 7.7 rating reflects meaningful confidentiality impact against internal assets.
Server-side request forgery in Elastic Kibana allows authenticated users holding connector management privileges to bypass operator-configured egress allowlists by crafting a Webhook connector with an arbitrary target. The flaw enables Kibana to issue outbound HTTP requests to internal or otherwise restricted destinations, exposing sensitive data accessible from the Kibana host. No public exploit identified at time of analysis, and the vulnerability is not present on the CISA KEV list.
Kibana's dashboard management functionality in versions 8.0.0 through 8.19.15 and 9.0.0 through 9.3.4 accepts a dashboard identifier that is not properly normalized, allowing an authenticated user with only limited dashboard-creation permissions to embed path-traversal sequences in that identifier; when an administrator later deletes the dashboard through the Kibana UI, the request is redirected to an unintended internal endpoint and can destroy user accounts or other resources. Exploitation is distinctly conditional rather than automatic - it requires valid low-privilege credentials (PR:L) plus a privileged human delete action (UI:R), and CISA's SSVC scoring marks it non-automatable and of partial technical impact, with integrity and availability effects but no data disclosure. There is no public exploit identified at time of analysis (EPSS 0.03%, 8th percentile), and Elastic shipped fixes in Kibana 8.19.16 and 9.3.5 under ESA-2026-30; overall this is a moderate-severity, low-urgency issue despite the 7.3 CVSS base score.
Server-Side Request Forgery (SSRF) in Open WebUI versions ≤0.8.12 allows authenticated users with OAuth access to force the server to make HTTP requests to arbitrary internal resources and exfiltrate complete response data. Exploitation requires OAuth-enabled deployments with ENABLE_OAUTH_SIGNUP=true or OAUTH_UPDATE_PICTURE_ON_LOGIN=true. An attacker controls the OAuth provider's 'picture' claim URL, triggering server-side HTTP requests to cloud metadata services (AWS IMDS), localhost services (Redis, Elasticsearch), or internal network endpoints. The full response is base64-encoded and stored in the user's profile_image_url field, enabling complete data exfiltration. Fixed in version 0.9.0 per GitHub advisory GHSA-24c9-2m8q-qhmh. EPSS data not available; no CISA KEV listing indicates limited widespread exploitation, though publicly available proof-of-concept exists in the GitHub advisory.
Remote unauthenticated attackers can delete arbitrary ElasticSearch documents and MinIO storage files in nexent v1.7.5.2 via the unprotected DELETE /{index_name}/documents endpoint. The backend service fails to authenticate requests or validate the path_or_url parameter, enabling mass data destruction and denial of service. EPSS probability (0.12%) indicates low predicted exploitation likelihood, and no active exploitation or public exploit code has been identified at time of analysis, though the CVSS 9.1 reflects the severe impact of unauthenticated remote data deletion.
Remote code execution in Elastic Logstash versions 8.0.0 through 8.19.13 allows unauthenticated network attackers to write arbitrary files and execute code via malicious compressed archives. The vulnerability exploits improper path validation in archive extraction utilities, enabling attackers who compromise or control update endpoints to deliver path traversal payloads. When automatic pipeline reloading is enabled, arbitrary file writes escalate to full RCE with Logstash process privileges. CVSS 8.1 (High) with network vector but high attack complexity. EPSS data and KEV status not provided; no public exploit confirmed at time of analysis, though the technical details disclosed increase weaponization risk for environments with exposed update mechanisms.
Server-Side Request Forgery in Kibana One Workflow allows authenticated users with workflow privileges to bypass host allowlist restrictions in the Workflows Execution Engine, enabling unauthorized access to sensitive internal endpoints and data disclosure. Affects Kibana versions 9.3.0 through 9.3.2. No public exploit code or active exploitation has been confirmed at time of analysis.
Authenticated Kibana users with Fleet management privileges can read Elasticsearch index data beyond their intended RBAC permissions through debug route handlers in the Fleet plugin. This scope bypass affects Elastic Kibana deployments where users hold Fleet sub-feature privileges (agent policies, settings management). The vulnerability requires low-privilege authentication (PR:L) and has network attack vector (AV:N) with low complexity (AC:L), enabling cross-scope data confidentiality breach (S:C/C:H). No public exploit identified at time of analysis. EPSS data not available, but the specific privilege escalation vector and remote exploitability warrant prioritization in Kibana Fleet deployments.
Server-Side Request Forgery in PraisonAI's passthrough API allows authenticated remote attackers to access internal cloud metadata services and private network resources. The vulnerability affects the praisonai Python package where the passthrough() and apassthrough() functions accept unvalidated caller-controlled api_base parameters that are directly concatenated and passed to httpx requests. With default AUTH_ENABLED=False configuration, this is remotely exploitable to retrieve EC2 IAM credent
Kibana versions up to 9.3.0 contains a vulnerability that allows attackers to read arbitrary files from the Kibana server filesystem, and perform Server-Side (CVSS 8.6).
Kibana versions 6.7.0 to 6.8.8 and 7.0.0 to 7.6.2 contain a prototype pollution flaw in the Upgrade Assistant. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Kibana versions before 5.6.15 and 6.6.1 contain an arbitrary code execution flaw in the Timelion visualizer. Rated critical severity (CVSS 10.0), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
The Groovy scripting engine in Elasticsearch before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to bypass the sandbox protection mechanism and execute arbitrary shell commands via a crafted. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Actively exploited in the wild (cisa kev) and public exploit code available.
The default configuration in Elasticsearch before 1.2 enables dynamic scripting, which allows remote attackers to execute arbitrary MVEL expressions and Java code via the source parameter to _search. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, low attack complexity. Actively exploited in the wild (cisa kev) and public exploit code available.
Permission-filtered search in Backstage deployments that use an Elasticsearch or OpenSearch backend can return documents that a DENY policy should have withheld, because an empty list of permitted document types causes the engine to issue an unfiltered query across all indices instead of returning zero results. Only authenticated Backstage users (CVSS PR:L) are positioned to trigger this, and only when permission.enabled is set to true, the search backend is Elasticsearch/OpenSearch rather than the default in-memory engine, and the user is actually governed by a DENY policy for one or more search document types; the impact is limited to confidentiality (C:L) with no integrity or availability effect. The vendor has released fixes in @backstage/plugin-search-backend 2.1.6 and @backstage/plugin-search-backend-module-elasticsearch 1.8.7 (Backstage release v1.54.1), and there is no public exploit identified at time of analysis. Consistent with our independent assessment, this is a genuine but low-urgency information-disclosure issue rather than a high-priority emergency.
Denial of service in Elasticsearch allows an authenticated user (CVSS vector PR:L) who holds read access to a single index to crash a node by defining a scripted runtime field whose script output builds a deeply nested geometry value; because serialization of script-generated geometry lacks the nesting-depth limit applied to text-supplied geometry, recursion exhausts the stack and the node terminates, and on some deployments it does not recover without manual intervention. The issue is availability-only (C:N/I:N/A:H, CVSS 6.5) with no data exposure, and no public exploit code was identified at time of analysis. Fixes are released in Elasticsearch 8.19.23, 9.4.8, and 9.5.5 per ESA-2026-198, so this is a moderate-priority patching item rather than an emergency, but clusters that allow untrusted users to read indices while scripting/runtime fields are enabled should treat it as more urgent.
Denial of service in Elasticsearch allows an authenticated user holding read access to just a single index to terminate a cluster node by submitting a search request whose aggregation definitions are deeply and maliciously nested. Processing the request drives unbounded recursive execution that exhausts the node's resources and crashes the affected process, which does not recover on its own and requires manual intervention to restore service. The flaw is scored CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), is availability-only, and no public exploit code or confirmed active exploitation was identified at time of analysis; the practical barrier is the authenticated read privilege prerequisite rather than remote reachability.
Denial of service in Elasticsearch lets an authenticated user who holds connector management privileges exhaust node heap memory by creating a connector resource with an excessively large description field and then causing that resource to be accessed or read, crashing the affected node. The path is network-reachable but requires PR:L authorization, and the impact is limited to availability with no data confidentiality or integrity loss. No public exploit code has been identified at time of analysis, and Elastic has released fixed versions 8.19.2, 9.0.6, 9.1.4, and 9.2.1 in advisory ESA-2026-195.
Denial of service in Elastic Endpoint on Windows can crash and repeatedly restart the endpoint protection process when it handles a specially crafted file name under Chinese, Japanese, or Korean system locales. The vendor advisory identifies fixes in Elastic Agent/Endpoint 8.19.22, 9.4.8, and 9.5.5 (ESA-2026-194), so Windows Elastic Defend deployments below those builds on the corresponding release lines should be treated as potentially affected. No public exploit code or CISA KEV entry was provided, and the independent assessment characterizes this as a moderate-priority, availability-only issue rather than a high-impact breach risk.
Sensitive information disclosure in Kibana 9.4.x and 9.5.x allows an authenticated user with limited Fleet management privileges to read private cryptographic key material that should be restricted to Fleet settings administrators. The exposed material can include Fleet Server host-connection keys, potentially enabling impersonation of trusted Fleet infrastructure in deployments where those keys are actively used; no public exploit identified at time of analysis. Vendor fixes are available in Kibana 9.4.8 and 9.5.5 per Elastic Security Advisory ESA-2026-193.
Denial of service in Elasticsearch allows authenticated users holding the manage_index_templates cluster privilege to exhaust node heap by registering multiple index-template resources with metadata near the per-resource size limit and then triggering a combined retrieval that materializes all metadata in memory simultaneously. Affected versions include Elasticsearch releases prior to 9.4.7, 9.5.3, and 8.19.23, as addressed in ESA-2026-192. No public exploit code has been identified at time of analysis, and exploitation requires the specified privilege, limiting the attack to trusted operators or compromised privileged accounts.
Missing authorization in Kibana's Metrics Experience feature lets an authenticated user who holds only Elasticsearch index-level read privileges - but no corresponding Kibana feature privilege - pull back index-derived metric data that a correctly protected sibling API would have blocked. Exploitation requires valid credentials (CVSS PR:L, remote, no user interaction) and is confined to information disclosure (C:L), giving a modest CVSS 3.1 base score of 4.3. Kibana installations running 9.4.0 or later are not affected, and no public exploit code or active exploitation has been identified at time of analysis.
Denial of service in Elasticsearch 9.x lets an authenticated attacker holding only low-privilege credentials terminate a node by submitting a request that drives uncontrolled recursion and excessive memory allocation, taking down cluster availability. The CVSS 6.5 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) confirms availability-only impact with no data exposure or modification, reachable over the network with no user interaction or non-default configuration - though authentication at a low privilege level is required, so exposure is limited to insiders, compromised credentials, or over-permissive accounts. Exploitation status is no public exploit identified at time of analysis (no CISA KEV listing, EPSS not available), making this a moderate, availability-only risk rather than a top-tier emergency; vendor fixes are published as Elasticsearch 9.4.8 and 9.5.5 in ESA-2026-190.
Denial of service in Elasticsearch stems from catastrophic backtracking in the ES|QL CHUNK function, which accepts user-supplied regular expressions as text-splitting separators without validating their computational complexity or bounding their execution time. An authenticated attacker who holds read access to any text-based index and can invoke CHUNK through ES|QL can submit a crafted pattern that drives exponential regex blowup, consuming excessive CPU on Elasticsearch worker threads and degrading query throughput for other tenants on the affected node, though the cluster does not crash. CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) reflects a bounded availability-only impact, no public exploit code was identified at time of analysis, and patched releases are available as Elasticsearch 8.19.22, 9.4.8, and 9.5.5 per Elastic security update ESA-2026-189.
Unauthorized data stream modification in Elasticsearch allows an authenticated user who holds privileges over only a single resource to alter data streams outside their authorized scope through the Modify Data Streams API, enabling data injection into those streams or degrading their searchability. The flaw is rated CVSS 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) and is confined to integrity and availability - it explicitly does not let the attacker read a data stream they could not already access. Only deployments running 7.17.5-7.17.29, 8.2.2-8.19.18, 9.0.0-9.3.7, or 9.4.0-9.4.3 are affected, and there is no public exploit identified at time of analysis; the vendor security update (ESA-2026-188) points to fixed releases 8.19.19, 9.3.8, and 9.4.4.
Denial of service in Elasticsearch 8.x and 9.x lets an authenticated user with only low privileges crash cluster nodes by submitting a specially crafted query that drives uncontrolled memory growth in the query processing engine, ending in an out-of-memory termination. Because the trigger can be repeated - including through queries embedded in shared resources such as saved searches or stored queries - the result can escalate from a single node restart to persistent cluster unavailability, though there is no data disclosure or modification path. The flaw is rated CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), and no public exploit code has been identified at time of analysis.
Resource exhaustion in Elasticsearch allows an authenticated high-privilege user to consume excessive node resources, causing denial of service through availability loss (CVSS 4.9). Affected deployments are all Elasticsearch versions before the vendor-fixed releases 8.19.22, 9.4.7, and 9.5.3, as reflected by the CPE wildcard and Elastic Security Advisory ESA-2026-184. Exploitation requires an authenticated account with high privileges (CVSS PR:H) and network access to the cluster API; there is no public exploit identified at time of analysis, and the issue is not confirmed actively exploited (CISA KEV). Impact is limited to availability, with no confidentiality or integrity effect, and realistic risk is confined to malicious insiders or attackers who already hold privileged credentials.
Authenticated denial of service in Elasticsearch lets a valid low-privilege account drive the node or cluster into uncontrolled resource consumption through an allocation-heavy request path, degrading or halting availability (CVSS 6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Only users holding at least a low-privileged, network-reachable API account can trigger it - an unauthenticated remote attacker cannot, and there is no confidentiality or integrity impact. Elastic rates this a genuine but modest-severity availability issue rather than a top-tier priority: no public exploit code has been identified at time of analysis, no CISA KEV listing applies, and the advisory does not name the specific endpoint or query construct that acts as the allocation sink. Vendor-released patches exist in Elasticsearch 8.19.22, 9.4.7, and 9.5.4 (ESA-2026-183).
Denial of service in Elasticsearch is possible because of uncontrolled resource consumption (CWE-400) that allows an authenticated user to drive excessive allocation and exhaust cluster resources. Elasticsearch deployments prior to 9.4.7 and 9.5.4 are affected; the issue is remote and low-complexity but requires valid low-privilege credentials or an API key (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), and the impact is limited to availability with no data disclosure or modification. There is no public exploit identified at time of analysis and no confirmed active exploitation, and the vendor-scored severity of 6.5 places this as a moderate availability-only issue rather than a top-tier priority.
Denial of service in Elastic Kibana allows an authenticated low-privilege user with network access to the Kibana HTTP interface to exhaust server resources and render the instance unavailable. The flaw is an uncontrolled resource consumption issue (CWE-400, CAPEC-130 Excessive Allocation) rated CVSS 3.1 base 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), meaning availability impact only, with no confidentiality or integrity loss and no user interaction required. Exploitation requires a valid session at low privilege (PR:L), so a fully unauthenticated attacker cannot trigger it per the assessed vector; no public exploit code and no confirmed in-the-wild exploitation were identified at time of analysis. Elastic has published fixed versions in 8.19.22, 9.4.7, and 9.5.3.
Authenticated denial of service in Elasticsearch lets a low-privilege user with network reachability to the cluster API exhaust node or cluster resources through a crafted request that triggers uncontrolled allocation (CWE-400 / CAPEC-130), driving availability-only degradation rather than data theft or code execution. The vendor-assessed CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 6.5) confirms the attacker must first hold valid low-privilege credentials (or reach an improperly exposed/authenticated API endpoint), that no user interaction is needed, and that confidentiality and integrity are unaffected while scope remains unchanged to the single affected deployment. Practical exposure is greatest in multi-tenant clusters or environments where the Elasticsearch HTTP API is broadly reachable; properly segmented single-tenant clusters face lower risk, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Authenticated denial of service in Elasticsearch allows a remote attacker holding only low-privilege credentials to drive uncontrolled resource consumption, exhausting node memory and degrading or halting cluster availability (CVSS 6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Impact is confined to availability - there is no confidentiality or integrity loss - and exploitation requires a valid account, API key, or service token, so fully unauthenticated attackers cannot trigger it against a properly secured cluster. No public exploit code or confirmed active exploitation has been identified at time of analysis, and vendor fixes are available in Elasticsearch 8.19.22, 9.4.7, and 9.5.4 (ESA-2026-179).
Denial of service in Elasticsearch allows a network-reachable, low-privilege authenticated user to exhaust cluster resources through excessive allocation, degrading availability down to a full outage while leaving data confidentiality and integrity intact (CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). The flaw is an uncontrolled resource consumption bug (CWE-400 / CAPEC-130 Excessive Allocation), and the CPE record lists elastic:elasticsearch without version constraints, so every unpatched Elasticsearch deployment is presumed affected pending the vendor advisory ESA-2026-176. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV; exploitation requires valid low-privilege credentials (a low-tier user, service account, or API key), which limits the population of attackers able to trigger it. The specific endpoint, query type, or configuration that produces the excessive allocation is not named in the available data describing the flaw and must be confirmed against the Elastic advisory.
Denial of service in Elasticsearch allows a network-reachable, low-privileged authenticated user (PR:L) to exhaust server resources and take the cluster's availability down by triggering uncontrolled resource allocation; no user interaction is required (AC:L, UI:N) and the impact is availability-only (C:N/I:N/A:H, base score 6.5). Because a valid account with minimal privileges is a prerequisite, clusters that enforce authentication and limit network exposure are materially less exposed, and the attack cannot be launched fully unauthenticated. No public exploit code and no confirmed active exploitation were identified at time of analysis, so the practical risk is concentrated in multi-tenant or broadly reachable clusters where low-privilege access is easy to obtain; Elastic has published fixed versions in 8.19.21, 9.4.6 and 9.5.3 under advisory ESA-2026-170.
Authenticated Kibana users who hold Synthetics privileges scoped to just one space can permanently delete Synthetics monitors that are shared into other spaces they are not authorized to access, because the space-scoped authorization check is missing on the delete path (CVSS 6.5, PR:L, I:H). When a targeted monitor is tied to a private location, the same action also tears down the underlying Elastic Agent integration configuration, bypassing the authorization controls Fleet would normally enforce. The flaw is limited to space-to-space abuse inside a single Kibana/Elastic deployment rather than cross-tenant compromise, and no public exploit identified at time of analysis; Elastic has published a security update (ESA-2026-139) addressing it.
Cross-user authorization bypass in Elastic Kibana lets an authenticated user who holds the Timeline feature privilege in a Kibana space enumerate, read, modify, and delete draft Timeline objects that belong to other users in that same space, because object ownership is enforced through a user-controlled key rather than through a proper ACL check. Only Timeline read privilege is needed to enumerate and disclose other users' drafts, while the Timeline write privilege is additionally required to alter or delete them; the issue is therefore meaningful only in multi-user, shared Kibana spaces where Timeline privileges are granted to more than one principal, and it is rated CVSS 6.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L), indicating moderate confidentiality, integrity, and availability impact. No public exploit code has been identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV); the vendor advisory referenced for this CVE points to the Kibana 8.19.22 and 9.4.6 security update (ESA-2026-103).
Server-side request forgery in Adminer's optional Elasticsearch driver (plugins/drivers/elastic.php) lets unauthenticated remote attackers force the Adminer host to issue HTTP GET requests to arbitrary reachable hosts and ports, because include/auth.inc.php calls Driver::connect() before it validates the submitted login result. Versions 4.16.0 through 6.0.1 are affected and the issue is conditional: it requires that the optional Elasticsearch driver be explicitly deployed (via the adminer/elastic.php template or an adminer_object() configuration) and that PHP allow_url_fopen be enabled so get_url()/file_get_contents() can send the outbound request. Impact is limited to low-confidentiality reconnaissance - a port-scanning oracle built from leaked JSON error fields and connection-failure text rendered on the login page - with no integrity or availability impact, and the independent assessment rates the issue MEDIUM, consistent with the vendor's CVSS 4.0 base score of 6.9; fixed in 6.0.2 and no public exploit identified at time of analysis.
Unauthenticated access to Elasticsearch index management endpoints in MoguBlog's mogu_search microservice (through version 6.2) allows any remote attacker to wipe, restructure, or poison the platform's blog search index. The ElasticSearchRestApi controller exposes POST operations - index initialization, bulk delete, single-document delete, and arbitrary entry injection - without any authentication gate in WebSecurityConfig. Four distinct proof-of-concept Python scripts are publicly available on GitHub, scripting each attack path and significantly lowering the exploitation barrier.
Path traversal in n8n's Elasticsearch and ElasticSecurity workflow nodes allows a low-privileged workflow editor to escape the intended Elasticsearch index scope and reach arbitrary indices or cluster administration endpoints using the platform's stored Elasticsearch credentials. Exploitation requires the ability to create or edit workflows containing Elasticsearch nodes, and the root cause is the absence of proper URL path-segment encoding (toPathSegment) in GenericFunctions.ts before identifiers are interpolated into REST request paths. No public exploit code or CISA KEV listing is present at time of analysis, but the scope change to a backend Elasticsearch cluster elevates the real-world impact beyond the CVSS base score suggests.
Incorrect authorization in Kibana (CWE-863) allows a low-privileged authenticated user to access data or resources beyond their intended authorization level, resulting in high-impact confidentiality breach. Affected versions are addressed in Kibana 9.4.6 and 9.5.3 per Elastic advisory ESA-2026-175. No public exploit code or CISA KEV listing has been identified at time of analysis.
Incorrect Authorization (CWE-863) in Kibana allows a low-privileged authenticated user to exploit misconfigured access control levels, resulting in partial denial of service against the Kibana instance. Affected across Kibana 8.x and 9.x branches, with fixes released in versions 8.19.21, 9.4.6, and 9.5.3 per Elastic advisory ESA-2026-174. No public exploit code or active exploitation has been identified at time of analysis.
Privilege abuse in Kibana allows an authenticated user holding Security read-level access in a single Kibana space to trigger Entity Analytics migration operations that perform write actions across all Kibana spaces, violating the platform's space-isolation access control model. The vulnerability stems from CWE-862 (Missing Authorization): the migration API endpoint executes privileged writes without verifying whether the caller's authorization scope covers the target spaces. No public exploit has been identified at time of analysis; a vendor patch is available per ESA-2026-154.
Cross-space agent data exposure in the Kibana Fleet feature allows authenticated low-privileged users to read agent metadata and diagnostic content outside their authorized Kibana space. An attacker holding read-level Fleet agent privileges in any one Kibana space can enumerate agents enrolled in other spaces - bypassing the space-based access boundary that Elastic uses for multi-tenancy isolation. No public exploit or active exploitation has been identified; CVSS 4.3 with PR:L aligns with the real-world impact: meaningful tenant boundary breach, but limited to read-only metadata disclosure.
Template injection in Kibana's Cribl integration allows a low-privileged authenticated user holding Fleet management rights to write Elasticsearch ingest pipelines exceeding their authorized Elasticsearch permissions. The flaw stems from insufficient validation of a configuration field that is rendered server-side as a script template, giving the attacker a code injection foothold (CWE-94) into the pipeline generation path. No public exploit has been identified at time of analysis, and the CVSS score of 4.3 (PR:L/I:L) reflects the constrained privilege requirement and limited integrity impact.
Query injection in n8n's Elasticsearch and Google Cloud Firestore workflow nodes allows a low-privileged authenticated user to escalate a single-document lookup into a full-collection read by injecting quote and brace characters into expression values. Affected versions are n8n before 2.35.4 and 2.36.x before 2.36.2. The CVSS 4.0 vector scores this at 6.3 with high subsequent-system confidentiality impact, reflecting that the vulnerable system itself is not directly compromised but the connected Elasticsearch or Firestore data stores can be fully exposed. No public exploit code or active exploitation has been identified at time of analysis.
Incorrect Authorization (CWE-863) in Kibana's machine learning feature allows authenticated users to invoke ML functionality beyond their assigned authorization scope, consuming Elasticsearch cluster resources they are not permitted to access. Affected across all Kibana versions prior to the 8.19.21, 9.4.6, and 9.5.2 releases patched under Elastic advisory ESA-2026-169. No confidentiality or integrity impact is present; exploitation is bounded to cluster resource exhaustion, with CVSS 4.3 (Medium) reflecting the limited blast radius and authentication prerequisite.
Memory exhaustion denial of service in Filebeat's HTTP ingestion endpoint allows an authenticated low-privileged attacker to crash the Filebeat process by sending specially crafted compressed payloads that trigger unbounded decompression (a decompression-bomb / zip-bomb pattern). Affected versions span the 8.x and 9.x branches, with patched releases 8.19.18 and 9.3.1 published under Elastic Security Advisory ESA-2026-165. No public exploit code or CISA KEV listing has been identified at time of analysis, and exploitation is constrained to attackers who can reach the HTTP input endpoint.
Incorrect authorization in Elastic Fleet Server allows any authenticated enrolled agent to interfere with multi-part upload sessions belonging to other enrolled agents, causing a denial of service of those upload operations. Fleet Server fails to verify session ownership during chunked data uploads, meaning a low-privileged agent credential is sufficient to disrupt peer agent activity. No public exploit exists and no active exploitation has been confirmed; CVSS rates this Low (3.1) reflecting the authentication prerequisite and high complexity timing condition.
Kibana's request processing layer fails to enforce memory allocation limits, allowing any authenticated low-privilege user to trigger unbounded heap consumption and deny service to all users of the instance. Elastic's advisory ESA-2026-163 discloses the issue across all Kibana branches and releases fixes in versions 8.19.16, 9.3.5, and 9.4.2. No public exploit code or active exploitation has been identified at time of analysis.
Observable response discrepancy in Kibana's Osquery feature enables cross-space scheduled query ID enumeration by authenticated low-privileged users. An attacker holding Osquery live-query privileges can determine whether a scheduled query identifier exists in a Kibana space they are not authorized to access by observing distinguishably different API responses. Vendor-released patch is version 9.4.4 per ESA-2026-161; no public exploit or CISA KEV listing is identified at time of analysis.
Authorization bypass in Elasticsearch's Remote Cluster Security (RCS) 2.0 cross-cluster search path lets an authenticated principal holding a cross-cluster API key for one index send a crafted request that is authorized against that permitted index while actually executing against a different, unauthorized index, exposing that index's document contents, field mappings and other metadata, and in limited cases permitting modification of retention-lease state on it. The flaw is an authenticated authorization-boundary bypass (CVSS 7.1, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N), so the real-world risk is concentrated in multi-tenant or shared clusters that issue cross-cluster API keys to less-trusted tenants, while single-tenant clusters without shared cross-cluster keys are not meaningfully exposed. No public exploit code has been identified at time of analysis.
Incorrect authorization in Elasticsearch 8.x and 9.x allows an authenticated, already-privileged user (CVSS PR:H) who has been granted a non-default, delegated role-management privilege to escalate privileges within a cluster. By abusing a role-definition setting that expands the set of indices matched against a delegated index-scoped privilege, the holder can modify their own assigned role and reach indices that should remain restricted, including internal security data, and from there potentially obtain full administrative control of the cluster. Exploitation is only possible when the cluster has the configurable delegated role-management privilege explicitly enabled and granted with a broadly-scoped index pattern; default deployments that never delegate this capability are not affected. No public exploit code has been identified at time of analysis and the flaw is not confirmed as actively exploited (not in CISA KEV). Vendor-released patches are available in Elasticsearch 8.19.22, 9.4.7, and 9.5.4.
Authorization bypass in Kibana's Fleet package installation process lets an authenticated user who holds delegated Fleet package-management privileges - but no direct Elasticsearch administrative rights - claim a data stream identifier already in use by another tenant sharing the same deployment. Because Fleet does not verify ownership of that identifier before applying the uploaded package's generated index and ingest-pipeline settings to pre-existing infrastructure, an attacker can redirect a victim tenant's subsequent data through infrastructure they control, achieving unauthorized disclosure and modification of that data and preventing it from reaching its intended destination (CVSS 8.8, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Exploitation requires a multi-tenant Kibana deployment with delegated Fleet privileges and valid authenticated access; it is impossible in single-tenant setups, and no public exploit identified at time of analysis.
Privilege escalation in Elastic Kibana's Agent Builder feature lets an authenticated non-administrative user who can edit a shared agent cause privileged operations to run under the identity of a higher-privileged user who later interacts with that agent (CWE-441 confused deputy). Rated CVSS 7.3 High (AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N), the flaw requires the Agent Builder feature to be enabled with at least one shared agent, the attacker to hold edit privileges on it, and a privileged victim to interact with the tampered agent; if the attacker can also author workflows, escalation to full Kibana and Elasticsearch cluster administrative control is possible. No public exploit identified at time of analysis, and vendor patches are available in Kibana 9.4.7 and 9.5.0.
Maliciously crafted on-chain account names processed by Klever-Go prior to 1.7.20 are spliced into Elasticsearch _bulk request bodies without JSON escaping, allowing an attacker who can submit a SetAccountName transaction to inject forged bulk actions that create, overwrite, or delete documents in any index the indexer can write to. Because the name is stored in consensus account state, the poisoned value is replayed by new and historical indexers, and no access to the indexing host or the Elasticsearch port is required. Severity is rated 8.4 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:L; our independent assessment CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H), exploitation requires an authenticated low-privilege on-chain account plus a deployment that actually runs the Elasticsearch indexer, and the issue is fixed in 1.7.20; no public exploit identified at time of analysis, though the upstream fix ships a regression test that reproduces the advisory's injection construction.
Authenticated attackers can read arbitrary Elasticsearch indices in zlt2000 microservices-platform through 6.0.0 by supplying any index name in the POST /search/{indexName} or GET /agg/requestStat/{indexName}/{routing} endpoints, bypassing authorization checks. This exposes sensitive data such as the sys_user index containing user records and password hashes; the vulnerability has a CVSS 4.0 base score of 7.1 and an assessed CVSS 3.1 vector of AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, meaning high confidentiality impact with no integrity or availability effect. Publicly available exploit code exists (no CISA KEV confirmation), and exploitation requires only a valid low-privilege session on a network-reachable search-center service.
Missing authorization in zlt2000 microservices-platform through 6.0.0 lets any authenticated account - including one with zero assigned roles - invoke administrative APIs for user management, role assignment, password resets by user ID, and Elasticsearch index deletion, because the shipped default of zlt.security.auth.urlPermission.enable is false and suppresses all permission checks once authentication succeeds. Exploitation is not pre-auth: it requires a valid low-privilege session against a deployment running the out-of-the-box configuration, and publicly available exploit code exists (VulnCheck-reported PoC scripts covering role-granting, user enumeration, password reset, and ES index deletion), though no confirmed active exploitation (CISA KEV) has been recorded. Assessed severity is high (CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 8.8; vendor-published CVSS 4.0 score 8.7) because a zero-role user obtains both read and write access to sensitive administrative functions.
Incorrect authorization in Apache Syncope (3.0.0-M0 through 3.0.16, 4.0.0-M0 through 4.0.7, and 4.1.0-M0 through 4.1.2) allows an authenticated principal that holds a search entitlement to retrieve identity and entity records outside its authorized realms by issuing a non-recursive search request. The Realms filter that normally constrains results to the requester's permissions can be rendered empty for non-recursive queries, effectively removing the privilege restriction before the search is translated into SQL, Neo4j, or Elasticsearch/OpenSearch queries; recursive searches are not affected. The exposure is backend-agnostic but gated by authentication and an existing search entitlement, so it is a data-confidentiality bypass rather than anonymous remote code execution - no public exploit code has been identified at time of analysis, EPSS is low (0.48%, ~40th percentile), and there is no CISA KEV listing. Vendor fixes are available in 4.0.8 and 4.1.3.
Stored cross-site scripting in Amundsen Frontend through 4.3.0 allows authenticated users with description-write access to inject arbitrary JavaScript into table, dashboard, and feature description fields, executing attacker-controlled code in the browser of every user who subsequently views search results. The root cause is React's dangerouslySetInnerHTML used without any HTML sanitization in ResourceListItem components (TableListItem and siblings), meaning payloads such as img elements with onerror handlers stored via the metadata service or Elasticsearch persist and fire on each page load. No public exploit code has been identified at time of analysis, but the attack pattern is elementary for anyone with metadata write access.
Incorrect authorization (CWE-863) in Elastic Kibana allows authenticated users holding only low-privilege accounts to modify configurations that should be restricted to higher-privilege roles, bypassing Kibana's access control enforcement. The CVSS vector (AV:N/AC:L/PR:L/UI:N, C:H/I:H/A:N) confirms the flaw is network-exploitable with minimal complexity and yields high confidentiality and integrity impact against Kibana's configuration plane. Elastic has released patched versions across the 8.x and 9.x release trains under advisory ESA-2026-178; no public exploit has been identified and the vulnerability is not listed in CISA KEV.
Privilege escalation in Kibana's Fleet management component allows any user holding Fleet management privileges to mint arbitrarily elevated Elasticsearch cluster credentials - up to full cluster administration - for every Elastic Agent enrolled in a targeted policy. Elasticsearch cluster privilege declarations sourced from integration packages were not validated before being used to generate agent credentials (CWE-863: Incorrect Authorization), enabling an attacker to inject overprivileged credentials across an entire agent fleet. No public exploit has been identified at time of analysis, and CISA KEV status is not confirmed, but the impact is laterally broad: a single privileged user can compromise all agents and the Elasticsearch cluster they authenticate to.
Path traversal in Kibana's Fleet feature enables a low-privileged attacker with Fleet Settings write access to plant a malicious pathname in settings that, when subsequently acted upon by an administrator, causes deletion of privileged internal resources including user accounts and organizational assets. All Kibana versions prior to 8.19.18, 9.3.6, and 9.4.3 are affected per ESA-2026-158. No public exploit code or active exploitation has been confirmed; the two-party nature of the attack - requiring both attacker write access and administrator interaction - moderates opportunistic exploitability despite the High CVSS rating.
Local privilege escalation in Elastic Agent on Windows enables a low-privileged local user to achieve SYSTEM-level code execution by exploiting overly permissive access controls (CWE-732) on resources created during unprivileged-mode installation. The agent service, running as SYSTEM, will execute attacker-controlled binaries placed via the CAPEC-642 binary replacement technique. Vendor-released patches 8.19.21, 9.4.6, and 9.5.2 are available per advisory ESA-2026-150; no public exploit identified at time of analysis.
Second-order path traversal in Kibana allows a low-privileged user with tag creation rights to cause an administrator's routine tag management action to operate on an unintended privileged resource, resulting in permanent deletion of administrator accounts or other organizational assets. Affected versions span the Elastic Stack deployment across the 8.x and 9.x series, with patches released in Kibana 8.19.16, 9.3.5, and 9.4.2. No public exploit has been identified and the vulnerability is not in the CISA KEV catalog, but the potential to delete administrative accounts elevates this beyond a typical medium-severity finding in multi-tenant deployments.
Missing authorization in Elasticsearch's custom inference service allows a low-privileged user holding only inference execution rights to redirect outbound inference traffic to an attacker-controlled endpoint, causing administrator-provisioned credentials to leak to that destination. Affected across the 8.x and 9.x branches (Elasticsearch 8.0.0 through 8.19.18, 9.0.0 through 9.3.7, 9.4.0 through 9.4.3, and 9.5.0), this is a privilege-abuse path where an underprivileged internal user effectively hijacks admin-level secrets without requiring elevated permissions. No public exploit or active exploitation has been identified; EPSS sits at 0.17% and SSVC rates technical impact as partial.
Remote code execution in Elasticsearch's machine learning component allows an authenticated user with ML model deployment privileges to execute arbitrary attacker-controlled logic on the Elasticsearch host node by supplying a crafted trained model artifact. The flaw stems from unsafe deserialization (CWE-502) of model artifact data during the ML inference loading process, granting the attacker a broader OS system-call surface than the ML subsystem is intended to expose. Elastic has released fixed versions 8.19.2, 9.4.5, and 9.5.1 via ESA-2026-114; no public exploit code or CISA KEV listing has been identified at time of analysis.
Privilege escalation in Kibana allows an authenticated user holding workflow edit permissions to cause scheduled workflow executions to run under the privileges of a higher-privileged user, granting unauthorized read and write access to data outside their authorization scope. The flaw (CWE-863, Incorrect Authorization) stems from Kibana's workflow scheduling subsystem failing to enforce authorization boundaries when executing scheduled jobs - a pattern classified under CAPEC-180. No public exploit exists at time of analysis, but the CVSS 8.3 (High) score with a network-accessible, low-privilege attack vector reflects genuine impact for any multi-user Kibana deployment. Elastic's advisory ESA-2026-61 references Kibana 9.4.3 as the fix release.
Log injection in @logtape/syslog allows network-accessible attackers to forge arbitrary syslog records in downstream collectors such as rsyslog, Splunk, and Elastic Stack. The escapeStructuredDataValue() function omits C0 control character escaping, so a literal newline embedded in a log property value terminates the current RFC 6587 TCP syslog frame and begins a new one; if the attacker-supplied bytes constitute a valid RFC 5424 header, the downstream collector accepts them as a separate, authentic-looking record. A second injection path exists through unvalidated SD-NAME keys, which can prematurely close structured-data elements. Both paths require the non-default SyslogSinkOptions.includeStructuredData: true setting. Publicly available proof-of-concept code exists; no CISA KEV listing at time of analysis.
Elasticsearch API key leakage in Kibana Fleet exposes enrolled agent credentials to any low-privileged authenticated user through a filter-based side channel. Fleet's agent listing endpoint accepts caller-supplied filter expressions evaluated under Kibana's own elevated internal Elasticsearch privileges rather than the caller's, and the match count in each response functions as a boolean oracle, enabling character-by-character reconstruction of the full API key value across all Kibana versions prior to 8.19.20, 9.4.5, and 9.5.1. No public exploit code has been identified and the vulnerability is not listed in the CISA KEV catalog at time of analysis, but the CVSS 7.1 (C:H) rating reflects the severity of full credential exfiltration via an authenticated, network-reachable, low-complexity attack.
Privilege escalation in Kibana Fleet allows an authenticated low-privileged user to bypass integration-scoped authorization controls by exploiting a logic flaw in how policy update requests are validated (CWE-863). An operator holding only the Elastic Defend endpoint policy management role can craft a Fleet API update request that substitutes a different integration type into an existing endpoint policy they control, because Fleet evaluates the authorization check against the stored policy's original integration rather than the replacement integration supplied in the request. No public exploit code has been identified at time of analysis, but the vendor (Elastic) has issued advisory ESA-2026-127 with patched releases.
Cross-space authorization bypass in Kibana allows authenticated users to access trained machine learning model inference outputs, and stop or modify active model deployments, in Kibana Spaces they are not authorized to access. The vulnerability arises because API endpoints for ML model inference and deployment management accept user-controlled resource identifiers without enforcing space-level ACL boundaries, enabling privilege escalation across the Space isolation boundary. No public exploit code has been identified and Elastic has released fixed versions 8.19.20, 9.4.5, and 9.5.1 per advisory ESA-2026-126.
Incorrect authorization in Kibana Agent Builder allows authenticated users to access, modify, or delete private agents they do not own when sharing a username with another principal across different Elasticsearch authentication realms. The flaw stems from a fallback ownership check that compares usernames - which are not unique across realms - rather than stable user identifiers, enabling cross-realm identity confusion. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis, but the low attack complexity and network accessibility make this a credible insider or multi-tenant threat.
Heap corruption and potential remote code execution in Elasticsearch's native ML inference engine can be triggered by any user holding the low-privilege ML model upload and deploy permission. By crafting a model that embeds an operation computing a memory address from an attacker-controlled offset, a low-privileged authenticated user can cause the native inference subprocess to read and write outside its allocated heap, reliably crashing that process or, under controlled heap layout conditions, executing arbitrary code within it. No active exploitation or public proof-of-concept has been identified at time of analysis, but the CVSS 8.8 rating, network-accessible vector, and explicit RCE potential in the vendor description place this in the urgent-remediation tier for any organization running Elasticsearch with ML features delegated to non-admin users.
Privilege escalation in Kibana arises from insufficient CSRF protection in the Vega visualization engine, affecting all versions prior to 8.19.20 and 9.4.5. Any Kibana user with visualization creation rights can embed a specially crafted Vega specification that, when rendered by a higher-privileged user's browser, silently issues authenticated HTTP requests to Kibana under the victim's session credentials. No public exploit code has been identified and no CISA KEV listing exists at time of analysis, though the low attack complexity and widely deployed nature of the product make this a meaningful remediation priority.
Missing Authorization in Kibana's Elastic Security module permits authenticated users holding detection rule authoring privileges to execute Osquery live queries and Elastic Defend response actions against enrolled managed endpoints without possessing the specific Osquery or Elastic Defend privileges that normally govern those capabilities. The CVSS 8.1 score reflects a network-accessible, low-complexity attack path with high confidentiality and integrity impact against enrolled host infrastructure. No active exploitation has been confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis, but patch versions 8.19.20 and 9.4.5 are available per Elastic Security Advisory ESA-2026-96.
Relative path traversal in Kibana's Fleet component allows an authenticated low-privileged user to delete arbitrary Kibana resources by supplying a crafted Fleet Server host configuration identifier containing traversal sequences. Elastic has confirmed the flaw in ESA-2026-94 and released patched versions 8.19.17, 9.3.6, and 9.4.3. No public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Server-side code injection in Elastic Fleet Server (8.5.0-8.19.19, 9.0.0-9.4.4, and 9.5.0) lets an actor who can define an output configuration in Kibana smuggle script syntax through an output identifier that is never restricted to safe characters. Because Fleet Server later concatenates that identifier into a script it builds during routine agent policy processing, embedded script fragments execute on the server rather than being treated as inert data, yielding attacker-controlled code execution (CWE-94). No public exploit identified at time of analysis and EPSS is low (0.36%), but SSVC rates technical impact as total.
Kibana's Machine Learning subsystem fails to enforce space-level authorization, allowing any authenticated low-privilege user in one Kibana space to read ML data from all other spaces and make unauthorized modifications across the entire deployment. The root cause is that ML operations execute with elevated internal Elasticsearch permissions while a subset of ML functionality omitted the per-request space isolation filter that enforces tenancy boundaries. No public exploit has been identified, but the attack requires only a standard user account, making it a realistic internal threat in multi-tenant or shared Kibana deployments. Fixed versions 8.19.20 and 9.4.5 are referenced in the Elastic security advisory ESA-2026-92.
Elastic Kibana's Elastic Security endpoint policy editor exposes sensitive Elastic Defend telemetry through a privilege escalation in the field value suggestion feature. Authenticated users holding Kibana Elastic Security feature privileges - but lacking Elasticsearch index-level read access to Elastic Defend event indices - can retrieve field values including process command line arguments, which routinely contain credentials, API tokens, and connection strings harvested from protected endpoints. No public exploit has been identified at time of analysis, but the low attack complexity and scope change across the Kibana-to-Elasticsearch authorization boundary make this straightforward to abuse by any user with a qualifying Kibana role.
Missing authorization on Kibana's Observability Onboarding API routes allows any authenticated low-privilege user sharing a Kibana space to enumerate, read, and overwrite the onboarding flow state of other users in that space. Affected installations include all Kibana versions prior to 8.19.19 and 9.4.5 across both self-managed and Elastic Cloud deployments. No public exploit code has been identified at time of analysis and this vulnerability is not listed in the CISA KEV catalog; however, the CVSS high integrity impact (I:H) reflects an attacker's ability to corrupt another user's onboarding progress and trigger persistent server errors in the victim's Observability Onboarding view.
Privilege escalation in Elastic Kibana's Agent Builder component (versions 9.4.0-9.4.3) allows authenticated low-privileged users to create and execute Agent tools that invoke Kibana features they are not authorized to access, bypassing the platform's feature-level access controls. The Agent Builder omits authorization verification against the target feature's required privilege set before tool creation and execution, enabling cross-feature privilege escalation and potential disclosure of sensitive data. No public exploit code exists and EPSS is 0.25%, but SSVC rates technical impact as total, making this a meaningful risk in multi-tenant or role-segmented Kibana deployments.
Local privilege escalation to full product takeover in Oracle Communications BRM - Elastic Charging Engine (versions 15.0.0.0.0, 15.0.1.0.0, 15.1.0.0.0, 15.2.0.0.0) lets a low-privileged attacker with logon access to the host running the ECE infrastructure compromise the Diameter Gateway and SDK component. Per Oracle's CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N), exploitation is authenticated and local but easily performed, yielding high confidentiality, integrity, and availability impact (base 7.8). No public exploit identified at time of analysis, and the CVE is not listed in CISA KEV.
Unauthorized information disclosure and case-attachment tampering in Elastic Kibana lets a low-privileged authenticated user with limited file-management permissions read, alter, or delete case attachments belonging to feature areas they should not reach, including sensitive Security Solution cases. The flaw stems from Kibana's file-access authorization check and its resource retrieval using two different resolution mechanisms, allowing the authorization gate to be bypassed. No public exploit identified at time of analysis; not listed in CISA KEV, and EPSS was not provided.
Authorization bypass and information disclosure in GeoNetwork 4.x (4.0.0-alpha.1 through 4.4.10) lets an unauthenticated remote user retrieve restricted metadata records through the Elasticsearch-backed search API. Under certain request conditions the proxy layer skips the step that injects GeoNetwork's access-control filters, so requests reach the index without group-visibility, ownership, draft-exclusion, or portal filtering applied. There is no public exploit identified at time of analysis, but the flaw is unauthenticated and network-reachable on any public-facing instance, making disclosure of non-public catalog records trivial once the triggering condition is known.
Log injection in Elastic Kibana (fixed in 7.17.15 and 8.11.1) allows an attacker with low-privilege access to embed unneutralized control characters in input that Kibana writes verbatim to its log files; when an operator later views those logs in a terminal that interprets ANSI/control sequences, the injected payload can forge, hide, or rewrite displayed log content. The issue is tracked as CWE-117 (Improper Output Neutralization for Logs) and carries a vendor CVSS of 8.0. There is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Denial of service in Elastic Fleet Server (versions 8.0.0-8.19.10 and 9.0.0-9.2.4) allows remote attackers to exhaust memory by sending a specially crafted request to an upload endpoint, driving excessive allocation until the server becomes unresponsive. The flaw is a resource-throttling failure (CWE-770) with availability-only impact and no confidentiality or integrity loss. No public exploit identified at time of analysis; EPSS is low (0.30%, 22nd percentile) and CISA SSVC records no observed exploitation.
Authentication bypass in Daytona prior to 0.184.0 allows attackers to join organizations via pending invitations using unverified email addresses. The invitation accept and decline paths failed to enforce email verification (unlike organization creation), so on OIDC identity providers permitting self-service signup with pre-verification sessions, an attacker registering an email matching a pending invite can claim it and inherit the assigned role - up to Owner. No public exploit identified at time of analysis, but the path to full Owner-level organization takeover makes this a high-priority fix.
Unauthenticated NoSQL operator injection in Budibase server <= 3.39.0 allows anonymous attackers to read or modify all documents in any MongoDB, CouchDB, Elasticsearch, DynamoDB-PartiQL, or REST-with-JSON-body datasource when a builder has published a query with a PUBLIC role. By injecting JSON metacharacters through query parameters, an attacker can override the intended filter, bypass authentication, and exfiltrate sensitive data or mass-update records in a single HTTP request. Exploit code is publicly available, though no active exploitation is confirmed, and the vulnerability has been patched in version 3.39.12.
Server-side request forgery in Open WebUI versions 0.9.5 and earlier allows authenticated OAuth users to read arbitrary internal HTTP responses by abusing the `_process_picture_url` function in `backend/open_webui/utils/oauth.py`, which validates only the initial URL and then permits aiohttp's default 10-redirect follow chain to reach internal addresses. The decoded response body is stored in the attacker's `profile_image_url` and retrievable via `GET /api/v1/auths/`, yielding cloud metadata credentials and access to localhost-bound services. Publicly available exploit code exists (detailed sentinel-verified PoC supplied by the reporter); no public exploit identified at time of analysis in the form of weaponized tooling, and the CVE is not on the CISA KEV list.
NoSQL/query injection in Spring AI Vector Stores (1.0.0-1.0.8 and 1.1.0-1.1.7) allows remote unauthenticated attackers to inject special characters into vector-store inputs and force execution of arbitrary queries against Elasticsearch, OpenSearch, and GemFire VectorDB backends. The flaw resides in the spring-ai-elasticsearch-store, spring-ai-opensearch-store, and spring-ai-gemfire-store components, enabling information disclosure and limited integrity/availability impact against any application embedding Spring AI's vector-store abstraction. No public exploit identified at time of analysis, but the CVSS 8.6 (scope unchanged here, network vector, no privileges) makes this a high-priority patch for any Spring AI deployment ingesting untrusted text.
Server-Side Request Forgery in Elastic Kibana 9.3.0 through 9.3.2 lets an authenticated user holding connector management privileges override the operator-configured connector allowlist and force the Kibana server to make outbound requests to destinations that egress controls were meant to block. Because the request originates from the trusted server, an attacker can reach internal or otherwise restricted network services and exfiltrate their responses. EPSS is very low (0.03%, 9th percentile) and there is no public exploit identified at time of analysis, but the scope-changing CVSS 7.7 rating reflects meaningful confidentiality impact against internal assets.
Server-side request forgery in Elastic Kibana allows authenticated users holding connector management privileges to bypass operator-configured egress allowlists by crafting a Webhook connector with an arbitrary target. The flaw enables Kibana to issue outbound HTTP requests to internal or otherwise restricted destinations, exposing sensitive data accessible from the Kibana host. No public exploit identified at time of analysis, and the vulnerability is not present on the CISA KEV list.
Kibana's dashboard management functionality in versions 8.0.0 through 8.19.15 and 9.0.0 through 9.3.4 accepts a dashboard identifier that is not properly normalized, allowing an authenticated user with only limited dashboard-creation permissions to embed path-traversal sequences in that identifier; when an administrator later deletes the dashboard through the Kibana UI, the request is redirected to an unintended internal endpoint and can destroy user accounts or other resources. Exploitation is distinctly conditional rather than automatic - it requires valid low-privilege credentials (PR:L) plus a privileged human delete action (UI:R), and CISA's SSVC scoring marks it non-automatable and of partial technical impact, with integrity and availability effects but no data disclosure. There is no public exploit identified at time of analysis (EPSS 0.03%, 8th percentile), and Elastic shipped fixes in Kibana 8.19.16 and 9.3.5 under ESA-2026-30; overall this is a moderate-severity, low-urgency issue despite the 7.3 CVSS base score.
Server-Side Request Forgery (SSRF) in Open WebUI versions ≤0.8.12 allows authenticated users with OAuth access to force the server to make HTTP requests to arbitrary internal resources and exfiltrate complete response data. Exploitation requires OAuth-enabled deployments with ENABLE_OAUTH_SIGNUP=true or OAUTH_UPDATE_PICTURE_ON_LOGIN=true. An attacker controls the OAuth provider's 'picture' claim URL, triggering server-side HTTP requests to cloud metadata services (AWS IMDS), localhost services (Redis, Elasticsearch), or internal network endpoints. The full response is base64-encoded and stored in the user's profile_image_url field, enabling complete data exfiltration. Fixed in version 0.9.0 per GitHub advisory GHSA-24c9-2m8q-qhmh. EPSS data not available; no CISA KEV listing indicates limited widespread exploitation, though publicly available proof-of-concept exists in the GitHub advisory.
Remote unauthenticated attackers can delete arbitrary ElasticSearch documents and MinIO storage files in nexent v1.7.5.2 via the unprotected DELETE /{index_name}/documents endpoint. The backend service fails to authenticate requests or validate the path_or_url parameter, enabling mass data destruction and denial of service. EPSS probability (0.12%) indicates low predicted exploitation likelihood, and no active exploitation or public exploit code has been identified at time of analysis, though the CVSS 9.1 reflects the severe impact of unauthenticated remote data deletion.
Remote code execution in Elastic Logstash versions 8.0.0 through 8.19.13 allows unauthenticated network attackers to write arbitrary files and execute code via malicious compressed archives. The vulnerability exploits improper path validation in archive extraction utilities, enabling attackers who compromise or control update endpoints to deliver path traversal payloads. When automatic pipeline reloading is enabled, arbitrary file writes escalate to full RCE with Logstash process privileges. CVSS 8.1 (High) with network vector but high attack complexity. EPSS data and KEV status not provided; no public exploit confirmed at time of analysis, though the technical details disclosed increase weaponization risk for environments with exposed update mechanisms.
Server-Side Request Forgery in Kibana One Workflow allows authenticated users with workflow privileges to bypass host allowlist restrictions in the Workflows Execution Engine, enabling unauthorized access to sensitive internal endpoints and data disclosure. Affects Kibana versions 9.3.0 through 9.3.2. No public exploit code or active exploitation has been confirmed at time of analysis.
Authenticated Kibana users with Fleet management privileges can read Elasticsearch index data beyond their intended RBAC permissions through debug route handlers in the Fleet plugin. This scope bypass affects Elastic Kibana deployments where users hold Fleet sub-feature privileges (agent policies, settings management). The vulnerability requires low-privilege authentication (PR:L) and has network attack vector (AV:N) with low complexity (AC:L), enabling cross-scope data confidentiality breach (S:C/C:H). No public exploit identified at time of analysis. EPSS data not available, but the specific privilege escalation vector and remote exploitability warrant prioritization in Kibana Fleet deployments.
Server-Side Request Forgery in PraisonAI's passthrough API allows authenticated remote attackers to access internal cloud metadata services and private network resources. The vulnerability affects the praisonai Python package where the passthrough() and apassthrough() functions accept unvalidated caller-controlled api_base parameters that are directly concatenated and passed to httpx requests. With default AUTH_ENABLED=False configuration, this is remotely exploitable to retrieve EC2 IAM credent
Kibana versions up to 9.3.0 contains a vulnerability that allows attackers to read arbitrary files from the Kibana server filesystem, and perform Server-Side (CVSS 8.6).
Kibana versions 6.7.0 to 6.8.8 and 7.0.0 to 7.6.2 contain a prototype pollution flaw in the Upgrade Assistant. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Kibana versions before 5.6.15 and 6.6.1 contain an arbitrary code execution flaw in the Timelion visualizer. Rated critical severity (CVSS 10.0), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
The Groovy scripting engine in Elasticsearch before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to bypass the sandbox protection mechanism and execute arbitrary shell commands via a crafted. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Actively exploited in the wild (cisa kev) and public exploit code available.
The default configuration in Elasticsearch before 1.2 enables dynamic scripting, which allows remote attackers to execute arbitrary MVEL expressions and Java code via the source parameter to _search. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, low attack complexity. Actively exploited in the wild (cisa kev) and public exploit code available.
Permission-filtered search in Backstage deployments that use an Elasticsearch or OpenSearch backend can return documents that a DENY policy should have withheld, because an empty list of permitted document types causes the engine to issue an unfiltered query across all indices instead of returning zero results. Only authenticated Backstage users (CVSS PR:L) are positioned to trigger this, and only when permission.enabled is set to true, the search backend is Elasticsearch/OpenSearch rather than the default in-memory engine, and the user is actually governed by a DENY policy for one or more search document types; the impact is limited to confidentiality (C:L) with no integrity or availability effect. The vendor has released fixes in @backstage/plugin-search-backend 2.1.6 and @backstage/plugin-search-backend-module-elasticsearch 1.8.7 (Backstage release v1.54.1), and there is no public exploit identified at time of analysis. Consistent with our independent assessment, this is a genuine but low-urgency information-disclosure issue rather than a high-priority emergency.
Denial of service in Elasticsearch allows an authenticated user (CVSS vector PR:L) who holds read access to a single index to crash a node by defining a scripted runtime field whose script output builds a deeply nested geometry value; because serialization of script-generated geometry lacks the nesting-depth limit applied to text-supplied geometry, recursion exhausts the stack and the node terminates, and on some deployments it does not recover without manual intervention. The issue is availability-only (C:N/I:N/A:H, CVSS 6.5) with no data exposure, and no public exploit code was identified at time of analysis. Fixes are released in Elasticsearch 8.19.23, 9.4.8, and 9.5.5 per ESA-2026-198, so this is a moderate-priority patching item rather than an emergency, but clusters that allow untrusted users to read indices while scripting/runtime fields are enabled should treat it as more urgent.
Denial of service in Elasticsearch allows an authenticated user holding read access to just a single index to terminate a cluster node by submitting a search request whose aggregation definitions are deeply and maliciously nested. Processing the request drives unbounded recursive execution that exhausts the node's resources and crashes the affected process, which does not recover on its own and requires manual intervention to restore service. The flaw is scored CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), is availability-only, and no public exploit code or confirmed active exploitation was identified at time of analysis; the practical barrier is the authenticated read privilege prerequisite rather than remote reachability.
Denial of service in Elasticsearch lets an authenticated user who holds connector management privileges exhaust node heap memory by creating a connector resource with an excessively large description field and then causing that resource to be accessed or read, crashing the affected node. The path is network-reachable but requires PR:L authorization, and the impact is limited to availability with no data confidentiality or integrity loss. No public exploit code has been identified at time of analysis, and Elastic has released fixed versions 8.19.2, 9.0.6, 9.1.4, and 9.2.1 in advisory ESA-2026-195.
Denial of service in Elastic Endpoint on Windows can crash and repeatedly restart the endpoint protection process when it handles a specially crafted file name under Chinese, Japanese, or Korean system locales. The vendor advisory identifies fixes in Elastic Agent/Endpoint 8.19.22, 9.4.8, and 9.5.5 (ESA-2026-194), so Windows Elastic Defend deployments below those builds on the corresponding release lines should be treated as potentially affected. No public exploit code or CISA KEV entry was provided, and the independent assessment characterizes this as a moderate-priority, availability-only issue rather than a high-impact breach risk.
Sensitive information disclosure in Kibana 9.4.x and 9.5.x allows an authenticated user with limited Fleet management privileges to read private cryptographic key material that should be restricted to Fleet settings administrators. The exposed material can include Fleet Server host-connection keys, potentially enabling impersonation of trusted Fleet infrastructure in deployments where those keys are actively used; no public exploit identified at time of analysis. Vendor fixes are available in Kibana 9.4.8 and 9.5.5 per Elastic Security Advisory ESA-2026-193.
Denial of service in Elasticsearch allows authenticated users holding the manage_index_templates cluster privilege to exhaust node heap by registering multiple index-template resources with metadata near the per-resource size limit and then triggering a combined retrieval that materializes all metadata in memory simultaneously. Affected versions include Elasticsearch releases prior to 9.4.7, 9.5.3, and 8.19.23, as addressed in ESA-2026-192. No public exploit code has been identified at time of analysis, and exploitation requires the specified privilege, limiting the attack to trusted operators or compromised privileged accounts.
Missing authorization in Kibana's Metrics Experience feature lets an authenticated user who holds only Elasticsearch index-level read privileges - but no corresponding Kibana feature privilege - pull back index-derived metric data that a correctly protected sibling API would have blocked. Exploitation requires valid credentials (CVSS PR:L, remote, no user interaction) and is confined to information disclosure (C:L), giving a modest CVSS 3.1 base score of 4.3. Kibana installations running 9.4.0 or later are not affected, and no public exploit code or active exploitation has been identified at time of analysis.
Denial of service in Elasticsearch 9.x lets an authenticated attacker holding only low-privilege credentials terminate a node by submitting a request that drives uncontrolled recursion and excessive memory allocation, taking down cluster availability. The CVSS 6.5 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) confirms availability-only impact with no data exposure or modification, reachable over the network with no user interaction or non-default configuration - though authentication at a low privilege level is required, so exposure is limited to insiders, compromised credentials, or over-permissive accounts. Exploitation status is no public exploit identified at time of analysis (no CISA KEV listing, EPSS not available), making this a moderate, availability-only risk rather than a top-tier emergency; vendor fixes are published as Elasticsearch 9.4.8 and 9.5.5 in ESA-2026-190.
Denial of service in Elasticsearch stems from catastrophic backtracking in the ES|QL CHUNK function, which accepts user-supplied regular expressions as text-splitting separators without validating their computational complexity or bounding their execution time. An authenticated attacker who holds read access to any text-based index and can invoke CHUNK through ES|QL can submit a crafted pattern that drives exponential regex blowup, consuming excessive CPU on Elasticsearch worker threads and degrading query throughput for other tenants on the affected node, though the cluster does not crash. CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) reflects a bounded availability-only impact, no public exploit code was identified at time of analysis, and patched releases are available as Elasticsearch 8.19.22, 9.4.8, and 9.5.5 per Elastic security update ESA-2026-189.
Unauthorized data stream modification in Elasticsearch allows an authenticated user who holds privileges over only a single resource to alter data streams outside their authorized scope through the Modify Data Streams API, enabling data injection into those streams or degrading their searchability. The flaw is rated CVSS 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) and is confined to integrity and availability - it explicitly does not let the attacker read a data stream they could not already access. Only deployments running 7.17.5-7.17.29, 8.2.2-8.19.18, 9.0.0-9.3.7, or 9.4.0-9.4.3 are affected, and there is no public exploit identified at time of analysis; the vendor security update (ESA-2026-188) points to fixed releases 8.19.19, 9.3.8, and 9.4.4.
Denial of service in Elasticsearch 8.x and 9.x lets an authenticated user with only low privileges crash cluster nodes by submitting a specially crafted query that drives uncontrolled memory growth in the query processing engine, ending in an out-of-memory termination. Because the trigger can be repeated - including through queries embedded in shared resources such as saved searches or stored queries - the result can escalate from a single node restart to persistent cluster unavailability, though there is no data disclosure or modification path. The flaw is rated CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), and no public exploit code has been identified at time of analysis.
Resource exhaustion in Elasticsearch allows an authenticated high-privilege user to consume excessive node resources, causing denial of service through availability loss (CVSS 4.9). Affected deployments are all Elasticsearch versions before the vendor-fixed releases 8.19.22, 9.4.7, and 9.5.3, as reflected by the CPE wildcard and Elastic Security Advisory ESA-2026-184. Exploitation requires an authenticated account with high privileges (CVSS PR:H) and network access to the cluster API; there is no public exploit identified at time of analysis, and the issue is not confirmed actively exploited (CISA KEV). Impact is limited to availability, with no confidentiality or integrity effect, and realistic risk is confined to malicious insiders or attackers who already hold privileged credentials.
Authenticated denial of service in Elasticsearch lets a valid low-privilege account drive the node or cluster into uncontrolled resource consumption through an allocation-heavy request path, degrading or halting availability (CVSS 6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Only users holding at least a low-privileged, network-reachable API account can trigger it - an unauthenticated remote attacker cannot, and there is no confidentiality or integrity impact. Elastic rates this a genuine but modest-severity availability issue rather than a top-tier priority: no public exploit code has been identified at time of analysis, no CISA KEV listing applies, and the advisory does not name the specific endpoint or query construct that acts as the allocation sink. Vendor-released patches exist in Elasticsearch 8.19.22, 9.4.7, and 9.5.4 (ESA-2026-183).
Denial of service in Elasticsearch is possible because of uncontrolled resource consumption (CWE-400) that allows an authenticated user to drive excessive allocation and exhaust cluster resources. Elasticsearch deployments prior to 9.4.7 and 9.5.4 are affected; the issue is remote and low-complexity but requires valid low-privilege credentials or an API key (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), and the impact is limited to availability with no data disclosure or modification. There is no public exploit identified at time of analysis and no confirmed active exploitation, and the vendor-scored severity of 6.5 places this as a moderate availability-only issue rather than a top-tier priority.
Denial of service in Elastic Kibana allows an authenticated low-privilege user with network access to the Kibana HTTP interface to exhaust server resources and render the instance unavailable. The flaw is an uncontrolled resource consumption issue (CWE-400, CAPEC-130 Excessive Allocation) rated CVSS 3.1 base 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), meaning availability impact only, with no confidentiality or integrity loss and no user interaction required. Exploitation requires a valid session at low privilege (PR:L), so a fully unauthenticated attacker cannot trigger it per the assessed vector; no public exploit code and no confirmed in-the-wild exploitation were identified at time of analysis. Elastic has published fixed versions in 8.19.22, 9.4.7, and 9.5.3.
Authenticated denial of service in Elasticsearch lets a low-privilege user with network reachability to the cluster API exhaust node or cluster resources through a crafted request that triggers uncontrolled allocation (CWE-400 / CAPEC-130), driving availability-only degradation rather than data theft or code execution. The vendor-assessed CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 6.5) confirms the attacker must first hold valid low-privilege credentials (or reach an improperly exposed/authenticated API endpoint), that no user interaction is needed, and that confidentiality and integrity are unaffected while scope remains unchanged to the single affected deployment. Practical exposure is greatest in multi-tenant clusters or environments where the Elasticsearch HTTP API is broadly reachable; properly segmented single-tenant clusters face lower risk, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Authenticated denial of service in Elasticsearch allows a remote attacker holding only low-privilege credentials to drive uncontrolled resource consumption, exhausting node memory and degrading or halting cluster availability (CVSS 6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Impact is confined to availability - there is no confidentiality or integrity loss - and exploitation requires a valid account, API key, or service token, so fully unauthenticated attackers cannot trigger it against a properly secured cluster. No public exploit code or confirmed active exploitation has been identified at time of analysis, and vendor fixes are available in Elasticsearch 8.19.22, 9.4.7, and 9.5.4 (ESA-2026-179).
Denial of service in Elasticsearch allows a network-reachable, low-privilege authenticated user to exhaust cluster resources through excessive allocation, degrading availability down to a full outage while leaving data confidentiality and integrity intact (CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). The flaw is an uncontrolled resource consumption bug (CWE-400 / CAPEC-130 Excessive Allocation), and the CPE record lists elastic:elasticsearch without version constraints, so every unpatched Elasticsearch deployment is presumed affected pending the vendor advisory ESA-2026-176. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV; exploitation requires valid low-privilege credentials (a low-tier user, service account, or API key), which limits the population of attackers able to trigger it. The specific endpoint, query type, or configuration that produces the excessive allocation is not named in the available data describing the flaw and must be confirmed against the Elastic advisory.
Denial of service in Elasticsearch allows a network-reachable, low-privileged authenticated user (PR:L) to exhaust server resources and take the cluster's availability down by triggering uncontrolled resource allocation; no user interaction is required (AC:L, UI:N) and the impact is availability-only (C:N/I:N/A:H, base score 6.5). Because a valid account with minimal privileges is a prerequisite, clusters that enforce authentication and limit network exposure are materially less exposed, and the attack cannot be launched fully unauthenticated. No public exploit code and no confirmed active exploitation were identified at time of analysis, so the practical risk is concentrated in multi-tenant or broadly reachable clusters where low-privilege access is easy to obtain; Elastic has published fixed versions in 8.19.21, 9.4.6 and 9.5.3 under advisory ESA-2026-170.
Authenticated Kibana users who hold Synthetics privileges scoped to just one space can permanently delete Synthetics monitors that are shared into other spaces they are not authorized to access, because the space-scoped authorization check is missing on the delete path (CVSS 6.5, PR:L, I:H). When a targeted monitor is tied to a private location, the same action also tears down the underlying Elastic Agent integration configuration, bypassing the authorization controls Fleet would normally enforce. The flaw is limited to space-to-space abuse inside a single Kibana/Elastic deployment rather than cross-tenant compromise, and no public exploit identified at time of analysis; Elastic has published a security update (ESA-2026-139) addressing it.
Cross-user authorization bypass in Elastic Kibana lets an authenticated user who holds the Timeline feature privilege in a Kibana space enumerate, read, modify, and delete draft Timeline objects that belong to other users in that same space, because object ownership is enforced through a user-controlled key rather than through a proper ACL check. Only Timeline read privilege is needed to enumerate and disclose other users' drafts, while the Timeline write privilege is additionally required to alter or delete them; the issue is therefore meaningful only in multi-user, shared Kibana spaces where Timeline privileges are granted to more than one principal, and it is rated CVSS 6.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L), indicating moderate confidentiality, integrity, and availability impact. No public exploit code has been identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV); the vendor advisory referenced for this CVE points to the Kibana 8.19.22 and 9.4.6 security update (ESA-2026-103).
Server-side request forgery in Adminer's optional Elasticsearch driver (plugins/drivers/elastic.php) lets unauthenticated remote attackers force the Adminer host to issue HTTP GET requests to arbitrary reachable hosts and ports, because include/auth.inc.php calls Driver::connect() before it validates the submitted login result. Versions 4.16.0 through 6.0.1 are affected and the issue is conditional: it requires that the optional Elasticsearch driver be explicitly deployed (via the adminer/elastic.php template or an adminer_object() configuration) and that PHP allow_url_fopen be enabled so get_url()/file_get_contents() can send the outbound request. Impact is limited to low-confidentiality reconnaissance - a port-scanning oracle built from leaked JSON error fields and connection-failure text rendered on the login page - with no integrity or availability impact, and the independent assessment rates the issue MEDIUM, consistent with the vendor's CVSS 4.0 base score of 6.9; fixed in 6.0.2 and no public exploit identified at time of analysis.
Unauthenticated access to Elasticsearch index management endpoints in MoguBlog's mogu_search microservice (through version 6.2) allows any remote attacker to wipe, restructure, or poison the platform's blog search index. The ElasticSearchRestApi controller exposes POST operations - index initialization, bulk delete, single-document delete, and arbitrary entry injection - without any authentication gate in WebSecurityConfig. Four distinct proof-of-concept Python scripts are publicly available on GitHub, scripting each attack path and significantly lowering the exploitation barrier.
Path traversal in n8n's Elasticsearch and ElasticSecurity workflow nodes allows a low-privileged workflow editor to escape the intended Elasticsearch index scope and reach arbitrary indices or cluster administration endpoints using the platform's stored Elasticsearch credentials. Exploitation requires the ability to create or edit workflows containing Elasticsearch nodes, and the root cause is the absence of proper URL path-segment encoding (toPathSegment) in GenericFunctions.ts before identifiers are interpolated into REST request paths. No public exploit code or CISA KEV listing is present at time of analysis, but the scope change to a backend Elasticsearch cluster elevates the real-world impact beyond the CVSS base score suggests.
Incorrect authorization in Kibana (CWE-863) allows a low-privileged authenticated user to access data or resources beyond their intended authorization level, resulting in high-impact confidentiality breach. Affected versions are addressed in Kibana 9.4.6 and 9.5.3 per Elastic advisory ESA-2026-175. No public exploit code or CISA KEV listing has been identified at time of analysis.
Incorrect Authorization (CWE-863) in Kibana allows a low-privileged authenticated user to exploit misconfigured access control levels, resulting in partial denial of service against the Kibana instance. Affected across Kibana 8.x and 9.x branches, with fixes released in versions 8.19.21, 9.4.6, and 9.5.3 per Elastic advisory ESA-2026-174. No public exploit code or active exploitation has been identified at time of analysis.
Privilege abuse in Kibana allows an authenticated user holding Security read-level access in a single Kibana space to trigger Entity Analytics migration operations that perform write actions across all Kibana spaces, violating the platform's space-isolation access control model. The vulnerability stems from CWE-862 (Missing Authorization): the migration API endpoint executes privileged writes without verifying whether the caller's authorization scope covers the target spaces. No public exploit has been identified at time of analysis; a vendor patch is available per ESA-2026-154.
Cross-space agent data exposure in the Kibana Fleet feature allows authenticated low-privileged users to read agent metadata and diagnostic content outside their authorized Kibana space. An attacker holding read-level Fleet agent privileges in any one Kibana space can enumerate agents enrolled in other spaces - bypassing the space-based access boundary that Elastic uses for multi-tenancy isolation. No public exploit or active exploitation has been identified; CVSS 4.3 with PR:L aligns with the real-world impact: meaningful tenant boundary breach, but limited to read-only metadata disclosure.
Template injection in Kibana's Cribl integration allows a low-privileged authenticated user holding Fleet management rights to write Elasticsearch ingest pipelines exceeding their authorized Elasticsearch permissions. The flaw stems from insufficient validation of a configuration field that is rendered server-side as a script template, giving the attacker a code injection foothold (CWE-94) into the pipeline generation path. No public exploit has been identified at time of analysis, and the CVSS score of 4.3 (PR:L/I:L) reflects the constrained privilege requirement and limited integrity impact.
Query injection in n8n's Elasticsearch and Google Cloud Firestore workflow nodes allows a low-privileged authenticated user to escalate a single-document lookup into a full-collection read by injecting quote and brace characters into expression values. Affected versions are n8n before 2.35.4 and 2.36.x before 2.36.2. The CVSS 4.0 vector scores this at 6.3 with high subsequent-system confidentiality impact, reflecting that the vulnerable system itself is not directly compromised but the connected Elasticsearch or Firestore data stores can be fully exposed. No public exploit code or active exploitation has been identified at time of analysis.
Incorrect Authorization (CWE-863) in Kibana's machine learning feature allows authenticated users to invoke ML functionality beyond their assigned authorization scope, consuming Elasticsearch cluster resources they are not permitted to access. Affected across all Kibana versions prior to the 8.19.21, 9.4.6, and 9.5.2 releases patched under Elastic advisory ESA-2026-169. No confidentiality or integrity impact is present; exploitation is bounded to cluster resource exhaustion, with CVSS 4.3 (Medium) reflecting the limited blast radius and authentication prerequisite.
Memory exhaustion denial of service in Filebeat's HTTP ingestion endpoint allows an authenticated low-privileged attacker to crash the Filebeat process by sending specially crafted compressed payloads that trigger unbounded decompression (a decompression-bomb / zip-bomb pattern). Affected versions span the 8.x and 9.x branches, with patched releases 8.19.18 and 9.3.1 published under Elastic Security Advisory ESA-2026-165. No public exploit code or CISA KEV listing has been identified at time of analysis, and exploitation is constrained to attackers who can reach the HTTP input endpoint.
Incorrect authorization in Elastic Fleet Server allows any authenticated enrolled agent to interfere with multi-part upload sessions belonging to other enrolled agents, causing a denial of service of those upload operations. Fleet Server fails to verify session ownership during chunked data uploads, meaning a low-privileged agent credential is sufficient to disrupt peer agent activity. No public exploit exists and no active exploitation has been confirmed; CVSS rates this Low (3.1) reflecting the authentication prerequisite and high complexity timing condition.
Kibana's request processing layer fails to enforce memory allocation limits, allowing any authenticated low-privilege user to trigger unbounded heap consumption and deny service to all users of the instance. Elastic's advisory ESA-2026-163 discloses the issue across all Kibana branches and releases fixes in versions 8.19.16, 9.3.5, and 9.4.2. No public exploit code or active exploitation has been identified at time of analysis.
Observable response discrepancy in Kibana's Osquery feature enables cross-space scheduled query ID enumeration by authenticated low-privileged users. An attacker holding Osquery live-query privileges can determine whether a scheduled query identifier exists in a Kibana space they are not authorized to access by observing distinguishably different API responses. Vendor-released patch is version 9.4.4 per ESA-2026-161; no public exploit or CISA KEV listing is identified at time of analysis.