Avada Builder is a WordPress plugin people use to drag and drop pretty pages onto their sites. This week researchers disclosed two flaws in it that let unauthenticated attackers read arbitrary files and pull data straight out of the database. There are roughly one million active installs. That is a million potential credential vending machines, and the cybersecurity fallout from this kind of bug rarely stays on the site where it started.

Stolen credentials don’t sit in a folder. They move. They get packaged, sold, and reused by stealer malware operators who have spent the last two years industrializing the harvest. While that’s happening, a handful of platform vendors have finally figured out that secure defaults are a control. The contrast across this week’s news is sharp enough to be useful.

The plugin layer is where your credentials actually leak

The Avada Builder vulnerabilities are exactly the kind of thing that should not exist in 2026. Arbitrary file read on a public endpoint. Database extraction with no authentication required. The plugin ships inside the Avada theme ecosystem, which has appeared on roughly a million WordPress sites over the years.

WordPress plugins are the soft underbelly of the public internet. A plugin author with one bad sanitizer can punch a hole in a million tenants at once. Patching depends on a patchwork of site owners who may not even know what plugins they have installed, let alone whether the auto-update toggle is flipped. Site owners get scolded for this every time. The structural problem sits with vendor-side discipline around input validation and authorization, plus a hosting ecosystem that doesn’t consistently enforce updates.

The data that comes out of these bugs is exactly what feeds the next stage of the attack chain. wp-config.php contains database credentials. The database contains hashed user passwords (often with weak hashing on older sites), plus API tokens, plus session data, plus customer PII. A file-read flaw on a public-facing CMS frequently amounts to a free initial access pass for whoever scrapes the disclosure feed first.

Once they’re stolen, they go through something like Gremlin

Unit 42 published an updated analysis this week of Gremlin Stealer, and the trajectory tells you everything you need to know about where harvested credentials end up. The latest variant has added crypto clipping (silently swapping wallet addresses in copied text), session hijacking (lifting active browser tokens to bypass MFA), and resource-file obfuscation that buries payloads inside what look like normal compiled binary assets.

This isn’t amateur hour. Stealer authors are building the feature set you’d expect from a mature SaaS product. Telemetry, modular plugins, customer support channels on Telegram. The economics work because the supply of credentials never stops. Plugin bugs feed it. Phishing feeds it. Malvertising feeds it. Compromised package registries feed it.

Once a stealer pulls a credential off an endpoint, that credential typically gets:

• Validated against common services to confirm it actually works
• Tagged with metadata such as employer, geography, MFA status, and account value
• Posted to a Telegram or Discord broker channel within minutes
• Resold to ransomware affiliates, initial access brokers, and BEC crews
• Used to log into things you forgot you owned, often months later

The point: your incident response window starts the moment any single endpoint in your environment touches a stealer, including an employee laptop that hit a personal site on the weekend. The lag between infection and exploitation is collapsing fast.

Defaults are doing more cybersecurity work than your SOC

In the middle of this mess, Google quietly shipped something that should have existed a decade ago. Google Workspace Context-Aware Access now supports default policy assignment for SAML applications. Translation: if an admin forgets to assign a CAA policy to a third-party SSO app, a baseline still applies.

This is a small change that matters more than it sounds. Organizations get owned through SSO when someone adds a new app, forgets to apply the policy, and the app sits in the tenant for nine months without device-trust or IP-restriction enforcement. Default deny works. Default policy works. Optional policy mostly lets humans forget.

Compare the two postures across this week’s stories. Avada ships with no validation on a public endpoint. Stealer operators harvest the result. Google adds a default that catches the most common admin mistake. One vendor leaks credentials. Another vendor reduces what an attacker can do with them. Defenders living in the middle don’t get to pick whether their plugin authors and their identity providers are competent. They do get to pick how they respond when one of them isn’t.

This is also where defense in depth stops being a slogan and starts being a budget line. The plugin layer will keep leaking. The stealer ecosystem will keep buying. The only reliable countermove is to assume both and make every layer above them harder to walk through.

What to actually do this week

Concrete steps, vendor-neutral, useful even if you’ve never touched any of the products named above. None of this is exotic. Most of it is overdue security hardening.

Patch Avada Builder now if you have it, and audit every plugin on every WordPress instance you own. If you can’t enumerate your plugins, that itself is the finding. Strip anything you haven’t actively used in the last 90 days, then turn on auto-updates with a staging gate.

Rotate WordPress secrets. Database credentials, salt keys, and any API tokens that touched a vulnerable site should be considered public. File-read bugs leak wp-config.php and similar files. Treat them like they already did.

Move WordPress admin behind an authenticated path. Block /wp-admin and /wp-login.php at the edge for any IP that isn’t on an allowlist or behind your VPN. A simple firewall rule deflects opportunistic brute-force traffic and pre-authenticated exploit scanners in one move.

Treat stealer infections as identity incidents. Wipe the device, sure. But also revoke every active session the user held, rotate every saved credential the browser had stored, and step-up reauth across the user’s accounts. The endpoint cleanup is the easy part. Threat detection without identity cleanup is just paperwork.

Inventory your SAML apps. For each one, confirm there’s an explicit access policy applied. If your IdP supports default policy assignment, turn it on. Then walk the app list and audit anything created by a now-departed employee. SSO orphans are a recurring access path.

Watch egress. Stealer infections show up clearly when someone reads the logs: short bursts of HTTPS POSTs to fresh domains, Telegram or Discord API traffic from non-developer endpoints, DNS lookups to dynamic DNS providers. Pipe that into your threat detection stack and tune it for stealer C2 patterns specifically.

The week’s news is a tidy little flowchart of how breaches happen now. A plugin vendor leaves a door open. A stealer ecosystem fences what comes through. A platform vendor finally raises the floor on defaults. You can’t fix the first. You can’t shut down the second. You can absolutely raise your own floor before next week’s plugin disclosure does it for you.

Sources

• Avada Builder WordPress plugin flaws allow site credential theft
• Gremlin Stealer’s Evolved Tactics: Hiding in Plain Sight With Resource Files
• Google lets Workspace admins apply one policy across all SAML apps