QSearchQSearch
A vertical stack of five horizontal severity-tier bars rendered with Swiss tabular precision, descending in opacity from a hot volt-lime upper bar through a cooler signal-blue lower bar, evoking vulnerability severity stratification

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.

Tracking 10103 CVEsUpdated dailyLatest entry 2026-06-16
  • CVE-2026-450762.7 LOW2026-05-28

    Synapse is an open source Matrix homeserver implementation

    Synapse is an open source Matrix homeserver implementation. Prior to 1.152.1, in federated rooms, malicious homeservers can craft room events in such a way that prevents Synapse from providing full history to paginating clients. Clients could therefore fail to display room history. This vulnerability is fixed in 1.152.1.

    elementCWE-20
  • CVE-2026-444626.4 MEDIUM2026-05-28

    Zed is a code editor

    Zed is a code editor. Prior to 0.229.0, Zed's terminal tool permission system can be bypassed via bash variable expansion chaining (${var@P}), allowing arbitrary command execution under an allowlisted command prefix. This vulnerability is fixed in 0.229.0.

    zedCWE-184
  • CVE-2026-411856.5 MEDIUM2026-05-28

    When Calico is configured with the Azure IPAM plugin, the Calico CNI binary mutates the incoming CNI configuration to attach subnet infor...

    When Calico is configured with the Azure IPAM plugin, the Calico CNI binary mutates the incoming CNI configuration to attach subnet information before delegating to the IPAM plugin. After mutating, the Azure IPAM helper logs the entire unmarshaled configuration map (stdinData) at INFO level to /var/log/calico/cni/cni.log on every CNI ADD and DEL invocation — once per pod scheduled or terminated on the node. When the cluster is deployed using token-based Kubernetes authentication, this log entry contains the ServiceAccount token, client key, and certificate authority in plaintext. Any principal with read access to /var/log/calico/cni/cni.log on a node  can read these logs and extract the credentials, which grant cluster-wide Calico networking admin privileges.

    tigeraCWE-532
  • CVE-2026-411846.5 MEDIUM2026-05-28

    In Calico, the install-cni init container logs the rendered CNI configuration to standard output

    In Calico, the install-cni init container logs the rendered CNI configuration to standard output. When the configuration template uses the __SERVICEACCOUNT_TOKEN__ placeholder (Canal/Flannel-Calico deployments), the installer substitutes the live Kubernetes ServiceAccount bearer token before logging, exposing the token to any authenticated user with pods/log permission in the namespace with calico-node. The token holds patch privileges on pods/status, enabling annotation-based attacks against cluster workloads. The default kubeconfig-based authentication path is not affected. This is a direct regression of TTA-2018-001.

    tigeraCWE-532
  • CVE-2026-411604.3 MEDIUM2026-05-28

    EspoCRM is an open source customer relationship management application

    EspoCRM is an open source customer relationship management application. Prior to 9.3.5, a business logic flaw (Broken Access Control) in EspoCRM 9.3.3 allows low-privileged users to pin arbitrary notes without having the required edit permissions for the parent object. Due to a "write first, authorize later" execution flaw in the backend API, even though the server correctly returns a 403 Forbidden error, the targeted note's pinned status is already persistently modified in the database. The root cause lies in the server-side processing of the POST /api/v1/Note/{id}/pin endpoint. In application/Espo/Tools/Stream/Api/PostNotePin.php, the process() method first calls getNote($id) before calling checkParent($note). This vulnerability is fixed in 9.3.5.

    CWE-284CWE-639
  • CVE-2026-411416.5 MEDIUM2026-05-28

    EspoCRM is an open source customer relationship management application

    EspoCRM is an open source customer relationship management application. Prior to 9.3.5, the POST /api/v1/EmailTemplate/:id/prepare endpoint accepts an emailAddress parameter and resolves the owning entity (Contact, Lead, Account, or User) without performing an ACL check. An authenticated user with EmailTemplate read permission can extract all field values of any entity by supplying the target's email address, bypassing read: own or read: team ACL restrictions. This vulnerability is fixed in 9.3.5.

    CWE-639
  • CVE-2026-487355.5 MEDIUM2026-05-28

    pypdf is a free and open-source pure-python PDF library

    pypdf is a free and open-source pure-python PDF library. Prior to 6.12.1, an attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires parsing large XMP metadata, possibly with lots of unnecessary elements. This vulnerability is fixed in 6.12.1.

    pypdf_projectCWE-770
  • CVE-2026-485255.3 MEDIUM2026-05-28

    PyJWT is a JSON Web Token implementation in Python

    PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option ("b64": false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.

    pyjwt_projectCWE-400
  • CVE-2026-485243.7 LOW2026-05-28

    PyJWT is a JSON Web Token implementation in Python

    PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient.get_signing_key() forces a fresh HTTP request to the JWKS endpoint for every JWT with an unknown kid value, with no rate limiting. Since kid comes from the unverified token header, an attacker can trigger unlimited outbound requests. The vulnerability surfaces only when a JWKS fetch fails; an attacker can attempt to provoke that with sustained unknown-kid traffic, but the outcome depends on upstream JWKS-endpoint behavior (rate limiting, transient errors) which is beyond the attacker's control. This vulnerability is fixed in 2.13.0.

    pyjwt_projectCWE-460CWE-755
  • CVE-2026-485235.4 MEDIUM2026-05-28

    PyJWT is a JSON Web Token implementation in Python

    PyJWT is a JSON Web Token implementation in Python. From 2.9.0 to 2.12.1, there is a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow. This vulnerability is fixed in 2.13.0.

    pyjwt_projectCWE-347
  • CVE-2026-485224.2 MEDIUM2026-05-28

    PyJWT is a JSON Web Token implementation in Python

    PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch. If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies as valid. The library does not directly return non-HTTP(S) URI contents to the attacker; the chained "plant a JWKS to forge tokens" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. This vulnerability is fixed in 2.13.0.

    pyjwt_projectCWE-441CWE-918
  • CVE-2026-481563.3 LOW2026-05-28

    pypdf is a free and open-source pure-python PDF library

    pypdf is a free and open-source pure-python PDF library. Prior to 6.12.0, an attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires cross-reference streams with /W [0 0 0] values and large /Size values. This vulnerability is fixed in 6.12.0.

    pypdf_projectCWE-834
  • CVE-2026-481555.5 MEDIUM2026-05-28

    pypdf is a free and open-source pure-python PDF library

    pypdf is a free and open-source pure-python PDF library. Prior to 6.12.0, an attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires extracting text in layout mode with large character offsets. This vulnerability is fixed in 6.12.0.

    pypdf_projectCWE-400
  • CVE-2026-409144.3 MEDIUM2026-05-28

    A vulnerability exists in Apache Artemis whereby an application using the STOMP protocol with security credentials that grant either the ...

    A vulnerability exists in Apache Artemis whereby an application using the STOMP protocol with security credentials that grant either the consume or send permission on an address can augment the routing-type supported by that address even if said user doesn't have the createAddress permission for that particular address. A user could successfully send a message to an address or consume a message from a queue with a routing-type not supported by the corresponding address when that operation should actually be rejected on the basis that the user doesn't have permission to change the routing-type of the address. Even though the user was already granted permission to send and/or consume messages, they should not be able to augment the routing-type of the address without the createAddress permission. This issue affects Apache Artemis: from 2.50.0 through 2.53.0; Apache ActiveMQ Artemis: from 2.0.0 through 2.44.0. Users are recommended to upgrade to version 2.54.0, which fixes the issue.

    apacheCWE-863
  • CVE-2026-462395.5 MEDIUM2026-05-28

    In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov5647: Fix runtime PM refcount leak in s_ctrl Three co...

    In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov5647: Fix runtime PM refcount leak in s_ctrl Three control cases (AUTOGAIN, EXPOSURE_AUTO, ANALOGUE_GAIN) directly return without calling pm_runtime_put(), causing runtime PM reference count leaks. Change these cases from 'return' to 'ret = ... break' pattern to ensure pm_runtime_put() is always called before function exit.

    linux
  • CVE-2026-462365.5 MEDIUM2026-05-28

    In the Linux kernel, the following vulnerability has been resolved: media: rc: xbox_remote: heed DMA restrictions The buffer for IO mus...

    In the Linux kernel, the following vulnerability has been resolved: media: rc: xbox_remote: heed DMA restrictions The buffer for IO must not be part of the device structure because that violates the DMA coherency rules.

    linux
  • CVE-2026-462355.5 MEDIUM2026-05-28

    In the Linux kernel, the following vulnerability has been resolved: media: saa7164: add ioremap return checks and cleanups Add checks f...

    In the Linux kernel, the following vulnerability has been resolved: media: saa7164: add ioremap return checks and cleanups Add checks for ioremap return values in saa7164_dev_setup(). If ioremap for BAR0 or BAR2 fails, release the already allocated PCI memory regions, remove the device from the global list, decrement the device count, and return -ENODEV. This prevents potential null pointer dereferences and ensures proper cleanup on memory mapping failures.

    linuxCWE-476
  • CVE-2026-462335.5 MEDIUM2026-05-28

    In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: only purge non-released claims When batadv_bla_pur...

    In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: only purge non-released claims When batadv_bla_purge_claims() goes through the list of claims, it is only traversing the hash list with an rcu_read_lock(). Due to a potential parallel batadv_claim_put(), it can happen that it encounters a claim which was actually in the process of being released+freed by batadv_claim_release(). In this case, backbone_gw is set to NULL before the delayed RCU kfree is started. Calling batadv_bla_claim_get_backbone_gw() is then no longer allowed because it would cause a NULL-ptr derefence. To avoid this, only claims with a valid reference counter must be purged. All others are already taken care of.

    linuxCWE-476
  • CVE-2026-462315.5 MEDIUM2026-05-28

    In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: put backbone reference on failed claim hash insert ...

    In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: put backbone reference on failed claim hash insert When batadv_bla_add_claim() fails to insert a new claim into the hash, it leaked a reference to the backbone_gw for which the claim was intended. Call batadv_backbone_gw_put() on the error path to release the reference and avoid leaking the backbone_gw object.

    linux
  • CVE-2026-462295.5 MEDIUM2026-05-28

    In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Clear VRAM on allocation to prevent stale data exposure ...

    In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Clear VRAM on allocation to prevent stale data exposure KFD VRAM allocations set AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE but not AMDGPU_GEM_CREATE_VRAM_CLEARED, leaving freshly allocated VRAM with stale data from prior use observable by compute kernels. The GEM ioctl path already sets VRAM_CLEARED for all userspace allocations via amdgpu_gem_create_ioctl() and amdgpu_mode_dumb_create(). The KFD path was missing this flag, allowing stale page table remnants to leak into user buffers. This causes crashes in RCCL P2P transport where non-zero data in ptrExchange/head/tail fields corrupts the protocol handshake.

    linux

Weekly 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.