Video summary

Wordpress Situation is Absolutely Insane

Main summary

Key takeaways

Technology

Summary of technological concepts / vulnerability chain

The video breaks down two major vulnerabilities in WordPress that chain together to achieve RCE (remote code execution), demonstrating that the exploit can be fast and reliable against certain WordPress versions.

1) Pre-check + fast exploit demonstration (RCE via web shell)

  • The process begins with a scan/check to see whether a vulnerable REST batch v1 endpoint is active.
  • It performs an HTTP check that returns error code 207, indicating the site is vulnerable.
  • It then triggers an interactive shell by:
    • triggering the exploit
    • uploading a web shell
    • gaining command execution as an unprivileged user (priv-esc is discussed later).

2) Which WordPress versions are vulnerable

  • The vulnerability exists only in a specific range of versions.
  • The speaker claims it’s not vulnerable when running versions before 6.8.5.
  • It is also stated that WordPress 7.0.2 (updated) is not vulnerable.
  • Emphasis: default WordPress features are affected (not only third-party plugins).

3) Bug #1: Route confusion in REST API batch v1 (enables unauthorized “get”-like dispatch)

  • The core issue is an unauthenticated REST API “batch” v1 endpoint that allows batching multiple REST requests (up to 25).
  • The batch endpoint is designed for POST sub-requests (not GET).
  • Vulnerability detail (route mismatch / index misalignment):
    • The handler builds two parallel arrays (e.g., matches and validation) and indexes them inconsistently.
    • If URL parsing fails (path fails DEP parse URL), the path is appended to validation but not matches.
    • This creates an out-of-order index mismatch, leading to route confusion: a sub-request is dispatched under the wrong handler/path.
  • Fix described:
    • on parse error, the request is appended to both arrays, keeping indexes aligned.
  • Outcome:
    • attackers can use the batch handler to dispatch behavior effectively equivalent to a GET request, despite the endpoint being intended for POST only.

4) Bug #2: Blind SQL injection via WordPress post query (“author__not_in” injection)

  • The second bug is a SQL injection involving the WordPress post query method, specifically:
    • the author not in parameter/field.
  • Key nuance:
    • Previously, author not in was effectively treated/validated as an integer (post ID).
    • The exploit shapes parameters so that author not in is reached without the usual sanitization path that normally comes from author exclude.

How it triggers

  • Using the route confusion from Bug #1, the attacker dispatches a request that goes down a different internal route.
  • This bypasses normal handling and allows parameters like:
    • author exclude (mapping to author not in)
    • along with orderby and per_page
  • These reach a vulnerable SQL construction in a way that allows SQL injection.

5) How the blind SQLi turns into webshell + RCE (object cache poisoning)

The SQL injection is described as a blind SQL injection:

  • The result isn’t directly visible.
  • Exploitation relies on side channels.

Approach

  • Uses conditional logic with time-delay techniques (sleep/no-sleep) as a “CTF standard” method to extract data.

More advanced leap (as described)

  • Rather than simply extracting a hash, the exploit uses the SQLi to perform object cache poisoning / object hydration cache poisoning.
  • That poisoning causes creation of a fake post / temporary oEmbed cache post to obtain an internal post ID (or equivalent).
  • Then it uses internal WordPress flows:
    • to apply a Customizer change that poisons/creates an internal object triggering further actions
    • ultimately targeting the WordPress users REST endpoint (v2 users) to create an administrator account
  • With the new admin account, it uploads a normal plugin that contains a web shell.

Web shell behavior

  • Gated by a secret password
  • On correct password, it executes shell commands (e.g., ls, id).

6) Follow-on risk: likelihood of Linux local privilege escalation (LPE)

  • If compromised, the attacker may already have root due to publicly known Linux kernel local privilege escalations.
  • Practical advice from the speaker:
    • treat the system as compromised
    • destroy/rebuild the instance, then patch and redeploy.

7) “AI was involved” claim + speed of PoC

  • The speaker argues the exploit’s speed/complexity (two bugs chained + blind SQLi turned into cache poisoning + webshell) suggests AI assistance in building the PoC.
  • Timing claims:
    • disclosures allegedly around July 16
    • working PoC reportedly appeared about 10 hours later
  • It’s also claimed the exploit works “almost instantaneously” once weaponized.

Key “defender” takeaway / suggested mitigation

  • Patch WordPress: reiteration that 7.0.2+ is not vulnerable.
  • If you suspect exploitation:
    • assume additional compromise (possible root)
    • rebuild the system from scratch after patching.

Main speakers / sources

  • Main speaker: the video’s narrator/author (no name provided in subtitles).
  • Referenced sources/tools (by description, not directly quoted as primary speakers):
    • Tenable (cited regarding why AI could solve the exploit quickly)
    • Treated as external: linked prior videos/cards about Linux kernel LPEs and escalation details
    • WordPress developers / authors (batch v1 introduced around October 2020)

Original video