Export limit exceeded: 413979 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (1344 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-45559 | 1 Roxy-wi | 1 Roxy-wi | 2026-06-10 | 4.9 Medium |
| Roxy-WI is a web interface for managing Haproxy, Nginx, Apache and Keepalived servers. In versions 8.2.6.4 and prior, get_ldap_email (app/modules/roxywi/user.py:120-157) builds the LDAP search filter via f-string concatenation. The username URL path parameter is taken verbatim — no checkAjaxInput, no LDAP escape — and inserted, a username like *)(mail=*)(cn=* injects additional clauses, allowing the admin to enumerate or harvest attributes outside the intended record. At time of publication, there are no publicly available patches. | ||||
| CVE-2026-46249 | 1 Linux | 1 Linux Kernel | 2026-06-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Fix PF driver crash with kexec kernel booting During a kexec reboot the hardware is not power-cycled, so AF state from the old kernel can persist into the new kernel. When AF and PF drivers are built as modules, the PF driver may probe before AF reinitializes the hardware. The PF driver treats the RVUM block revision as an indication that AF initialization is complete. If this value is left uncleared at shutdown, PF may incorrectly assume AF is ready and access stale hardware state, leading to a crash. Clear the RVUM block revision during AF shutdown to avoid PF mis-detecting AF readiness after kexec. | ||||
| CVE-2026-46257 | 1 Linux | 1 Linux Kernel | 2026-06-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/timer-sp804: Fix an Oops when read_current_timer is called on ARM32 platforms where the SP804 is not registered as the sched_clock. On SP804, the delay timer shares the same clkevt instance with sched_clock. On some platforms, when sp804_clocksource_and_sched_clock_init is called with use_sched_clock not set to 1, sched_clkevt is not properly initialized. However, sp804_register_delay_timer is invoked unconditionally, and read_current_timer() subsequently calls sp804_read on an uninitialized sched_clkevt, leading to a kernel Oops when accessing sched_clkevt->value. Declare a dedicated clkevt instance exclusively for delay timer, instead of sharing the same clkevt with sched_clock. This ensures that read_current_timer continues to work correctly regardless of whether SP804 is selected as the sched_clock. | ||||
| CVE-2024-43537 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-06-09 | 6.5 Medium |
| Windows Mobile Broadband Driver Denial of Service Vulnerability | ||||
| CVE-2024-43502 | 1 Microsoft | 6 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 3 more | 2026-06-09 | 7.1 High |
| Windows Kernel Elevation of Privilege Vulnerability | ||||
| CVE-2026-48104 | 2 7-zip, Mcmilk | 2 7-zip, 7-zip | 2026-06-08 | 4.2 Medium |
| 7-Zip is a file archiver with a high compression ratio. Versions 9.18 through 26.00 contain an uninitialized heap read in the SquashFS archive handler caused by a sparsely populated index array. In the SquashFS handler, _blockToNode is allocated with capacity for every metadata block but populated only when an inode crosses a block boundary, so a crafted image with few inodes spanning many blocks leaves most slots holding raw heap contents (the underlying allocator does not zero-initialize POD storage). When OpenDir looks up an attacker-influenced blockIndex (derived from the RootInode superblock field), it reads two of these uninitialized slots and passes them as the left/right bounds of a binary search over _nodesPos, which dereferences the midpoint without bounds checking; if the resulting value happens to match the search key, the returned index is used to read a full node struct from _nodes whose fields feed further directory parsing, forming a chained OOB read primitive that is heap-layout-dependent and not reliably triggerable. The SquashFS handler is enabled by default in stock 7z.dll and the issue triggers during Open() with no interaction beyond opening the file; impact is denial of service from wild-pointer dereference and potential heap information disclosure, with no write primitive. Version 26.01 fixes the issue. | ||||
| CVE-2026-11089 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-06-08 | 6.5 Medium |
| Uninitialized Use in Media in Google Chrome prior to 149.0.7827.53 allowed a remote attacker who had compromised the renderer process to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-48101 | 2 7-zip, Mcmilk | 2 7-zip, 7-zip | 2026-06-08 | 6.5 Medium |
| 7-Zip is a file archiver with a high compression ratio. Versions 9.21 through 26.00 contain an An uninitialized memory disclosure vulnerability in the UEFI capsule (.scap) parser in 7-Zip. The OpenCapsule function allocates a heap buffer of attacker-declared CapsuleImageSize (up to 1 GiB) without zero-initialization, then reads the file contents into it with ReadStream_FALSE whose return value is silently discarded. If the file is truncated, the unread tail of the buffer retains uninitialized heap memory, which is then exposed as extracted file content via GetStream. Version 26.0.1 fixes the issue. | ||||
| CVE-2025-27810 | 2 Arm, Trustedfirmware | 2 Mbed Tls, Mbed Tls | 2026-06-05 | 5.4 Medium |
| Mbed TLS before 2.28.10 and 3.x before 3.6.3, in some cases of failed memory allocation or hardware errors, uses uninitialized stack memory to compose the TLS Finished message, potentially leading to authentication bypasses such as replays. | ||||
| CVE-2025-48513 | 1 Amd | 6 Ryzen 6000 Series Processors With Radeon Graphics, Ryzen 7035 Series Processors With Radeon Graphics, Ryzen 7040 Series Mobile Processors With Radeon Graphics and 3 more | 2026-06-02 | N/A |
| Use of uninitialized resource within the AMD Platform Management Framework (PMF) could allow an attacker to read a uninitialized kernel memory resulting in loss of confidentiality or availability. | ||||
| CVE-2026-31626 | 1 Linux | 1 Linux Kernel | 2026-06-01 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify() Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using uninitialized data. Smatch warns that only 6 bytes are copied to this 8-byte (u64) variable, leaving the last two bytes uninitialized: drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify() warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes) Initializing the variable at the start of the function fixes this warning and ensures predictable behavior. | ||||
| CVE-2026-47272 | 1 Mcdope | 1 Pam Usb | 2026-05-29 | 7.1 High |
| pam_usb provides hardware authentication for Linux using ordinary removable media. Prior to 0.9.0, the pusb_pad_compare() function in src/pad.c only verified that the user-side pad (~/.pamusb/device.pad) could be read, but did not enforce that the system-side pad (the pad file on the USB device) was also present and readable. If the user-side pad was deleted or unreadable, the function returned a failure that was treated as non-fatal in certain code paths, allowing authentication to succeed without the USB device being verified. A local user can delete their own ~/.pamusb/device.pad to remove the USB device requirement and authenticate without the physical device. This vulnerability is fixed in 0.9.0. | ||||
| CVE-2026-46139 | 1 Linux | 1 Linux Kernel | 2026-05-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: use kzalloc to zero-initialize security descriptor buffer Commit 62e7dd0a39c2d ("smb: common: change the data type of num_aces to le16") split struct smb_acl's __le32 num_aces field into __le16 num_aces and __le16 reserved. The reserved field corresponds to Sbz2 in the MS-DTYP ACL wire format, which must be zero [1]. When building an ACL descriptor in build_sec_desc(), we are using a kmalloc()'ed descriptor buffer and writing the fields explicitly using le16() writes now. This never writes to the 2 byte reserved field, leaving it as uninitialized heap data. When the reserved field happens to contain non-zero slab garbage, Samba rejects the security descriptor with "ndr_pull_security_descriptor failed: Range Error", causing chmod to fail with EINVAL. Change kmalloc() to kzalloc() to ensure the entire buffer is zero-initialized. [1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/20233ed8-a6c6-4097-aafa-dd545ed24428 | ||||
| CVE-2021-26333 | 1 Amd | 2 Chipset Driver, Psp Driver | 2026-05-28 | 5.5 Medium |
| An information disclosure vulnerability exists in AMD Platform Security Processor (PSP) chipset driver. The discretionary access control list (DACL) may allow low privileged users to open a handle and send requests to the driver resulting in a potential data leak from uninitialized physical pages. | ||||
| CVE-2019-18197 | 5 Canonical, Debian, Linux and 2 more | 6 Ubuntu Linux, Debian Linux, Linux Kernel and 3 more | 2026-05-28 | 7.5 High |
| In xsltCopyText in transform.c in libxslt 1.1.33, a pointer variable isn't reset under certain circumstances. If the relevant memory area happened to be freed and reused in a certain way, a bounds check could fail and memory outside a buffer could be written to, or uninitialized data could be disclosed. | ||||
| CVE-2019-13117 | 6 Canonical, Debian, Fedoraproject and 3 more | 6 Ubuntu Linux, Debian Linux, Fedora and 3 more | 2026-05-28 | 5.3 Medium |
| In numbers.c in libxslt 1.1.33, an xsl:number with certain format strings could lead to a uninitialized read in xsltNumberFormatInsertNumbers. This could allow an attacker to discern whether a byte on the stack contains the characters A, a, I, i, or 0, or any other character. | ||||
| CVE-2026-45865 | 1 Linux | 1 Linux Kernel | 2026-05-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mctp i2c: initialise event handler read bytes Set a 0xff value for i2c reads of an mctp-i2c device. Otherwise reads will return "val" from the i2c bus driver. For i2c-aspeed and i2c-npcm7xx that is a stack uninitialised u8. Tested with "i2ctransfer -y 1 r10@0x34" where 0x34 is a mctp-i2c instance, now it returns all 0xff. | ||||
| CVE-2026-45896 | 1 Linux | 1 Linux Kernel | 2026-05-28 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: mtd: intel-dg: Fix accessing regions before setting nregions The regions array is counted by nregions, but it's set only after accessing it: [] UBSAN: array-index-out-of-bounds in drivers/mtd/devices/mtd_intel_dg.c:750:15 [] index 0 is out of range for type '<unknown> [*]' Fix it by also fixing an undesired behavior: the loop silently ignores ENOMEM and continues setting the other entries. | ||||
| CVE-2026-45858 | 1 Linux | 1 Linux Kernel | 2026-05-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1 When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle. 0 A B N [UUUUUUUUUUUU] U: unwritten extent [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written. 0 A B N [WWWWWWWWWWWW] W: written extent [SSDDDDDDDDZZ] Z: zeroed, S: stale data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A. 0 A B N [WW|WWWWWWWWWW] [SS|DDDDDDDDZZ] Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, don't convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4_split_extent() will pass the EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the second time, allowing it to properly handle the split. If the split is successful, it will keep extent from 0 to A as unwritten. | ||||
| CVE-2026-46134 | 1 Linux | 1 Linux Kernel | 2026-05-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_ec_typec: Init mutex in Thunderbolt registration cros_typec_register_thunderbolt() missed initializing the `adata->lock` mutex. This leads to a NULL dereference when the mutex is later acquired (e.g. in cros_typec_altmode_work()). Initialize the mutex in cros_typec_register_thunderbolt() to fix the issue. | ||||