CVE-2026-106390
Incorrect provision of specified functionality in SanitizerAPI in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to leak sen
CVSS
—
Sem CVSS
EPSS
0.2%
p10
KEV
—
Exploit Today
3
0-100
Publicado: 6 de out. de 2026 · Última mod.: 6 de out. de 2026 · CWE-684
0.2%EPSS · 30 dias0.2%
2026-10-122026-11-10
Incorrect provision of specified functionality in SanitizerAPI in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to leak sensitive information via a crafted HTML page. (Chromium security severity: Low)
CVECVSSEPSSKEVRExploitTítuloMod.
CVE-2026-125729——
——0Plack::Middleware::CSP versions before 0.03 for Perl send the Content Security Policy under the wrong header name, so browsers never enforce it.
The call method sets the policy in a response header named "content-security-protocol" instead of "Content-Security-Policy". Browsers ignore that header.
Any cross-site scripting flaw in the wrapped application can run scripts the policy was meant to block.3hCVE-2026-119078—13.8%
——4Apache Commons Codec's Blake3 class documented the output of its doFinalize methods as depending on any previously finalized bytes, so that consecutive calls would return different output. In fact, doFinalize does not change the hash state: calling it again without supplying more input returns the same bytes. The key-derivation example in the class Javadoc, shipped since 1.16.0, derives two keys with two consecutive doFinalize calls. Code that follows it gets identical keys, so the separation between the derived keys is lost. The same applies to any application that calls doFinalize more than once on one instance and expects new output each time.
This issue affects Apache Commons Codec from 1.16.0 before 1.23.0.
Version 1.23.0 corrects the documentation, but the behavior of doFinalize is unchanged. Upgrading alone does not fix affected code. Users should check their applications for repeated doFinalize calls on the same Blake3 instance and derive multiple keys by requesting the combined length in one call and splitting the output, as the updated Javadoc shows.22hCVE-2026-1063616.5 MÉD20.7%
——6Incorrect provision of specified functionality in Mobile in Google Chrome on on iOS prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to bypass web origin policy via crafted network traffic. (Chromium security severity: Medium)27dCVE-2026-791265.9 MÉD15.2%
——5Incorrect provision of specified functionality in Proxy in Google Chrome on on Windows prior to 152.0.7977.65 allowed an adjacent attacker to potentially obtain sensitive information via crafted network traffic. (Chromium security severity: Low)75dCVE-2026-52735—43.6%
——13ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, Zebra can accept a block that zcashd rejects because the P2SH signature-operation counter undercounts redeem scripts containing a disabled opcode followed by signature opcodes. In zebra-script/src/lib.rs, p2sh_input_sigop_count used the pure-Rust script::Code::sig_op_count path, whose try_fold parser stops at disabled opcodes such as OP_CODESEPARATOR and returns only the partial count accumulated before the error. The zcashd reference implementation continues static signature-operation counting through disabled opcodes, so an attacker can broadcast P2SH spends that Zebra counts below MAX_BLOCK_SIGOPS while zcashd counts above the 20,000-operation limit. If a Zebra miner includes those transactions, Zebra validators accept the block while zcashd validators reject it, creating a consensus chain split that affects network integrity and availability without requiring the attacker to produce a block. This issue is fixed in version 4.5.0.19dCVE-2026-445973.7 BAI39.4%
——12Tor before 0.4.9.7 has an out-of-bounds read when an END, a TRUNCATE, or a TRUNCATED cell lacks a reason in its payload, aka TROVE-2026-011.15d