Vulnerabilities

strongSwan's libcharon, the component implementing IKEv2/IPsec key negotiation in the charon daemon, contains a use-after-free (CWE-416) in its handling of IKEv2 rekeying collisions, affecting versions 6.0.0 through 6.0.7. The flaw is triggered when two peers simultaneously initiate rekeying of the same security association and the daemon frees an object that the colliding rekey transaction still references; because the CVSS vector scores network attack complexity as high with low privileges required, an attacker needs to be a valid (authenticated) IKEv2 peer and hit a timing-dependent race condition. Successful exploitation can crash the VPN daemon, and the high confidentiality/integrity/availability impacts in the score indicate memory corruption that could potentially extend to code execution in the context of the daemon. Anyone running strongSwan 6.0.0 through 6.0.7 as an IKEv2 responder or initiator — including VPN gateways, site-to-site tunnel endpoints, and appliances or distributions that bundle the 6.0.x series — is affected. No public proof-of-concept, in-the-wild exploitation, or CISA KEV listing is known at the time of this analysis.

Do: Upgrade strongSwan to a release newer than 6.0.7 once the fix is published — check the upstream release notes or security advisories for the patched 6.0.x version, as the affected range ends at 6.0.7. Until then, restrict IKEv2 access (UDP 500/4500) to trusted, authenticated peers via firewall rules or peer allowlists, and monitor VPN gateways for unexpected charon daemon crashes or restarts. Because exploitation requires valid IKEv2 credentials and a hard-to-hit race condition (AC:H), exposure to unauthenticated attackers is limited, but authenticated VPN peers should be treated as potential sources of malicious rekey traffic.

Fastify versions before 5.12.2 misinterpret the object resolved by a successful Ajv async validator as the value-result protocol used by custom validator compilers, which is an input validation flaw (CWE-20). The flaw is triggered when an authenticated request passes its route schema but contains a property named 'value' at the root of the body: Fastify then replaces the entire validated request body with that property's value before the handler executes. An authenticated low-privilege attacker can exploit this to make the handler operate on nested, effectively unvalidated data, achieving unauthorized state changes and data disclosure on routes the schema was supposed to protect. Any Fastify application running a version before 5.12.2 that uses Ajv async validation and accepts request bodies with a root-level 'value' property is affected. There is no known public proof of concept, the flaw is not in CISA KEV, and EPSS puts 30-day exploitation probability at 0.4% (32nd percentile), indicating low observed exploitation risk so far.

Do: Upgrade to fastify 5.12.2 or later. As an interim mitigation, avoid accepting request bodies with a root-level 'value' property on routes using Ajv async validation, and audit such routes for handlers that make authorization or state-change decisions based on the body's structure. Because no exploitation is observed yet, prioritize patching internet-facing Fastify APIs that accept untrusted authenticated input.

@fastify/middie, the middleware engine used to run Express-style middleware inside Fastify, decides whether to run path-scoped middleware by matching the raw request target, while Fastify's router resolves absolute-form request targets to their path before dispatching, so the two layers evaluate different strings (a CWE-436 interpretation conflict). An unauthenticated network attacker can send a request whose request line uses an absolute-form target, which then reaches the route handler while path-scoped middleware such as authentication or authorization is skipped. The attacker gains the ability to bypass path-based access controls in the affected application and reach protected endpoints without credentials. Affected users are operators of Fastify applications running @fastify/middie 9.1.0 through 9.3.3 that rely on middie path-scoped middleware for access control on reachable routes. There is no public proof of concept, the flaw is not in CISA KEV, and EPSS estimates a 0.3% 30-day exploitation probability, so no exploitation is currently known.

Do: Upgrade to @fastify/middie 9.3.4 or later. As an interim mitigation, do not rely on middie path-scoped middleware for authentication or authorization on internet-facing routes; enforce access control in Fastify's own lifecycle hooks (which see the resolved route) or normalize request targets at the proxy layer. Audit your Fastify applications for @fastify/middie in the 9.1.0-9.3.3 range and check whether any front-end proxy forwards absolute-form request targets to the application.

Kibana contains an incorrect authorization flaw (CWE-863) in which Elasticsearch cluster privilege declarations supplied by integration packages are not validated before being used to mint credentials for enrolled Elastic Agents. A user who holds Fleet management privileges can manipulate these privilege declarations (CAPEC-153, input data manipulation) so that every Elastic Agent assigned to a targeted policy receives a credential with arbitrarily elevated Elasticsearch cluster privileges, potentially up to full cluster administration. An attacker with this level of access gains high confidentiality and integrity impact (CVSS 3.1: 8.1, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), since the mis-issued agent credentials can be used to access or modify cluster data broadly. Affected users are organizations running Elastic Kibana with Fleet management and enrolled Elastic Agents that use integration packages; specific affected and patched version ranges are not provided in the available data. There is currently no known exploitation: the flaw is not in CISA KEV, no public proof-of-concept is known, and EPSS estimates only a 0.2% probability of exploitation within 30 days.

Do: Upgrade Kibana to a patched release per Elastic's advisory (specific fixed versions are not stated in the available data). Restrict Fleet management privileges to trusted users, and review integration packages for overly broad Elasticsearch cluster privilege declarations. Audit credentials issued to enrolled Elastic Agents for unexpected cluster privileges and re-issue/rotate agent credentials if abuse is suspected.

Versions of @fastify/http-proxy before 11.6.2 fail to validate proxied HTTP request paths for backslash-based dot-segments before forwarding them to the configured upstream. Because the plain HTTP request handler skips the destination validation that the WebSocket path performs, and the underlying reply-from library only rejects forward-slash traversal, an unauthenticated network attacker can send requests containing backslash dot-segments that escape the boundary enforced by the prefix and rewritePrefix options. This lets the attacker reach upstream paths that were intended to remain hidden behind the proxy, resulting in disclosure of internal endpoints. Any application using @fastify/http-proxy below 11.6.2 is affected. Exploitation has not been reported publicly: there is no known proof of concept, the issue is not in CISA KEV, and EPSS currently estimates only a 0.6% chance of exploitation in the next 30 days.

Do: Upgrade to @fastify/http-proxy 11.6.2 or later. If you cannot upgrade immediately, review your prefix/rewritePrefix configuration for upstream paths that should stay hidden, and consider rejecting incoming proxied request paths containing backslashes or dot-segments at an upstream control such as a reverse proxy or WAF. Check access logs for unusual requests with backslash sequences in the path targeting your proxy endpoints.

Incorrect Authorization (CWE-863) in Elastic Cloud on Kubernetes (ECK) can lead to unauthorized modification of data via Metadata Spoofing (CAPEC-690). An actor holding limited Kubernetes permissions confined to a single namespace could cause attacker-controlled certificate material to be included in the Elasticsearch client trust bundle managed by ECK in a separate namespace.

Elastic Agent on Windows, when installed in unprivileged mode, creates resources used by the agent service with access-control permissions broader than required (CWE-732, incorrect permission assignment for critical resource). A local attacker with low privileges can exploit this by replacing the agent service's binaries (CAPEC-642), causing the service to execute attacker-chosen code. Because the agent service runs in a privileged context, this results in full SYSTEM-level privileges on the affected Windows host. Only Windows systems where Elastic Agent was installed in unprivileged mode are affected, per the vendor description. There is currently no known public proof-of-concept, the issue is not in CISA's KEV, and EPSS estimates only about a 0.1% probability of exploitation in the next 30 days.

Do: Inventory Windows endpoints running Elastic Agent and identify which were installed in unprivileged mode, as those are the affected hosts. Upgrade those agents to the patched release cited in Elastic's security advisory (Elastic is the CNA; check elastic.co/security for the exact fixed version). As an interim mitigation, verify and restrict ACLs on the Elastic Agent installation directory and service resources so unprivileged users cannot write to or replace the service binaries.

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') (CWE-22) in Elastic Maps Server can lead to information disclosure via Path Traversal (CAPEC-126). An unauthenticated attacker able to reach the service over the network could cause it to return the contents of files outside its intended content directory that are readable by the server process.

Kibana's Fleet feature contains a path traversal flaw (CWE-22, CAPEC-126) that lets an attacker direct administrative actions at unintended internal resources. It is triggered when a low-privileged user holding Fleet Settings write access supplies a malicious pathname, and an administrator subsequently interacts with the affected Fleet interface, causing that administrative action to execute against the wrong targets. The attacker gains deletion of privileged resources such as user accounts and other organizational assets, with high integrity and availability impact but no confidentiality impact per the CVSS 3.1 vector (7.3, AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:H). Any Elastic Kibana deployment with the Fleet feature enabled, where non-administrative users have Fleet Settings write permissions, is potentially affected; exploitation additionally requires an administrator to interact with the Fleet UI. There is currently no known exploitation, no public proof-of-concept, the flaw is not in CISA KEV, and EPSS estimates a 0.3% probability of exploitation within 30 days.

Do: Upgrade Kibana to a patched release per Elastic's advisory for CVE-2026-78590, since exact fixed version numbers are not included in the available data. Until patched, restrict Fleet Settings write permissions to trusted administrators and review Fleet audit logs for unexpected deletions of users or other privileged resources. Administrators should verify Fleet prompts and resource paths before acting on them.

Improper Handling of Highly Compressed Data (CWE-409) in APM Server can lead to a persistent denial of service via Excessive Allocation (CAPEC-130). An authenticated user with write access to source map content could store specially crafted, highly compressed content that exhausts the memory available to APM Server when it is later processed, terminating the process. The condition recurs on every restart until the stored content is removed.

Allocation of Resources Without Limits or Throttling (CWE-770) in Filebeat can lead to a denial of service via Excessive Allocation (CAPEC-130). An attacker able to reach the Filebeat HTTP ingestion endpoint could send specially crafted compressed requests that exhaust the memory resources of the Filebeat process.

Incorrect Authorization (CWE-863) in Fleet Server can lead to a denial of service of agent upload operations via Privilege Abuse (CAPEC-122). Fleet Server does not correctly verify session ownership during multi-part data upload operations, allowing any authenticated agent to interfere with the active upload sessions belonging to other enrolled agents.

Improper Neutralization of Input During Web Page Generation ("Cross-site Scripting") vulnerability in Drupal Address Suggestion allows Cross-Site Scripting (XSS). This issue affects Address Suggestion versions: from 0.0.0 to 1.0.25.

Elastic Kibana contains an incorrect authorization flaw (CWE-863) that permits privilege escalation through scheduled workflow executions. A user holding workflow edit permissions can manipulate a workflow so that its scheduled runs execute with the privileges of a different, higher-privileged user instead of their own context. The attacker thereby gains the ability to access and modify data beyond their authorized scope; the CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L, score 8.3) indicates network-based exploitation requiring only low privileges and no user interaction. Any Kibana deployment in which users have been granted workflow edit permissions is plausibly affected, though the specific affected version ranges are not stated in the available data. No public proof-of-concept, KEV listing, or known in-the-wild exploitation exists, and EPSS currently puts the 30-day exploitation probability at 0.4%.

Do: Restrict the workflow edit privilege to trusted administrators and review your Kibana role definitions to see which users currently hold it. Watch for Elastic's advisory on CVE-2026-63137 and upgrade Kibana to the patched release it specifies. Audit recent scheduled workflow executions for runs that occurred under unexpected or higher-privileged user contexts.

Elasticsearch's machine learning component (CVE-2026-72649) contains a deserialization-of-untrusted-data flaw (CWE-502) that can lead to remote code execution via object injection. An attacker who is an authenticated user with sufficient privileges to create and deploy trained models can submit a specially crafted trained model artifact, causing attacker-controlled logic to execute with a materially broader system-call surface than intended. Successful exploitation yields remote code execution with high impact to confidentiality, integrity, and availability (CVSS 3.1: 8.8 High, network vector, low privileges required, no user interaction). Only Elasticsearch deployments where the machine learning feature is in use and model-creation/deployment privileges are granted to untrusted or compromised accounts are meaningfully exposed. As of this analysis there is no known public proof-of-concept, the issue is not in CISA's Known Exploited Vulnerabilities catalog, and no in-the-wild exploitation has been reported; EPSS currently estimates roughly a 0.6% probability of exploitation within 30 days.

Do: Inventory your Elasticsearch clusters for use of the machine learning feature and review which users hold privileges to create and deploy trained models, restricting them to trusted operators and, ideally, trusted model sources. Apply the patched Elasticsearch release identified in Elastic's security advisory as soon as it is available, prioritizing ML-enabled clusters (particularly security/SIEM deployments). Until patched, treat trained-model artifact uploads as untrusted input and monitor model-creation and deployment activity for anomalies.