| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Denial-of-service in the Widget component. This vulnerability was fixed in Firefox 154, Firefox ESR 153.1, Thunderbird 154, and Thunderbird 153.1. |
| Ech0 before 5.0.1 does not impose any size or shape limit on the Accept-Language header processed by its i18n middleware, which runs on every HTTP request. The header is passed unfiltered to go-i18n's NewLocalizer, which internally calls golang.org/x/text/language.ParseAcceptLanguage. The CVE-2022-32149 mitigation in x/text caps '-' characters but not '_' characters, which the parser aliases to '-', allowing quadratic-time parsing to be triggered with a large header (up to Go's default 1 MiB) built from underscore separators. An unauthenticated attacker can send such requests to consume roughly 1.5 seconds of CPU each, and concurrent requests can saturate a multi-core server (denial of service). |
| Issue summary: Receiving a DTLS record for a future epoch while a handshake
is in progress causes OpenSSL to buffer far more memory than the record
itself requires.
Impact summary: A peer can use a small amount of network traffic to make an
OpenSSL DTLS endpoint retain a disproportionately large amount of memory,
which may lead to a Denial of Service.
CWE: CWE-405: Asymmetric Resource Consumption (Amplification)
Description: While a DTLS handshake is in progress, a peer may legitimately
have already moved on to the next epoch (for example, having sent its
ChangeCipherSpec and Finished messages) before the local endpoint has
processed the same transition, typically because of reordering on the
underlying UDP transport. OpenSSL buffers such early records so that they
can be processed once the local endpoint catches up.
Buffering a record currently retains the entire read buffer it arrived in,
which is sized to hold the largest possible DTLS record (around 16
kilobytes), rather than just the bytes that make up the record itself. Up
to 100 such records may be buffered per connection. As a result, a peer
that sends a stream of small forged records claiming to belong to the next
epoch can cause an OpenSSL DTLS endpoint to retain around 1.7 megabytes of
memory, despite sending only a small fraction of that amount of data over
the network.
An attacker therefore gains a memory amplification factor of around 1200,
and can multiply the effect across as many associations as it is able to
open, making this a remote memory exhaustion Denial of Service risk for
DTLS servers. Since the memory retained per connection remains bounded,
and any limit an application already places on the number of concurrent
associations also bounds the total exposure, this issue has been assessed
as Low severity.
FIPS impact: no
No FIPS modules are affected by this issue as the affected code is outside
the OpenSSL FIPS module boundary.
OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are vulnerable to this
issue.
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.2.
OpenSSL 3.6 users should upgrade to OpenSSL 3.6.4.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.8.
OpenSSL 3.4 users should upgrade to OpenSSL 3.4.7.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.22.
Premium support customers only:
OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1zi
OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zr
This issue was reported on 18 May 2026 by Amazon Web Services.
The fix has been developed by Matt Caswell.
-- cut (non-publishing metadata for internal use) --
Reported by: Amazon Web Services
Fixed by: Matt Caswell |
| OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. Versions prior to 3.2.10, 3.3.12, and 3.4.13 contain an infinite-loop vulnerability in SampleCountChannel. The helper roundListSizeUp() rounds a sample-list size up to the next power of two using repeated unsigned left shifts, which terminates for normal values but fails for UINT_MAX: the sequence reaches 0x80000000, and the next left shift wraps the 32-bit value to 0. Because 0 remains less than UINT_MAX, the loop never progresses and never exits. The bug is reachable through public OpenEXRUtil APIs, either by editing the sample-count buffer through SampleCountChannel::Edit (whose destructor calls endEdit()) or by calling SampleCountChannel::set(x, y, UINT_MAX) on a valid pixel. This issue has been fixed in versions 3.2.10, 3.3.12, and 3.4.13. |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to cause a denial of service due to uncontrolled resource consumption when parsing directory records. |
| In libexpat before 2.8.1, the computational complexity of attribute name collision checks allows a denial of service via moderately sized crafted XML input. |
| urllib3 is an HTTP client library for Python. From 2.6.0 to before 2.7.0, urllib3 could decompress the whole response instead of the requested portion (1) during the second HTTPResponse.read(amt=N) call when the response was decompressed using the official Brotli library or (2) when HTTPResponse.drain_conn() was called after the response had been read and decompressed partially (compression algorithm did not matter here). These issues could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This could result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data) on the client side. This vulnerability is fixed in 2.7.0. |
| Denial-of-service (DoS) vulnerability in the internal JPEG2000 (JPX) decoding implementation of the Poppler fork developed by Innodata Labs. When an application processes an untrusted PDF file containing specially crafted JPXDecode images, a remote attacker can cause uncontrolled memory consumption. The flaw occurs in the JPXStream::readCodestream() function, where values controlled from the SIZ segment (such as img.nComps) are used for the memory allocation of tiles and components without adequate validation. This allows an attacker to force excessive memory allocation and cause a resource exhaustion, ultimately causing the pdftoppm process to terminate due to out-of-memory (OOM) conditions. |
| AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below allow a zip bomb to be used to execute a DoS against the AIOHTTP server. An attacker may be able to send a compressed request that when decompressed by AIOHTTP could exhaust the host's memory. This issue is fixed in version 3.13.3. |
| Checkmate is an open-source, self-hosted tool designed to track and monitor server hardware, uptime, response times, and incidents in real-time with beautiful visualizations. Prior to 3.9.1, the public POST /api/v1/auth/register route in server/src/api/routes/authRoutes.ts passes multipart profileImage uploads through in-memory Multer parsing before registration validation, without file-size, file-count, or MIME-type limits in server/src/api/middleware/upload.ts. An unauthenticated attacker can submit concurrent oversized files that are buffered before invalid registration or invite-token checks reject the request, exhausting memory and crashing or destabilizing the backend. This issue is fixed in version 3.9.1. |
| vLLM before 0.27.0 fails to properly classify DeepStream as a GPU backend and omits pixel-limit enforcement in its decode path. Unauthenticated attackers can activate DeepStream at request time to initialize the process-wide GPU decode pool and submit video that bypasses resource controls, causing partial denial of service for concurrent requests. |
| In the Linux kernel, the following vulnerability has been resolved:
net: thunderbolt: Tear down DMA paths before stopping the rings
tbnet_tear_down() stops both rings and frees their frame buffers before
calling tb_xdomain_disable_paths(). tb_ring_stop() zeroes the ring's
descriptor base and tbnet_free_buffers() unmaps and frees the pages the
frames sit in, so by the time __tb_path_deactivate_hop() polls the hop's
'pending' bit, anything still in flight has nowhere to drain to.
The teardown sequence has been in this order since the driver was added.
The setup path has not: commit ff7cd07f3064 ("net: thunderbolt: Enable
DMA paths only after rings are enabled") moved the path enable to the end
of tbnet_connected_work() and documented why:
/* Both logins successful so enable the rings, high-speed DMA
* paths and start the network device queue.
*
* Note we enable the DMA paths last to make sure we have primed
* the Rx ring before any incoming packets are allowed to
* arrive.
*/
Teardown was never updated to match, so the rings and the paths now come
down in the same order they go up instead of in reverse.
On an ASMedia ASM4242 host router the 'pending' bit then never clears:
every teardown burns the full 500 ms timeout and
__tb_path_deactivate_hop() returns -ETIMEDOUT. Raising the timeout to
5 s does not help, so the hop is not slow to drain, it never drains
at all.
The failure is invisible above the thunderbolt core.
__tb_path_deactivate_hops() is void and only calls tb_port_warn();
tb_path_deactivate(), tb_tunnel_deactivate() and
__tb_disconnect_xdomain_paths() are void as well, and
tb_disconnect_xdomain_paths() ends in an unconditional "return 0". So
tb_xdomain_disable_paths() reports success and the netdev_warn() below
it never fires. Repeated teardowns eventually take the XDomain control
channel down, after which the peer node is gone and only a power cycle
brings the controller back.
Deactivating the paths first fixes it. Measured with kretprobes on a
stock v6.17 tree with no other patches applied, on a link that was up
and had just carried traffic:
before: __tb_path_deactivate_hop() returns 0 for the first hop, then
-ETIMEDOUT for the second 500335 us later
after: 0 for both, 525 us apart
Alternating the two orderings ABBA over three load levels, four
teardowns per arm: every teardown failed before the change (21 of 21
that ran), none failed after (0 of 24). The before arms ran short
because the link died partway through. The same split shows up when
the interface is enslaved to a bond instead of just brought down, which
is how I ran into this in the first place. Throughput and latency after
the change are unchanged.
Hosts whose routers drain the hop despite the stale descriptor base see
no functional difference, since the paths end up deactivated either way. |
| Vulnerability in the Helidon product of Oracle Fusion Middleware (component: Imperative Web Server). The supported version that is affected is 3.2.19. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Helidon. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Helidon. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). |
| A memory leak flaw was found in cockpit-ws. The login page handler leaks a heap allocation on every unauthenticated request that carries a CockpitLang cookie, allowing a remote unauthenticated attacker to exhaust memory on the host and cause a denial of service. |
| A vulnerability has been found in BusyBox up to 1.30.1. This vulnerability affects unknown code of the file networking/wget.c of the component FEATURE_WGET_TIMEOUT Handler. Such manipulation of the argument -T leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The name of the patch is 83a40bf7a93c8ac093d33ab452222dd5b9eb57ff. A patch should be applied to remediate this issue. |
| Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). The supported version that is affected is 7.2.14. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle VM VirtualBox. CVSS 3.1 Base Score 6.0 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H). |
| Grav is a file-based Web platform. Prior to 2.0.1, Grav ZipArchiver::extract() in system/src/Grav/Common/Filesystem/ZipArchiver.php passes archives to ZipArchive::extractTo() without enforcing the system.gpm.archive uncompressed-size, file-count, or nesting-depth limits. Code using Archiver::create('zip') to extract an attacker-controlled archive can exhaust disk space or inodes and make the site unavailable. This issue is fixed in version 2.0.1. |
| Vulnerability in the MySQL Connectors product of Oracle MySQL (component: Connector/ODBC). The supported version that is affected is 26.7.0. Easily exploitable vulnerability allows unauthenticated attacker with logon to the infrastructure where MySQL Connectors executes to compromise MySQL Connectors. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Connectors. CVSS 3.1 Base Score 5.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H). |
| RansomLook contains multiple weaknesses in its authentication endpoint that allow an unauthenticated remote attacker to enumerate valid usernames, perform unrestricted password-guessing attacks, and potentially exhaust application worker resources.
For local authentication, the login implementation previously checked whether a submitted username existed before invoking the password hash verification function. Requests containing a nonexistent username therefore returned significantly faster than requests for valid accounts, for which the computationally expensive password verification routine was executed. A remote attacker could measure these response-time differences to determine which usernames correspond to valid RansomLook accounts.
In addition, the /login endpoint did not restrict the number or frequency of failed authentication attempts. An attacker could consequently perform password brute-force, dictionary, password-spraying, or credential-stuffing attacks against known accounts without server-side throttling. For valid usernames, each authentication attempt also invokes the password key-derivation function, which consumes a significant amount of CPU time. A sufficiently high rate of login attempts could therefore occupy the application's synchronous Gunicorn workers and cause a denial of service affecting the entire application.
The issue has been addressed by always performing password verification using a randomly generated dummy password hash when the supplied username does not exist, eliminating the username-dependent timing discrepancy. Failed authentication attempts are additionally rate-limited per client IP address using Valkey/Redis, with five failed attempts within five minutes resulting in a one-hour block. The reverse-proxy configuration was also updated so that the application derives the client address from a trusted X-Forwarded-For value that cannot be overridden by a client-supplied header. |
| Micrometer-instrumented Apache HttpAsyncClient (4.x or 5.x) usage via MicrometerHttpClientInterceptor can leak memory unboundedly when asynchronous requests fail before receiving a response (e.g. connection resets or timeouts). Tracking state for these requests remains in memory indefinitely, and sustained failures lead to heap exhaustion and OutOfMemoryError crashes. |
