Total
329 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-31157 | 2026-06-17 | N/A | 5.3 MEDIUM | ||
| Improper initialization in UEFI firmware OutOfBandXML module in some Intel(R) Processors may allow a privileged user to potentially enable information disclosure via local access. | |||||
| CVE-2024-28084 | 2 Fedoraproject, Intel | 2 Fedora, Inet Wireless Daemon | 2026-06-17 | N/A | 7.5 HIGH |
| p2putil.c in iNet wireless daemon (IWD) through 2.15 allows attackers to cause a denial of service (daemon crash) or possibly have unspecified other impact because of initialization issues in situations where parsing of advertised service information fails. | |||||
| CVE-2024-26021 | 2026-06-17 | N/A | 2.3 LOW | ||
| Improper initialization in the firmware for some Intel(R) AMT and Intel(R) Standard Manageability may allow a privileged user to potentially enable information disclosure via local access. | |||||
| CVE-2024-25563 | 1 Intel | 14 Killer, Killer Wi-fi 6 Ax1650, Killer Wi-fi 6e Ax1675 and 11 more | 2026-06-17 | N/A | 3.4 LOW |
| Improper initialization in firmware for some Intel(R) PROSet/Wireless Software and Intel(R) Killer(TM) Wi-Fi before version 23.40 may allow a privileged user to potentially enable information disclosure via local access. | |||||
| CVE-2024-22064 | 1 Zte | 1 Zxun-epdg | 2026-06-17 | N/A | 8.3 HIGH |
| ZTE ZXUN-ePDG product, which serves as the network node of the VoWifi system, under by default configuration, uses a set of non-unique cryptographic keys during establishing a secure connection(IKE) with the mobile devices connecting over the internet . If the set of keys are leaked or cracked, the user session informations using the keys may be leaked. | |||||
| CVE-2024-21807 | 2026-06-17 | N/A | 8.8 HIGH | ||
| Improper initialization in the Linux kernel mode driver for some Intel(R) Ethernet Network Controllers and Adapters before version 28.3 may allow an authenticated user to potentially enable escalation of privilege via local access. | |||||
| CVE-2024-12289 | 1 Hashicorp | 1 Boundary | 2026-06-17 | N/A | 5.9 MEDIUM |
| Boundary Community Edition and Boundary Enterprise (“Boundary”) incorrectly handle HTTP requests during the initialization of the Boundary controller, which may cause the Boundary server to terminate prematurely. Boundary is only vulnerable to this flaw during the initialization of the Boundary controller, which on average is measured in milliseconds during the Boundary startup process. This vulnerability, CVE-2024-12289, is fixed in Boundary Community Edition and Boundary Enterprise 0.16.4, 0.17.3, 0.18.2. | |||||
| CVE-2024-11158 | 1 Rockwellautomation | 1 Arena | 2026-06-17 | N/A | 6.7 MEDIUM |
| An “uninitialized variable” code execution vulnerability exists in the Rockwell Automation Arena® that could allow a threat actor to craft a DOE file and force the software to access a variable before it being initialized. If exploited, a threat actor could leverage this vulnerability to execute arbitrary code. To exploit this vulnerability, a legitimate user must execute the malicious code crafted by the threat actor. | |||||
| CVE-2024-0089 | 2 Microsoft, Nvidia | 10 Windows, Cloud Gaming, Geforce and 7 more | 2026-06-17 | N/A | 7.8 HIGH |
| NVIDIA GPU Display Driver for Windows contains a vulnerability where the information from a previous client or another process could be disclosed. A successful exploit of this vulnerability might lead to code execution, information disclosure, or data tampering. | |||||
| CVE-2023-5370 | 1 Freebsd | 1 Freebsd | 2026-06-17 | N/A | 5.5 MEDIUM |
| On CPU 0 the check for the SMCCC workaround is called before SMCCC support has been initialized. This resulted in no speculative execution workarounds being installed on CPU 0. | |||||
| CVE-2023-52452 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix accesses to uninit stack slots Privileged programs are supposed to be able to read uninitialized stack memory (ever since 6715df8d5) but, before this patch, these accesses were permitted inconsistently. In particular, accesses were permitted above state->allocated_stack, but not below it. In other words, if the stack was already "large enough", the access was permitted, but otherwise the access was rejected instead of being allowed to "grow the stack". This undesired rejection was happening in two places: - in check_stack_slot_within_bounds() - in check_stack_range_initialized() This patch arranges for these accesses to be permitted. A bunch of tests that were relying on the old rejection had to change; all of them were changed to add also run unprivileged, in which case the old behavior persists. One tests couldn't be updated - global_func16 - because it can't run unprivileged for other reasons. This patch also fixes the tracking of the stack size for variable-offset reads. This second fix is bundled in the same commit as the first one because they're inter-related. Before this patch, writes to the stack using registers containing a variable offset (as opposed to registers with fixed, known values) were not properly contributing to the function's needed stack size. As a result, it was possible for a program to verify, but then to attempt to read out-of-bounds data at runtime because a too small stack had been allocated for it. Each function tracks the size of the stack it needs in bpf_subprog_info.stack_depth, which is maintained by update_stack_depth(). For regular memory accesses, check_mem_access() was calling update_state_depth() but it was passing in only the fixed part of the offset register, ignoring the variable offset. This was incorrect; the minimum possible value of that register should be used instead. This tracking is now fixed by centralizing the tracking of stack size in grow_stack_state(), and by lifting the calls to grow_stack_state() to check_stack_access_within_bounds() as suggested by Andrii. The code is now simpler and more convincingly tracks the correct maximum stack size. check_stack_range_initialized() can now rely on enough stack having been allocated for the access; this helps with the fix for the first issue. A few tests were changed to also check the stack depth computation. The one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv. | |||||
| CVE-2023-4503 | 1 Redhat | 3 Enterprise Linux, Jboss Enterprise Application Platform, Jboss Enterprise Application Platform Expansion Pack | 2026-06-17 | N/A | 6.8 MEDIUM |
| An improper initialization vulnerability was found in Galleon. When using Galleon to provision custom EAP or EAP-XP servers, the servers are created unsecured. This issue could allow an attacker to access remote HTTP services available from the server. | |||||
| CVE-2023-49062 | 1 Facebook | 1 Katran | 2026-06-17 | N/A | 7.5 HIGH |
| Katran could disclose non-initialized kernel memory as part of an IP header. The issue was present for IPv4 encapsulation and ICMP (v4) Too Big packet generation. After a bpf_xdp_adjust_head call, Katran code didn’t initialize the Identification field for the IPv4 header, resulting in writing content of kernel memory in that field of IP header. The issue affected all Katran versions prior to commit 6a03106ac1eab39d0303662963589ecb2374c97f | |||||
| CVE-2023-48361 | 2026-06-17 | N/A | 2.3 LOW | ||
| Improper initialization in firmware for some Intel(R) CSME may allow a privileged user to potentially enable information disclosure via local access. | |||||
| CVE-2023-45315 | 2 Intel, Microsoft | 2 Power Gadget, Windows | 2026-06-17 | N/A | 5.5 MEDIUM |
| Improper initialization in some Intel(R) Power Gadget software for Windwos all versions may allow an authenticated user to potentially enable denial of service via local access. | |||||
| CVE-2023-45085 | 1 Softiron | 1 Hypercloud | 2026-06-17 | N/A | 3.2 LOW |
| An issue exists in SoftIron HyperCloud where compute nodes may come online immediately without following the correct initialization process. In this instance, workloads may be scheduled on these nodes and deploy to a failed or erroneous state, which impacts the availability of these workloads that may be deployed during this time window. This issue impacts HyperCloud versions from 2.0.0 to before 2.0.3. | |||||
| CVE-2023-40349 | 1 Jenkins | 1 Gogs | 2026-06-17 | N/A | 5.3 MEDIUM |
| Jenkins Gogs Plugin 1.0.15 and earlier improperly initializes an option to secure its webhook endpoint, allowing unauthenticated attackers to trigger builds of jobs. | |||||
| CVE-2023-40261 | 1 Dieboldnixdorf | 1 Vynamic Security Suite | 2026-06-17 | N/A | 6.8 MEDIUM |
| Diebold Nixdorf Vynamic Security Suite (VSS) before 3.3.0 SR17, 4.0.0 SR07, 4.1.0 SR04, 4.2.0 SR04, and 4.3.0 SR02 fails to validate file attributes during the Pre-Boot Authorization (PBA) process. This can be exploited by a physical attacker who is able to manipulate the contents of the system's hard disk. | |||||
| CVE-2023-3242 | 1 Br-automation | 1 Automation Runtime | 2026-06-17 | N/A | 8.6 HIGH |
| Improper initialization implementation in Portmapper used in B&R Industrial Automation Automation Runtime <G4.93 allows unauthenticated network-based attackers to cause permanent denial-of-service conditions. | |||||
| CVE-2023-37479 | 1 Openenclave | 1 Openenclave | 2026-06-17 | N/A | 5.3 MEDIUM |
| Open Enclave is a hardware-agnostic open source library for developing applications that utilize Hardware-based Trusted Execution Environments, also known as Enclaves. There are two issues that are mitigated in version 0.19.3. First, Open Enclave SDK does not properly sanitize the `MXCSR` register on enclave entry. This makes applications vulnerable to MXCSR Configuration Dependent Timing (MCDT) attacks, where incorrect `MXCSR` values can impact instruction retirement by at most one cycle, depending on the (secret) data operand value. Please find more details in the guidance from Intel in the references. Second, Open Enclave SDK does not sanitize x86's alignment check flag `RFLAGS.AC` on enclave entry. This opens up the possibility for a side-channel attacker to be notified for every unaligned memory access performed by the enclave. The issue has been addressed in version 0.19.3 and the current master branch. Users will need to recompile their applications against the patched libraries to be protected from this vulnerability. There are no known workarounds for this vulnerability. | |||||