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
The WAF that proves it's safe to block.
DBshieldX sits behind your nginx, inspects every request in about 3 ms and checks the SQL your app sends. Every route starts in monitor mode, so you switch on blocking with evidence, not hope.
- Added latency, p95
- 3.2 ms
- Production sites
- 16
- Policy rollback
- < 7 s
Measured on live traffic, Oct–Nov 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
How it works
Two checkpoints: one for every request, one for every query.
DBshieldX adds a small proxy behind the nginx you already run. Nothing changes in your app. If DBshieldX is ever slow or down, traffic goes straight through to your app.
- 1
Visitor
People, bots and scanners
- 2
Your nginx or CDN
TLS and caching, as today
- 3 · DBshieldX proxy
Request check
9 attack classes, bots and behaviour, scored in about 3 ms. Repeat attackers banned through CrowdSec.
- 4
Your app
Unchanged
- 5 · DBshieldX SQL check
Query check
Learns your app's query shapes and flags any it has never seen.
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.
Coverage
Rules you can read, for the attacks that actually arrive.
Detection decodes common disguises (URL, base64, shell tricks, path encodings) before it scores. 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_circleExtra weight for stacked queries, delays and system-catalog reads
check_circleWorks from live statements or a recorded PostgreSQL session log
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.
Results
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.
See it on your own traffic.
We'll set up DBshieldX in monitor mode on one of your sites and walk you through what it finds after a week. Nothing is blocked until you say so.