Security disclosure: CSRF vulnerability in the WP Umbrella plugin, fixed in 2.27.0

August 10, 2026

We build WP Umbrella in public, and that includes the days when the news is about us. Today we’re disclosing a security vulnerability that affected the WP Umbrella WordPress plugin from version 2.24.2 through 2.26.2. It is fixed in version 2.27.0, released today, and we are rolling the update out automatically to all connected sites.

Here is exactly what happened, what we did about it, and what we found when we went looking for signs of abuse.

TL;DR

• A CSRF vulnerability in the WP Umbrella plugin (versions 2.24.2 to 2.26.2) could allow WordPress REST actions to run without a valid security nonce. Exploitation required specific conditions: an administrator, already logged into their WordPress site, had to be lured into visiting a malicious page. No remote attack without interaction, no direct access for a stranger.
• We audited 32.4 million events for signs of exploitation. Every candidate event was traced back to legitimate activity. We found zero evidence that this vulnerability was ever exploited.
• Version 2.27.0 shipped today with the fix, and an automatic update campaign is pushing it to all connected sites.
• What was not affected: no data stored at WP Umbrella, no credentials, no backups. The flaw was on the WordPress side of the site, not in our infrastructure.
• The vulnerability was reported to Patchstack by an external security researcher on August 4. Independently, our own internal security audit found the same bug on August 8 and fixed it the same day. By the time the report reached us, the fix was already written and tested.
• What you need to do: confirm your sites run plugin version 2.27.0 or later. For most of you, the automatic update has already handled it.

What the vulnerability was

The WP Umbrella plugin registers its own routes on the WordPress REST API. To let our platform talk to your site, the plugin relaxes WordPress’s cookie-nonce check, but only, in theory, for our own routes.

The bug: the check that decided “is this one of our routes?” looked for the string /wp-json/wp-umbrella/ anywhere in the request URL, including the query string, instead of checking the route WordPress had actually resolved. That meant a request to a core WordPress endpoint (say, the endpoint that creates users) could smuggle our namespace into a throwaway query parameter and have the nonce check waived.

WordPress nonces exist precisely to stop cross-site request forgery. With the check waived, an attacker could craft a malicious link or page that, if visited by an administrator while logged into their WordPress site, would silently execute REST actions in that administrator’s session. The canonical payload creates a new administrator account.

Important scoping:

• The attack requires an active, logged-in administrator session and a successful CSRF lure. It cannot be executed remotely against an idle site.
• No WP Umbrella API keys, tokens, or platform credentials were involved or exposed.
• Patchstack rated the vulnerability Medium severity, CVSS 5.4.

Timeline

Date	What happened
May 21, 2026	Vulnerable code ships in plugin version 2.24.2
August 4, 2026	An external researcher reports the vulnerability to Patchstack
August 8, 2026	Our own internal whitebox security audit independently finds the same bug, reproduces it end to end in a lab, and fixes it the same day
August 10, 2026	Version 2.27.0 is published with the fix. Automatic update campaign launched across all connected sites. Coordinated disclosure with Patchstack
August 10, 2026	Fleet-wide exploitation audit completed

Two things in that timeline matter to us.

First, the researcher found it before we did, by four days, and they get full credit for the discovery. That is how coordinated disclosure should work, and we’re grateful to them and to Patchstack.

Second, we didn’t fix this because someone made us. Our own proactive audit of the plugin surfaced the bug independently, and the fix was written, tested against a working exploit in a lab, and queued for release before the external report ever reached us. When it did reach us, our answer was “already fixed, shipping now.”

Was it exploited?

This was our first question too, and we didn’t want to answer it with a shrug. So we went hunting.

We ran a fleet-wide audit against our data: 32,473,743 events across 5,581 sites, covering June 21 through August 10. We searched for the specific fingerprint this attack would leave: critical account and configuration changes arriving through the REST channel, where legitimate admin activity arrives through wp-admin.

That search returned 35 candidate events across 16 sites. We investigated every single one, individually. Every one traced back to legitimate activity: support-access workflows initiated by the site owners themselves, role demotions (the opposite of an attack), routine side effects of plugin updates, and capability registrations during plugin activations.

Based on these results, no credential rotation or account revocation is required.

What you should do

1. Check your plugin version. Every site should be on WP Umbrella plugin 2.27.0 or later. If your sites are connected to the platform, the automatic update campaign is handling this for you. Most sites are already patched.

That’s it. No password resets, no API key rotation, no support ticket needed.

Credit

Our thanks to the external researcher who reported this vulnerability through Patchstack’s managed disclosure program, and to Patchstack for coordinating the disclosure. Independent researchers make the whole WordPress ecosystem safer, ours included.

If you have questions about this disclosure, write to us at support@wp-umbrella.com. A human will answer.