Urgent: WordPress core flaw CVE-2026-119977 is being exploited
An unauthenticated code execution flaw in WordPress core upgrades is under active attack. Here is who is affected and what to do today.
Self-hosted web application firewall
Stop the attacks already hitting your site, without blocking your real customers.
In one week, 159 attacking clients hit our 16 production sites, and 93% of them weren't on any shared blocklist. DBshieldX shows you what's hitting yours, proves which pages are safe to block, and undoes any change in seconds.
- Attacking clients in one week
- 159
- Not on any blocklist
- 93%
- Added latency, p95
- 3.2 ms
Our own production sites, 7 days to 7 November 2026; latency October 2026. How we measure
shop.example.com · policy v5 Illustration
POST /checkout
7 days in monitor · review queue settled
POST /login
Blocking · credential-stuffing rule on
POST /webhooks/payments
Pinned to monitor · partner traffic
Review queue
SQL injection · field: q · GET /search
Attack Expected
Switch POST /checkout to block Roll back to v4
Fits the stack you already run nginxDocker · systemdCrowdSecAuthelia 2FAMaxMind GeoLite2Webhooks · n8n
Sound familiar?
bug_report
“Our logs are full of probes for .env, wp-login and SQL injection.”
Why it keeps happening
Automated scanners ask every site the same questions, and new ones appear faster than blocklists can list them. Of the 159 attacking clients on our own sites in one week, 93% weren't on any shared blocklist.
toggle_off
“We have a firewall, but it only logs. Last time we switched blocking on, it stopped real customers.”
Why it keeps happening
Most firewalls give you two settings, off and on, with no safe path between them. So blocking stays off, and the attacks get through.
storage
“If someone got into our database, we'd find out from a customer.”
Why it keeps happening
Request rules guess from the outside what a value will do once it reaches your code. Nothing is watching the queries that actually reach your data.
What it costs to leave it
A data breach
If customer data is exposed, you may have to report it to the ICO within 72 hours and tell the people affected.
A firewall nobody trusts
One wrong block costs orders and goodwill. Then blocking gets switched off and stays off.
Lost client confidence
For an agency, one compromised client site puts the whole relationship at risk.
What changes
Today
With DBshieldX
close TodayYou see attacks in the logs after they have happened.
check With DBshieldXYou see what would be blocked, page by page, before you block anything.
close TodayBlocking is all or nothing, so it stays off.
check With DBshieldXEach page switches to blocking once it has 7 days of clean evidence behind it.
close TodayA wrong block means an outage while you work out why.
check With DBshieldXAny change rolls back in under 7 seconds, with no restart.
close TodayBlocklists only stop attackers someone has already reported.
check With DBshieldXRequests are judged on what they contain and how the client behaves, and repeat attackers are banned on all your servers.
close TodayNothing watches what reaches the database.
check With DBshieldXAny query your app has never sent before is flagged.
close TodayYour traffic goes through someone else's network.
check With DBshieldXEverything runs on your own servers.
Who it's for
How it works
DBshieldX adds a small proxy behind the nginx you already run, checks every request in about 3 ms, and checks the SQL your app sends. Nothing changes in your app, and if DBshieldX is ever slow or down, traffic goes straight through.
Monitor first. Block one route at a time. Undo in seconds.
visibility
01 · Monitor
See what it would block
Every route starts in monitor mode. DBshieldX logs what it would have stopped and never touches real visitors.
rule
02 · Review
Decide in one click
Mark each group of findings as an attack or expected traffic. Expected traffic becomes a precise exclusion for that rule, field and route.
block
03 · Block
Switch on with evidence
A route can block once it has run 7 days with its queue settled. You get an alert on its first block, and any block later marked expected counts as a false positive.
history
04 · Roll back
Every change is a version
Activate any earlier policy version and every proxy picks it up in under 7 seconds, with no restart.
What it stops
Rules you can read, for the attacks that actually arrive.
Each finding names its rule and the field it was found in, so you always know why something was flagged.
storage
SQL injection
Unions, stacked queries, blind and time-based
code
Cross-site scripting
Script, event-handler and URL vectors
terminal
Command injection
Including shell evasion tricks
folder_open
Path traversal
Encoded, doubled and Unicode forms
dns
Server-side request forgery
Internal and cloud-metadata addresses
data_object
Template injection
Common server template engines
schema
NoSQL and LDAP injection
Operator and filter abuse
smart_toy
Bad bots and scanners
Tool fingerprints and probe paths
password
Abusive behaviour
Credential stuffing, enumeration, error bursts
DBshieldX protects the application and database layers. Keep your CDN for volumetric DDoS; the two work together.
The DB in DBshieldX
A second line of defence where your data lives.
Your app sends the same few shapes of query thousands of times a day. DBshieldX learns those shapes with the values removed. An injection changes the shape, so a query it has never seen stands out, even when the request looked harmless at the front door.
check_circleLearns per app, from normal use
check_circleNever stores the values in your queries
Learned shape
select id, title from todos where owner_id = ? and title like ?
Incoming query, new shape
select id, title from todos where owner_id = ? and title like ? [injected clause]
Unseen shapeFlagged
Illustration; the injected clause is elided.
Proof
We run DBshieldX on our own sites first.
158k
requests a week inspected across 16 sites on 4 servers
159 / 159
clients block mode would have stopped in a week were scanners or fuzzers
93%
of those attackers were on no CrowdSec blocklist
0
false-positive blocks on our first blocking route in its first 7.8 days
7 days to 7 November 2026, from DBshieldX's own event records. Latency: p95 added by the proxy on live traffic, October 2026. How we measure
Security & privacy
Your traffic stays on your servers.
Self-hosted
The proxy, engine and dashboard run on your own machines. No request is sent to us.
Detail only when you opt in
By default, events record the rule, route and score, not the payload. Turn on evidence excerpts per tenant, with secrets masked and every view logged.
Retention you set
Detail is kept 30 days by default (7 to 90). Client IDs are hashed with a salt per tenant.
Tenants kept apart
Every customer sees only their own sites, keys and data. Dashboard sign-in uses two-factor single sign-on.
Fails open
If the engine is slow or stopped, requests go through and the error is logged. Your site stays up.
Protected by DBshieldX
Our own production sites run behind DBshieldX. Report a vulnerability to security@dbshieldx.com, or read our disclosure policy.
Pricing
Start free in monitor mode. Pay when you block.
Plans from £29 a month (ex VAT), from a free Monitor plan for one site to an Agency plan with a separate tenant for each client. Tell us how many sites and servers you have and we'll send a quote.
Compare plansFrom the blog
Why a WAF should check your SQL, not just your HTTP requests
Request rules see what arrives at your site. A query check sees what reaches your database. How learning your app's query shapes adds a second line of defence.
Why your site gets .env and wp-login probes, and what to do about them
Automated scanners ask every website for config files and WordPress login pages, whatever it runs. Why it happens, and the simple steps that make it harmless.
FAQ
Not by surprise. Every route starts in monitor mode, you review what it would block, and you switch routes to blocking one at a time. Any change can be rolled back in seconds, and DBshieldX fails open if it has a problem.
No. It protects the application and database layers and works behind your CDN and nginx.
Blocking decisions come from rules you can read and from your app's own learned query shapes. A machine-learning scorer is in evaluation and only observes for now.
Nowhere outside your servers. The proxy, engine and dashboard run on your own machines. If we install or manage DBshieldX for you, we handle data only on your instructions, under a data processing agreement.
Run the containers, then point your site's nginx upstream at the DBshieldX proxy, keeping your app as a backup line. We walk you through it on the demo call.
Your site stays up. If the engine is slow or stopped, requests go straight through to your app and the error is logged.
Find out what's hitting your site, free.
We'll run DBshieldX in monitor mode on one of your sites for a week, free, then walk you through what it would have blocked and which pages are safe to protect. Nothing is blocked until you say so.