Pexip Infinity versions 30.0 through 40.x before 41.0 contain a vulnerability due to improper input validation in the web server. This flaw allows a malicious attacker to cause resource exhaustion, rendering a Pexip Infinity node inaccessible. The vulnerability is classified under CWE-770, indicating allocation of resources without limits or throttling. The issue impacts availability but does not affect confidentiality or integrity.
An uncontrolled resource consumption vulnerability in the Fireware OS login process (wgagent) allows a remote, unauthenticated attacker to cause a denial of service by sending a specially crafted request.
An uncontrolled resource consumption vulnerability in Fireware OS's diagnostic tasks feature allows a low-privileged, authenticated user to cause a denial of service of the system's diagnostic tools by repeatedly starting and aborting a specially crafted diagnostic task through the web UI.
CVE-2026-102821 is an uncontrolled resource consumption vulnerability in the Eugeny russh Rust SSH client and server library. Versions prior to 0.63.2 allow an authenticated remote peer to flood SSH_MSG_CHANNEL_OPEN messages without sending the required SSH_MSG_KEX_ECDH_INIT, causing the server to enqueue replies on an unbounded channel. This leads to memory growth until the process is terminated. The issue is fixed in version 0.63.2.
CVE-2026-102713 is a high-severity vulnerability in Eclipse ThreadX NetX Duo up to version 6.5.2.202603. The TFTP server component, when built with packet chaining, does not properly limit the length of received DATA datagrams. This allows an unauthenticated attacker to upload an oversized datagram that causes out-of-bounds memory writes into files and can also suspend the server thread permanently.
setup.py test %endif
Security Fix(es):
PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT get_signing_key_from_jwt is affected because unknown kid misses force refreshes without a negative cache or minimum refresh interval. This occurs when unauthenticated tokens repeatedly use the same unknown kid or varying kid values absent from the cached JWKS. As a result, each cache miss causes PyJWKClient to refresh the JWKS. Consequently, attacker traffic can amplify outbound requests to the configured JWKS endpoint. This issue is fixed in version 2.14.0.(CVE-2026-101917)
PyJWT is a Python implementation of JSON Web Token standards. From 2.0.0a1 until 2.15.0, PyJWT PyJWKClient.get_signing_key_from_jwt is affected because payload parser catches ValueError but not RecursionError. This occurs when an attacker-controlled recursively nested payload reaches json.loads. As a result, documented PyJWT exception handling does not contain the failure. Consequently, an unauthenticated request can raise an exception that may produce an HTTP 500 response. The advisory-defined affected implementation also includes jwt/api_jwt.py, verify_signature=False. This issue is fixed in version 2.15.0.(CVE-2026-101918)
PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWS._load in jwt/api_jws.py is affected because parser catches ValueError but not RecursionError. This occurs when a deeply nested token header reaches json.loads. As a result, RecursionError escapes the documented PyJWT error hierarchy. Consequently, an unauthenticated malformed token can cause a request-level failure and HTTP 500. This issue is fixed in version 2.14.0.(CVE-2026-102265)
PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT signature segment is affected because signature segment decoding accepts characters outside the canonical Base64URL representation. This occurs when non-Base64URL characters are appended to a valid compact JWS signature segment. As a result, base64url_decode produces the same signature bytes for different serialized segments. Consequently, raw-token revocation checks can fail to recognize an equivalent modified token. This issue is fixed in version 2.14.0.(CVE-2026-102269)
PyJWT is a Python implementation of JSON Web Token standards. From 2.1.0 until 2.15.0, PyJWT OKPAlgorithm.from_jwk in jwt/algorithms.py is affected because private-JWK import path does not compare the public key derived from d with x. This occurs when an OKP private JWK supplies non-corresponding x and d components. As a result, identity derived from x can differ from operations performed with d. Consequently, if an integration also accepts private key parameters from a proof header without rejecting them, an attacker may use a stolen sender-constrained token without the legitimate private key. This issue is fixed in version 2.15.0.(CVE-2026-102275)
CVE-2026-101911 is a medium severity vulnerability in the JavaScript ip-address library before version 10.7.1. It involves uncontrolled resource consumption due to unbounded string input in the Address6 constructor, Address6.isValid, and related parsing code. Large attacker-controlled inputs can cause synchronous stalls, high memory usage, invalid string length exceptions, and process termination. The issue is fixed in version 10.7.1.
mH-DEVELOPER smart home module is vulnerable to Denial of Service due to uncontrolled resource consumption. The Express bodyParser is configured with a 250 MB limit for JSON and URL-encoded request bodies. An authenticated attacker on the LAN can send large request bodies that exhausts buffers in RAM, causing out-of-memory conditions and crashing the fh-node process, resulting in denial of service. The successful attack depends on the current memory usage of the device which is not under full control of the attacker. Critically, due to CVE-2026-82930 all endpoints can be queried unauthenticated, so any user on LAN can perform this attack.
This issue was fixed in version 3.0.30
CVE-2026-92103 is a resource allocation vulnerability in the elixir-mint mint HTTP/2 client library. A malicious HTTP/2 server can cause the client to buffer up to about 16 MiB of data per connection by sending frames with large declared payloads but withholding the last byte. This leads to excessive memory consumption on the client side. The issue affects mint versions from 0.1.0 up to but not including 1.10.2.
CVE-2026-91043 is a high-severity vulnerability in the elixir-mint mint library affecting versions from 1.1.0 up to but not including 1.10.2. It involves improper resource allocation limits in the HTTP/2 client implementation, allowing a malicious HTTP/2 server to cause excessive memory consumption on the client by exploiting how header sizes are enforced. This can lead to denial of service by exhausting the memory of the process or the entire virtual machine.
CVE-2026-67225 is a medium severity vulnerability in rabbitmq-server affecting versions 3.13.0 through 3.13.14, 4.0.0 through 4.0.19, 4.1.0 through 4.1.10, and 4.2.0 through 4.2.5. The issue involves the stream protocol storing the FrameMax value negotiated during the Tune handshake but failing to validate inbound frame lengths against this value. This allows a remote client to cause excessive memory consumption and potentially a denial of service when the stream plugin is enabled. The vulnerability is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15, 4.0.20, 4.1.11, and 4.2.6, the Web STOMP WebSocket handler enforced neither max_frame_size nor login_timeout before authentication, allowing an unauthenticated client to keep a connection alive with a slow stream of small frames and accumulate unbounded pre-authentication state. The rabbitmq_web_stomp plugin must be enabled, and no authentication is required to reach the vulnerable path. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
A pre-authentication attacker could leverage type size/count handling to cause excessive allocation leading to potential denial of service.
This issue affects Apache Qpid Broker-J: through 10.1.0.
Users are recommended to upgrade to version 10.1.1, which fixes the issue.
authentik is an open-source identity provider. Prior to 2026.2.7, 2026.5.7, and 2026.8.2, an unauthenticated attacker can submit a malformed SAML message to an authentik deployment using SAML in either the identity-provider or SAML source role. The message can stop the worker handling /application/saml/* or /source/saml/*, causing the requests assigned to that worker to fail. Worker process termination and automatic restart do not destroy database-backed sessions, but continued malicious messages can cause a sustained share of legitimate traffic to fail. Other protocol implementations are not affected. This issue is fixed in versions 2026.2.7, 2026.5.7, and 2026.8.2.
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, add_binding/3 parses the routing key as an integer weight N and computes ring positions with lists:seq(NextN0, NextN0 + N - 1). validate_binding/2 only checks N >= 1 , no upper bound. The resulting list is stored in the exchange's Khepri record, replicated cluster-wide, and reloaded on restart. A user with write permission on a consistent-hash exchange and read on a queue can create a binding whose routing key (the hash-ring weight) is an arbitrarily large integer. The broker allocates a list of that many integers via lists:seq/2 and persists it to Khepri across all cluster nodes , a single binding with weight 100000000 allocates ~800 MB on every node and survives restarts. Preconditions include rabbitmq_consistent_hash_exchange plugin enabled write permission on a consistent-hash exchange + read on a queue (standard binding perms). This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.
RabbitMQ is a messaging and streaming broker. Prior to versions 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15, The content-header BodySize (a uint64) was stored without validation against max_message_size. The size check ran only when assembly completed. By declaring body_size = 2^63-1 and then streaming fragments, a client ensured that check_msg_size never fired, so the accumulated body size went unbounded. A reader process accumulates memory until the memory alarm fires, degrading all publishers cluster-wide, or until the node runs out of memory. The memory alarm provides only partial mitigation, since it is reactive rather than preventive. AMQP 0-9-1 is the most widely used protocol, and any publisher can trigger this condition. Preconditions include Any authenticated AMQP 0-9-1 client with publish permission can exploit this.. This issue is fixed in versions 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15.
RabbitMQ is a messaging and streaming broker. Prior to versions 4.1.11, 4.2.6, and 4.3.0, validate_partitions only checks that the requested partition count is at least 1, with no upper bound. A large count such as lists:seq(0, 500000000) allocates roughly 8GB. Preconditions include The rabbitmq_stream_management plugin must be enabled. The caller needs the management tag and access to the target vhost.. This issue is fixed in versions 4.1.11, 4.2.6, and 4.3.0.