Export limit exceeded: 15998 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 24289 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (24289 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-84496 | 1 Apple | 1 Macos | 2026-10-28 | 6.5 Medium |
| An out-of-bounds write issue was addressed with improved bounds checking. This issue is fixed in macOS Golden Gate 27.2, macOS Tahoe 26.7.2. Mounting a maliciously crafted disk image may cause unexpected system termination or corrupt kernel memory. | ||||
| CVE-2026-93521 | 1 X.org | 2 Xorg-x11-server, Xwayland | 2026-10-28 | 7.8 High |
| A buffer overflow in RandR ChangeProviderProperty requests in X.Org X Server before 2.1.25 and XWayland before 24.4.14 could be used by authenticated X clients to crash or execute code within the X server context. | ||||
| CVE-2026-96521 | 3 Adobe, Apple, Microsoft | 3 Photoshop, Macos, Windows | 2026-10-28 | 7.8 High |
| Photoshop Desktop is affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2026-113776 | 1 Pypa | 1 Virtualenv | 2026-10-28 | 7.8 High |
| virtualenv is a tool for creating isolated virtual python environments. From 20.26.6 until 21.14.2, ViaTemplateActivator.instantiate_template() replaces placeholders one key at a time across the complete activation template, so trigger names such as __VIRTUAL_NAME__, __VIRTUAL_ENV__, or __VIRTUAL_PROMPT__ inside an already substituted and quoted environment path or prompt can be replaced during a later pass. The later value's quoting can close the earlier literal and execute the remaining path when a user activates the environment through bash, fish, xonsh, or activate_this.py. The distinct csh prompt-display token __VIRTUAL_PROMPT_DISPLAY_TCSH__ can instead break the generated script without establishing command execution. The attacker must influence the destination path or --prompt, and a value without a relevant placeholder name does not trigger this mechanism. This issue is fixed in version 21.14.2. | ||||
| CVE-2026-93520 | 1 X.org | 3 Xorg-server, Xorg-x11-server, Xwayland | 2026-10-28 | 7.8 High |
| A heap buffer overflow caused by mismatching size calculations between XkbAllocNames and ChangeKeycodeRange in X.org X server before 2.1.25 and XWayland before 24.1.14 could be used by authenticated X clients to crash or potentially execute code in X server context. | ||||
| CVE-2026-99184 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-28 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: accel/rocket: search every core slot when a core is removed rocket_remove() decrements rdev->num_cores for each core it removes, while find_core_for_dev() searches slots 0 to num_cores - 1. Unbinding the cores in the order they were bound therefore loses the last one: by the time it is removed the search range has already shrunk past its slot, so find_core_for_dev() returns -1 and rocket_remove() gives up without doing anything. num_cores never reaches zero, rocket_device_fini() never runs, and the file-scoped rdev keeps pointing at a device that is going away. Binding the cores again starts from that stale count, because rocket_probe() takes rdev->num_cores as the slot to fill. On an RK3588, which describes three cores, the second round lands on slots 1, 2 and 3 while rdev->cores was allocated with room for three: rocket fdab0000.npu: Rockchip NPU core 1 version: 1179210309 rocket fdac0000.npu: Rockchip NPU core 2 version: 1179210309 rocket fdad0000.npu: Rockchip NPU core 3 version: 1179210309 The write to rdev->cores[3] is past the end of the array. Nothing in tree reads the core array often enough to notice, so the overrun is silent today. It turned up while testing a devfreq series on top of this, where a worker walks every core a few times a second, and UBSAN caught the first bool it read out of the overrun entry: UBSAN: invalid-load in drivers/accel/rocket/rocket_devfreq.c:47:10 load of value 5 is not a valid value for type '_Bool' Workqueue: devfreq_wq devfreq_monitor Record how many slots were allocated and search all of them. Every core is then found on removal, num_cores reaches zero, the device is torn down and a later bind starts from a clean rdev. This does not make unbinding a single core out of several work. probe still takes num_cores as the slot to fill, so rebinding one core while its siblings stay bound would write over a slot that is already in use, and rocket_open() still reaches for cores[0] whether or not anything is there. Both of those want more thought than a fix should carry. Found by unbinding and rebinding all three cores on an Orange Pi 5 Plus. With this applied, 25 unbind/rebind rounds and 5 module unload/reload rounds run clean there: the cores land in slots 0, 1 and 2 every time, whichever order they are bound in, and the shared supply goes back to a single user after each round. | ||||
| CVE-2026-103603 | 2 Bouncycastle, Legion Of The Bouncy Castle Inc. | 2 Bc-csharp, Bc-csharp | 2026-10-28 | 7.5 High |
| Memory allocation with excessive size value in the HSS/LMS signature code (HssPublicKeyParameters, HssSignature) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated attacker who can supply both an HSS public key and a signature to cause a denial of service through memory exhaustion via a public key encoding with an excessive level count, because the level count L read when parsing an HSS public key was not checked against the RFC 8554 maximum of 8, and signature parsing then allocated an array of L - 1 entries before reading any further signature data. A single verification can commit up to about 17 GB of memory or fail with an OutOfMemoryException. | ||||
| CVE-2026-63574 | 2 Bouncycastle, Legion Of The Bouncy Castle Inc. | 2 Bc-csharp, Bc-csharp | 2026-10-28 | 7.5 High |
| Memory allocation with excessive size value in the OpenPGP signature and user attribute subpacket parsers (SignatureSubpacketsParser.ReadPacket, UserAttributeSubpacketsParser.ReadPacket) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote, unauthenticated attacker who can supply a crafted OpenPGP public key, certificate or signature to cause a denial of service (OutOfMemoryException or memory exhaustion in the parsing process) via a subpacket header using the five-octet length form, because the declared length was used to size the subpacket buffer with no upper bound and without being compared with the size of the enclosing subpacket area or packet, so a few bytes of input could demand an allocation of up to about 2 GB before any subpacket data was read. | ||||
| CVE-2026-118477 | 1 Eisge | 1 Kalifast | 2026-10-28 | 9.8 Critical |
| The ei_git_repo_url parameter in the Git remote configuration endpoint of KaliFast is vulnerable to OS Command Injection. This OS Command Injection vulnerability allows an authenticated attacker (free registration available) to execute arbitrary commands on the KaliFast server with www-data privileges. Fixed in version 2026061802. | ||||
| CVE-2026-96778 | 2 Python, Python-pillow | 2 Pillow, Pillow | 2026-10-28 | 8.8 High |
| Pillow is a Python imaging library. From 9.4.0 until 13.0.0, ImagingJpegEncode() in src/libImaging/JpegEncode.c can call jpeg_write_marker() for a JPEG COM comment when an ICC profile has exactly filled the 65536-byte encoder buffer. libjpeg writes one byte before checking the exhausted free_in_buffer counter, which then wraps and permits the attacker-controlled comment and subsequent compressed image data to overwrite adjacent heap memory. Re-saving an untrusted image as JPEG while preserving its ICC profile and forwarded comment can crash the process and may enable code execution in suitable runtime and heap layouts. This issue is fixed in version 13.0.0. | ||||
| CVE-2026-113726 | 1 Pypa | 1 Virtualenv | 2026-10-27 | 7.8 High |
| virtualenv is a tool for creating isolated virtual python environments. Prior to 21.13.0, the bash activate script that zsh also sources leaves the environment name unescaped; from 21.13.0 until 21.14.4, it escapes backslashes, dollar signs, and backticks only when BASH_VERSION is set, so zsh receives the raw value. The script assigns that value to PS1. In zsh with PROMPT_SUBST, an attacker-influenced environment directory, --prompt, or VIRTUALENV_PROMPT value containing command, parameter, or arithmetic expansion syntax can therefore execute commands in the user's shell each time the prompt is drawn. A percent sign is separately interpreted as a zsh prompt escape but does not by itself execute commands. Plain zsh with PROMPT_SUBST disabled and bash are not affected by this mechanism. This issue is fixed in version 21.14.4. | ||||
| CVE-2020-37286 | 1 Vyperlang | 1 Vyper | 2026-10-27 | 6.5 Medium |
| Vyper from 0.1.0b4 before 0.3.0 contains a memory corruption vulnerability caused by an incorrect stack tip pointer when internal function calls appear inside tuples or nested calls. Contracts using such calls as tuple elements, call arguments, or builtin arguments like concat or ecrecover can return corrupted values or pass wrong arguments to external calls. | ||||
| CVE-2026-6893 | 1 Redhat | 13 Dracut, Enterprise Linux, Enterprise Linux Eus and 10 more | 2026-10-27 | 7.5 High |
| A flaw was found in dracut. A remote attacker on the adjacent network can exploit this vulnerability by providing specially crafted DHCP (Dynamic Host Configuration Protocol) options, such as a malicious hostname, to a system using dracut's legacy DHCP path. These options are improperly handled and written into temporary shell scripts without proper escaping, leading to command injection. This allows the attacker to achieve root code execution within the initramfs, potentially compromising the system's boot and network behavior. | ||||
| CVE-2026-111379 | 1 Freerdp | 1 Freerdp | 2026-10-27 | 7.3 High |
| FreeRDP before 3.32.0 contains a heap buffer overflow vulnerability in persistent_cache_read_entry_v3 that allows local attackers to corrupt memory by supplying a crafted v3 persistent cache file. Attackers can set large width and height values that wrap the size calculation in persist_cache_get_data, causing fread to overflow an undersized buffer and potentially execute code. | ||||
| CVE-2026-112398 | 2 Python, Python-pillow | 2 Pillow, Pillow | 2026-10-27 | 9.8 Critical |
| Pillow is a Python imaging library. Prior to 13.0.0, Pillow's FlashPix JPEG-tile decoder can write decoded scanlines beyond the allocated tile buffer. FlashPix (FPX) JPEG decoding selects raw mode LA with two bytes per pixel, while an unrecognized JPEG mode can be decoded as JCS_UNKNOWN with four components, causing ImagingJpegDecode to write four-component scanlines into the two-byte tile buffer. An attacker can supply a crafted OLE2 FlashPix file to an application with the optional olefile dependency installed that opens or thumbnails untrusted input. This can corrupt heap memory and may allow arbitrary code execution. This issue is fixed in version 13.0.0. | ||||
| CVE-2026-112397 | 2 Python, Python-pillow | 2 Pillow, Pillow | 2026-10-27 | 7.5 High |
| Pillow is a Python imaging library. Prior to 13.0.0, Pillow's ImageMorph.MorphOp.apply() can access memory before a row buffer for a zero-width image. PPM and PGM input can create an image with width zero, and the native morphology routine indexes outrow[width - 1] without rejecting that geometry. An attacker can supply such an image to an application that applies a morphology operation. This can crash the process. This issue is fixed in version 13.0.0. | ||||
| CVE-2026-106117 | 1 Sixlabors | 1 Imagesharp | 2026-10-27 | 7.5 High |
| ImageSharp is a 2D graphics library. From 3.0.0 until 4.1.1, decoding a strip TIFF using CCITT Group 3 or Modified Huffman compression can pass attacker-expanded runs to BitWriterUtils.WriteBits without first checking the current row width. T4TiffCompression.WritePixelRun can accumulate oversized makeup-code runs, and ModifiedHuffmanTiffCompression.Decompress validates the width only after writing. The unchecked writes can overflow the strip buffer, corrupt heap memory, and terminate the process. This strip-path vulnerability is distinct from the tiled decompressor-width mismatch. This issue is fixed in version 4.1.1. | ||||
| CVE-2026-110247 | 1 Mozilla | 1 Thunderbird | 2026-10-27 | 8.4 High |
| Several buffer-growth sites in libmime performed size arithmetic in 32-bit types without overflow checks. On a sufficiently large message the growth guard could fail open, or the buffer could be reallocated smaller than required, and a subsequent memcpy would then write attacker-controlled data across adjacent heap allocations. This vulnerability was fixed in Thunderbird 158 and Thunderbird 153.6. | ||||
| CVE-2026-98142 | 1 Linux | 1 Linux Kernel | 2026-10-27 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/cirrus-qemu: Validate BAR0 size during probe The `cirrus-qemu` driver relies on `CIRRUS_VRAM_SIZE` (4 MB) to validate framebuffer sizes. However, during PCI probe, the driver mapped BAR0 without verifying that its size matches `CIRRUS_VRAM_SIZE`. If a PCI device with a BAR0 smaller than 4 MB is bound to the driver, the mapped VRAM will be smaller than expected. Because validation checks assume 4 MB VRAM, framebuffers larger than the mapped memory can be created. When the display plane is updated (e.g. during release), `cirrus_primary_plane_helper_atomic_update()` copies the framebuffer to VRAM using `drm_fb_memcpy()`. Writing past the end of the mapped I/O memory causes a supervisor write page fault: BUG: unable to handle page fault for address: ffffc9000389c000 ... RIP: 0010:memcpy_toio+0x7c/0xe0 arch/x86/lib/iomem.c:110 ... Call Trace: <TASK> iosys_map_memcpy_to include/linux/iosys-map.h:285 [inline] drm_fb_memcpy+0x325/0x5d0 drivers/gpu/drm/drm_format_helper.c:442 cirrus_primary_plane_helper_atomic_update+0x98a/0xb00 drivers/gpu/drm/tiny/cirrus-qemu.c:358 drm_atomic_helper_commit_planes+0x626/0xea0 drivers/gpu/drm/drm_atomic_helper.c:3038 drm_atomic_helper_commit_tail+0x60/0x510 drivers/gpu/drm/drm_atomic_helper.c:1989 commit_tail+0x2b1/0x3c0 drivers/gpu/drm/drm_atomic_helper.c:2074 drm_atomic_helper_commit+0xa77/0xb10 drivers/gpu/drm/drm_atomic_helper.c:2312 Fix this by validating in `cirrus_pci_probe()` that the PCI BAR0 resource is not less than `CIRRUS_VRAM_SIZE`, returning `-ENODEV` if it is less. | ||||
| CVE-2026-63566 | 2 Bouncycastle, Legion Of The Bouncy Castle Inc. | 2 Bc-csharp, Bc-csharp | 2026-10-27 | 7.5 High |
| Memory allocation with excessive size value in the DTLS handshake reassembly (DtlsReliableHandshake, DtlsReassembler) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated DTLS peer to cause a denial of service through memory exhaustion via crafted handshake message fragments, because the reassembly buffer for each incoming handshake message was allocated at the 24-bit length declared in the fragment header, without the check against the peer's maximum handshake message size that TLS already applied. A fragment carrying no payload can force an allocation of almost 16 MB, for each of up to 16 pending messages per handshake, before the handshake is authenticated. DTLS servers and DTLS clients are both affected; TLS is not. | ||||