linefeed.sh — Luke Francis

Wonder Ad Blocker: Reverse Engineering a Malicious Chrome Extension

Sun, 26 Apr 2026 00:00:00 GMT

I was pirating a movie. I’m not going to pretend there’s a noble origin story here. I was on one of those sites, a popup appeared trying to get me to install a Chrome extension called “Ad Block Wonder,” and instead of closing it like a normal person, I thought: I wonder what this thing actually does.

It had 500k users. 4+ stars on the Chrome Web Store. The listing calls it “the successor to uBlock”, which is a wild claim to make about an extension distributed through piracy site popups, but sure. I pulled the source code and started reading.

I did not expect to spend the next several hours mapping out a six-platform ad intelligence scraping operation.

”Barely 2000 lines of code”

We’ll get to why that quote matters in a minute, but let’s start with what’s actually in this extension.

The first thing you notice is a directory called src/blocker/special/scripts/. Inside are six files: facebook.js, x.js, reddit.js, tiktok.js, pinterest.js, twitch.js. Each one is a dedicated scraping module for its respective platform. These aren’t blockers at all, they’re collectors. They hook into browser APIs to intercept API responses in real time and extract ad data from them.

facebook.js is 2,206 lines. Just that one file. For an extension that “barely” has 2,000 lines total. The full codebase across JS/CSS/JSON is over 1.7 million lines.

But I’m getting ahead of myself.

Your browsing history, on a schedule

Before we even get to the fun platform-specific stuff, let’s talk about what the extension does on every single page you visit.

A content script called broker.js runs on every URL, at document_start, in all frames. Every time you navigate to a top-level page, it logs the domain and increments a counter. Visit Reddit 47 times this week? It knows. These get stored as navDoms: a neat little dictionary of your browsing habits with frequency counts.

When you first install the extension, a function called installDataGathering() runs and snapshots every tab you currently have open. All those domains go into installDoms. So, from the moment of installation, the extension knows what you were doing.

Both of these — your ongoing browsing history and your install-time snapshot — get POSTed as plaintext JSON to the developer’s server. In v3.8 that was wonderadblock.com/wonder-3_7.php. In v4.1 it moved to wonderupdates.com/wonder-3_7.php. More on that domain switch later.

The payload also includes a persistent user ID (stored as wonderinformation — incredible variable name), your extension version, your personal allowlist, and as of v4.1, three shiny new tracking parameters: sid, cid, and an. Those are affiliate/campaign attribution tags scraped from the Chrome Web Store URL at install time. They tell the developer which ad network or shady popup drove your install, so they can pay their distribution partners accordingly.

No encryption on any of this by the way. The HTTP helper is a bare fetch() with Content-Type: application/json and JSON.stringify(body). Just plaintext JSON over HTTPS. They didn’t even try.

Facebook: 2,206 lines of “not a Facebook script”

facebook.js is where things get genuinely impressive, in a “wow, someone put real engineering effort into this grift” kind of way.

The file starts with hardcoded lookup tables for parsing personal data. Relationship statuses, like Single, In a Relationship, Married, Engaged, Civil Union, Domestic Partnership, Open Relationship, It’s Complicated, Separated, Divorced, Widowed. Education levels from “In high school” through “Doctorate degree.” These are for categorizing you.

The main event is WAIST scraping — WAIST being Facebook’s “Why Am I Seeing This” transparency feature. When you click that on an ad, Facebook shows you what targeting criteria the advertiser used to reach you. This extension scrapes all of it automatically for every ad it encounters. The targeting categories it extracts include:

Age and gender. Relationship status. Education level and schools. Employer and job title. Interests. Location. Locale. And the really fun ones — Custom Audiences from datafiles (advertiser-uploaded customer lists), Custom Audiences from website pixel tracking, Custom Audiences from mobile app activity, and Lookalike audiences. Over 30 targeting categories total.

There’s a whole ParseWAIST module that resolves Facebook’s internal Relay GraphQL fragments and packages the targeting data with the advertiser’s ID, name, and profile picture into a clean object. Someone sat down and reverse engineered Facebook’s internal ad transparency UI to build this. That’s not trivial work.

But it gets better. There’s a function called getAccessToken() (which, just by the way, incredible naming decision if you’re trying to claim this extension is innocent). It navigates to adsmanager.facebook.com/adsmanager/ inside your authenticated session, scrapes the __accessToken (a 100+ character Facebook Graph API token), the token’s expiry time, and your c_user cookie (your Facebook user ID). These get stored in an IndexedDB database named mooz.

The extension then uses your stolen token to make authenticated Graph API calls for advertiser fanpage data, like contact info, email, phone numbers, business hours, Instagram account, follower counts. This is happening silently in the background while you browse Facebook thinking your ads are being blocked. Whether it’s also sent to the developer’s server I can’t confirm from static analysis, but it’s being harvested and stored persistently either way.

And to make all of this work, the extension injects a declarativeNetRequest rule (ID 9999992, because of course it’s a magic number) that overrides Facebook’s own CORS security headers. It sets Access-Control-Allow-Credentials to true and Access-Control-Allow-Origin to facebook.com on all Facebook responses. Facebook’s security team put those headers there for a reason. This extension removes them.

The same pattern, five more times

The same hook-intercept-exfiltrate pattern repeats across X/Twitter, Reddit, TikTok, Pinterest, and Twitch. Each module hooks XMLHttpRequest or fetch prototypes to intercept API responses, filters for ad content, and extracts targeting and engagement data. The technique varies slightly per platform, but the structure is identical. Intercept the API response before the page sees it, extract the ad data, send it home. (Side note: the handler that would relay it to the server isn’t obviously wired up in these versions, but everything is there for it to do so.)

Twitch is worth calling out separately because it crosses a line the others don’t. The fetch hook captures your Authorization header, Client-Integrity token, Client-ID, and Device-ID from intercepted GQL requests, then uses those credentials to make its own authenticated requests on your behalf. It also overrides document.visibilityState and document.hidden, tricking the site into thinking you’re actively watching when you’re not. This is, pretty cleanly, credential harvesting.

The fake stats

My favorite detail. When you click the extension popup, it shows you stats about how much data the extension has “saved” you and how much faster your pages are loading. Confidence-inspiring numbers with units and everything.

They’re completely made up.

randomBetweenTwoNumbers(400, 600) for the timing. randomBetweenTwoNumbers(30, 60) for the kilobytes. Literally Math.random(). The stats in the popup are generated fresh every time you look at them with no relation to anything that actually happened. Pure theatre for user retention.

I genuinely respect the audacity.

The remote control

When the extension phones home, the server sends instructions back. The response can include:

wondercycle, which controls how often the extension phones home
rules, an array of declarativeNetRequest rules that gets applied via updateDnrRules(), which replaces all existing dynamic rules with whatever the server sends
whitelistedDomains and allowedDomains, domains that bypass all blocking entirely
scriptletExcludes, domains excluded from scriptlet injection

The developer has full remote control over what gets blocked and what doesn’t across 500k browsers. That rules array can include redirect rules, not just block/allow. The mechanism to silently redirect URLs through the extension is sitting right there.

The developer responds

I posted a review detailing the browsing history exfiltration and the existence of the platform scraping modules. The developer replied publicly:

I am genuinely speechless… I can only assume you’re mistaking my extension with another. There is no Facebook specific script… there is barely 2000 lines of code in the whole extension.

He then asked me to “be kind enough to correct your review.”

So I downloaded v4.1, the version he shipped after my review. I diffed it against v3.8.

facebook.js is byte-for-byte identical. Still 2,206 lines. Still imported at scripts.js:1. Still mapped to facebook.com in domains.js:2. Still scraping WAIST data. Still stealing Graph API tokens. The developer shipped a new version, replied publicly claiming the file doesn’t exist, and didn’t change a single byte of it.

What did change in v4.1:

The server endpoint moved from wonderadblock.com to wonderupdates.com.
Three new tracking parameters (sid, cid, an) were added to the exfiltration payload.
The new tracking keys were mirrored to Chrome sync storage so they persist across reinstalls.

So after being publicly called out for data collection, the developer: denied everything, moved the server to a new domain, and added more tracking. I’ll let you sit with that for a minute.

The product itself

None of this code is obfuscated. Every variable name is plaintext: getAccessToken, sendAd, wonderinformation, navDoms, installDoms. The developer didn’t webpack it, didn’t minify it, didn’t run it through any kind of transform. They just shipped human-readable JavaScript that steals your Facebook access token in a function called getAccessToken and apparently assumed nobody would ever open the files and look.

For 500k installs and months on the Chrome Web Store, they were right. The Web Store review process didn’t flag any of it. The extension has a 4+ star rating. It’s still live as of this writing.

But I think the interesting question isn’t “how did this get through review.” It’s “what is this thing actually for.”

This isn’t adware in the traditional sense. The developer isn’t injecting banner ads into your pages or swapping out affiliate links. This is an ad intelligence platform. Someone is building a cross-platform dataset of ad creatives, targeting parameters, engagement metrics, and advertiser contact information — harvested from real user sessions on Facebook, X, Reddit, TikTok, Pinterest, and Twitch. Layered on top is per-user browsing history with visit frequency, tied to a persistent ID, with affiliate attribution tracking to map the install funnel.

That’s a product. Ad intelligence platforms, at least the legitimate ones, charge thousands per month for this kind of data. Who’s running ad campaigns on Facebook targeting women aged 25–34 in Dallas who work at Deloitte and are interested in yoga? What creative are they using? How much engagement is it getting? What’s the advertiser’s contact info? Normally you’d need to pay a SaaS company a lot of money for those answers. Or you could just contact “Ad Block Wonder” and let half a million people’s browsers collect it for you for free.

The browsing history adds a behavioral layer on top, because now you don’t solely have ad targeting data, you have it correlated with browsing patterns. The affiliate tracking adds a distribution layer — you know exactly which shady popup networks are driving installs, so you can scale the ones that work. The remote-controlled whitelist adds a second revenue stream, as ad networks can pay to get un-blocked across 500k browsers with no user visibility. The server-pushed DNR rules add a third: arbitrary redirect capability across every URL those 500k users visit.

This is the full stack of a shadow ad intelligence business, distributed through piracy site popups and disguised as an ad blocker. The only thing I can’t tell you from the code alone is who’s buying the data on the other end.

The extension is still live on the Chrome Web Store as of this writing. I’ve reported it to Google and the affected platforms’ security teams. If you have it installed, remove it.

48 Hours on a SCADA Honeypot

Mon, 06 Apr 2026 00:00:00 GMT

What happens when you disguise a Hetzner VPS as a small-town water treatment plant and point it at the internet? 47,771 events, eight attack campaigns, and a nine-year-old piece of North Korean malware. In two days.

The setup

On a Friday night in April 2026, I deployed a high-interaction honeypot on a Hetzner Cloud server in Ashburn, Virginia, themed as the internet-facing SCADA gateway for a fictional municipal water utility called Cedar Creek Municipal Water Authority.

The goal wasn’t groundbreaking research. I just wanted to watch attackers do their thing.

The infrastructure was built on T-Pot, Deutsche Telekom’s open-source honeypot platform, running 39 Docker containers across about 20 different honeypot services. The box emulated SSH, Telnet, HTTP/HTTPS, SMB, SMTP, SIP, Modbus, S7comm, SNMP, IEC 60870-5-104, BACnet, IPMI, and a handful of others, all on a single IP address.

The ICS theming was the fun part. Conpot was configured to respond to SNMP queries with Siemens, SIMATIC, S7-300, a common PLC found in water treatment plants. Cowrie’s fake SSH filesystem was populated with directories like /opt/schneider/ and /var/log/scada/, a .bash_history full of modpoll commands, and an MOTD referencing NIST 800-82.

On top of T-Pot, I built a custom employee portal on port 9443: a Cedar Creek MWA login page styled to look like a dated ASP.NET intranet running on IIS 8.5. It served a robots.txt that “accidentally” exposed internal paths like /admin/, /scada/, /vpn/, and /owa/. The unprotected directories contained an Active Directory LDIF export with employee usernames, and a Swagger API doc with a dev key in the comments. The protected directories (behind basic auth that accepted the same AD credentials — password reuse as the vulnerability) contained IT meeting minutes, PLC commissioning notes, a disaster recovery plan, and a VPN config file. Credentials were buried inside boring operational documents, not sitting in files labeled passwords.txt. The whole thing was designed as a realistic attack chain: find the portal, discover usernames from the AD export, find passwords through credential reuse, log in, explore the fake intranet.

Nobody found the portal credential chain in 48 hours. The bots had other priorities.

The first hour

Within minutes of going live, the traffic started. By the end of the first hour, the dashboard showed 33 attacks. Cowrie was catching SSH banner grabs: 0.2-second connections from scanners probing port 22 and immediately disconnecting. The SSH client string was SSH-2.0-libssh-0.2, a lightweight library commonly used by automated scanners. No humans yet, just bots mapping what was listening on the Hetzner IP range.

Port 445 (SMB) was the most-hit port in the first hour. That turned out to be a preview of something much more interesting.

By the time I went to sleep at 3 AM, roughly two hours after deployment, the event count was at 8,500. The username and password tag clouds in Kibana told a story: alongside the expected root/admin and root/123456 attempts, there were clusters of Solana-specific credentials. solana/solana, sol/sol, solnode/solnode, helius/helius, firedancer/firedancer, raydium/raydium. Someone was running a credential list specifically targeting Solana validator nodes on Hetzner infrastructure.

Campaign 1: mdrfckr

The first full intrusion sessions appeared within a few hours. Every single one followed an identical playbook: strip immutable flags from .ssh with chattr -ia, nuke and recreate the .ssh directory, plant a single authorized key with the comment mdrfckr, check CPU info and core count, change the root password with chpasswd, kill competing malware processes, blank out hosts.deny, then run a full hardware survey (CPU model, RAM, disk, architecture via uname, lscpu, free, and df). Every session, same order, same commands.

The SSH key comment says it all: mdrfckr. This is the Outlaw botnet (also known as Dita), a well-documented cryptomining operation linked to Romanian cybercriminals. The same SSH public key was first observed on VirusTotal on July 5, 2018. Eight years later, it’s still being planted on compromised servers.

I captured 155 intrusion sessions from this botnet across the 48-hour window, originating from 10+ unique IPs across the United States, France, Hungary, China, and the Seychelles. Every session used the same SSH key, the same command sequence, and a unique randomly-generated password for each compromised host.

The playbook breaks down like this:

Remove immutable flags from .ssh (chattr -ia). Undoes any file protection a previous administrator set.
Nuke and replace SSH keys. Deletes all existing authorized keys and plants their own, locking out the legitimate owner and any other attacker who previously planted keys.
Change the root password to a random string. Each session uses a different password (K3LZwFN3e1vq, PLpL9jEf2t3p, DoEizj7TZjn7, etc.). This prevents other botnets using the same leaked credential list from getting back in.
Kill competing malware. pkill -9 secure.sh; pkill -9 auth.sh terminates common persistence scripts used by rival botnets.
Blank hosts.deny. Removes IP-based access controls.
Full hardware recon. CPU model, core count, RAM, disk space, architecture. This determines whether the box is worth deploying a miner on and which binary to use.

The competing-malware-kill step is worth noting. The threat model for this botnet isn’t the system administrator discovering the compromise. It’s another botnet stealing the compute. Every compromised server is contested territory, and the first attacker to change the locks wins. The playbook dedicates more steps to locking out other botnets than to evading detection.

A previous researcher documented this botnet in October 2022, finding 12,913 unique IPs across 152 countries over a two-month period. In 2022, the botnet used SSH-2.0-libssh-0.6.3. My honeypot observed SSH-2.0-libssh_0.11.1. They’ve upgraded the SSH library while keeping the exact same SSH key and command sequence for eight years.

Campaign 2: Solana validator hunters

The second-most-active campaign was specifically targeting Solana blockchain validator nodes. Hetzner has historically hosted a large fraction of Solana’s validator infrastructure, to the point where Solana’s geographic concentration on Hetzner was considered a decentralization risk for the network.

The credential pairs tell the story: solana/solana (141 attempts), sol/sol (129), solv/solv (115), sol/123 (95), solv/123456 (95), sol/solana (70), solana/sol (64), solv/12345678 (63), node/node (45), solana/solana123 (44).

The usernames aren’t random. solana, sol, solv, and node are common naming conventions for Solana validator operators. helius (a Solana RPC provider) and firedancer (Jump Crypto’s validator client) also appeared in the credential lists.

Every successful Solana-targeting session ran exactly one command: /bin/./uname -s -v -n -r -m. The unusual /bin/./ path prefix (using a redundant ./) is likely an evasion technique against simple command logging that watches for /bin/uname or just uname. All sessions came from IP ranges in Bulgaria (195.178.110.x, Techoff Srv Limited), the Netherlands (2.57.122.x), and a separate cluster (92.118.39.x).

The objective here is straightforward: Solana validators hold keypair files on disk that control staked tokens. A typical validator might have hundreds of thousands of dollars in staked SOL. SSH access to a validator node means access to the keypairs, which means draining the stake.

Campaign 3: WannaCry, still going

This was the surprise.

Dionaea, the malware-capturing honeypot on port 445 (SMB), collected 16 binary samples over 48 hours. Every single one was 5,267,459 bytes, a PE32 DLL compiled for x86 Windows. The compile timestamp in the PE header: May 11, 2017.

Strings analysis turned up the kill switch URL:

http://www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwff.com

WannaCry. Nine years old and still propagating.

For anyone unfamiliar: this is the ransomware attributed to North Korea’s Lazarus Group that tore through the world in May 2017, spreading via EternalBlue (MS17-010), an SMB exploit developed by the NSA and leaked by the Shadow Brokers. It’s a worm, so it self-propagates without human interaction. Marcus Hutchins famously halted the ransomware payload by registering the kill switch domain above on May 12, 2017. The domain is still registered, but now it redirects through affiliate links to… Kohl’s department store. Every zombie machine checking the kill switch is generating impressions for someone’s retail affiliate account.

The infected machines hitting my honeypot are almost certainly IoT devices, embedded systems, or neglected servers that were compromised in 2017 and have been scanning the internet continuously ever since. Nobody has cleaned them. They just keep going.

Campaign 4: PHPUnit remote code execution

Tanner, the web application honeypot, logged 789 requests probing 589 unique URL paths. The dominant pattern was systematic scanning for eval-stdin.php, a known vulnerability in PHPUnit (CVE-2017-9841) that allows remote code execution. The scanner tried every common web application directory as a prefix to the same path (/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php): laravel/, yii/, zend/, cms/, api/, demo/, crm/, admin/, blog/, public/, tests/, and dozens more. Automated webshell planting. Find the vulnerable endpoint, upload a PHP shell, establish persistence.

Campaign 5: Android Debug Bridge

ADBHoney captured an attempt to compromise the server via Android Debug Bridge (port 5555). The command created a hidden directory in /data/local/tmp and tried four different download methods in sequence (wget, busybox wget, curl, toybox wget) to pull an ARM7 binary called parm7 from a remote server at 196.251.107.133. The fallback chain exists because IoT devices running Android have inconsistent tooling installed. The binary name indicates it’s compiled for ARMv7, the most common architecture in Android phones, tablets, IP cameras, and smart TVs. IoT botnet recruitment.

What didn’t happen

No one discovered the employee portal’s credential chain. The Cedar Creek MWA login page was visited by scanners and indexed by Censys, but no attacker attempted to log in with credentials harvested from the AD export in /owa/. The multi-stage attack chain went completely untested. This isn’t surprising for a 48-hour window dominated by automated botnets. Targeted human attackers operating on ICS-specific intelligence would need more time to discover and investigate the portal.

No attacker interacted with the SCADA theming in Cowrie’s SSH either. The fake filesystem with Schneider Electric directories, Modbus register maps, and SCADA event logs went unexplored. Every successful Cowrie session ran the same automated recon scripts. None of the attackers typed ls and looked around at what kind of system they’d compromised. The mdrfckr botnet treats every compromised server identically regardless of what’s on it.

So what

The main thing I took away from this is how deeply impersonal internet-facing attacks are. 47,771 events and not one of them was about Cedar Creek Municipal Water Authority. Nobody cared that this was themed as a water plant. Nobody explored the SCADA directories. The bots don’t read. They sweep the Hetzner IP range (and the rest of the IPv4 space) with automated tools, and my server happened to be on a routable address.

The other thing that stuck with me is how old everything is. WannaCry is from 2017 and still propagating. The mdrfckr SSH key has been active since 2018. CVE-2017-9841 is being scanned for in 2026. The internet is full of stuff that just keeps running because nobody has bothered to turn it off, attacking other stuff that just keeps running because nobody has bothered to patch it. It’s less of a war zone and more of an abandoned parking lot where someone left a bunch of Roombas on.

The whole project cost about $3.50 in Hetzner compute. Fun times.

CVE-2026-6994: Envoy Query Parameter Injection via header_mutation

Thu, 02 Apr 2026 00:00:00 GMT

Summary

The header_mutation filter’s query_parameter_mutations feature inserts values from formatters (e.g. %REQ(header)%) into query strings without URL encoding. The encoding helper (PercentEncoding::urlEncode()) exists in the codebase, but this code path doesn’t call it.

Example

An attacker sets a header containing URL metacharacters:

X-Inject: alice&admin=true&sql=1'OR'1'='1

Envoy copies the header value verbatim into the upstream request’s query string:

/api?user=alice&admin=true&sql=1'OR'1'='1

Root cause

params.add() at header_mutation.cc:22 and toString() at utility.cc:1156 output raw values. Other Envoy filters (OAuth2, gRPC transcoder) correctly use urlEncode() for the same operation — this filter just didn’t.

Impact

CVSS: 6.3
Arbitrary query-parameter injection
Authorization bypass when upstream services trust query parameters
Enables SQLi / XSS / parameter smuggling against upstream services
Affects: v1.33.0+

Discovery

Code review of Envoy’s header_mutation filter and query_parameter_mutations path. Confirmed end-to-end against a running Envoy instance.

Status

Fixed in PR #43502. CVE assigned.

CVE-2026-31360: Traefik SPIFFE Trust Domain Bypass

Wed, 18 Mar 2026 00:00:00 GMT

Summary

Traefik’s verifyServerCertMatchesURI overwrites the expected SPIFFE URI’s host with the certificate’s actual host before comparison, defeating trust-domain validation entirely. Any valid certificate from a shared CA pool passes validation regardless of which trust domain issued it.

Secondary finding

While verifying impact in real deployments, I also discovered that Consul Connect was generating SPIFFE URIs without trust domains. That makes trust-domain isolation non-functional for the entire Consul Connect user base, independently of the Traefik bug.

Discovery

Code review of Traefik’s mTLS implementation and SPIFFE URI parsing. The relevant function constructs the comparison target by mutating the expected URI in place.

Impact

CVSS: 8.2 (High)
Cross-trust-domain service impersonation in zero-trust architectures using SPIRE or Consul Connect.

Status

Patched. CVE assigned by MITRE.

CVE-2026-31361: Traefik ACME Private Key Exposure via Logs

Wed, 18 Mar 2026 00:00:00 GMT

Summary

When the ACME private key fails to parse, GetPrivateKey() (account.go:60-61) logs the entire DER-encoded key as a slice of decimal bytes via the %+v format string:

Cannot unmarshal private key [48 130 9 ...]

The key material flows to stdout, log files, and any connected log aggregator (Splunk, ELK, CloudWatch, Datadog).

Why it matters

This converts narrow file-storage access (acme.json, 0600 permissions, single host) into broad exposure across logging infrastructure that ops teams routinely access and that retains data for years.

History

A partial fix existed in v1.7.20 (truncating to 16 bytes) but was never ported forward to v2.x or v3.x. Five years of regression.

Discovery

Code review of Traefik’s ACME certificate-storage error-handling paths.

Status

Patched. CVE assigned by MITRE.

CVE-2026-33413: etcd Authorization Bypass Across Multiple APIs

Wed, 04 Mar 2026 00:00:00 GMT

Summary

Several etcd APIs did not consult the auth middleware before serving requests. Unauthorized callers could:

enumerate cluster topology via MemberList
trigger or clear alarms (operational disruption)
interact with the Lease APIs, interfering with TTL-based keys
initiate compaction, permanently removing historical revisions

Discovery

Systematic review of etcd’s auth middleware and gRPC API layer. Cross-referenced every gRPC method against the set of methods that go through authorization, and looked at the gaps.

Impact

CVSS: 8.8
An unauthenticated attacker with network reach to the etcd port can exfiltrate cluster topology and disrupt the cluster.

Note on Kubernetes

Kubernetes is not affected. The Kubernetes API server performs authorization itself and does not rely on etcd’s built-in auth.

Status

Patched in etcd 3.6.9, 3.5.28, 3.4.42. Credited in the SIG-etcd security release.

CVE-2026-33343: etcd Nested Transactions Bypass RBAC

Wed, 04 Mar 2026 00:00:00 GMT

Summary

etcd evaluates transactions recursively. When a transaction’s body contains nested transactions, the inner operations were not re-checked against the caller’s RBAC permissions. An authenticated user with restricted key-range permissions could use a nested transaction to read or modify keys outside their permitted range — the entire data store, in practice.

Discovery

Code review of etcd’s transaction evaluator while looking at the auth surface. The outer call enforced authorization on the keys it touched; inner operations executed under the parent’s authorization context without re-checking.

Impact

CVSS: 6.5
Any authenticated user with any key-range permission can escape the range constraint.

Note on Kubernetes

As with CVE-2026-33413, Kubernetes is not affected — the API server enforces authorization above etcd.

Status

Patched in etcd 3.6.9, 3.5.28, 3.4.42. Credited in the SIG-etcd security release.