Five critical flaws disclosed across four WordPress plugins and the Avada theme give unauthenticated attackers conditional paths to administrator access or server-side code execution. Fixes are now public for WPMU DEV Dashboard, Avada and Fusion Builder, TranslatePress, Pods, and GiveWP.
The strangest failures sit inside controls that appear protective. WPMU DEV Dashboard signs an SSO message that another endpoint accepts under a different interpretation. GiveWP’s “safe” unserialize helper preserves an attacker-controlled object long enough for a later read to restore it. The researchers demonstrated both paths, but none of the five primary reports says attackers have exploited these flaws in the wild.
Five fixes landed together
All five fixes are public.
The affected releases, prerequisites, and outcomes differ enough that “update WordPress” is too broad to be useful. Operators need to identify each extension and its state:
| Product | Affected release | Required condition | Demonstrated outcome | First fixed release |
|---|---|---|---|---|
| WPMU DEV Dashboard | 5.0.1 and earlier | Site connected to WPMU DEV; Hub SSO enabled and mapped to an administrator | Administrator session; site takeover | 5.0.2 |
| Avada and Fusion Builder | Avada 7.16 and earlier; Fusion Builder 3.16 and earlier | Both active, plus specific administrator-authored content | Arbitrary PHP execution as the web-server user | Avada 7.16.1 and Fusion Builder 3.16.1 |
| TranslatePress | 3.3.1 and earlier | Automatic string saving; targeted administrator uses a published secondary language | Password-reset link disclosure; administrator takeover | 3.3.2 |
| Pods | 3.3.9 and earlier | Public AJAX router reaches the JSON meta-box-loader compatibility path | Administrator methods, including password replacement | 3.3.9.1, with fixes for five older branches |
| GiveWP | 4.16.7.1 and earlier | Reachability varies by release, form type, site history, and active gateway | PHP object injection chained to operating-system command execution | 4.16.7.2 |
Wordfence’s WPMU DEV report and its reports on Avada, TranslatePress, and Pods document coordinated fixes. Patchstack’s GiveWP analysis says version 4.16.7.2 breaks the reported chain at several independent points.
Wordfence and Patchstack sell firewall or mitigation services for the products they evaluated. Their reports remain the primary technical records here, and their commercial protections should be treated as supplemental controls alongside the vendor fixes.
Trust checks fail differently
Each exploit crosses a different trust boundary before reaching a privileged outcome.
WPMU DEV Dashboard exposes two unauthenticated Hub SSO actions. The first signs a delimiter-free sequence containing a token, state, redirect, and domain. The second verifies a delimiter-free sequence containing the token, state, and redirect. By requesting an empty redirect and then moving the returned domain into the second redirect field, an attacker presents the same bytes under a different logical layout. As Wordfence put it, “The attacker does not need to know the WPMU DEV API key. Step 1 acts as a signing oracle.”
TranslatePress creates a different data-flow error. When automatic string saving is enabled, a password-reset email for an administrator using a secondary-language profile can enter a translation dictionary. The public trp_get_translations_regular AJAX action returns attacker-selected dictionary rows, including the plaintext reset URL. An attacker who knows the administrator’s username or email can trigger a reset, retrieve the key, and set a new password.
Pods fails after its checks run. Its public pods_admin router sends allowlist, nonce, login, and capability failures through pods_error(). In one compatibility path, that function writes to the PHP error log and returns instead of terminating the request, so dispatch continues to administrator methods.
Avada is a six-part chain rather than one failed check. Wordfence says unauthenticated input reaches a privileged maintenance operation whose authorization and file constraints allow attacker-controlled PHP to be written and executed. The researchers withheld the additional exploit detail, but report that they produced a working end-to-end proof of concept.
Figure details
A five-row comparison matrix separates WPMU DEV Dashboard, Avada with Fusion Builder, TranslatePress, Pods, and GiveWP. The columns show the required site state, the failed trust boundary, the demonstrated outcome, and the first fixed release or supported backport. It does not depict one shared exploit chain, and it notes that the primary sources do not report exploitation in the wild.
GiveWP preserves the payload
GiveWP carries the deepest published mechanism.
Versions through 4.16.7.1 pass serialized input to a helper that calls PHP’s unserialize() with classes disabled. That option converts an object to __PHP_Incomplete_Class; it does not erase the original class name or properties. When GiveWP serializes the placeholder into wp_give_sessions, PHP writes the attacker-controlled object bytes back out.
A later session read unserializes those bytes without the same restriction. GiveWP ships TCPDF and test-data classes that form a gadget chain ending at call_user_func_array(). Patchstack says an attacker can point that call at system() and run a command as the web-server user.
The chain also obtains its own account. The give_action=user_register handler creates a user without consulting WordPress’s users_can_register setting. The attacker can then place a serialized object in profile metadata, submit a donation that stores it, and trigger execution with another front-end request. The donation request that poisons the session returns HTTP 500, giving defenders a useful event to correlate with account creation and later front-end access.
GiveWP 4.16.6 narrowed some paths but did not fix the object injection. Its recursive check returned the original serialized string, which preserved the payload for the next read. Version 4.16.7.2 instead rejects serialized names, restricts read sinks, validates the gadget provider, sanitizes metadata, and migrates stored objects out of the affected tables. Patchstack notes that the registration-policy bypass remains, although it no longer leads to the reported code-execution chain after the object-injection fix.
Scope depends on site state
Deployment counts are directional.
The sources cite about 350,000 WPMU DEV Dashboard installations, more than one million Avada sales, more than 400,000 TranslatePress installations, more than 100,000 Pods installations, and 100,000 GiveWP installations. Those figures cannot be added into a vulnerable-site total: sales differ from active installations, multiple components can share one site, and every demonstrated path has prerequisites.
The limiting conditions matter during triage. A WPMU DEV site without mapped Hub SSO is outside the reported path. TranslatePress does not persist the reset link when the administrator uses the site’s default language. Avada needs Fusion Builder and qualifying content. GiveWP 4.16.6 through 4.16.7.1 is narrower than older releases, but an older, imported, restored, draft, or trashed form can restore reachability.
Pods may already be patched through a WordPress.org forced update. Verify it anyway. The current fixed line is 3.3.9.1, and the vendor also backported fixes to 3.2.8.3, 3.1.4.2, 3.0.10.4, 2.9.19.4, and 2.8.23.4.
None of the primary reports describes exploitation in the wild. That is an evidence boundary, not a reason to leave a reachable unauthenticated path open.
Inventory every affected branch
Start with the installed versions. On hosts managed with WP-CLI, run the checks that match the components you deploy:
wp plugin get wpmudev-updates --field=version
wp theme get Avada --field=version
wp plugin get fusion-builder --field=version
wp plugin get translatepress-multilingual --field=version
wp plugin get pods --field=version
wp plugin get give --field=versionUpgrade WPMU DEV Dashboard to 5.0.2 or later, both Avada and Fusion Builder to 7.16.1 and 3.16.1 or later, TranslatePress to 3.3.2 or later, and GiveWP to 4.16.7.2 or later. For Pods, use 3.3.9.1 or the fixed release for the older branch you intentionally maintain. If WPMU DEV Dashboard cannot be updated immediately, disable Hub SSO until 5.0.2 is installed.
Then review recognition signals before declaring the exposure closed:
- Web access logs for unusual requests to
/wp-admin/admin-ajax.phpcarryingwdpsso_step1,wdpsso_step2,trp_get_translations_regular, orpods_admin. - WordPress audit records for unexpected password resets, new administrator accounts, unfamiliar administrator sessions, or plugin and theme changes.
- PHP and web logs for a GiveWP donation request returning HTTP 500 followed by front-end requests from the same session or source.
- Filesystem monitoring for newly written PHP files under locations writable by the web-server account.
The verification test has two parts. The version commands must report only the fixed releases listed above, and review from the disclosure date forward must find no unexplained administrator, password-reset, extension-installation, or executable-file event associated with the affected request paths. The expected result is a patched inventory and an evidence-backed account of any matching activity; an unexplained match moves the host into incident response.