| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The c_rehash script does not properly sanitise shell metacharacters to prevent command injection. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). Fixed in OpenSSL 1.1.1o (Affected 1.1.1-1.1.1n). Fixed in OpenSSL 1.0.2ze (Affected 1.0.2-1.0.2zd). |
| A flaw was found in Keycloak. This vulnerability allows an unauthenticated remote attacker to cause a denial of service (DoS) by repeatedly initiating TLS 1.2 client-initiated renegotiation requests to exhaust server CPU resources, making the service unavailable. |
| A vulnerability has been found in JD Cloud BE6500 4.4.1.r4308. This issue affects the function sub_4780 of the file /jdcapi. Such manipulation of the argument ddns_name leads to command injection. The attack may be performed from remote. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| Hasura GraphQL 1.3.3 contains a denial of service vulnerability that allows attackers to overwhelm the service by crafting malicious GraphQL queries with excessive nested fields. Attackers can send repeated requests with extremely long query strings and multiple threads to consume server resources and potentially crash the GraphQL endpoint. |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 6.3 before 18.4.6, 18.5 before 18.5.4, and 18.6 before 18.6.2 that could have allowed an authenticated user to cause a Denial of Service condition by sending crafted API calls with large content parameters. |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 11.10 before 18.4.6, 18.5 before 18.5.4, and 18.6 before 18.6.2 that could have allowed an authenticated user to cause a denial of service condition by uploading specially crafted images. |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 11.10 before 18.4.6, 18.5 before 18.5.4, and 18.6 before 18.6.2 that could have allowed an unauthenticated user to create a denial of service condition by sending crafted GraphQL queries that bypass query complexity limits. |
| Ai command injection in Agentic AI and Visual Studio Code allows an unauthorized attacker to execute code over a network. |
| Improper neutralization of special elements used in a command ('command injection') in SQL Server allows an authorized attacker to elevate privileges over a network. |
| Vault and Vault Enterprise (“Vault”) are vulnerable to an unauthenticated denial of service when processing JSON payloads. This occurs due to a regression from a previous fix for [+HCSEC-2025-24+|https://discuss.hashicorp.com/t/hcsec-2025-24-vault-denial-of-service-though-complex-json-payloads/76393] which allowed for processing JSON payloads before applying rate limits. This vulnerability, CVE-2025-12044, is fixed in Vault Community Edition 1.21.0 and Vault Enterprise 1.16.27, 1.19.11, 1.20.5, and 1.21.0. |
| Denial of service condition in M-Files Server in versions before 24.2 (excluding 23.2 SR7 and 23.8 SR5) allows anonymous user to cause denial of service against other anonymous users. |
| Tornado is a Python web framework and asynchronous networking library. When Tornado's ``multipart/form-data`` parser encounters certain errors, it logs a warning but continues trying to parse the remainder of the data. This allows remote attackers to generate an extremely high volume of logs, constituting a DoS attack. This DoS is compounded by the fact that the logging subsystem is synchronous. All versions of Tornado prior to 6.5.0 are affected. The vulnerable parser is enabled by default. Upgrade to Tornado version 6.50 to receive a patch. As a workaround, risk can be mitigated by blocking `Content-Type: multipart/form-data` in a proxy. |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can allow a low-privileged authenticated user to cause Excessive Allocation (CAPEC-130) of computing resources and a denial of service (DoS) of the Kibana process via a crafted HTTP request. |
| In the Linux kernel, the following vulnerability has been resolved:
ubifs: Set page uptodate in the correct place
Page cache reads are lockless, so setting the freshly allocated page
uptodate before we've overwritten it with the data it's supposed to have
in it will allow a simultaneous reader to see old data. Move the call
to SetPageUptodate into ubifs_write_end(), which is after we copied the
new data into the page. |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can allow a low-privileged authenticated user to cause Excessive Allocation (CAPEC-130) causing a persistent denial of service (OOM crash) via submission of oversized user settings data. |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can allow an authenticated user with snapshot restore privileges to cause Excessive Allocation (CAPEC-130) of memory and a denial of service (DoS) via crafted HTTP request. |
| Allocation of resources without limits or throttling (CWE-770) allows an unauthenticated remote attacker to cause excessive allocation (CAPEC-130) of memory and CPU via the integration of malicious IPv4 fragments, leading to a degradation in Packetbeat. |
| In the Linux kernel, the following vulnerability has been resolved:
powerpc/kasan: Limit KASAN thread size increase to 32KB
KASAN is seen to increase stack usage, to the point that it was reported
to lead to stack overflow on some 32-bit machines (see link).
To avoid overflows the stack size was doubled for KASAN builds in
commit 3e8635fb2e07 ("powerpc/kasan: Force thread size increase with
KASAN").
However with a 32KB stack size to begin with, the doubling leads to a
64KB stack, which causes build errors:
arch/powerpc/kernel/switch.S:249: Error: operand out of range (0x000000000000fe50 is not between 0xffffffffffff8000 and 0x0000000000007fff)
Although the asm could be reworked, in practice a 32KB stack seems
sufficient even for KASAN builds - the additional usage seems to be in
the 2-3KB range for a 64-bit KASAN build.
So only increase the stack for KASAN if the stack size is < 32KB. |
| An authenticated user can provide a malformed ACL to the fileserver's StoreACL RPC, causing the fileserver to crash, possibly expose uninitialized memory, and possibly store garbage data in the audit log. Malformed ACLs provided in responses to client FetchACL RPCs can cause client processes to crash and possibly expose uninitialized memory into other ACLs stored on the server. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: smscufx: fix error handling code in ufx_usb_probe
The current error handling code in ufx_usb_probe have many unmatching
issues, e.g., missing ufx_free_usb_list, destroy_modedb label should
only include framebuffer_release, fb_dealloc_cmap only matches
fb_alloc_cmap.
My local syzkaller reports a memory leak bug:
memory leak in ufx_usb_probe
BUG: memory leak
unreferenced object 0xffff88802f879580 (size 128):
comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s)
hex dump (first 32 bytes):
80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff .!|.............
00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00 ................
backtrace:
[<ffffffff814c99a0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1045
[<ffffffff824d219c>] kmalloc include/linux/slab.h:553 [inline]
[<ffffffff824d219c>] kzalloc include/linux/slab.h:689 [inline]
[<ffffffff824d219c>] ufx_alloc_urb_list drivers/video/fbdev/smscufx.c:1873 [inline]
[<ffffffff824d219c>] ufx_usb_probe+0x11c/0x15a0 drivers/video/fbdev/smscufx.c:1655
[<ffffffff82d17927>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
[<ffffffff82712f0d>] call_driver_probe drivers/base/dd.c:560 [inline]
[<ffffffff82712f0d>] really_probe+0x12d/0x390 drivers/base/dd.c:639
[<ffffffff8271322f>] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
[<ffffffff827132da>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:808
[<ffffffff82713c27>] __device_attach_driver+0xf7/0x150 drivers/base/dd.c:936
[<ffffffff82710137>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
[<ffffffff827136b5>] __device_attach+0x105/0x2d0 drivers/base/dd.c:1008
[<ffffffff82711d36>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
[<ffffffff8270e242>] device_add+0x642/0xdc0 drivers/base/core.c:3517
[<ffffffff82d14d5f>] usb_set_configuration+0x8ef/0xb80 drivers/usb/core/message.c:2170
[<ffffffff82d2576c>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238
[<ffffffff82d16ffc>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293
[<ffffffff82712f0d>] call_driver_probe drivers/base/dd.c:560 [inline]
[<ffffffff82712f0d>] really_probe+0x12d/0x390 drivers/base/dd.c:639
[<ffffffff8271322f>] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778
Fix this bug by rewriting the error handling code in ufx_usb_probe. |
