WordPress Plugin Rest Routes Has an Unauthenticated SQL Injection
- The Mess: Rest Routes through version 5.5.5 contains CVE-2026-16061, an unauthenticated SQL injection flaw in a public REST endpoint. An attacker doesn’t need a WordPress account to reach the vulnerable code.
- The Damage: A vulnerable WordPress database can become readable or manipulable through a remotely supplied SQL query, potentially exposing site data and application secrets.
- The Fix: Update Rest Routes as soon as a patched release is available, or disable the plugin until a fixed version is released.
WordPress has another problem.
This time it isn’t a fake CAPTCHA.
It isn’t a malicious administrator account.
And it isn’t a plugin requiring a complicated chain of authenticated requests.
It’s a database injection bug sitting behind a public REST route.
The vulnerability is tracked as:
CVE-2026-16061
and affects Rest Routes through version 5.5.5.
No WordPress Account Required
That’s the part worth paying attention to.
The vulnerable endpoint is publicly accessible.
An attacker can send a crafted request without first logging into WordPress.
The plugin takes a value from the URL and uses it in a SQL query without adequate sanitization and validation.
That’s enough to create a classic SQL injection vulnerability.
The attack chain is brutally simple:
Internet
↓
public REST endpoint
↓
malicious table name
↓
SQL injection
↓
database
No administrator password required.
The Vulnerable Route
The affected functionality is associated with the plugin’s custom-table REST route:
custom-tables/tables/{table_name}
The {table_name} value is taken from the URL and reaches a database query without the necessary validation.
That’s the fundamental mistake.
User-controlled input should never be allowed to dictate the structure of a database query.
Yet that’s exactly what happens here.
CVSS 8.6
The vulnerability has been scored 8.6 High under CVSS v3.1 by vulnerability tracking sources.
The important characteristics are:
Network exploitable
Low complexity
No privileges required
No user interaction
SQL injection
That combination makes this considerably more interesting than an ordinary authenticated WordPress bug.
What Can SQL Injection Do Here?
SQL injection doesn’t automatically mean:
“instant server takeover.”
That’s not what we should claim.
The immediate problem is database manipulation.
Depending on the database permissions available to WordPress and the exact query context, an attacker may be able to:
read database information
extract sensitive records
modify stored data
or
use database access as a stepping stone toward further compromise.
The actual impact depends on the site’s database configuration and privileges.
But giving an unauthenticated Internet user a path into SQL queries is already bad enough.
WordPress Databases Contain More Than Posts
A typical WordPress database can contain:
user accounts
email addresses
configuration data
plugin settings
API credentials
session-related information
site content
and potentially data belonging to customers.
The database is the brain behind the application.
An attacker doesn’t necessarily need filesystem access if the database already contains something valuable.
Rest Routes Makes This More Interesting
The plugin exists specifically to create and expose REST routes.
That’s the irony.
REST APIs are useful because they make application data accessible programmatically.
But every public endpoint becomes another input boundary.
If that endpoint feeds unsanitized data into SQL, the API itself becomes the attack surface.
No Authentication Changes Everything
An authenticated SQL injection is already serious.
An unauthenticated one is much more attractive to attackers.
There is no need to:
find a WordPress username
brute-force a password
steal a session
or
trick an administrator.
The attacker can go straight for the vulnerable endpoint.
That makes automated scanning possible.
This Is Exactly How Mass Exploitation Starts
Attackers don’t need to know who owns a website.
They can scan for installations using the vulnerable plugin.
Find the relevant REST route.
Determine whether the target responds as expected.
Then attempt exploitation.
That’s how thousands of unrelated WordPress sites can suddenly become targets of the same campaign.
The attacker doesn’t care whether the site is:
a blog
an online shop
a company website
or
a site nobody visits.
The vulnerable software is what matters.
There Is No Public PoC Yet
This is an important distinction.
WPScan currently states that the proof of concept will be disclosed after the issue has been remediated.
So we’re not dealing with a publicly documented exploit that anyone can copy and paste today.
That gives administrators a small window.
Use it.
Once a working PoC becomes public, exploitation attempts can become much easier to automate.
The CVE Is Already Public
CVE-2026-16061 was published on August 29, 2026.
The CVE record describes the same underlying problem: Rest Routes through 5.5.5 fails to sanitize and validate input from a public REST route before placing it into an SQL query.
The GitHub Advisory Database also lists the vulnerability and references the WPScan advisory.
The disclosure clock is already running.
What About a Patch?
This is where the situation gets slightly annoying.
WPScan currently lists no known fix for the affected versions.
So administrators shouldn’t blindly assume:
“I’ll just update WordPress and everything is fine.”
WordPress itself isn’t the problem.
The vulnerable plugin is.
If there is no patched Rest Routes release available yet, the safer temporary option is to disable or remove the plugin if the site can operate without it.
Don’t Confuse the Plugin With WordPress Core
This is a plugin vulnerability.
There is no indication that WordPress core itself is vulnerable because of CVE-2026-16061.
That’s an important distinction.
The attack surface is the third-party plugin.
And that’s why plugin inventory matters so much.
How Many Sites Are Exposed?
The available vulnerability records do not provide a reliable current installation count that we can safely use as a headline number.
So we’re not going to invent one.
That’s better than repeating an old download figure and pretending it represents today’s vulnerable installations.
The important fact is simpler:
every exposed site running Rest Routes ≤ 5.5.5 is potentially vulnerable.
What Administrators Should Check
Start with the plugin version.
If the site is running:
5.5.5 or earlier
treat it as vulnerable.
Then determine whether Rest Routes is actually needed.
If it isn’t:
disable it.
If the site depends on it:
monitor for a patched release and restrict exposure where practical.
Check the Logs
Even though there is currently no public PoC, administrators should inspect access logs for suspicious requests involving the plugin’s REST endpoints.
Look for:
unexpected requests to custom-table routes
SQL metacharacters
unusual URL parameters
repeated requests from the same source
and
abnormal response sizes.
Don’t expect every attack attempt to leave an obvious fingerprint.
Attackers can probe quietly.
Database Monitoring Helps
If the site has database query logging or Web Application Firewall telemetry, this is a good time to review it.
Look for unexpected queries generated by requests hitting the Rest Routes endpoints.
A WAF can also provide another layer of protection while administrators wait for a proper fix.
But a WAF is not a replacement for patching.
Don’t Wait for the Headlines
The dangerous part of newly disclosed WordPress vulnerabilities is the time gap.
Today:
technical disclosure.
Tomorrow:
PoC.
Then:
scanners.
Then:
mass exploitation.
The timeline isn’t guaranteed.
But we’ve seen this pattern repeatedly.
The Attacker Doesn’t Need to Know Your Site
That’s what makes unauthenticated vulnerabilities so unpleasant.
An attacker doesn’t need reconnaissance about the company.
They don’t need an employee’s LinkedIn profile.
They don’t need to send phishing emails.
They can attack the application directly.
The vulnerable endpoint becomes the introduction.
Why This Fits Bugstoday
This is exactly the sort of WordPress security story worth tracking.
It’s:
new
specific
remotely exploitable
unauthenticated
and
database-facing.
And unlike another generic plugin XSS, this one has a clear attack primitive:
SQL injection.
The Next Step Is the PoC
The most important thing to watch now is whether a working exploit becomes public.
Once researchers publish a reliable PoC, defenders can reproduce the issue.
Attackers can do the same.
That’s when the risk calculation changes.
For now, the vulnerability is public, the affected versions are known, and the fix status remains the weak point.
Bugstoday Opinion
WordPress administrators have seen this movie before.
A vulnerability appears.
Everyone says they’ll patch it.
Someone publishes a PoC.
Bots start scanning.
Then somebody discovers that half the vulnerable sites were running a plugin nobody remembered installing.
CVE-2026-16061 is not a zero-day. It isn’t confirmed as actively exploited. And there is no public PoC yet.
But it’s an unauthenticated SQL injection in a public REST endpoint.
That’s enough reason to take it seriously.
Bugstoday verdict: Rest Routes has put another WordPress database behind an Internet-facing attack surface. Until a fixed version is available, don’t treat 5.5.5 and earlier as “probably fine.” If you don’t need the plugin, kill it. If you do, monitor it closely and be ready to patch the moment a proper fix lands.
