WP Umbrella Security Add-on: Stop Exploits Before You Can Update

In 2025, Patchstack found 11,334 new vulnerabilities across the WordPress ecosystem, a 42% increase over 2024. The subset that should actually worry you grew far faster: vulnerabilities classified as highly exploitable increased 113% year over year.

Nearly all of that risk lives in the plugin stack. 91% of the new vulnerabilities were in plugins and 9% in themes; WordPress core accounted for just 6, all low priority. Core is not your problem. The plugins your clients rely on, and don’t always let you update on time, are.

The WP Umbrella Security Add-on, formerly Site Protect, exists for exactly that gap. It blocks known exploits at the application level while the vulnerable plugin or theme is still unpatched, so you update on your schedule instead of the attacker’s.

Whether you’re evaluating it for the first time or you subscribed back when it was called Site Protect, this guide covers what the add-on is today: three components, what’s included free on every account, and how to enable it across a portfolio. More than 10,000 sites already run with it enabled.

How fast are WordPress vulnerabilities exploited?

Faster than most update workflows can move. Patchstack’s State of WordPress Security in 2026 report, published in February 2026, measured the gap between a vulnerability going public and its first observed exploitation. Two findings frame the problem.

First, the patch gap: 46% of vulnerabilities disclosed in 2025 had not received a patch by the time of disclosure. For nearly half of new flaws, “just update” is not an available instruction on day one. There is nothing to update to.

Second, the speed. Among heavily exploited vulnerabilities, the weighted median time to first exploit was 5 hours. That figure describes the most heavily targeted flaws, not every disclosure. But those are precisely the ones that arrive as automated campaigns against every reachable site.

The full disclosure-to-exploitation curve, measured on the top-targeted vulnerabilities published in 2025 (a subset accounting for roughly 95% of observed exploitation activity):

• 20% were first exploited within 6 hours
• 37% within 12 hours
• 45% within 24 hours
• 58% within 72 hours
• 70% within 7 days

Consistent with that curve, the same report found that approximately half of high-impact vulnerabilities get exploited within 24 hours. Patchstack’s conclusion is blunt: the first 24 hours are critical when a new exploitable vulnerability is published.

Now hold that against how agencies actually work. Nobody patches an entire portfolio within 5 hours of every disclosure. Updates wait for testing, staging, and client approval, and that caution is correct: it’s what keeps care plans from breaking sites. The cost is an open exploit window. Closing that window without rushing your updates is the Security add-on’s job.

How does the Security add-on block exploits before you update?

Through virtual patching, powered by Patchstack. Where malware scanning asks “did something bad already get in?”, virtual patching asks the better question: “can we stop the attempt at the door?” For the concept in depth, read our explainer on what virtual patching is in WordPress.

The mechanics: when Patchstack confirms a new vulnerability, a rule targeting that specific exploit pattern is deployed to protected sites through its threat feed. The rule runs at the PHP level, before WordPress fully loads, and rejects requests matching the attack. No plugin code is modified, and nothing waits on the plugin’s vendor. The vulnerability still exists, technically. The exploit never lands.

Say a form plugin ships a SQL injection flaw tied to one parameter. The firewall applies a rule that blocks manipulation of that exact parameter and nothing else. Legitimate traffic passes untouched. Because rules target confirmed vulnerabilities instead of guessing at suspicious-looking traffic, the false positives that plague broad firewalls (broken contact forms, blocked checkouts) are rare by design.

You can also see it working. The firewall’s insights view shows attacks blocked, the top attacking IPs, and the rules firing most often across your sites. The firewall never waits for you to read an alert before blocking; that part is automatic. But the evidence is there whenever you, or a client, wants to see it.

Earlier versions of this product were deliberately hands-off: nothing to configure, nothing to tune. That is still the default experience. Enabling the add-on turns everything on with recommended defaults. The difference today is control: every piece can be adjusted per site, which matters when one client runs a locked-down brochure site and another needs stricter or looser rules.

What all of this buys you is time. When the next high-severity disclosure hits a plugin you manage, protected sites are covered while you test the update properly and ship it deliberately.

One scope note: these rules cover known, confirmed vulnerabilities and common attack vectors. What that does and does not mean for zero-days is covered further down.

What’s included in the Security add-on?

Three components, enabled together.

1. Firewall & Virtual Patching (Patchstack). The blocking layer described above, with the insights view showing attacks blocked, top IPs, and top rules. The firewall rules also cover common abuse patterns beyond confirmed vulnerabilities, such as comment posting through proxies.

2. Security Hardening. Per-site toggles that shrink the attack surface at the application and .htaccess level: disable the theme and file editors, hide WordPress version information from bots, block user enumeration, restrict XML-RPC to authenticated users, block access to debug.log, disable directory listing, and set security response headers.

The header set has evolved with the standards. It centers on current protections like X-Frame-Options against clickjacking and Content-Security-Policy. Older examples like X-XSS-Protection are out: MDN marks it deprecated and warns it can itself create XSS vulnerabilities in otherwise safe sites.

Hardening is also where fleet scale shows. Apply the recommended defaults everywhere in a few clicks, then loosen or tighten individual toggles on the sites that need it, instead of hand-editing .htaccess files across every install.

3. Security-Driven Activity Log. The detection layer, watching the sites themselves for attack behavior: brute-force login attempts, mass content deletion, privilege escalation, unusual sign-in locations, file integrity changes, and changes to critical settings. It is distinct from the platform Activity Log, which records what happens inside WP Umbrella and is included on every account.

Each detection carries its forensics. Suppose a sign-in lands from an unusual location: the log shows the account involved, the IP address, and a timeline of what that session touched. Within minutes you know whether it was your client working from a holiday rental or someone who should not be there, and exactly what to inspect if it’s the latter.

Every WP Umbrella account also ships with a security baseline at no extra cost, alongside the platform’s broader WordPress security features. Here is how the product splits:

Included with every account	Security add-on
Vulnerability monitoring (Patchstack checks every 6 hours)	Firewall & virtual patching, with the insights view
One-click fixing updates	Security hardening toggles, bulk and per site
Site Health with dismissible warnings	Security-Driven Activity Log with forensics
Platform Activity Log	Malware scanner
Uptime, PHP error, and performance monitoring

Which component stops which attack?

No single layer covers everything, which is why the three ship together. Here is the map from the threats you actually see to the component that handles them:

Threat	What stops it
Exploit attempt against a known plugin or theme vulnerability	Firewall & Virtual Patching
Attack on a disclosed flaw that has no patch yet	Firewall & Virtual Patching (rules deploy independently of the vendor’s fix)
Bots fingerprinting your WordPress version or enumerating usernames	Security Hardening
Clickjacking or script injection via missing response headers	Security Hardening (security headers)
Brute-force login campaigns	Security-Driven Activity Log detection, with Hardening shrinking the target
A compromised account deleting content or escalating privileges	Security-Driven Activity Log forensics

Read it as three lines of defense: prevention at the front, a smaller attack surface in the middle, detection behind everything.

What the Security add-on is NOT

Honest scoping saves support tickets later. Three boundaries worth knowing before you enable it.

It is not a substitute for updates. Virtual patching blocks the exploit, not the flaw. The vulnerable code stays on the site until you update. What changes is the tempo: you update deliberately, on your maintenance schedule, instead of scrambling the night a disclosure drops.

It is not blanket zero-day immunity. Rules cover confirmed vulnerabilities and common attack vectors. A flaw nobody has discovered yet has no rule. Hardening shrinks the surface such a flaw could reach, but no security product can honestly promise immunity to the unknown, and we won’t.

It is not a DNS-level or CDN firewall. It works at the application level, inside each WordPress site’s request cycle. If your traffic already passes through an edge firewall or CDN, the two operate at different layers and complement each other rather than conflict.

How do you enable the Security add-on?

Three steps, a few minutes.

Step 1: Have a paid WP Umbrella plan

The Security add-on runs on top of a paid per-site subscription; it is not a standalone product. If you’re not on a paid plan yet, start there (see WP Umbrella pricing). Every account, add-on or not, already includes the free security baseline described above.

Step 2: Turn it on, in bulk or per site

Enable it in bulk from the main dashboard or the security bulk view, or site by site from the Security tab. Enabling turns on all three components with recommended defaults, and every piece can be adjusted per site afterwards.

The price is 2€ / $2 per site per month, on top of your per-site subscription. For the return-on-investment math across a whole portfolio, read WP Umbrella Security Add-on Pricing Explained.

Step 3: Let it run, and show your clients

From activation, virtual patching rules apply and update in real time from Patchstack’s threat feed, hardening defaults take effect, and the activity log starts watching. There is nothing you must configure, only things you may.

Your white-label client reports also include security sections, so the protection you provide shows up in the document your clients actually read. That turns an invisible layer into a line item your care plans can charge for.