Threats Tagged 'cwe-754'

Envoy proxy versions prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1 contain a vulnerability where improper handling of scoped IPv6 addresses causes the process to abort or crash. This occurs due to the inability of inet_pton to parse percent scope identifiers in IPv6 addresses reconstructed by certain internal functions. The issue affects deployments using kernel-provided scoped IPv6 destinations in ORIGINAL_DST transparent-proxy setups and specific QUIC connection paths. The vulnerability results in denial of service by terminating the Envoy process. Fixes are available in the specified patched versions.

RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, readLongstr in read.go returns an empty string and a nil error when a declared AMQP longstr length exceeds 0x7FFFFFFF instead of returning ErrSyntax. The function leaves the declared field bytes unread, while readTable treats the operation as successful and continues parsing from the wrong offset. A malicious or compromised broker can provide an oversized longstr in a table field and desynchronize subsequent AMQP parsing, causing attacker-controlled trailing bytes to be interpreted as later fields or frames and disrupting connection integrity and availability. This issue is fixed in version 1.13.0.

Skipper is an HTTP router and reverse proxy for service composition. Prior to 0.27.35, the opaAuthorizeRequestWithBody filter in filters/openpolicyagent/openpolicyagent.go can allow an oversized declared Content-Length request to bypass a deny-on-presence Rego policy because ExtractHttpBodyOptionally leaves OPA with an empty parsed_body while forwarding the complete request body upstream. This incomplete remediation of CVE-2026-50197 affects deployments that authorize request-body content and exceed -open-policy-agent-max-request-body-size, which defaults to 1 MB. Policy logic that does not reject input.attributes.request.http.truncated_body can therefore fail open and permit a forbidden payload to reach the protected service, while small bodies and the previously fixed chunked-body case are evaluated normally. This issue is fixed in version 0.27.35.

### Summary The Phoenix JavaScript presence client (`assets/js/phoenix/presence.js`) tests whether a presence already exists using a bare truthiness check (`state[key]`) rather than an own-property check. Because applications commonly track presences under a client-supplied username or id, the presence key can be attacker-controlled. A user who joins a channel and picks a key that names an `Object.prototype` member (`__proto__`, `constructor`, `toString`, `hasOwnProperty`, and similar) makes the lookup return the inherited `Object.prototype` object instead of `undefined`, which is truthy. The code then reads `.metas.map(...)` off it and throws an uncaught `TypeError`, breaking presence sync for every viewer of that channel topic. Any authenticated channel participant can trigger it. ### Details The victim is any browser subscribed to a presence channel. When it receives the server's `presence_state` message, it invokes `Presence.syncState`, which iterates the incoming presences and checks whether each one already exists locally via `let currentPresence = state[key]`. `state` is a plain object inheriting from `Object.prototype`. For an ordinary key like `alice`, `state["alice"]` is `undefined` (falsy) and the safe path runs. For the key `__proto__` (or `constructor`, `toString`, etc.), `state["__proto__"]` does not resolve to a tracked presence but to JavaScript's built-in `Object.prototype`, which is truthy. The `if(currentPresence)` guard passes, and the code evaluates `currentPresence.metas.map(m => m.phx_ref)`. Since `Object.prototype.metas` is `undefined`, calling `.map` on it throws a `TypeError`. Phoenix wraps no try/catch around channel binding callbacks, so the `TypeError` propagates out of the message handler: `this.state` is never updated and `onSync()` never fires. The malicious key is tracked server-side, so it is re-pushed on every presence update and keeps re-throwing, leaving presence permanently broken until the attacker leaves. `Presence.syncDiff` uses the same unsafe `state[key]` existence-check pattern, so presence diffs fail identically. Two scoping points matter. The impact is per channel topic, not global: presence state is per-topic on the server and per-`Presence`-instance in the browser, so only viewers of the topic carrying the malicious key are affected. The bug is a read-time confusion of the prototype object, not prototype pollution: the crash occurs on the `state["__proto__"]` read in `syncState`, before any `state[key] = ...` write is reached, so `Object.prototype` is never mutated and nothing leaks across channels. The fix builds the state and accumulator objects with `Object.create(null)` (or a `Map`) and gates existence checks with `Object.prototype.hasOwnProperty.call(obj, key)`. If an application does not pass a client-controlled key to `Presence.track`, it is **not** affected. ### PoC 1. Connect to an application that uses `Phoenix.Presence` and tracks presences under a client-chosen key (e.g. a username). 2. Join a presence channel choosing the key `__proto__` (or `constructor`, `toString`, `hasOwnProperty`). 3. The server tracks the presence and pushes `presence_state` / `presence_diff` to every subscriber of that topic. 4. Each viewer's `Presence.syncState` (or `syncDiff`) reads `state["__proto__"]`, gets the truthy `Object.prototype`, and throws an uncaught `TypeError`. 5. Presence sync stays broken for all viewers of the topic until the attacker leaves the channel. ### Impact An attacker with ordinary channel access can cause a persistent, stored client-side denial of service against every browser viewing a presence channel topic, freezing presence updates for all of them until the attacker disconnects. Any application driving the Phoenix JavaScript presence client with user-influenced presence keys is affected.

ALOS HTTP, a Go web framework and application server, has a vulnerability where a malformed request path starting with a question mark can cause an out-of-bounds panic. This occurs because the code accesses an array element without checking if the array is empty, leading to server process termination. The issue is fixed in version 0.0.0-20260617230736-314b6783e196.

This vulnerability allows a normal (non-admin) user to disable the Forcepoint One Endpoint SafariExtension and bypass DLP protection in F1E Mac OS before v26.04.5758.

Russh is a Rust SSH client & server library. Prior to 0.62.4, an unauthenticated SSH client can cause a denial of service by sending SSH_MSG_KEX_ECDH_INIT with a 32-byte all-zero Q_C value. Curve25519Kex::server_dh in russh/src/kex/curve25519.rs accepts the all-zero peer public value and computes an all-zero shared secret, after which compute_exchange_hash calls encode_mpint in russh/src/kex/mod.rs and indexes beyond the end of the input while skipping leading zero bytes. The resulting panic occurs before authentication and terminates the server key-exchange task. This issue is fixed in version 0.62.4.

Russh is a Rust SSH client & server library. Prior to 0.62.4, a malicious SSH server can crash a russh client session with a malformed KEX_ECDH_REPLY containing a server ephemeral value that is not 32 bytes long. The client-side Curve25519Kex::compute_shared_secret function in russh/src/kex/curve25519.rs passes the decoded exchange.server_ephemeral value to clone_from_slice without validating its length, causing a deterministic panic before the server host key is verified. The panic terminates the spawned client session task and surfaces as a JoinError, while the embedding process normally remains running. This issue is fixed in version 0.62.4.

A vulnerability has been identified in Desigo DXR2 (All versions < V01.21.233.16-7862), Desigo PXC3 (All versions < V01.21.233.16-7862), Desigo PXC4 (All versions < V02.21.194.36-2715), Desigo PXC5.E003 (All versions < V02.21.194.36-2715), Desigo PXC5.E24 (All versions < V02.21.194.36-2715), Desigo PXC7 (All versions < V02.21.194.36-2715). The affected devices are vulnerable to a denial-of-service (DoS) vulnerability. An attacker can exploit this issue by sending a malformed BACnet packet, causing the device to stop responding to BACnet queries. Recovery requires a device reset or reboot to restore normal functionality.

SAP Approuter does not consistently handle certain error conditions. An attacker with low privileges could exploit this under a non-default configuration. Successful exploitation is highly complex, as it depends on conditions outside the attacker's control. This could result in a low impact on availability. There is no impact on confidentiality and integrity.