Five WordPress plugin and theme flaws let attackers take the site or the whole server

Two of these reach the server. Three own the site.

Sort the five by blast radius and they split cleanly. GiveWP (CVE-2026-82222, CVSS 10.0) and Avada (CVE-2026-18431, CVSS 9.8) both end in code running on the machine that hosts the site. GiveWP gets there through PHP object injection, Avada by writing a file of the attacker's choosing into a location the web server will execute. Once either fires, the attacker is a process on your host, not a user in your dashboard.

The other three stay inside WordPress, which is still a full takeover. WPMU DEV Dashboard (CVE-2026-76581) lets an unauthenticated request map to an administrator on sites wired to the Hub single sign-on. Pods (CVE-2026-19598) escalates a nobody to administrator. TranslatePress (CVE-2026-19632) leaks the plaintext key from an administrator password-reset link, which is admin access by another door. Bad, but recoverable by cleaning WordPress. The GiveWP and Avada pair is not: after code runs on the host, the site database is the least of your problems.

GiveWP is authenticated in name only

The reporting splits on one point worth resolving, because it changes how you triage. One account describes GiveWP's bug as needing a logged-in user; another calls it unauthenticated. Both are describing the same flaw. GiveWP ships a registration action that creates an account without checking whether the site even allows registration, so an attacker can mint the account they need and then trip the object-injection path. Treat it as unauthenticated. Turning off open registration in WordPress settings does not close it, and any triage that files this under "needs a login first" is under-rating a CVSS 10.0.

The root cause is a pattern worth naming for its own sake. GiveWP wrapped PHP's unserialize in a helper meant to make it safe, then fed that helper attacker-controlled data from the donation flow, and a gadget chain in a library the plugin bundles finished the job. A homegrown allowlist around unserialize is not a mitigation. If your own code leans on one, this is the week to stop assuming it holds.

The plugin layer is a steady pipe into hosting

This is not a one-off pileup. The same class keeps arriving here: unauthenticated code execution in Forminator, Elementor Pro's file-upload flaw, a Branda account takeover that came back after a patch, and hidden admin webshells planted through BdThemes plugins. The third-party plugin and theme surface, not WordPress core, is the reliable way onto the host, and the cadence is not slowing.

The window between disclosure and mass scanning is short, and GiveWP's own history proves it. According to Pi-hole's 2025 disclosure, the same donation plugin was involved in a breach that exposed roughly 30,000 donor records. A plugin with more than 100,000 installs and a fresh CVSS 10.0 is a scanning target the moment the advisory is public. No public exploitation was reported for these five at disclosure, which is the state today, not a guarantee about next week.

Update the five, then hunt for what a scanner missed

Patch first, in blast-radius order. GiveWP is fixed in 4.16.7.2; anything at 4.16.7.1 or earlier is exposed. Update Avada past 7.16 with its Fusion Builder component, WPMU DEV Dashboard past 5.0.1, TranslatePress past 3.3.1, and Pods past 3.3.9, to the current release for each. If you run any of these across a fleet of client sites, that is today's work, not this sprint's.

Then accept that patching is a race you can lose, and add the control that does not depend on winning it. For the two server-reaching flaws, the durable detection is on the host, not in the plugin: a new PHP file appearing in an uploads directory, a web-worker process spawning a shell, an outbound connection from a box that should only serve pages. That is the gap between a plugin scanner, which needs a signature for a CVE it has never seen, and watching the host filesystem and process activity, which flags the webshell drop whether or not anyone has named the bug yet. On shared or panel-managed hosting the stakes compound, because one tenant's vulnerable plugin can become the first step toward root on the whole box.

Assume the next batch looks like this one: a handful of high-install add-ons, all unauthenticated, one or two of them quietly reaching the server. Patch velocity buys you a day. Host-level detection is what covers the day you were too slow.