ReportizFlow
Filtered by vendor
Subscriptions
Total
1406 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2019-25220 | 1 Bitcoin | 1 Bitcoin Core | 2025-05-22 | 7.5 High |
| Bitcoin Core before 24.0.1 allows remote attackers to cause a denial of service (daemon crash) via a flood of low-difficulty header chains (aka a "Chain Width Expansion" attack) because a node does not first verify that a presented chain has enough work before committing to store it. | ||||
| CVE-2024-55563 | 1 Bitcoin | 1 Bitcoin Core | 2025-05-22 | 5.3 Medium |
| Bitcoin Core through 27.2 allows transaction-relay jamming via an off-chain protocol attack, a related issue to CVE-2024-52913. For example, the outcome of an HTLC (Hashed Timelock Contract) can be changed because a flood of transaction traffic prevents propagation of certain Lightning channel transactions. | ||||
| CVE-2024-35202 | 1 Bitcoin | 2 Bitcoin, Bitcoin Core | 2025-05-22 | 7.5 High |
| Bitcoin Core before 25.0 allows remote attackers to cause a denial of service (blocktxn message-handling assertion and node exit) by including transactions in a blocktxn message that are not committed to in a block's merkle root. FillBlock can be called twice for one PartiallyDownloadedBlock instance. | ||||
| CVE-2021-47551 | 1 Linux | 1 Linux Kernel | 2025-05-22 | 6.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdkfd: Fix kernel panic when reset failed and been triggered again In SRIOV configuration, the reset may failed to bring asic back to normal but stop cpsch already been called, the start_cpsch will not be called since there is no resume in this case. When reset been triggered again, driver should avoid to do uninitialization again. | ||||
| CVE-2024-26618 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-05-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: arm64/sme: Always exit sme_alloc() early with existing storage When sme_alloc() is called with existing storage and we are not flushing we will always allocate new storage, both leaking the existing storage and corrupting the state. Fix this by separating the checks for flushing and for existing storage as we do for SVE. Callers that reallocate (eg, due to changing the vector length) should call sme_free() themselves. | ||||
| CVE-2023-4912 | 1 Gitlab | 1 Gitlab | 2025-05-22 | 2.6 Low |
| An issue has been discovered in GitLab EE affecting all versions starting from 10.5 before 16.4.3, all versions starting from 16.5 before 16.5.3, all versions starting from 16.6 before 16.6.1. It was possible for an attacker to cause a client-side denial of service using malicious crafted mermaid diagram input. | ||||
| CVE-2023-3246 | 1 Gitlab | 1 Gitlab | 2025-05-22 | 4.3 Medium |
| An issue has been discovered in GitLab EE/CE affecting all versions starting before 16.3.6, all versions starting from 16.4 before 16.4.2, all versions starting from 16.5 before 16.5.1 which allows an attackers to block Sidekiq job processor. | ||||
| CVE-2022-3295 | 1 Ikus-soft | 1 Rdiffweb | 2025-05-21 | 7.5 High |
| Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.4.8. | ||||
| CVE-2024-21011 | 4 Debian, Netapp, Oracle and 1 more | 17 Debian Linux, Active Iq Unified Manager, Data Infrastructure Insights Acquisition Unit and 14 more | 2025-05-21 | 3.7 Low |
| Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2, 22; Oracle GraalVM Enterprise Edition: 20.3.13 and 21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L). | ||||
| CVE-2022-3298 | 1 Ikus-soft | 1 Rdiffweb | 2025-05-21 | 7.5 High |
| Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.4.8. | ||||
| CVE-2024-49974 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-05-21 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches. | ||||
| CVE-2024-26646 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-05-21 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: thermal: intel: hfi: Add syscore callbacks for system-wide PM The kernel allocates a memory buffer and provides its location to the hardware, which uses it to update the HFI table. This allocation occurs during boot and remains constant throughout runtime. When resuming from hibernation, the restore kernel allocates a second memory buffer and reprograms the HFI hardware with the new location as part of a normal boot. The location of the second memory buffer may differ from the one allocated by the image kernel. When the restore kernel transfers control to the image kernel, its HFI buffer becomes invalid, potentially leading to memory corruption if the hardware writes to it (the hardware continues to use the buffer from the restore kernel). It is also possible that the hardware "forgets" the address of the memory buffer when resuming from "deep" suspend. Memory corruption may also occur in such a scenario. To prevent the described memory corruption, disable HFI when preparing to suspend or hibernate. Enable it when resuming. Add syscore callbacks to handle the package of the boot CPU (packages of non-boot CPUs are handled via CPU offline). Syscore ops always run on the boot CPU. Additionally, HFI only needs to be disabled during "deep" suspend and hibernation. Syscore ops only run in these cases. [ rjw: Comment adjustment, subject and changelog edits ] | ||||
| CVE-2021-47374 | 1 Linux | 1 Linux Kernel | 2025-05-21 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: dma-debug: prevent an error message from causing runtime problems For some drivers, that use the DMA API. This error message can be reached several millions of times per second, causing spam to the kernel's printk buffer and bringing the CPU usage up to 100% (so, it should be rate limited). However, since there is at least one driver that is in the mainline and suffers from the error condition, it is more useful to err_printk() here instead of just rate limiting the error message (in hopes that it will make it easier for other drivers that suffer from this issue to be spotted). | ||||
| CVE-2022-41846 | 1 Axiosys | 1 Bento4 | 2025-05-20 | 5.5 Medium |
| An issue was discovered in Bento4 1.6.0-639. There ie excessive memory consumption in the function AP4_DataBuffer::ReallocateBuffer in Core/Ap4DataBuffer.cpp. | ||||
| CVE-2022-41845 | 1 Axiosys | 1 Bento4 | 2025-05-20 | 5.5 Medium |
| An issue was discovered in Bento4 1.6.0-639. There ie excessive memory consumption in the function AP4_Array<AP4_ElstEntry>::EnsureCapacity in Core/Ap4Array.h. | ||||
| CVE-2022-3364 | 1 Ikus-soft | 1 Rdiffweb | 2025-05-20 | 7.5 High |
| Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.5.0a3. | ||||
| CVE-2022-3371 | 1 Ikus-soft | 1 Rdiffweb | 2025-05-20 | 7.5 High |
| Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.5.0a3. | ||||
| CVE-2025-47793 | 2025-05-19 | 4.3 Medium | ||
| Nextcloud Server is a self hosted personal cloud system, and the Nextcloud Groupfolders app provides admin-configured folders shared by everyone in a group or team. In Nextcloud Server prior to 30.0.2, 29.0.9, and 28.0.1, Nextcloud Enterprise Server prior to 30.0.2 and 29.0.9, and Nextcloud Groupfolders app prior to 18.0.3, 17.0.5, and 16.0.11, the absence of quota checking on attachments allowed logged-in users to upload files exceeding the group folder quota. Nextcloud Server versions 30.0.2 and 29.0.9, Nextcloud Enterprise Server versions 30.0.2, 29.0.9, or 28.0.12, and Nextcloud Groupfolders app 18.0.3, 17.0.5, and 16.0.11 fix the issue. No known workarounds are available. | ||||
| CVE-2022-3456 | 1 Ikus-soft | 1 Rdiffweb | 2025-05-15 | 9.8 Critical |
| Allocation of Resources Without Limits or Throttling in GitHub repository ikus060/rdiffweb prior to 2.5.0. | ||||
| CVE-2025-30202 | 1 Vllm | 1 Vllm | 2025-05-14 | 7.5 High |
| vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Versions starting from 0.5.2 and prior to 0.8.5 are vulnerable to denial of service and data exposure via ZeroMQ on multi-node vLLM deployment. In a multi-node vLLM deployment, vLLM uses ZeroMQ for some multi-node communication purposes. The primary vLLM host opens an XPUB ZeroMQ socket and binds it to ALL interfaces. While the socket is always opened for a multi-node deployment, it is only used when doing tensor parallelism across multiple hosts. Any client with network access to this host can connect to this XPUB socket unless its port is blocked by a firewall. Once connected, these arbitrary clients will receive all of the same data broadcasted to all of the secondary vLLM hosts. This data is internal vLLM state information that is not useful to an attacker. By potentially connecting to this socket many times and not reading data published to them, an attacker can also cause a denial of service by slowing down or potentially blocking the publisher. This issue has been patched in version 0.8.5. | ||||