A new Linux flaw that hands attackers root — pedit COW

root without touching disk, a suspicious ad blocker, and a 29-year-old hole in Squid. Welcome in Security Sunday

A new serious vulnerability has surfaced in the Linux kernel that allows privilege escalation to root. Tracked as CVE-2026–46331 and nicknamed “pedit COW,” it is an out-of-bounds write in act_pedit, which is part of the network traffic control subsystem (traffic control, tc).

The technical heart of the problem lies in the tcf_pedit_act() function. The tc tool can use the pedit action to rewrite packet headers, and the kernel is supposed to create a private copy of the data before modifying it — the classic copy-on-write (COW) pattern. However, the function validates the write range only once.

The exploit never touches a file on disk. Instead, it poisons a cached copy of a setuid root binary directly in memory, injects a short payload into it, and runs that payload with root privileges. File integrity checks return a clean result while the attacker already has a root shell running.

The range of affected systems is broad. The PoC author confirmed a path from an unprivileged user to root on RHEL 10 and Debian 13 (trixie), where unprivileged user namespaces are enabled by default.

According to distribution security trackers, as of 25 June the following were listed as vulnerable: Ubuntu versions from 18.04 through 26.04; Red Hat lists RHEL 8, 9, and 10 as affected; and Debian still marks versions 11 and 12 as vulnerable, while trixie has been patched (the linux package from version 6.12.94–1). Upstream, the bug had been present since kernel v5.18 and was fixed in mainline on 16 June 2026, with backports to the supported stable branches.

The recommended course of action is simple: deploy the patched kernel and reboot the system.

The same logic as pedit COW is shared by earlier flaws such as Dirty Pipe, Copy Fail, DirtyClone, and Dirty Frag.

Test your system before hackers do!

Every week we bring examples of attacks and vulnerabilities that can affect anyone. If you’re not sure whether your infrastructure is resilient, we’d be glad to help you find out. At SysNetShield we offer vulnerability scanning, penetration testing, Red Teaming, and phishing campaign simulations.

Get in touch — the first consultation or a vulnerability scan of a single domain/IP address is free.

A popular YouTube ad blocker hides a silent threat to millions of users

Security researchers at Island discovered that a popular Chrome extension called Adblock for YouTube contains a hidden ability to run arbitrary JavaScript on any visited page.

The extension (with the identifier cmedhionkhpnakcndndgjdbohmhepckk) has, according to the Chrome Web Store, over 10 million installs, a 4.4-star rating, and even carries the “Featured” badge that Google uses to mark vetted extensions. At the same time, researchers Oleg Zaytsev and Shachar Gritzman emphasize that they did not encounter any malicious code that had actually been delivered to users.

The core of the problem lies in the combination of broad permissions and weak controls. Although it is ostensibly an ad blocker exclusively for YouTube, the extension’s manifest declares the <all_urls> permission, so it actually runs on every page the user opens — from webmail through banking to corporate portals.

Technically, the mechanism works like this: every 24 hours the extension downloads a configuration from the remote server api.adblock-for-youtube.com. The response contains ordinary ad-blocking rules, but also a scripletsRules field through which the server decides which so-called scriptlets run and with what arguments. One of them, named trusted-create-element, can create a <script> element on the page whose content is supplied directly by the server. It then runs in the context of that page, with all of its data, sessions, and forms.

In their PoC, the researchers set up a controlled environment in which their fake server returned a scriptlet that first ran legitimately on YouTube and then opened a Salesforce address with the string “youtube.com” in the query parameter. The scriptlet injected itself into the logged-in Salesforce session, from which it read account data visible to the user and sent it back to the server.

For both individuals and companies, the takeaway is clear. It is worth reviewing your installed extensions (at chrome://extensions), keeping only the ones you actually use, and checking what permissions each extension has.

Squidbleed: a twenty-nine-year-old flaw in the Squid proxy, uncovered by artificial intelligence

A vulnerability has been found in the popular Squid web proxy server; it has been named Squidbleed and is officially tracked as CVE-2026–47729.

It is a so-called heap buffer over-read, which can cause the proxy to return to an attacker a chunk of memory belonging to a completely different user — typically fragments of their unencrypted HTTP requests, including login credentials, cookies, or session tokens.

The nickname references the famous Heartbleed, because the memory leaks in a very similar way. The flaw was disclosed in June by researchers at Calif[.]io, and according to their own write-up as well as a follow-up report, it had been present in Squid since 1997.

The cause is hidden in the parser that Squid uses to display directory listings from FTP servers. The code contains a loop that skips whitespace, which was created in 1997 to accommodate old NetWare servers that padded their listings with extra spaces.

What matters is to whom and under what circumstances the data leaks. Squid itself describes the attack as the action of a “trusted client” — that is, someone who is already allowed to use the proxy, not an arbitrary machine from the internet.

For the attack to work, several conditions must be met at once: the attacker must have access to the proxy, and the proxy must be able to reach an FTP server controlled by the attacker on port 21 (both FTP and port 21 are enabled in the default configuration). SUSE rates the flaw as medium severity, with a CVSS score of 6.5.

Calif[.]io credits the Claude Mythos Preview model, which found this flaw.

Cisco Catalyst SD-WAN: CVE-2026–20245 exploited before disclosure

Mandiant’s security team (part of Google Cloud) published an analysis of an attack in which an unknown actor exploited a vulnerability in the Cisco Catalyst SD-WAN platform as a zero-day for at least two months before it was publicly announced.

Cisco disclosed the vulnerability — tracked as CVE-2026–20245 with a CVSS score of 7.8 — in early June and released patches roughly a week later. It is already the seventh vulnerability in Cisco SD-WAN products whose exploitation has come to light this year.

We covered this vulnerability in one of the previous editions of Security Sunday; let’s take a look at how the attacker exploited it before it was disclosed.

The key step of the attack involved uploading a malicious file, evil_tenant.csv, using the command request tenant-upload tenant-list /home/admin/evil_tenant.csv vpn 0. This file contained a payload that escalated the attacker’s privileges and created a hidden account named troot with full root rights. From the compromised administrator account, the attacker then switched to the new troot account using the su command, gaining complete control over the device.

The attacker’s emphasis on covering their tracks also deserves attention. Mandiant reports that throughout the entire intrusion the actor used anti-forensic techniques: they backed up configuration files before modifying them, restored them to their original state once finished, deleted all the files they had created (including evil_tenant.csv), and finally ran a verification script to confirm that no traces were left behind.

According to Google, this is a continuation of the “living off the edge” trend, in which attackers deliberately target network devices at the perimeter. No specific group (APT) has yet been identified as being behind the attack.