Incident TRIGGER

What happened, in one paragraph

On 27 July 2026 at 06:22 EDT, an attacker created a full administrator account on a client WordPress site by sending crafted requests to the site's REST API. The parameter that normally excludes an author from a post listing was passed into the database query without being forced to an integer, which let the attacker append their own SQL. Nothing was uploaded. No plugin was installed. No file on the server changed. Four minutes later our daily database scan noticed an account that should not exist, and the incident was contained, root-caused and closed across all 33 WordPress installations the same morning.

Timeline

The attack chain

The database error log is the whole story. This is the query that failed, lightly trimmed:

SELECT SQL_CALC_FOUND_ROWS wp_posts.*
FROM wp_posts
WHERE 1=1
  AND wp_posts.post_author NOT IN (1)
  AND 1=0 UNION ALL SELECT 0,1,0x323032302d...,'trigger','publish','closed'
  OR wp_posts.post_status = 'private')))
LIMIT 0, 500

Read it left to right. post_author NOT IN (1) is WordPress excluding an author from a listing, which is a normal thing for a REST request to ask for. Everything after it is the attacker's. AND 1=0 makes the site's real results vanish, and UNION ALL SELECT substitutes a row of their own choosing.

Decoding the long hexadecimal literal in that row gives the payload:

[embed width="500" height="750"]https://<site>/cookie-policy/#6aaccb1[/embed]

That is an oEmbed shortcode. When WordPress renders a post containing one, the server fetches the target URL itself. The fragment #6aaccb1 is the attacker's own marker, and it matches the account they created in the same second, wp2_6aaccb. The synthetic post was the vehicle; the account was the goal.

GET /wp-json/wp/v2/posts?author_exclude[]=1)

400  {"code":"rest_invalid_param",
      "message":"Invalid parameter(s): author_exclude",
      "details":{"author_exclude[0] is not of type integer."}}

Why the firewall missed it

This is the part worth the reader's time, because the failure was not negligence. The site had a SQL injection firewall installed at the Apache level, and its rules were correct. Among them:

RewriteCond %{QUERY_STRING}   ...union\s+(?:all\s+)?select...
RewriteCond %{HTTP_REFERER}   ...union\s+(?:all\s+)?select...
RewriteCond %{HTTP_USER_AGENT} ...union\s+(?:all\s+)?select...

The pattern that describes this exact attack was present and would have matched the payload character for character. It never got the chance.

The general lesson is not "our rules were wrong." It is that a control has a coverage surface as well as a ruleset, and the two are audited separately. Before trusting any firewall, enumerate the channels it can actually see, then ask whether the attack surface you care about travels on one of them. A pattern list is reassuring and easy to review. A coverage gap is silent.

Why file scanning could never find it

A search for everything modified on that server in the previous 24 hours returned page caches and log files, and nothing else. No shell, no altered plugin, no injected theme file.

The attack lived entirely in a request and a database. This is the counterpart to the more familiar WordPress compromise where the answer is always a file: here there is no file to find, no signature to write, and no checksum to fail. A scanner that only walks the filesystem will report a compromised site as clean, truthfully and uselessly.

How it was detected

A scheduled job runs every morning across every WordPress installation and flags accounts whose email address ends in .invalid or whose username matches known automated-creation prefixes. It found exactly one:

ROGUE ADMINS: 1
    wp2_6aaccb   wp2_6aaccb@wp2shell.invalid   2026-07-27 10:22:25

Two details made the alert immediately actionable rather than merely alarming. It named the affected site, and it carried the account's creation timestamp, which is what let us find the matching second in a 32 MB error log instead of reading the whole thing.

What we changed

Two layers, deployed to all 33 installations the same morning.

1. A request guard that can read the body

A must-use plugin hooks rest_pre_dispatch, which runs before any REST route executes. It walks the query parameters, the POST body, the JSON body and the URL parameters, and does two things:

• Type-enforces integer parameters. author_exclude, author__not_in, post__in, include, exclude, parent, page, per_page and their relatives must be integers or the request is refused. This closes the specific hole regardless of which plugin owns the route.
• Blocks SQL syntax in any other parameter, logging the route, the offending parameter and the source address.

2. The Apache ruleset everywhere

Eight installations had no firewall block at all. They have it now. Coverage of both layers is 33 of 33.

Check your own site

Three checks, in the order that finds an answer fastest.

Look for manufactured accounts

SELECT ID, user_login, user_email, user_registered
FROM wp_users
WHERE user_email LIKE '%.invalid'
   OR user_login REGEXP '^(wp2_|wpsvc_|w2s_|Nx_|Bunk_)';

Look for the injection in your error log

grep -a "UNION ALL SELECT" error_log | head
grep -a "class-wp-rest-server.php" error_log | tail -50

A database syntax error and a new account sharing a timestamp is the signature.

Confirm your parameters are typed

curl -s -o /dev/null -w "%{http_code}\n" \
  "https://example.com/wp-json/wp/v2/posts?per_page=1&author_exclude[]=1)"

400 is correct. 200 or 500 means the parameter reached the query without being validated, and the route deserves a closer look.

Follow-up: five hours later

The guard went live at roughly 06:30. By 07:30 the same morning it had blocked a distributed campaign against four different client sites from four different addresses, using a technique the original attack did not.

requests.1.body.requests.1.path

And a false positive of our own

The same logs showed 182 blocks in a single second against one site’s /elementor/v1/globals/typography/* routes. That was not an attack. It was a person opening the page editor, which fetches every global style in parallel.

The cause was ours: the guard type-enforced any parameter named id as an integer, and Elementor’s global IDs are strings such as primary and e8d3680. A generic key name is a poor place to enforce a type. The specific WordPress query parameters keep their integer check, because their contract genuinely requires one; id does not and was removed.

The shape of the data was the tell: 182 hits, one second, one address, one route family. Attacks rarely look that tidy. A person clicking does.

Lessons worth keeping

• Audit a firewall's coverage surface, not just its rules. The correct rule was installed and never saw the traffic. Ask which channels the control can read before trusting what it blocks.
• Scan the database, not only the filesystem. An attack that writes no file is invisible to every file-based scanner, and this one wrote nothing.
• Type-check parameters at the boundary. WordPress core does this correctly; the gap appeared where a plugin did not. If a value should be an integer, refuse everything else before it reaches a query.
• Test a blocker in both directions. A control that only proves it blocks attacks has proved half of what matters. Include deliberate false-positive traps.
• Give alerts a timestamp. The creation time is what turned a 32 MB log into one readable second.
• Removing the symptom is not closing the door. Two rogue accounts had been removed from this site the previous day. Without finding the entry point, the third arrived on schedule.

Indicators of compromise

Written up the same day, from the actual logs, by the team that responded to it. If you run WordPress and want the two checks in section eight run against your own estate, write to sales@appwt.com.