Aggregating NVD, CVE, and multi-source threat feeds, this list provides deep analysis of high-risk threats such as RCE. By integrating CVSS and EPSS models, the system dynamically tracks Exp (Exploit) resources and PoC availability to accurately assess Exploitability. Combined with official Patches and remediation strategies, it helps prioritize Vulnerability Management workflows, significantly shortening response cycles and securing your critical assets.
Assigner (CNA / source)：[email protected] Remove this filter
| CVE | Description | Max CVSS | EPSS % | Published | Updated |
|---|---|---|---|---|---|
| CVE-2025-12060 | The keras.utils.get_file API in Keras, when used with the extract=True option for tar archives, is vulnerable to a path traversal attack. The utility uses Python's tarfile.extractall function without the filter="data" feature. A remote attacker can craft a malicious tar archive containing special symlinks, which, when extracted, allows them to write arbitrary files to any location on the filesystem outside of the intended destination folder. This vulnerability is linked to the underlying Python | 8.9 | 0.56% | 2025-10-30 | 2026-06-17 |
| CVE-2025-12058 | The Keras.Model.load_model method, including when executed with the intended security mitigation safe_mode=True, is vulnerable to arbitrary local file loading and Server-Side Request Forgery (SSRF). This vulnerability stems from the way the StringLookup layer is handled during model loading from a specially crafted .keras archive. The constructor for the StringLookup layer accepts a vocabulary argument that can specify a local file path or a remote file path. * Arbitrary Local File Read: A | 5.9 | 0.25% | 2025-10-29 | 2026-06-17 |
| CVE-2025-12080 | On Wear OS devices, when Google Messages is configured as the default SMS/MMS/RCS application, the handling of ACTION_SENDTO intents utilizing the sms:, smsto:, mms:, and mmsto: Uniform Resource Identifier (URI) schemes is incorrectly implemented. Due to this misconfiguration, an attacker capable of invoking an Android intent can exploit this vulnerability to send messages on the user’s behalf to arbitrary receivers without requiring any further user interaction or specific permissions. This al | 6.9 | 0.15% | 2025-10-27 | 2026-06-17 |
| CVE-2025-62496 | A vulnerability exists in the QuickJS engine's BigInt string parsing logic (js_bigint_from_string) when attempting to create a BigInt from a string with an excessively large number of digits. The function calculates the necessary number of bits (n_bits) required to store the BigInt using the formula: $$\text{n\_bits} = (\text{n\_digits} \times 27 + 7) / 8 \quad (\text{for radix 10})$$ * For large input strings (e.g., $79,536,432$ digits or more for base 10), the intermediate calculation $( | 7.1 | 0.44% | 2025-10-16 | 2026-06-17 |
| CVE-2025-62495 | An integer overflow vulnerability exists in the QuickJS regular expression engine (libregexp) due to an inconsistent representation of the bytecode buffer size. * The regular expression bytecode is stored in a DynBuf structure, which correctly uses a $\text{size}\_\text{t}$ (an unsigned type, typically 64-bit) for its size member. * However, several functions, such as re_emit_op_u32 and other internal parsing routines, incorrectly cast or store this DynBuf $\text{size}\_\text{t}$ value | 7.1 | 0.42% | 2025-10-16 | 2026-06-17 |
| CVE-2025-62494 | A type confusion vulnerability exists in the handling of the string addition (+) operation within the QuickJS engine. * The code first checks if the left-hand operand is a string. * It then attempts to convert the right-hand operand to a primitive value using JS_ToPrimitiveFree. This conversion can trigger a callback (e.g., toString or valueOf). * During this callback, an attacker can modify the type of the left-hand operand in memory, changing it from a string to a different type | 7.1 | 0.47% | 2025-10-16 | 2026-06-17 |
| CVE-2025-62493 | A vulnerability exists in the QuickJS engine's BigInt string conversion logic (js_bigint_to_string1) due to an incorrect calculation of the required number of digits, which in turn leads to reading memory past the allocated BigInt structure. * The function determines the number of characters (n_digits) needed for the string representation by calculating: $$ \\ \text{n\_digits} = (\text{n\_bits} + \text{log2\_radix} - 1) / \text{log2\_radix}$$ $$$$This formula is off-by-one in certain edge | 5.9 | 0.36% | 2025-10-16 | 2026-06-17 |
| CVE-2025-62492 | A vulnerability stemming from floating-point arithmetic precision errors exists in the QuickJS engine's implementation of TypedArray.prototype.indexOf() when a negative fromIndex argument is supplied. * The fromIndex argument (read as a double variable, $d$) is used to calculate the starting position for the search. * If d is negative, the index is calculated relative to the end of the array by adding the array's length (len) to d: $$d_{new} = d + \text{len}$$ * Due to the inher | 5.9 | 0.36% | 2025-10-16 | 2026-06-17 |
| CVE-2025-62491 | A Use-After-Free (UAF) vulnerability exists in the QuickJS engine's standard library when iterating over the global list of unhandled rejected promises (ts->rejected_promise_list). * The function js_std_promise_rejection_check attempts to iterate over the rejected_promise_list to report unhandled rejections using a standard list loop. * The reason for a promise rejection is processed inside the loop, including calling js_std_dump_error1(ctx, rp->reason). * If the promise rejection | 8.8 | 0.37% | 2025-10-16 | 2026-06-17 |
| CVE-2025-62490 | In quickjs, in js_print_object, when printing an array, the function first fetches the array length and then loops over it. The issue is, printing a value is not side-effect free. An attacker-defined callback could run during js_print_value, during which the array could get resized and len1 become out of bounds. This results in a use-after-free.A second instance occurs in the same function during printing of a map or set objects. The code iterates over ms->records list, but once again, elements | 8.8 | 0.37% | 2025-10-16 | 2026-06-17 |
| CVE-2025-5009 | In Gemini iOS, when a user shared a snippet of a conversation, it would share the entire conversation via a sharable public link that contained the entire conversation history and not just the snippet. | 1.0 | 0.12% | 2025-10-08 | 2026-06-17 |
| CVE-2025-59734 | It is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion <2. When a STOR chunk is present, a subsequent FOBJ chunk will be saved in ctx->stored_frame. Stored frames can later be referenced by FTCH chunks. For files using subversion < 2, the undecoded frame is stored, and decoded again when the FTCH chunks are parsed. However, in process_frame_obj if the frame has an invalid size, there’s an early return, with a value of 0. This cause | 8.7 | 0.17% | 2025-10-06 | 2026-06-17 |
| CVE-2025-59733 | When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are "B", "G", "R" and "A". The channel parsing code can be found in decode_header. The buffer td->uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset. The function dwa_uncompress then assumes at [5] that if there are 4 channels, the | 8.7 | 0.17% | 2025-10-06 | 2026-06-17 |
| CVE-2025-59732 | When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that the height and width are divisible by 8. If the height or width of the image is not divisible by 8, the copy loops at [0] and [1] will continue to write until the next multiple of 8. The buffer td->uncompressed_data is allocated in decode_block based on the precise height and width of the image, so the "rounded-up" multiple of 8 in the copy loop can exceed the buffer bounds, and the write bloc | 8.7 | 0.15% | 2025-10-06 | 2026-06-17 |
| CVE-2025-59731 | When decoding an OpenEXR file that uses DWAA or DWAB compression, the specified raw length of run-length-encoded data is not checked when using it to calculate the output data. We read rle_raw_size from the input file at [0], we decompress and decode into the buffer td->rle_raw_data of size rle_raw_size at [1], and then at [2] we will access entries in this buffer up to (td->xsize - 1) * (td->ysize - 1) + rle_raw_size / 2, which may exceed rle_raw_size. We recommend upgrading to version 8.0 | 6.9 | 0.16% | 2025-10-06 | 2026-06-17 |
| CVE-2025-59730 | When decoding a frame for a SANM file (ANIM v0 variant), the decoded data can be larger than the buffer allocated for it. Frames encoded with codec 48 can specify their resolution (width x height). A buffer of appropriate size is allocated depending on the resolution. This codec can encode the frame contents using a run-length encoding algorithm. There are no checks that the decoded frame fits in the allocated buffer, leading to a heap-buffer-overflow. process_frame_obj initializes the buffer | 5.7 | 0.15% | 2025-10-06 | 2026-06-17 |
| CVE-2025-59729 | When parsing the header for a DHAV file, there's an integer underflow in offset calculation that leads to reading the duration from before the start of the allocated buffer. If we load a DHAV file that is larger than MAX_DURATION_BUFFER_SIZE bytes (0x100000) for example 0x101000 bytes, then at [0] we have size = 0x101000. At [1] we have end_buffer_size = 0x100000, and at [2] we have end_buffer_pos = 0x1000. The loop then scans backwards through the buffer looking for the dhav tag; when it is f | 5.7 | 0.15% | 2025-10-06 | 2026-06-17 |
| CVE-2025-59728 | When calculating the content path in handling of MPEG-DASH manifests, there's an out-of-bounds NUL-byte write one byte past the end of the buffer.When we call xmlNodeGetContent below [0], it returns a buffer precisely allocated to match the string length, using strdup internally. If this buffer is not an empty string, it is assigned to root_url at [1].If the last (non-NUL) byte in this buffer is not '/' then we append '/' in-place at [2]. This will write two bytes into the buffer, starting at th | 8.7 | 0.17% | 2025-10-06 | 2026-06-17 |
| CVE-2025-9906 | The Keras Model.load_model method can be exploited to achieve arbitrary code execution, even with safe_mode=True. One can create a specially crafted .keras model archive that, when loaded via Model.load_model, will trigger arbitrary code to be executed. This is achieved by crafting a special config.json (a file within the .keras archive) that will invoke keras.config.enable_unsafe_deserialization() to disable safe mode. Once safe mode is disable, one can use the Lambda layer feature of keras, w | 8.6 | 0.19% | 2025-09-19 | 2026-06-17 |
| CVE-2025-9905 | The Keras Model.load_model method can be exploited to achieve arbitrary code execution, even with safe_mode=True. One can create a specially crafted .h5/.hdf5 model archive that, when loaded via Model.load_model, will trigger arbitrary code to be executed. This is achieved by crafting a special .h5 archive file that uses the Lambda layer feature of keras which allows arbitrary Python code in the form of pickled code. The vulnerability comes from the fact that the safe_mode=True option is not h | 7.3 | 0.21% | 2025-09-19 | 2026-06-17 |