CVE Watch
Every published CVE, mapped to engagement reality.
Crawled from cve.org every day. Each entry annotated with the QSearch coverage signal — how many of our agents, skills, and playbooks address the technique. Subscribe via RSS for SIEM pipe, or get the weekly digest by email.
Smart contract Marginal v1 performs unsafe downcast, allowing attackers to settle a large debt position for a negligible asset cost
Smart contract Marginal v1 performs unsafe downcast, allowing attackers to settle a large debt position for a negligible asset cost.
CWE-681Memory-safety vulnerability in github.com/jackc/pgx/v5
Memory-safety vulnerability in github.com/jackc/pgx/v5.
jackcMemory-safety vulnerability in github.com/jackc/pgx/v5
Memory-safety vulnerability in github.com/jackc/pgx/v5.
jackcOCS Inventory NG Server version 2.12.3 and prior contain a stored cross-site scripting vulnerability that allows unauthenticated attacker...
OCS Inventory NG Server version 2.12.3 and prior contain a stored cross-site scripting vulnerability that allows unauthenticated attackers to execute arbitrary JavaScript by submitting malicious User-Agent HTTP headers to the /ocsinventory endpoint. Attackers can register rogue agents or craft requests with malicious User-Agent values that are stored without sanitization and rendered with insufficient encoding in the web console, leading to arbitrary JavaScript execution in the browsers of authenticated users viewing the statistics dashboard.
ocsinventory-ngCWE-79In importWrappedKey of KMKeymasterApplet.java, there is a possible way access keys that should be restricted due to improper input valida...
In importWrappedKey of KMKeymasterApplet.java, there is a possible way access keys that should be restricted due to improper input validation. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.
googleCWE-20A flaw was found in Keycloak
A flaw was found in Keycloak. A remote attacker can exploit a Cross-Origin Resource Sharing (CORS) header injection vulnerability in Keycloak's User-Managed Access (UMA) token endpoint. This flaw occurs because the `azp` claim from a client-supplied JSON Web Token (JWT) is used to set the `Access-Control-Allow-Origin` header before the JWT signature is validated. When a specially crafted JWT with an attacker-controlled `azp` value is processed, this value is reflected as the CORS origin, even if the grant is later rejected. This can lead to the exposure of low-sensitivity information from authorization server error responses, weakening origin isolation, but only when a target client is misconfigured with `webOrigins: ["*"]`.
redhatCWE-346In the Linux kernel, the following vulnerability has been resolved: ksmbd: use volume UUID in FS_OBJECT_ID_INFORMATION Use sb->s_uuid f...
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().
linuxIn the Linux kernel, the following vulnerability has been resolved: media: dvb-net: fix OOB access in ULE extension header tables The u...
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.
linuxCWE-125Zcash zcashd before 6.12.0 allows invalid transactions to be accepted under certain conditions, which potentially could have resulted in ...
Zcash zcashd before 6.12.0 allows invalid transactions to be accepted under certain conditions, which potentially could have resulted in the draining of user funds from the Sprout pool. It was sometimes not verifying Sprout proofs.
CWE-358A vulnerability was determined in zhongyu09 openchatbi up to 0.2.1
A vulnerability was determined in zhongyu09 openchatbi up to 0.2.1. The impacted element is an unknown function of the component Multi-stage Text2SQL Workflow. Executing a manipulation of the argument keywords can lead to sql injection. The attack may be launched remotely. The exploit has been publicly disclosed and may be utilized.
CWE-74CWE-89MyBB Like Plugin 3.0.0 contains a cross-site scripting vulnerability that allows attackers to inject malicious scripts by creating posts ...
MyBB Like Plugin 3.0.0 contains a cross-site scripting vulnerability that allows attackers to inject malicious scripts by creating posts or threads with unvalidated subject content. Attackers can craft post subjects containing script tags that execute when other users view the attacker's profile, where liked posts are displayed without sanitization.
mybbCWE-79The Stackfield Desktop App before 1.10.2 for macOS and Windows contains a path traversal vulnerability in certain decryption functionalit...
The Stackfield Desktop App before 1.10.2 for macOS and Windows contains a path traversal vulnerability in certain decryption functionality when processing the filePath property. A malicious export can write arbitrary content to any path on the victim's filesystem.
stackfieldCWE-22In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 re...
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.
linuxCWE-787In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix cache_request leak in cache_release When a reader's fil...
In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix cache_request leak in cache_release When a reader's file descriptor is closed while in the middle of reading a cache_request (rp->offset != 0), cache_release() decrements the request's readers count but never checks whether it should free the request. In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the cache_request is removed from the queue and freed along with its buffer and cache_head reference. cache_release() lacks this cleanup. The only other path that frees requests with readers == 0 is cache_dequeue(), but it runs only when CACHE_PENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up. Add the same cleanup logic from cache_read() to cache_release(): after decrementing readers, check if it reached 0 with CACHE_PENDING clear, and if so, dequeue and free the cache_request.
linuxCWE-401In the Linux kernel, the following vulnerability has been resolved: mac80211: fix crash in ieee80211_chan_bw_change for AP_VLAN stations...
In the Linux kernel, the following vulnerability has been resolved: mac80211: fix crash in ieee80211_chan_bw_change for AP_VLAN stations ieee80211_chan_bw_change() iterates all stations and accesses link->reserved.oper via sta->sdata->link[link_id]. For stations on AP_VLAN interfaces (e.g. 4addr WDS clients), sta->sdata points to the VLAN sdata, whose link never participates in chanctx reservations. This leaves link->reserved.oper zero-initialized with chan == NULL, causing a NULL pointer dereference in __ieee80211_sta_cap_rx_bw() when accessing chandef->chan->band during CSA. Resolve the VLAN sdata to its parent AP sdata using get_bss_sdata() before accessing link data. [also change sta->sdata in ARRAY_SIZE even if it doesn't matter]
linuxCWE-476In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - Fix OOM ->tfm_count leak If memory allocati...
In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - Fix OOM ->tfm_count leak If memory allocation fails, decrement ->tfm_count to avoid blocking future reads.
linuxIn the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix memory leak in xe_vm_madvise_ioctl When check_bo_args_a...
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix memory leak in xe_vm_madvise_ioctl When check_bo_args_are_sane() validation fails, jump to the new free_vmas cleanup label to properly free the allocated resources. This ensures proper cleanup in this error path. (cherry picked from commit 29bd06faf727a4b76663e4be0f7d770e2d2a7965)
linuxCWE-401In the Linux kernel, the following vulnerability has been resolved: spi: fix statistics allocation The controller per-cpu statistics is...
In the Linux kernel, the following vulnerability has been resolved: spi: fix statistics allocation The controller per-cpu statistics is not allocated until after the controller has been registered with driver core, which leaves a window where accessing the sysfs attributes can trigger a NULL-pointer dereference. Fix this by moving the statistics allocation to controller allocation while tying its lifetime to that of the controller (rather than using implicit devres).
linuxCWE-476In the Linux kernel, the following vulnerability has been resolved: mtd: Avoid boot crash in RedBoot partition table parser Given CONFI...
In the Linux kernel, the following vulnerability has been resolved: mtd: Avoid boot crash in RedBoot partition table parser Given CONFIG_FORTIFY_SOURCE=y and a recent compiler, commit 439a1bcac648 ("fortify: Use __builtin_dynamic_object_size() when available") produces the warning below and an oops. Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000 ------------[ cut here ]------------ WARNING: lib/string_helpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1 memcmp: detected buffer overflow: 15 byte read of buffer size 14 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONE As Kees said, "'names' is pointing to the final 'namelen' many bytes of the allocation ... 'namelen' could be basically any length at all. This fortify warning looks legit to me -- this code used to be reading beyond the end of the allocation." Since the size of the dynamic allocation is calculated with strlen() we can use strcmp() instead of memcmp() and remain within bounds.
linuxIn the Linux kernel, the following vulnerability has been resolved: serial: core: fix infinite loop in handle_tx() for PORT_UNKNOWN uar...
In the Linux kernel, the following vulnerability has been resolved: serial: core: fix infinite loop in handle_tx() for PORT_UNKNOWN uart_write_room() and uart_write() behave inconsistently when xmit_buf is NULL (which happens for PORT_UNKNOWN ports that were never properly initialized): - uart_write_room() returns kfifo_avail() which can be > 0 - uart_write() checks xmit_buf and returns 0 if NULL This inconsistency causes an infinite loop in drivers that rely on tty_write_room() to determine if they can write: while (tty_write_room(tty) > 0) { written = tty->ops->write(...); // written is always 0, loop never exits } For example, caif_serial's handle_tx() enters an infinite loop when used with PORT_UNKNOWN serial ports, causing system hangs. Fix by making uart_write_room() also check xmit_buf and return 0 if it's NULL, consistent with uart_write(). Reproducer: https://gist.github.com/mrpre/d9a694cc0e19828ee3bc3b37983fde13
linuxCWE-835
6.8 MEDIUM
9.8 CRITICAL
3.7 LOWWeekly digest
Get the curated CVE digest every Monday
One email a week, sent Monday morning CET. The CVEs published or modified in the last seven days, severity-ordered, with the QSearch coverage signal. Unsubscribe with one click — included in every send.
Pipe the CVE feed into your stack.
CVE Watch publishes RSS, Atom, and JSON feeds — wire them into your SIEM, Slack, Discord, or your RSS reader of choice. Or get the curated weekly digest by email.