Total
2494 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-47208 | 2 Qnap, Qnap Systems Inc. | 4 Qts, Quts Hero, Qts and 1 more | 2026-01-05 | 6.5 Medium |
| An allocation of resources without limits or throttling vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains a user account, they can then exploit the vulnerability to prevent other systems, applications, or processes from accessing the same type of resource. We have already fixed the vulnerability in the following versions: QTS 5.2.6.3195 build 20250715 and later QuTS hero h5.2.6.3195 build 20250715 and later | ||||
| CVE-2025-57705 | 2 Qnap, Qnap Systems Inc. | 4 Qts, Quts Hero, Qts and 1 more | 2026-01-05 | 4.9 Medium |
| An allocation of resources without limits or throttling vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains an administrator account, they can then exploit the vulnerability to prevent other systems, applications, or processes from accessing the same type of resource. We have already fixed the vulnerability in the following versions: QTS 5.2.7.3256 build 20250913 and later QuTS hero h5.2.7.3256 build 20250913 and later QuTS hero h5.3.1.3250 build 20250912 and later | ||||
| CVE-2024-57838 | 1 Linux | 1 Linux Kernel | 2026-01-05 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: s390/entry: Mark IRQ entries to fix stack depot warnings The stack depot filters out everything outside of the top interrupt context as an uninteresting or irrelevant part of the stack traces. This helps with stack trace de-duplication, avoiding an explosion of saved stack traces that share the same IRQ context code path but originate from different randomly interrupted points, eventually exhausting the stack depot. Filtering uses in_irqentry_text() to identify functions within the .irqentry.text and .softirqentry.text sections, which then become the last stack trace entries being saved. While __do_softirq() is placed into the .softirqentry.text section by common code, populating .irqentry.text is architecture-specific. Currently, the .irqentry.text section on s390 is empty, which prevents stack depot filtering and de-duplication and could result in warnings like: Stack depot reached limit capacity WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8 with PREEMPT and KASAN enabled. Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into the .irqentry.text section and updating the kprobes blacklist to include the .irqentry.text section. This is done only for asynchronous interrupts and explicitly not for program checks, which are synchronous and where the context beyond the program check is important to preserve. Despite machine checks being somewhat in between, they are extremely rare, and preserving context when possible is also of value. SVCs and Restart Interrupts are not relevant, one being always at the boundary to user space and the other being a one-time thing. IRQ entries filtering is also optionally used in ftrace function graph, where the same logic applies. | ||||
| CVE-2023-52622 | 3 Debian, Linux, Redhat | 4 Debian Linux, Linux Kernel, Enterprise Linux and 1 more | 2026-01-05 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ext4: avoid online resizing failures due to oversized flex bg When we online resize an ext4 filesystem with a oversized flexbg_size, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G the following WARN_ON is triggered: ================================================================== WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550 Modules linked in: sg(E) CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314 RIP: 0010:__alloc_pages+0x411/0x550 Call Trace: <TASK> __kmalloc_large_node+0xa2/0x200 __kmalloc+0x16e/0x290 ext4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ================================================================== This is because flexbg_size is too large and the size of the new_group_data array to be allocated exceeds MAX_ORDER. Currently, the minimum value of MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding maximum number of groups that can be allocated is: (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845 And the value that is down-aligned to the power of 2 is 16384. Therefore, this value is defined as MAX_RESIZE_BG, and the number of groups added each time does not exceed this value during resizing, and is added multiple times to complete the online resizing. The difference is that the metadata in a flex_bg may be more dispersed. | ||||
| CVE-2025-44652 | 1 Netgear | 2 Rax30, Rax30 Firmware | 2026-01-02 | 7.5 High |
| In Netgear RAX30 V1.0.10.94_3, the USERLIMIT_GLOBAL option is set to 0 in multiple bftpd-related configuration files. This can cause DoS attacks when unlimited users are connected. | ||||
| CVE-2025-21690 | 1 Linux | 1 Linux Kernel | 2026-01-02 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Ratelimit warning logs to prevent VM denial of service If there's a persistent error in the hypervisor, the SCSI warning for failed I/O can flood the kernel log and max out CPU utilization, preventing troubleshooting from the VM side. Ratelimit the warning so it doesn't DoS the VM. | ||||
| CVE-2025-68148 | 1 Freshrss | 1 Freshrss | 2025-12-31 | 4.3 Medium |
| FreshRSS is a free, self-hostable RSS aggregator. From version 1.27.0 to before 1.28.0, An attacker could globally deny access to feeds via proxy modifying to 429 Retry-After for a large list of feeds on given instance, making it unusable for majority of users. This issue has been patched in version 1.28.0. | ||||
| CVE-2025-32952 | 1 Haulmont | 4 Cuba Platform, Cuba Rest Api, Jmix Framework and 1 more | 2025-12-31 | 6.5 Medium |
| Jmix is a set of libraries and tools to speed up Spring Boot data-centric application development. In versions 1.0.0 to 1.6.1 and 2.0.0 to 2.3.4, the local file storage implementation does not restrict the size of uploaded files. An attacker could exploit this by uploading excessively large files, potentially causing the server to run out of space and return HTTP 500 error, resulting in a denial of service. This issue has been patched in versions 1.6.2 and 2.4.0. A workaround is provided on the Jmix documentation website. | ||||
| CVE-2024-48809 | 2 Onosproject, Opennetworking | 3 Sdran-in-a-box, Onos-a1t, Sdran-in-a-box | 2025-12-31 | 7.5 High |
| An issue in Open Networking Foundations sdran-in-a-box v.1.4.3 and onos-a1t v.0.2.3 allows a remote attacker to cause a denial of service via the onos-a1t component of the sdran-in-a-box, specifically the DeleteWatcher function. | ||||
| CVE-2021-47713 | 1 Hasura | 1 Graphql Engine | 2025-12-26 | 7.5 High |
| 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. | ||||
| CVE-2025-14157 | 1 Gitlab | 1 Gitlab | 2025-12-23 | 6.5 Medium |
| 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. | ||||
| CVE-2025-4097 | 1 Gitlab | 1 Gitlab | 2025-12-23 | 6.5 Medium |
| 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. | ||||
| CVE-2025-12562 | 1 Gitlab | 1 Gitlab | 2025-12-23 | 7.5 High |
| 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. | ||||
| CVE-2025-12044 | 1 Hashicorp | 2 Vault, Vault Enterprise | 2025-12-23 | 7.5 High |
| 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. | ||||
| CVE-2025-47287 | 3 Debian, Redhat, Tornadoweb | 7 Debian Linux, Enterprise Linux, Rhel E4s and 4 more | 2025-12-23 | 7.5 High |
| 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. | ||||
| CVE-2025-68389 | 1 Elastic | 1 Kibana | 2025-12-23 | 6.5 Medium |
| 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. | ||||
| CVE-2025-68384 | 1 Elastic | 1 Elasticsearch | 2025-12-23 | 6.5 Medium |
| 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. | ||||
| CVE-2025-68390 | 1 Elastic | 1 Elasticsearch | 2025-12-23 | 4.9 Medium |
| 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. | ||||
| CVE-2025-68388 | 2 Elastic, Elasticsearch | 2 Packetbeat, Packetbeat | 2025-12-23 | 5.3 Medium |
| 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. | ||||
| CVE-2024-26710 | 1 Linux | 1 Linux Kernel | 2025-12-23 | 5.5 Medium |
| 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. | ||||