VulniPulse uses Google Ads measurement to understand visits from advertisements and campaign performance. It runs cookie-free until you choose — accepting enables cookies for more accurate attribution. Rejecting keeps it cookie-free and never limits the site.
See exactly what is measuredComplete feed
Critical/high still unreviewed, or CISA KEV listed
Arbitrary code execution via prototype pollution of filename option. Red Hat rates this important (CVSS 8.1). Weakness: CWE-915.
request.form() limits silently ignored for application/x-www-form-urlencoded enable DoS. Red Hat rates this important (CVSS 7.5). Weakness: CWE-770. Red Hat lists fixing advisory RHSA-2026:36006 with package rhaiis/vllm-cuda-rhel9:1782951012, jaeger-main-2.19.0-1.hum1, rhaiis/vllm-rocm-rhel9:1782951244.
Denial of Service via uncontrolled recursion with crafted protobuf payload. Red Hat rates this moderate (CVSS 7.5). Weakness: CWE-606.
@angular/platform-server: Angular: SSRF via Hostname Hijacking in @angular/platform-server. Red Hat rates this important.
@angular/platform-server: domino: Angular Platform Server: Cross-Site Scripting via unescaped `</noscript>` tags in dynamic content. Red Hat rates this important (CVSS 8.1). Weakness: CWE-79.
A weakness has been identified in BerriAI litellm up to 1.59.8. Affected is the function UserAPIKeyAuth of the file litellm/proxy/_experimental/mcp_server/auth/user_api_key_auth_mcp.py of the component MCP Proxy. Executing a manipulation can lead to improper authentication. The attack may be launched remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure. A flaw was found in BerriAI litellm, within its MCP Proxy component. A remote attacker could exploit an improper authentication vulnerability in the UserAPIKeyAuth function. This could allow unauthorized access, potentially compromising the confidentiality, integrity, and availability of data within the system. A flaw was found in litellm. When the LiteLLM proxy MCP authentication flow mishandles 401/403 errors from API key validation, an attacker may bypass MCP proxy authentication and reach backend MCP servers that are configured with allow_all_keys: true. This issue affects litellm versions prior to 1.81.16 as shipped in select Red Hat products. Red Hat severity: Important — CVSS 7.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L). Weakness: CWE-303. No fixing RHSA erratum has published yet; monitor the Red Hat CVE page and patch when it ships.
vLLM versions >= 0.10.2 and < 0.13.0 are missing sparse tensor validation in multimodal embeddings processing. Because PyTorch disables sparse tensor invariant checks by default, an attacker can submit crafted embedding requests with malformed (negative or out-of-bounds) tensor indices, when the prompt-embeds feature is enabled, to trigger crashes or resource exhaustion (denial of service), with potential for out-of-bounds/write-what-where memory corruption. This continues CVE-2025-62164, whose prior fix only disabled the feature by default rather than addressing the root cause. A flaw was found in vLLM. This vulnerability allows a remote attacker to trigger crashes or resource exhaustion, leading to a denial of service (DoS). By submitting specially crafted embedding requests with malformed tensor indices, when the `prompt-embeds` feature is enabled, an attacker could also potentially achieve out-of-bounds memory corruption, which may enable arbitrary code execution. Red Hat rates this issue as having Important impact for affected Red Hat AI Inference Server images shipping vLLM 0.10.2 through 0.13.x when prompt-embeds multimodal embedding support is enabled. Versions outside this range, Red Hat OpenShift AI KServe sidecars, and Red Hat Enterprise Linux AI 3.4 bootc images (vLLM 0.17+/0.18+) are not affected. Red Hat severity: Important — CVSS 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-787. No fixing RHSA erratum has published yet; monitor the Red Hat CVE page and patch when it ships.
A heap buffer overflow vulnerability was found in libaom, the reference AV1 codec implementation. A flaw in the AV1 encoder's Look-Ahead Processing (LAP) mode causes the first-pass stats ring buffer wrap-around guard to be bypassed when g_lag_in_frames is set to 1 or higher. This results in a 232-byte out-of-bounds write on every encoded frame after the second, corrupting adjacent heap objects. An attacker who can influence encoder configuration in a transcoding service or WebRTC session could exploit this to cause a denial of service (process crash) or potentially achieve code execution. A heap buffer overflow vulnerability was found in libaom, the reference AV1 codec implementation. A flaw in the AV1 encoder's Look-Ahead Processing (LAP) mode causes the first-pass stats ring buffer wrap-around guard to be bypassed when g_lag_in_frames is set to 1 or higher. This results in a 232-byte out-of-bounds write on every encoded frame after the second, corrupting adjacent heap objects. An attacker who can influence encoder configuration in a transcoding service or WebRTC session could exploit this to cause a denial of service (process crash) or potentially achieve code execution. This vulnerability is rated as Important severity because a heap buffer overflow with attacker-influenced data can cause reliable denial of service and potentially lead to code execution, though the attacker has only indirect control over the written values (encoder-computed statistics). In Red Hat products, libaom ships bundled within Firefox and Thunderbird as a statically-linked dependency used for AV1 decoding and WebRTC encoding. The vulnerable code path requires the encoder to be configured with g_lag_in_frames >= 1 (Look-Ahead Processing mode). In Firefox's WebRTC implementation, the encoder configuration is controlled by the browser itself and not exposed to remote peers, which significantly limits the attack surface compared to standalone transcoding services. RHEL-AI 3.4 and Hummingbird 1 ship standalone libaom (aom) packages at versions within the affected range. Applications on those platforms that use the libaom encoder API with LAP mode and accept untrusted configuration input are vulnerable. Red Hat severity: Important — CVSS 7.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:H). Weakness: CWE-122. Fixed by RHSA-2026:30814 — update the affected packages (`sudo dnf update`). Affected Red Hat products: Red Hat Hardened Images.
An arbitrary address write vulnerability was found in libaom, the reference AV1 codec implementation. A missing bounds check in the SVC (Scalable Video Coding) layer ID control function allows an attacker to inject an arbitrary pointer into the cyclic refresh map field via crafted image pixel values. The encoder then writes approximately 1,200 bytes at the attacker-controlled address. This is fully deterministic and does not require a separate information leak. An attacker who can supply frames to a network-facing libaom encoder with SVC enabled could exploit this for denial of service or potential code execution. An arbitrary address write vulnerability was found in libaom, the reference AV1 codec implementation. A missing bounds check in the SVC (Scalable Video Coding) layer ID control function allows an attacker to inject an arbitrary pointer into the cyclic refresh map field via crafted image pixel values. The encoder then writes approximately 1,200 bytes at the attacker-controlled address. This is fully deterministic and does not require a separate information leak. An attacker who can supply frames to a network-facing libaom encoder with SVC enabled could exploit this for denial of service or potential code execution. This vulnerability is rated as Critical severity because it provides a fully deterministic arbitrary address write primitive that requires no information leak and is self-bootstrapping from attacker-controlled pixel values. The 1,200-byte write at an attacker-chosen address is sufficient for control flow hijacking. In Red Hat products, libaom ships bundled within Firefox and Thunderbird. The vulnerable code path requires the SVC (Scalable Video Coding) encoder feature to be enabled and the attacker to control both the layer_id configuration and the image frame pixel values. In Firefox's WebRTC implementation, SVC encoding parameters and frame submission are managed internally by the browser; a remote peer cannot directly set arbitrary layer IDs or inject pixel values into the local encoder. This significantly reduces exploitability in the browser context. RHEL-AI 3.4 (aom 3.12.0) and Hummingbird 1 (aom 3.13.3) ship standalone libaom packages within the affected version range. Services on those platforms that expose the SVC encoder API with attacker-controlled layer configuration and frame input are at highest risk. Red Hat severity: Important — CVSS 7.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H). Weakness: CWE-787. Fixed by RHSA-2026:30814 — update the affected packages (`sudo dnf update`). Affected Red Hat products: Red Hat Hardened Images.
A heap-buffer-overflow read vulnerability was found in libaom, the reference AV1 codec implementation. A missing bounds check in the SVC (Scalable Video Coding) layer ID control function allows setting a spatial_layer_id exceeding the configured number of layers. This causes an out-of-bounds heap read of approximately 40,728 bytes when computing a layer context array index. An attacker who can influence SVC encoder parameters in a network-facing service could exploit this for information disclosure (heap content leak) or denial of service (segmentation fault from hitting unmapped memory). A heap-buffer-overflow read vulnerability was found in libaom, the reference AV1 codec implementation. A missing bounds check in the SVC (Scalable Video Coding) layer ID control function allows setting a spatial_layer_id exceeding the configured number of layers. This causes an out-of-bounds heap read of approximately 40,728 bytes when computing a layer context array index. An attacker who can influence SVC encoder parameters in a network-facing service could exploit this for information disclosure (heap content leak) or denial of service (segmentation fault from hitting unmapped memory). This vulnerability is rated as Important severity because the 40KB out-of-bounds heap read can disclose sensitive information from adjacent heap allocations (including pointers useful for ASLR bypass in chained attacks) and reliably causes denial of service by hitting unmapped pages. In Red Hat products, libaom ships bundled within Firefox and Thunderbird. The vulnerable code path requires the SVC encoder feature to be enabled and an attacker to set spatial_layer_id to a value exceeding the number of configured spatial layers. In Firefox's WebRTC implementation, SVC layer parameters are managed internally by the browser and not directly exposed to remote peers, which limits exploitability. RHEL-AI 3.4 (aom 3.12.0) and Hummingbird 1 (aom 3.13.3) ship standalone libaom packages within the affected version range. Services that expose SVC encoder layer configuration to untrusted input are affected. Red Hat severity: Important — CVSS 7.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H). Weakness: CWE-125. Fixed by RHSA-2026:30814 — update the affected packages (`sudo dnf update`). Affected Red Hat products: Red Hat Hardened Images.
A remote code execution vulnerability was found in libaom, the reference AV1 codec implementation. Insufficient bounds validation in the AV1 encoder's SVC (Scalable Video Coding) layer ID control allows an attacker to supply crafted video frame pixels that overlap with internal encoder layer context structures. In fork-based video processing services, an attacker can use this to hijack the cyclic refresh map pointer, brute-force the process base address via a crash oracle, and redirect control flow to achieve arbitrary command execution. Exploitation requires the target service to use libaom with SVC encoding enabled and accept attacker-supplied video frames. A remote code execution vulnerability was found in libaom, the reference AV1 codec implementation. Insufficient bounds validation in the AV1 encoder's SVC (Scalable Video Coding) layer ID control allows an attacker to supply crafted video frame pixels that overlap with internal encoder layer context structures. In fork-based video processing services, an attacker can use this to hijack the cyclic refresh map pointer, brute-force the process base address via a crash oracle, and redirect control flow to achieve arbitrary command execution. Exploitation requires the target service to use libaom with SVC encoding enabled and accept attacker-supplied video frames. This vulnerability is rated as Critical severity because the researcher demonstrated successful remote code execution against a fork-based video processing service. The exploit chain leverages attacker-controlled pixel values to hijack internal encoder pointers, uses a crash oracle to brute-force ASLR, and ultimately achieves arbitrary command execution. However, the attack complexity is elevated: it requires a fork-based service architecture (for the crash oracle), multiple encoding attempts (for ASLR brute-force), and knowledge of the target binary layout. In Red Hat products, libaom ships bundled within Firefox and Thunderbird. Firefox does not use a fork-based architecture for WebRTC encoding, and SVC layer parameters are managed internally, making the demonstrated exploit chain not directly applicable to the browser context. RHEL-AI 3.4 (aom 3.12.0) and Hummingbird 1 (aom 3.13.3) ship standalone libaom packages within the affected version range. Fork-based transcoding or video conferencing services that use libaom with SVC encoding and accept attacker-supplied frames are at highest risk for this specific exploit chain. Red Hat severity: Important — CVSS 7.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:H). Weakness: CWE-787. Fixed by RHSA-2026:30814 — update the affected packages (`sudo dnf update`). Affected Red Hat products: Red Hat Hardened Images.
Two state-mutating endpoints in pgAdmin 4's SQL Editor blueprint -- DELETE /sqleditor/close/<trans_id> and POST /sqleditor/initialize/sqleditor/update_connection/<sgid>/<sid>/<did> -- were the only routes in the module missing the @pga_login_required decorator. Both reach a pickle.loads sink on session['gridData'][<trans_id>]['command_obj']: the close endpoint via close_sqleditor_session(), and update_sqleditor_connection via check_transaction_status(). In server mode these endpoints were reachable without any authenticated pgAdmin session. The defect is a missing-authentication-on-critical-function (CWE-306) wrapper around a deserialization-of-untrusted-data sink (CWE-502). Exploiting it for remote code execution requires the attacker to also forge a server-side session file whose gridData entry contains a malicious pickle payload, which in turn requires both (a) knowledge of pgAdmin's Flask SECRET_KEY (no chain to leak it is described here -- the attacker must already possess it) and (b) write access to pgAdmin's sessions/ directory on the host. Neither precondition is granted by this defect on its own. When those preconditions are met from another channel (misconfigured deployment, prior compromise, leaked configuration), the missing auth gate is the final hop that turns an existing partial compromise into unauthenticated code execution in the pgAdmin process -- and, by extension, on the host under whatever account runs pgAdmin. Fix is a one-line @pga_login_required decorator on each of the two endpoints, matching the convention used by every other route in the module. The is_authenticated / MFA chain now runs before the trans_id is dereferenced, so an unauthenticated request is rejected before reaching the deserialization path. The defect is server-mode only. In DESKTOP mode pgAdmin's before_request hook re-authenticates DESKTOP_USER on every request, so no endpoint can be exercised in an unauthenticated state and no auth decorator (or its absence) is meaningful. The accompanying regression test mirrors the attacker's path -- harvests an X-pgA-CSRFToken from GET /login and replays it against both endpoints -- and self-skips outside server mode for that reason; it is wired into the existing server-mode CI workflow alongside the data-isolation tests. This issue affects pgAdmin 4: from 6.9 before 9.16. A flaw was found in pgAdmin 4. Critical functions within the SQL Editor blueprint lacked proper authentication, allowing a remote attacker to bypass security controls. When combined with specific preconditions, such as knowledge of the Flask SECRET_KEY and write access to the sessions directory, this vulnerability could enable unauthenticated remote code execution on the server. This issue primarily affects pgAdmin 4 deployments in server mode. This is an Important flaw in pgAdmin 4, as it could lead to unauthenticated remote code execution on the server. However, successful exploitation requires an attacker to already possess the Flask SECRET_KEY and have write access to the pgAdmin sessions directory, which significantly raises the bar for exploitation and implies a prior compromise or misconfiguration. This vulnerability is specific to pgAdmin 4 deployments operating in server mode. Red Hat severity: Important — CVSS 9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H). Weakness: CWE-306. No fixing RHSA erratum has published yet; monitor the Red Hat CVE page and patch when it ships.
Read-only transaction bypass in the pgAdmin 4 AI Assistant allows an attacker who can influence database content that the assistant reads to execute arbitrary SQL with the privileges of the pgAdmin user's database role. The AI Assistant's execute_sql_query tool runs LLM-generated SQL inside a BEGIN TRANSACTION READ ONLY wrapper to prevent data modification. The LLM-supplied query was forwarded to the database driver without restriction to a single statement or to read-only verbs, so a multi-statement payload beginning with COMMIT, END, ROLLBACK, or ABORT terminated the read-only transaction and ran subsequent statements in autocommit mode. The trailing ROLLBACK then had no effect. Delivery is via prompt injection: an attacker who can write content into any object the AI Assistant may inspect (a row, a column value, a comment) can cause the LLM to emit the multi-statement payload as a tool call. With ordinary write privileges on the pgAdmin user's role the attacker can perform unauthorised data modification. When the pgAdmin user's role is a PostgreSQL superuser or holds pg_execute_server_program, the chain extends to remote code execution on the database server host via COPY ... TO PROGRAM. Fix validates the LLM-supplied query up front: it must parse to exactly one non-empty / non-comment statement whose leading real token (after stripping whitespace, comments, and punctuation) is one of SELECT, WITH, EXPLAIN, SHOW, VALUES, or TABLE. Transaction-control verbs, DML, DDL, CALL, COPY, DO, SET/RESET, and everything else are rejected before any database work happens. PostgreSQL's READ ONLY mode continues to backstop data-modifying CTEs, EXPLAIN ANALYZE on writes, and volatile side effects. This issue affects pgAdmin 4: from 9.13 before 9.16. A flaw was found in the pgAdmin 4 AI Assistant. An attacker with the ability to influence database content that the assistant reads can exploit a transaction bypass vulnerability through prompt injection. This allows the attacker to execute arbitrary SQL queries with the privileges of the pgAdmin user's database role. If the pgAdmin user has superuser privileges, this can lead to remote code execution on the database server. This Important flaw in the pgAdmin 4 AI Assistant allows an attacker to bypass read-only transaction protections through prompt injection. By influencing database content that the assistant reads, an attacker can execute arbitrary SQL queries with the privileges of the pgAdmin user's database role. This can escalate to remote code execution on the database server if the pgAdmin user holds superuser privileges, posing a significant risk to data integrity and system control. Red Hat severity: Important — CVSS 9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H). Weakness: CWE-89. No fixing RHSA erratum has published yet; monitor the Red Hat CVE page and patch when it ships.
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, the HTJ2K (High-Throughput JPEG 2000) decoder, ht_undo_impl() in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The ht_undo_imp function copies decoded pixels out of a per-line OpenJPH buffer using the EXR channel's declared width as the iteration count. The codestream embedded in the EXR chunk can declare different (smaller) tile/line dimensions than the EXR header advertises, but ht_undo_impl() does not validate this — it pulls width 32-bit samples from cur_line->i32[] without checking the OpenJPH line buffer's actual length. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by ojph::local::codestream::finalize_alloc(). The bug is reachable through the standard scanline-decode entry point used by every consumer of exr_decoding_run/Imf::checkOpenEXRFile, including thumbnailers, asset pipelines, and the exrcheck utility — i.e. any application that opens untrusted EXR files. The result is a deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12. A flaw was found in the OpenEXR image library. If an application opens a maliciously crafted EXR image file, it triggers a memory error. An attacker can use this to crash the application—causing a denial of service (DoS)—and potentially view sensitive information from the application's memory. Any system that processes untrusted EXR files is at risk. This flaw in the OpenEXR library allows attackers to crash applications or potentially view sensitive memory data by providing a specially crafted image file. Systems that automatically process untrusted EXR files (like asset pipelines or thumbnailers) are at the highest risk. Red Hat severity: Important — CVSS 7.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H). Weakness: CWE-125. No fixing RHSA erratum has published yet; monitor the Red Hat CVE page and patch when it ships. Will not fix / out of support: Red Hat Enterprise Linux 6.
An out-of-bounds write vulnerability in FFmpeg's libavcodec library, specifically in the MagicYUV decoder, allows denial-of-service and, in some cases, can be exploited for remote code execution. This vulnerability is associated with the file libavcodec/magicyuv.C. This issue affects FFmpeg before version 8.1.2. A flaw was found in FFmpeg's libavcodec library. This out-of-bounds write vulnerability, specifically within the MagicYUV decoder, could allow a remote attacker to execute arbitrary code on the affected system. In other scenarios, it may lead to a denial-of-service, making the system unavailable. This is an Important out-of-bounds write vulnerability in the FFmpeg libavcodec library's MagicYUV decoder. A remote attacker could exploit this flaw by providing a specially crafted media file, potentially leading to arbitrary code execution or a denial of service on affected Red Hat Enterprise Linux AI and Red Hat OpenShift AI systems. The impact is considered Important due to the potential for remote code execution without requiring complex attack vectors. Red Hat severity: Important — CVSS 8.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). Weakness: CWE-787. No fixing RHSA erratum has published yet; monitor the Red Hat CVE page and patch when it ships.
libssh2 through 1.11.1, fixed in commit 7acf3df contains an out-of-bounds write vulnerability in ssh2_transport_read() that fails to enforce upper bounds on packet_length field. Remote attackers can send crafted SSH packets with excessively large packet_length values to corrupt heap memory and achieve remote code execution. An out-of-bounds write vulnerability exists in the libssh2 client. A remote attacker can exploit this by sending a specially crafted SSH packet with an abnormally large length value. This corrupts the application's memory and can potentially allow the attacker to execute arbitrary code on the affected system. An Important out-of-bounds write vulnerability was discovered in libssh2. As it only impacts client installations of the library, exploitation would require a victim to initiate an SSH connection to an attacker-controlled server. This means an attacker must first redirect client connections via DNS poisoning, a man-in-the-middle, or compromise of a trusted host. While the vulnerability does not require authentication and requires no special configuration, the client redirection prerequisites significantly limit the practical attack surface compared to a server-side flaw. The integer overflow provides uncontrolled access to the heap, which reliably crashes the client process but is unlikely to achieve remote code execution in practice. Weaponizing the overflow for code execution would require a separate information disclosure vulnerability to defeat ASLR, along with a specific heap layout to place exploitable structures adjacent to the undersized allocation. On RHEL, ASLR is enabled by default and glibc's heap metadata integrity checks further raise the bar, making denial of service the realistic impact for most deployments. Red Hat Enterprise Linux (RHEL) 8 and newer are not affected by this flaw, as they do not ship the libssh2 package. Red Hat severity: Moderate — CVSS 7.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:L). Fixed by RHSA-2026:29950 — update the affected packages (`sudo dnf update`). Affected Red Hat products: Red Hat Hardened Images. Will not fix / out of support: Red Hat Enterprise Linux 6.
Starlette is a lightweight ASGI framework/toolkit. In versions 1.0.1 and earlier, StaticFiles on Windows is vulnerable to SSRF. An UNC path such as \\attacker.com\share can cause os.path.realpath to initiate an outbound SMB connection before the path is rejected, exposing the service account’s NTLMv2 credentials for offline cracking or relay even though the HTTP response is only a 404. The issue affects default follow_symlink=False deployments, including frameworks built on Starlette such as FastAPI; POSIX systems and follow_symlink=True are unaffected. The issue is fixed in 1.1.0. A flaw was found in Starlette, a lightweight ASGI framework. On Windows systems, the StaticFiles component is vulnerable to Server-Side Request Forgery (SSRF). A remote attacker can exploit this by providing a specially crafted Universal Naming Convention (UNC) path, which causes the system to initiate an outbound Server Message Block (SMB) connection. This action can expose the service account's NTLMv2 credentials, potentially leading to information disclosure or further attacks. This Important flaw in Starlette's StaticFiles component, which allows for NTLMv2 credential theft via specially crafted UNC paths, does not affect Red Hat products. The vulnerability is specific to Windows operating systems, and the vulnerable code is not present in Red Hat's supported configurations. Red Hat severity: Important — CVSS 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). Weakness: CWE-918. Fixed by RHSA-2026:30087, RHSA-2026:30088, RHSA-2026:30089 — update the affected packages (`sudo dnf update`). Affected Red Hat products: Red Hat AI Inference Server 3.3.
undici's ProxyAgent silently drops the requestTls option when configured with a SOCKS5 proxy URI (socks5:// or socks://). The target HTTPS connection through the SOCKS5 tunnel falls back to Node's default trust store, ignoring user-configured ca, cert, key, rejectUnauthorized, and servername settings. Applications that pin to an internal or corporate CA via requestTls.ca will, when their proxy URI is SOCKS5, get the default Mozilla CA bundle as the trust anchor instead. Any cert signed by any publicly-trusted CA for the target hostname is accepted, breaking the intended pin and enabling MITM read and tamper of the HTTPS exchange. Affected applications are those that use undici's ProxyAgent (or Socks5ProxyAgent directly) with SOCKS5 AND rely on requestTls for TLS scope restriction. The bug was introduced in undici 7.23.0 when SOCKS5 support was added. Patches: Upgrade to undici v7.28.0 or v8.5.0. Workarounds: No workaround is available within the SOCKS5 path. If a SOCKS5 proxy with TLS scope restriction is required and an upgrade is not yet possible, route the traffic through an HTTP-proxy ProxyAgent instead, where requestTls is honored correctly. A flaw was found in undici. When undici's ProxyAgent is configured with a SOCKS5 proxy Uniform Resource Identifier (URI), it silently ignores Transport Layer Security (TLS) options, such as custom Certificate Authorities (CAs). This allows a remote attacker to perform a Man-in-the-Middle (MITM) attack, intercepting and tampering with HTTPS communications. The connection falls back to Node.js's default trust store, bypassing intended security configurations and potentially leading to information disclosure or arbitrary code execution. This is an Important vulnerability. Applications using `undici`'s `ProxyAgent` with a SOCKS5 proxy URI will silently ignore user-configured TLS options, including custom Certificate Authorities. This bypasses intended security controls for HTTPS communication, enabling a remote attacker to perform Man-in-the-Middle attacks, potentially leading to information disclosure or arbitrary code execution in affected Red Hat products. Red Hat severity: Important — CVSS 7.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N). Weakness: CWE-295. Fixed by RHSA-2026:35841, RHSA-2026:34342, RHSA-2026:22380, RHSA-2026:22934, RHSA-2026:7378 — update the affected packages (`sudo dnf update`). Affected Red Hat products: Red Hat Enterprise Linux 10; Cluster Observability Operator 1.5.0; Red Hat Hardened Images.
When using Socks5ProxyAgent, undici reuses a single connection pool across different origins without verifying that the pool's origin matches the requested origin. All requests are dispatched through the pool connected to the first origin, regardless of the intended destination. This causes cross-origin request routing: credentials and request data intended for origin B are sent to origin A, responses from the wrong origin are trusted, and HTTPS requests may be silently downgraded to HTTP. Impacted users are applications that use Socks5ProxyAgent (directly or via setGlobalDispatcher) and make requests to more than one origin. This was introduced in undici 7.23.0 via PR #4385 and affects all versions through 8.1.0. Patches: Upgrade to undici v7.26.0 or v8.2.0. Workarounds: Use a separate Socks5ProxyAgent instance per origin, or avoid using Socks5ProxyAgent with multiple origins. A flaw was found in undici. When using Socks5ProxyAgent, undici incorrectly reuses a single connection pool across different origins. This can lead to cross-origin request routing, where sensitive credentials and data intended for one destination are sent to another. Consequently, responses from unintended origins may be trusted, and secure HTTPS connections could be silently downgraded to unencrypted HTTP, resulting in information disclosure and data integrity issues. This is rated as an Important security flaw. The `undici` library, when configured with `Socks5ProxyAgent` to handle requests for multiple origins, incorrectly reuses connection pools. This can lead to sensitive data and credentials being misrouted to unintended destinations, potentially downgrading HTTPS connections to HTTP and compromising data integrity and confidentiality. Red Hat products utilizing `undici` with `Socks5ProxyAgent` in multi-origin scenarios are affected. Red Hat severity: Important — CVSS 7.5 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-940. Fixed by RHSA-2026:35841, RHSA-2026:34342, RHSA-2026:22380, RHSA-2026:22934, RHSA-2026:7378 — update the affected packages (`sudo dnf update`). Affected Red Hat products: Red Hat Enterprise Linux 10; Cluster Observability Operator 1.5.0; Red Hat Hardened Images.
The undici WebSocket client enforces maxPayloadSize on the cumulative byte count of fragments in a message but does not enforce a limit on the number of fragments. A malicious WebSocket server can stream many small or empty continuation frames that each pass per-frame and cumulative-size validation, collectively causing unbounded memory growth in the client process. The result is memory exhaustion and a denial of service. Affected applications are those using the undici WebSocket client (new WebSocket(...)) or the WebSocketStream API that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint. All releases starting at undici 6.17.0 are affected. Patches: Upgrade to undici >= 6.26.0, >= 7.28.0, or >= 8.5.0. Workarounds: No workaround is available. The fix must be applied through an upgrade. A flaw was found in undici. A malicious WebSocket server can exploit this by streaming numerous small or empty continuation frames. This can bypass per-frame and cumulative-size validation, leading to unbounded memory growth in the client process. The primary consequence is memory exhaustion, resulting in a denial of service (DoS) for affected applications using the undici WebSocket client or WebSocketStream API. This Important denial of service flaw in the `undici` WebSocket client allows a remote attacker to cause unbounded memory growth. By sending numerous small or empty WebSocket frames, an unauthenticated attacker can exhaust system memory, leading to a denial of service in Red Hat products that use the affected client. Red Hat severity: Important — CVSS 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-770. Fixed by RHSA-2026:35841, RHSA-2026:35842, RHSA-2026:34342 — update the affected packages (`sudo dnf update`). Affected Red Hat products: Red Hat Enterprise Linux 10; Cluster Observability Operator 1.5.0. Will not fix / out of support: Red Hat Hardened Images.