Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2025-68809 | 9.1 critical | 1.0% | linux | In the Linux kernel, the following vulnerability has been resolved: ksmbd: vfs: fix race on m_flags in vfs_cache ksmbd maintains delete-on-close and pending-delete state in ksmbd_inode->m_flags. In vfs_cache.c this field is accessed under inconsistent locking: some paths read and modify m_flags under ci->m_lock while others do so without taking the lock at all. Examples: - ksmbd_query_inode_status() and __ksmbd_inode_close() use ci->m_lock when checking or updating m_flags. - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close() used to read and modify m_flags without ci->m_lock. This creates a potential data race on m_flags when multiple threads open, close and delete the same file concurrently. In the worst case delete-on-close and pending-delete bits can be lost or observed in an inconsistent state, leading to confusing delete semantics (files that stay on disk after delete-on-close, or files that disappear while still in use). Fix it by: - Making ksmbd_query_inode_status() look at m_flags under ci->m_lock after dropping inode_hash_lock. - Adding ci->m_lock protection to all helpers that read or modify m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()). - Keeping the existing ci->m_lock protection in __ksmbd_inode_close(), and moving the actual unlink/xattr removal outside the lock. This unifies the locking around m_flags and removes the data race while preserving the existing delete-on-close behaviour. | 14 h ago |
| CVE-2026-93790 | 8.8 high | 0.00% | linux | In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix out-of-bounds tid_data access in BA notif mvmsta->tid_data was indexed by the TFD loop counter 'i' instead of the actual TID value 'tid'. This writes lq_color into a random tid_data slot unrelated to the BA entry. Since multi-TID blockack is not really in use, 'i' was always 0 and no harm was done. Add a out-of-bound check before accessing the array. | 13 h ago |
| CVE-2024-14040 | 7.8 high | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: net: nexthop: Increase weight to u16 In CLOS networks, as link failures occur at various points in the network, ECMP weights of the involved nodes are adjusted to compensate. With high fan-out of the involved nodes, and overall high number of nodes, a (non-)ECMP weight ratio that we would like to configure does not fit into 8 bits. Instead of, say, 255:254, we might like to configure something like 1000:999. For these deployments, the 8-bit weight may not be enough. To that end, in this patch increase the next hop weight from u8 to u16. Increasing the width of an integral type can be tricky, because while the code still compiles, the types may not check out anymore, and numerical errors come up. To prevent this, the conversion was done in two steps. First the type was changed from u8 to a single-member structure, which invalidated all uses of the field. This allowed going through them one by one and audit for type correctness. Then the structure was replaced with a vanilla u16 again. This should ensure that no place was missed. The UAPI for configuring nexthop group members is that an attribute NHA_GROUP carries an array of struct nexthop_grp entries: struct nexthop_grp { __u32 id; /* nexthop id - must exist */ __u8 weight; /* weight of this nexthop */ __u8 resvd1; __u16 resvd2; }; The field resvd1 is currently validated and required to be zero. We can lift this requirement and carry high-order bits of the weight in the reserved field: struct nexthop_grp { __u32 id; /* nexthop id - must exist */ __u8 weight; /* weight of this nexthop */ __u8 weight_high; __u16 resvd2; }; Keeping the fields split this way was chosen in case an existing userspace makes assumptions about the width of the weight field, and to sidestep any endianness issues. The weight field is currently encoded as the weight value minus one, because weight of 0 is invalid. This same trick is impossible for the new weight_high field, because zero must mean actual zero. With this in place: - Old userspace is guaranteed to carry weight_high of 0, therefore configuring 8-bit weights as appropriate. When dumping nexthops with 16-bit weight, it would only show the lower 8 bits. But configuring such nexthops implies existence of userspace aware of the extension in the first place. - New userspace talking to an old kernel will work as long as it only attempts to configure 8-bit weights, where the high-order bits are zero. Old kernel will bounce attempts at configuring >8-bit weights. Renaming reserved fields as they are allocated for some purpose is commonly done in Linux. Whoever touches a reserved field is doing so at their own risk. nexthop_grp::resvd1 in particular is currently used by at least strace, however they carry an own copy of UAPI headers, and the conversion should be trivial. A helper is provided for decoding the weight out of the two fields. Forcing a conversion seems preferable to bending backwards and introducing anonymous unions or whatever. | 14 h ago |
| CVE-2026-62297 | 7.5 high | — | agamnentzar, ag-psd | ag-psd is a JavaScript library for reading and writing Photoshop Document files. Before the allocation-limit remediation attempt in version 31.0.0, `readPsd()` commits image and layer buffers from attacker-declared PSD geometry before validating the declarations against the actual available data or sane allocation limits. The `psdReader.js` implementation sizes off-heap typed arrays using `width`, `height`, `channels`, `depth` and `per-layer rectangles`, so a tiny PSD declaring enormous geometry can force multi-gigabyte memory allocation before a later bounds error. The reported 52-byte input on Node 24 produced approximately 3.17 GB peak RSS before a RangeError; under memory pressure the process can be terminated before the error can be caught, and concurrent inputs can exhaust memory. Services reading untrusted PSDs are exposed to denial of service. This differs from genuinely large PSD files whose memory demand is proportional to real input content. Version 31.0.0 adds a composite-image allocation limit, but complete coverage of the separately described layer-rectangle allocation path is not established and requires curator residual/scope review. | 5 h ago |
| CVE-2026-61627 | 7.3 high | — | libass | libass is a portable subtitle renderer for the `ASS`/SSA (Advanced Substation Alpha/Substation Alpha) subtitle format. Prior to 0.17.5, libass can overread and overwrite the glyph array in `wrap_lines_measure` while rendering malicious `ASS` content. In `wrap modes other than two`, a final line ending with a literal backslash-n sequence and otherwise consisting only of such sequences or spaces can remain after early trimming and make the line-measurement loops overshoot by one glyph. When the total text size exactly matches the allocated glyph-array capacity, the first loop reads an uninitialized 32-bit fixed-point `pos.x` value, although that value is not subsequently used. The second loop writes `pos.x` and `pos.y` beyond the array, zeroing the first and adding an attacker-controllable offset to the second. No actual exploitation beyond possible denial of service is known; broader exploitation is theoretical and constrained by the addresses, limited writes, and ASLR. This issue is fixed in version 0.17.5. | 10 h ago |
| CVE-2026-105960 | 6.8 medium | 0.00% | no CPE yet | PEAK-System PCAN contains a vulnerable operation involving a variable-length receive-record copy. The driver uses a requested or queued record count without sufficiently capping the copy to the actual caller-supplied output length. | 9 h ago |
| CVE-2026-55551 | 6.5 medium | — | infonl, dimpact-zaakafhandelcomponent | ZAC is an open-source, workflow-based Common Ground component for Dutch municipal case management. Prior to 5.2.0, by-id read endpoints in `src/main/kotlin/nl/info/zac/app/zaak/ZaakRestService.kt` omit `assertPolicy`(`policyService.readZaakRechten(zaak).lezen`) authorization. `RequestAuthorizationFilter` and `hasAnyApplicationRole` require only an application role on any zaaktype, not the target case's type, while `zaak-rechten.rego` enforces the actual `zaaktype_allowed` boundary only when invoked. An authenticated low-privileged municipal user who knows a case or decision UUID can use `GET /rest/zaken/besluit/zaakUuid/{uuid}` (`listBesluitenForZaakUUID`) to read decisions including types, dates, and free-text toelichting; `GET /rest/zaken/besluit/{uuid}/historie` (`listBesluitHistorie`) to read audit old/new values; and `GET /rest/zaken/{uuid}/process-diagram` (`downloadProcessDiagram`) to read BPMN workflow state across unauthorized zaaktypes. The advisory also identifies `zaak/{uuid}/afzender` (`listAfzendersVoorZaak`) as exposing zaaktype mailbox configuration without a policy check. The search/_zoek path is correctly authorization-filtered and is not part of this by-id read cluster. This issue is fixed in version 5.2.0. | 9 h ago |
| CVE-2026-61803 | 5.3 medium | — | frappe, lms | Frappe Learning Management System (LMS) is a learning system that helps users structure their content. Prior to version 2.52.1, the `course/certificate checkout` flow accepts client-controlled pricing, allowing an authenticated user to complete a paid-course or certificate purchase for an amount other than the actual price. This is a business-logic integrity issue; it does not expose other users' data or grant elevated privileges. This issue is fixed in version 2.52.1. | 9 h ago |
| CVE-2026-61840 | 2.3 low | — | vantern-org, questbot | Quest Bot is an opensource Discord Bot. Prior to 1.1.9, the `image to GIF` command uses a request helper that validates a hostname's public IP addresses but then sends the actual request by hostname, causing a `second DNS lookup`. An attacker controlling a domain can return a public address during validation and an internal address during the connection, bypassing the internal-address protection through `DNS rebinding`. The command takes its address directly from user input and its developer-only gate is disabled in normal deployments, so any member of a server with the bot can trigger the flaw without special permissions. Requests are restricted to `HTTPS on port 443`, and content is returned only when the response is a `genuine image`. The impact is therefore mostly blind internal probing with limited retrieval of image responses from loopback or internal endpoints, not arbitrary internal-data disclosure. Common cloud metadata services using plain HTTP on another port are not reachable through this path. This issue is fixed in version 1.1.9. | 4 h ago |
| CVE-2026-80907 | unscored | 0.00% | linux | In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix UVD dpb min size calculation for H264 This should use actual number of references from the decode message, instead of maximum derived from level. (cherry picked from commit 64b525edb7e7bdfcdc77883c5e413804e2396856) | 13 h ago |
| CVE-2025-68342 | unscored | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()] | 14 h ago |
| CVE-2024-35946 | unscored | 0.00% | linux | In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix null pointer access when abort scan During cancel scan we might use vif that weren't scanning. Fix this by using the actual scanning vif. | 14 h ago |
12 of 12
Download these 12 as CSV · subscribe to this list.
EPSS scores: 2026-10-30. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.