Export limit exceeded: 343506 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (343506 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-57835 | 1 Samsung | 41 Exynos, Exynos 1080, Exynos 1080 Firmware and 38 more | 2026-04-08 | 7.5 High |
| An issue was discovered in RRC in Samsung Mobile Processor, Wearable Processor, and Modem Exynos 980, 990, 850, 1080, 2100, 1280, 2200, 1330, 1380, 1480, 2400, 1580, 2500, 9110, W920, W930, W1000, Modem 5123, Modem 5300, and Modem 5400. Improper memory initialization results in an illegal memory access, causing a system crash via a malformed RRCReconfiguration message. | ||||
| CVE-2025-58349 | 1 Samsung | 41 Exynos, Exynos 1080, Exynos 1080 Firmware and 38 more | 2026-04-08 | 9.1 Critical |
| An issue was discovered in L2 in Samsung Mobile Processor, Wearable Processor, and Modem Exynos 980, 990, 850, 1080, 2100, 1280, 2200, 1330, 1380, 1480, 2400, 1580, 2500, 9110, W920, W930, W1000, Modem 5123, Modem 5300, and Modem 5400. Incorrect handling of LTE MAC packets containing many MAC Control Elements (CEs) leads to baseband crashes. | ||||
| CVE-2025-59440 | 1 Samsung | 41 Exynos, Exynos 1080, Exynos 1080 Firmware and 38 more | 2026-04-08 | 7.5 High |
| An issue was discovered in USIM in Samsung Mobile Processor, Wearable Processor, and Modem Exynos 980, 990, 850, 1080, 2100, 1280, 2200, 1330, 1380, 1480, 2400, 1580, 2500, 9110, W920, W930, W1000, Modem 5123, Modem 5300, and Modem 5400. Improper handling of SIM card proactive commands leads to a Denial of Service. | ||||
| CVE-2026-31405 | 1 Linux | 1 Linux Kernel | 2026-04-08 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: media: dvb-net: fix OOB access in ULE extension header tables The ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables in handle_one_ule_extension() are declared with 255 elements (valid indices 0-254), but the index htype is derived from network-controlled data as (ule_sndu_type & 0x00FF), giving a range of 0-255. When htype equals 255, an out-of-bounds read occurs on the function pointer table, and the OOB value may be called as a function pointer. Add a bounds check on htype against the array size before either table is accessed. Out-of-range values now cause the SNDU to be discarded. | ||||
| CVE-2026-31407 | 1 Linux | 1 Linux Kernel | 2026-04-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: add missing netlink policy validations Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink. These attributes are used by the kernel without any validation. Extend the netlink policies accordingly. Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN. | ||||
| CVE-2026-31408 | 1 Linux | 1 Linux Kernel | 2026-04-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold sco_recv_frame() reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold a reference under the lock. Fix by using sco_sock_hold() to take a reference before releasing the lock, and adding sock_put() on all exit paths. | ||||
| CVE-2026-31410 | 1 Linux | 1 Linux Kernel | 2026-04-08 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: use volume UUID in FS_OBJECT_ID_INFORMATION Use sb->s_uuid for a proper volume identifier as the primary choice. For filesystems that do not provide a UUID, fall back to stfs.f_fsid obtained from vfs_statfs(). | ||||
| CVE-2026-25932 | 1 Glpi-project | 1 Glpi | 2026-04-08 | 7.2 High |
| GLPI is a Free Asset and IT Management Software package. From 0.60 to before 10.0.24, an authenticated technician user can store an XSS payload in a supplier fields. This vulnerability is fixed in 10.0.24. | ||||
| CVE-2026-26026 | 1 Glpi-project | 1 Glpi | 2026-04-08 | 9.1 Critical |
| GLPI is a free asset and IT management software package. From 11.0.0 to before 11.0.6, template injection by an administrator lead to RCE. This vulnerability is fixed in 11.0.6. | ||||
| CVE-2026-26027 | 1 Glpi-project | 1 Glpi | 2026-04-08 | 7.5 High |
| GLPI is a free asset and IT management software package. From 11.0.0 to before 11.0.6, an unauthenticated user can store an XSS payload through the inventory endpoint. This vulnerability is fixed in 11.0.6. | ||||
| CVE-2026-26263 | 1 Glpi-project | 1 Glpi | 2026-04-08 | 8.1 High |
| GLPI is a free asset and IT management software package. From 11.0.0 to before 11.0.6, an unauthenticated time-based blind SQL injection exists in GLPI's Search engine. This vulnerability is fixed in 11.0.6. | ||||
| CVE-2026-29047 | 1 Glpi-project | 1 Glpi | 2026-04-08 | 7.2 High |
| GLPI is a free asset and IT management software package. From 10.0.0 to before 10.0.24 and 11.0.6, an authenticated user can perform a SQL injection via the logs export feature. This vulnerability is fixed in 10.0.24 and 11.0.6. | ||||
| CVE-2026-34378 | 2 Academysoftwarefoundation, Openexr | 2 Openexr, Openexr | 2026-04-08 | 6.5 Medium |
| OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.4.0 to before 3.4.9, a missing bounds check on the dataWindow attribute in EXR file headers allows an attacker to trigger a signed integer overflow in generic_unpack(). By setting dataWindow.min.x to a large negative value, OpenEXRCore computes an enormous image width, which is later used in a signed integer multiplication that overflows, causing the process to terminate with SIGILL via UBSan. This vulnerability is fixed in 3.4.9. | ||||
| CVE-2026-34379 | 2 Academysoftwarefoundation, Openexr | 2 Openexr, Openexr | 2026-04-08 | 7.1 High |
| OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9. | ||||
| CVE-2026-34380 | 2 Academysoftwarefoundation, Openexr | 2 Openexr, Openexr | 2026-04-08 | 5.9 Medium |
| OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a signed integer overflow exists in undo_pxr24_impl() in src/lib/OpenEXRCore/internal_pxr24.c at line 377. The expression (uint64_t)(w * 3) computes w * 3 as a signed 32-bit integer before casting to uint64_t. When w is large, this multiplication constitutes undefined behavior under the C standard. On tested builds (clang/gcc without sanitizers), two's-complement wraparound commonly occurs, and for specific values of w the wrapped result is a small positive integer, which may allow the subsequent bounds check to pass incorrectly. If the check is bypassed, the decoding loop proceeds to write pixel data through dout, potentially extending far beyond the allocated output buffer. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9. | ||||
| CVE-2026-34588 | 2 Academysoftwarefoundation, Openexr | 2 Openexr, Openexr | 2026-04-08 | 7.8 High |
| OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.1.0 to before 3.2.7, 3.3.9, and 3.4.9, internal_exr_undo_piz() advances the working wavelet pointer with signed 32-bit arithmetic. Because nx, ny, and wcount are int, a crafted EXR file can make this product overflow and wrap. The next channel then decodes from an incorrect address. The wavelet decode path operates in place, so this yields both out-of-bounds reads and out-of-bounds writes. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9. | ||||
| CVE-2026-34589 | 2 Academysoftwarefoundation, Openexr | 2 Openexr, Openexr | 2026-04-08 | 5.0 Medium |
| OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, the DWA lossy decoder constructs temporary per-component block pointers using signed 32-bit arithmetic. For a large enough width, the calculation overflows and later decoder stores operate on a wrapped pointer outside the allocated rowBlock backing store. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9. | ||||
| CVE-2026-34986 | 1 Go-jose | 1 Go-jose | 2026-04-08 | 7.5 High |
| Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. Prior to 4.1.4 and 3.0.5, decrypting a JSON Web Encryption (JWE) object will panic if the alg field indicates a key wrapping algorithm (one ending in KW, with the exception of A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty. The panic happens when cipher.KeyUnwrap() in key_wrap.go attempts to allocate a slice with a zero or negative length based on the length of the encrypted_key. This code path is reachable from ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() followed by Decrypt() on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected. This panic is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter less than 16 bytes long, but calling this function directly is less common. Panics can lead to denial of service. This vulnerability is fixed in 4.1.4 and 3.0.5. | ||||
| CVE-2026-35029 | 2 Berriai, Litellm | 2 Litellm, Litellm | 2026-04-08 | 8.8 High |
| LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.83.0, the /config/update endpoint does not enforce admin role authorization. A user who is already authenticated into the platform can then use this endpoint to modify proxy configuration and environment variables, register custom pass-through endpoint handlers pointing to attacker-controlled Python code, achieving remote code execution, read arbitrary server files by setting UI_LOGO_PATH and fetching via /get_image, and take over other privileged accounts by overwriting UI_USERNAME and UI_PASSWORD environment variables. Fixed in v1.83.0. | ||||
| CVE-2026-35030 | 2 Berriai, Litellm | 2 Litellm, Litellm | 2026-04-08 | 9.1 Critical |
| LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.83.0, when JWT authentication is enabled (enable_jwt_auth: true), the OIDC userinfo cache uses token[:20] as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters. This configuration option is not enabled by default. Most instances are not affected. An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user's cached token. On cache hit, the attacker inherits the legitimate user's identity and permissions. This affects deployments with JWT/OIDC authentication enabled. Fixed in v1.83.0. | ||||