CVE-2026-113012
Incomplete cleanup in GPU in Google Chrome prior to 156.0.8078.47 allowed a remote attacker who had compromised the renderer process to exec
CVSS
8.8
Alta
EPSS
0.5%
p42
KEV
—
Exploit Today
13
0-100
Publicado: 20 de out. de 2026 · Última mod.: 3 de nov. de 2026 · CWE-459
0.4%EPSS · 30 dias0.5%
2026-10-212026-11-07
Incomplete cleanup in GPU in Google Chrome prior to 156.0.8078.47 allowed a remote attacker who had compromised the renderer process to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High)
CVECVSSEPSSKEVRExploitTítuloMod.
CVE-2026-1235607.5 ALT—
———Zebra before 7.0.0 contains an incomplete cleanup vulnerability that allows unauthenticated peers to stall initial sync by serving a forged checkpoint block body. Attackers can supply a body with forged authorizing data near the final checkpoint, leaving rejected hashes in the sent-hash set so the node stops requesting blocks until restart.9hCVE-2026-1217503.1 BAI3.8%
——1Node Version Manager (nvm) is a POSIX-compliant shell function for managing multiple node.js versions. In versions 0.40.5 through 0.40.8, `nvm_download_artifact` downloads a release archive directly to its final path in `$NVM_DIR/.cache` and verifies its checksum afterwards; on a checksum mismatch it reports an error but leaves the rejected archive in place. A later `nvm install --offline` of the same version installs that cached file without a checksum, so an archive that was just rejected gets installed and its `node` and `npm` run. This gives code execution to a party who can alter the downloaded tarball (for example a poisoned CDN or cache object) but cannot also forge the `SHASUMS256.txt` beside it, if the victim runs `nvm install --offline` for that version after the visible "Checksums do not match" failure and before any online retry. Version 0.41.0 only puts an archive in the cache once its checksum has passed.4dCVE-2026-1212048.8 ALT24.4%
——7Incomplete cleanup in DevTools in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low)3dCVE-2026-121096—4.3%
——1Incomplete cleanup in V8 in Google Chrome prior to 157.0.8103.38 allowed a local attacker to read memory via a local program. (Chromium security severity: Medium)5dCVE-2026-121055—7.7%
——2Incomplete cleanup in DevTools in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to bypass system access restrictions via a crafted Chrome extension. (Chromium security severity: Low)5dCVE-2026-850334.6 MÉD11.9%
——4The AVRCP Target role in subsys/bluetooth/host/classic/avrcp.c keeps its vendor-dependent response transmit state in a per-connection object selected by connection index (get_avrcp_tg()), with the per-transfer context (tid, sent_len, and the BT_AVRCP_TG_FLAG_TX_ONGOING flag) stored in the user_data of the queued response net_buf. The AVCTP teardown handler avrcp_disconnected() did not cancel tg->vd_rsp_tx_work and did not release the buffers still queued on tg->vd_rsp_tx_pending, so a link drop in the middle of a fragmented response left the buffer on the list with TX_ONGOING still set.
A remote AVRCP Controller can trigger this deterministically: it issues a vendor-dependent command whose response exceeds one AVRCP fragment (for example GetElementAttributes or GetCapabilities), lets bt_avrcp_tg_vendor_tx_work() emit the START fragment, and then drops the ACL link instead of sending REQUEST_CONTINUING_RESPONSE. The AVCTP control channel requires an encrypted BR/EDR link (BT_SECURITY_L2), so the attacker must be a paired peer within radio range; no user interaction is needed.
Because the Target objects are static and reused, the next connection landing on the same connection index finds the stale buffer at the head of vd_rsp_tx_pending. Every run of the TX work sees TX_ONGOING and returns immediately, so all further vendor-dependent responses queue behind the stale head and are never sent — a persistent loss of AVRCP Target function that no timeout clears and only a reboot recovers. Each cycle also leaks one response buffer from a shallow application pool, and a new peer that sends REQUEST_CONTINUING_RESPONSE clears the stale TX_ONGOING via bt_avrcp_tg_process_continuing_cmd(), causing the un-sent remainder of the previous peer's response to be transmitted to it.
The fix cancels tg->vd_rsp_tx_work and unrefs every buffer on tg->vd_rsp_tx_pending in avrcp_disconnected(); since the TX context lives in the buffer user_data, releasing the buffers also resets the TX state machine. There is no memory corruption: the pre-fix buffer is leaked with a live reference, so no use-after-free arises.5d