Today’s digest is about the gap between “patched” and “actually fixed,” and between automation that protects you and automation that turns on you. A kernel bug that sat dormant for over a decade, a device-provisioning feature built for convenience, and a malware scanner with no human in the loop — each one shows what happens when a system trusts its own assumptions too long. Here’s what changed since yesterday’s digest.
Vulnerability watch: a 13-year-old Linux kernel bug called OVSwrap hands root to any local user with no configuration required
Security researcher Asim Manizada disclosed CVE-2026-64531 (CVSS 7.8), codenamed OVSwrap, on July 28 — a memory corruption flaw in the Linux kernel’s Open vSwitch action parser that traces back to an unsafe length-field assignment introduced 13 years ago. A 16-bit nested-action length field wraps when the kernel builds an oversized action, and the parser resumes reading inside attacker-controlled bytes that get processed as legitimate OVS actions, corrupting kernel memory in a way that escalates a normal local account straight to root. The exploit needs nothing beyond that local account: no Open vSwitch configuration, no running ovs-vswitchd process, no OVS bridge, no CAP_NET_ADMIN, no privileged container. Researchers confirmed default-configuration exploitation across a striking range of distributions — AlmaLinux, Alpine, Amazon Linux 2023, Arch, CentOS Stream, Debian, Fedora, Kali, Linux Mint, NixOS, openSUSE Tumbleweed, Pop!_OS, Rocky Linux, and Ubuntu 22.04 among them — and a public proof-of-concept now ships with pre-built exploitation records for roughly 800 kernel builds. The Hacker News · Security Affairs · GitHub PoC
The scary part isn’t the CVSS score, it’s the “no configuration required” line — this fires on stock kernel builds whether or not anyone on the box ever touched Open vSwitch. If you run any of the affected distributions, patch to a kernel carrying the upstream fix (net: openvswitch: reject oversized nested action attrs) before you do anything else, and if patching has to wait, the one-line mitigation — echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf — blocks the module from loading with no reboot needed. Given how trivially it converts any local foothold (a compromised low-privilege service account, a malicious container escape, a rogue insider) into root, treat unpatched multi-tenant Linux hosts as a priority regardless of whether they’re “supposed” to use OVS.
Supply chain watch: 15 chained TP-Link Omada flaws let attackers hijack routers, spoof devices, and intercept camera feeds
Forescout’s Vedere Labs team disclosed 15 previously unknown vulnerabilities in TP-Link’s Omada zero-touch provisioning (ZTP) ecosystem at Black Hat USA on August 5 — the mechanism that lets Omada controllers, gateways, switches, access points, and OLT platforms auto-configure new devices without manual setup. Eleven of the 15 received CVE identifiers (TP-Link declined to assign CVEs to the remaining four, citing low severity), and the flaws span four impact categories: client-side code execution, information disclosure, device hijacking and spoofing, and compromise of encrypted communications. Chained together — and combined with two previously disclosed CVEs (CVE-2025-7850 and CVE-2025-7851) — the flaws let an attacker infiltrate a network through the ZTP flow itself, potentially reaching management credentials, VPN keys, and internal resources. The impact isn’t limited to networking gear: some of the flaws extend into TP-Link’s broader ecosystem, including VIGI IP cameras, smart-home IoT devices, and the mobile apps and cloud accounts that manage them, with researchers noting live video surveillance feeds could be intercepted. TP-Link worked with Forescout under coordinated disclosure and has shipped patches and mitigations in stages. BleepingComputer · Forescout · Help Net Security
Zero-touch provisioning exists precisely so nobody has to manually vet each new device joining the network — which is exactly why a flaw in the provisioning path itself is so effective: it targets the moment a device is supposed to be untrusted and unconfigured. If you or a customer runs Omada controllers, gateways, or VIGI cameras, confirm firmware is current across the whole fleet, not just the controller — ZTP flaws that chain through client devices mean a single unpatched access point or camera can be the entry point even if your core controller is up to date.
Operations watch: Google’s own malware-detection automation mass-locks hundreds of legitimate Blogger sites, no human review in the loop
Starting August 4, Google’s automated content-scanning system began flagging hundreds of legitimate Blogger sites under its “Malware and Similar Malicious Content” policy — locking blogs, hiding them from public view, and in some cases issuing deletion notices with an 89-day countdown, all without any indication the sites actually hosted malicious content. Affected publishers flooded Google’s official support forum, with the original thread drawing over 300 “I have the same question” votes and 100+ replies before a Google Product Expert confirmed it wasn’t a targeted crackdown but a large-scale false-positive misfire: “False positives do occur from time to time, but not on this scale.” Google’s internal team began rolling back incorrect flags and restoring access over the following two days, though some publishers continued to report residual lockouts as of August 6. Owners with a “this blog has been locked” banner can request review from the Blogger dashboard’s Info tab. BleepingComputer · ppc.land
This isn’t a vulnerability, but it’s a useful mirror to hold up to your own detection stack: an automated classifier ran with a deletion clock attached and no human checkpoint before irreversible action, at a scale where even a small false-positive rate produces hundreds of wrongly-flagged, real customers. If any of your own detections auto-remediate — disabling accounts, quarantining hosts, revoking access — audit whether there’s a human-reviewed step before anything destructive fires, and whether your false-positive rate has actually been measured recently rather than assumed low.
Final thought
A kernel bug nobody touched for 13 years, a provisioning flow built for convenience, a malware scanner with too much authority and no brake pedal — the common thread is systems that kept working right up until an assumption nobody re-checked stopped holding. Patch cadence, fleet-wide firmware hygiene, and human checkpoints on automated remediation are unglamorous, but they’re what catches an assumption before it becomes an incident. If you want help auditing where your own automation might be trusted a little further than it should be, see our how-to guides or book a discovery call.