Threats Tagged 'hex'

Swoosh.Adapters.MsGraph constructs Microsoft Graph API request URLs by directly inserting the sender's email address into the URL path without encoding or validation. If the sender's address is derived from untrusted input, an attacker can inject URL-special characters to manipulate the request path and query string. This allows redirection of authenticated requests to other Graph endpoints within the token's scope, effectively enabling constrained server-side request forgery. Applications using fixed, trusted sender addresses are not affected. A patch is available to address this issue.

The mpp Elixir library version 0.4.0 and other versions from 0.2.0 up to but not including 0.6.0 contain a vulnerability in the cosign_fee_payer/3 function. When the server acts as the fee payer, it does not validate gas-related parameters before cosigning transactions, allowing a malicious client to specify arbitrarily high gas fees. This causes the server to pay inflated gas costs from its own wallet, leading to direct financial loss and potential denial of service if funds are depleted.

The mpp Elixir 0.4.0 server, when acting as the fee payer, copies client-supplied EIP-2930 access lists directly into cosigned fee-payer transactions without validation. This allows an attacker to inflate transaction fees by including fabricated access list entries, causing the fee-payer to pay significantly higher gas costs without additional on-chain work. The attack can increase gas costs by approximately 7.4 times, severely impacting operational costs and profit margins for low-cost transactions.

Elixir protobuf is a pure Elixir implementation of Google Protobuf. From 0.8.0 until 0.16.1, services that decode attacker-controlled protobuf bytes with Protobuf.Decoder can be taken offline when the schema contains a self-referential or cyclic message type. In lib/protobuf/decoder.ex, Protobuf.Decoder.value_for_field/3 handles an embedded?: true field by recursively entering the decode / build_message / handle_value / value_for_field call chain without enforcing a nesting-depth limit. Deeply nested embedded fields retain non-tail recursive frames, allowing a comparatively small request to consume substantial CPU and memory, pin a BEAM scheduler, and exhaust the node. This issue is fixed in version 0.16.1.

Improper Check for Unusual or Exceptional Conditions vulnerability in phoenixframework phoenix (Presence JavaScript client) allows an attacker with ordinary channel access to cause a persistent client-side denial of service against every viewer of a presence channel topic. This vulnerability is associated with program files assets/js/phoenix/presence.js and program routines Presence.syncState and Presence.syncDiff. The Phoenix JavaScript presence client checks whether a presence already exists with a bare truthiness test (state[key]) instead of an own-property check. Presence keys can be attacker-controlled, because applications track presences under a username or id supplied by the client. A user who joins a channel choosing a key that is an Object.prototype member name (__proto__, constructor, toString, hasOwnProperty, and similar) makes that lookup return JavaScript's built-in Object.prototype instead of undefined. Because the prototype is truthy, the code treats it as an existing presence and reads .metas.map(...) off it, which throws an uncaught TypeError. The exception propagates out of the presence message handler, so the local state is never updated and onSync() never fires. Because the malicious key is tracked on the server, it is re-pushed on every presence update and keeps re-throwing, so presence sync stays broken for every viewer of that channel topic until the attacker leaves. Both syncState and syncDiff use the same unsafe existence-check pattern. The impact is limited to the affected topic and is a read-time confusion of the prototype object, not a mutation of Object.prototype (it is not prototype pollution). This issue affects phoenix: from 1.2.0-rc.0 before 1.5.15, from 1.6.0-rc.0 before 1.6.17, from 1.7.0-rc.0 before 1.7.24, and from 1.8.0-rc.0 before 1.8.9; phoenix: from 1.2.0-rc.0 before 1.5.15, from 1.6.0-rc.0 before 1.6.17, from 1.7.0-rc.0 before 1.7.24, and from 1.8.0-rc.0 before 1.8.9.

Allocation of Resources Without Limits or Throttling vulnerability in phoenixframework phoenix (Phoenix.Socket module) allows an unauthenticated attacker to cause a denial of service against any endpoint that mounts a Phoenix socket with a reachable channel transport (WebSocket or LongPoll). This vulnerability is associated with program files lib/phoenix/socket.ex and program routine 'Elixir.Phoenix.Socket':handle_in/4. Phoenix transports do not limit the number of channels that a single transport process may join. Every phx_join message a client sends over one connection starts a persistent channel process, and the socket process accepts an unbounded number of them. A single unauthenticated client can therefore open one WebSocket or LongPoll connection and stream a large number of phx_join messages, spawning hundreds of thousands of channel processes over that one connection and eventually reaching the BEAM maximum process limit. Once the process table is exhausted the virtual machine can no longer start new processes, denying service to legitimate traffic across the whole node. Because the amplification happens inside a single connection, network-layer connection caps and rate limiting do not mitigate it. The fix adds a :max_channels_per_transport option (default 100) that bounds the number of channels a single transport process can join, forcing abusive clients to open many connections instead, where external load balancers and reverse proxies can throttle them. This issue affects phoenix: from 0.11.0 before 1.5.15, from 1.6.0-rc.0 before 1.6.17, from 1.7.0-rc.0 before 1.7.24, and from 1.8.0-rc.0 before 1.8.9.

An HTTP Request/Response Splitting vulnerability (CWE-113) exists in the cowlib library used by cowboy and gun. The vulnerability arises because the encoder escapes only backslash and double quote characters but allows other bytes, including CR and LF, to pass through. This mismatch with the parser's expectations enables an attacker to inject CRLF sequences into HTTP headers, potentially splitting the response. This affects cowlib versions prior to 2.16.0.

A vulnerability in the hackney HTTP client library allows unbounded memory allocation when processing HTTP/3 responses. Specifically, the hackney_h3:await_response_loop/6 function accumulates the HTTP/3 response body in memory without any size limit. A malicious HTTP/3 server can send small chunks repeatedly without a final frame, causing the client to keep accumulating data indefinitely. This leads to exhaustion of the BEAM process heap and an out-of-memory condition. The issue affects hackney versions from 2.0.0 up to but not including 4.0.1.

Uncontrolled Resource Consumption vulnerability in ericmj decimal allows unauthenticated remote Denial of Service. The decimal library does not bound the exponent on parsed input. Storing a decimal with a very large exponent (e.g. Decimal.new("1e1000000000")) is accepted without error. Subsequent calls to arithmetic functions (Decimal.add/2, Decimal.sub/2, Decimal.div/2M), Decimal.to_string/2M with :normalM or :xsdM format, Decimal.to_integer/1M, Decimal.round/3M, or Decimal.compare/3M with a threshold allocate memory proportional to the exponent value, which can exhaust available memory and crash the BEAM VM. Any application that accepts user-supplied decimal input and subsequently performs arithmetic, rounding, conversion to integer, or string formatting on it is exposed. A single malicious request is sufficient to cause an out-of-memory crash. This issue affects decimal: from 0.1.0 before 3.0.0.