Analysis · DiggingBeagle record

The object the tool authorized was not the object it used

Filesystem paths, translated hostnames, namespace tuples, OAuth issuers and KV-cache peers demonstrate one reusable boundary failure with different exploit prerequisites.

Published
Oct 26, 2026

Overview

A tool can validate a safe target and still act on an unsafe one. The mismatch may be a filename that changes meaning after normalization, a hostname interpreted differently by two libraries, or a request ID promoted into a network destination. Several October disclosures in AI tool infrastructure expose the same design error without relying on a model being persuaded by a malicious prompt.

What crosses the boundary

An agent may pass a path, URL or session identifier to a tool. The server checks that value against an allowlist and then hands it to a different component for execution. If those components disagree about identity, the authorization no longer covers the object that receives the effect. The problem is not merely an invalid string. It is a broken relationship between the checked object, the actual object, and the authority that allowed the operation.

The examples differ in how that relationship breaks:

Failure Object authorized Object or effect actually reached Important limitation
MCP Filesystem trailing-quote validation A normalized path inside an allowed tree A sibling path using the original spelling A local reproduced read, not evidence of broad exploitation
Filesystem case-folding and symlink resolution A guard's case-sensitive interpretation A symlink followed by a case-insensitive filesystem Depends on filesystem behavior and operation type
Filesystem parent-directory race A parent directory before a write A swapped target after validation Requires a concurrent directory change; Windows remained partly exposed after the Unix repair
MCP Fetch IDNA mismatch The address resolved using one IDNA convention The endpoint contacted using HTTPX's different convention The reproduced destination was a loopback stand-in, not a proven credential theft
MCP Fetch NAT64 classification An apparently public IPv6 address A translated embedded private or link-local IPv4 destination Successful contact additionally requires NAT64 routing
LangGraph persistent namespaces A structured tenant namespace A dotted storage key that could collide with a different tuple Concerns affected persistent stores, not the in-memory implementation
FastMCP OAuth discovery An issuer inferred from an untrusted service A credential exchange with an attacker-advertised issuer Version 4.1.2 needs explicit caller-configured issuer binding
vLLM KV-cache transfer A client-supplied request correlation value A decoded network peer used for KV transfer Only the affected P2pNcclConnector producer configuration is implicated

These are distinct technical defects, not a single CVE family. In the filesystem cases, identity can change through string handling, filesystem equivalence or time. In the fetch cases, it changes at the boundary between a classifier and the network stack. In the store, OAuth and cache cases, a lower-trust value is treated as an authority-bearing identifier.

Why patching the validator alone is not enough

Consider the three filesystem failures. Trimming a quote before an allowlist comparison is dangerous when the subsequent file operation uses the untrimmed path. A case-sensitive canonicalization helper is insufficient when the mounted filesystem resolves names differently. Even perfect name normalization does not protect a write if the directory is replaced between checking and opening it. The MCP Filesystem race investigation distinguishes the handle-bound Unix behavior shipped in 2.0.1 from a remaining Windows junction-swap route. Calling that release a complete cross-platform cure would erase the difference that matters.

The network disclosures require the same precision. The IDNA discrepancy was deterministic: Python's IDNA2003 treatment and HTTPX's IDNA2008 treatment could lead to different domains. It was not time-based DNS rebinding. NAT64 concerns an IPv6 representation of a forbidden IPv4 destination, and a classification-only reproduction does not establish a successful request on a network without translation. A policy that checks a parsed hostname but ignores what the socket connects to remains dependent on transport behavior.

The other examples show why a generic input filter misses the mechanism. LangGraph needs unambiguous serialization of tenant namespace components. FastMCP needs the OAuth issuer determined by trusted caller configuration, not by the service being authenticated; upgrading to 4.1.2 without supplying that issuer preserves compatibility behavior that the maintainer warns about. vLLM needs a request header to remain correlation data rather than a destination selector. The vulnerable connector was removed in 0.24.0, but that finding cannot be generalized to every vLLM configuration.

Test the identity at the effect, not just at the gate

For a filesystem write, the useful assertion is that the operation is performed through the authorized directory or file handle, including while another process swaps a parent. For an outbound request, it is that the address and redirect target actually contacted satisfy egress policy. For a multi-tenant store, two distinct namespace tuples must never map to the same authorization domain. For OAuth, the credential recipient must match a trusted configured issuer. For disaggregated inference, the KV transfer peer must come from authenticated configuration rather than arbitrary request text.

These checks should be exercised as negative cases: equivalent spellings, relative and Unicode paths, case-insensitive mounts, simultaneous directory replacement, hostname normalization disagreements, translated addresses, colliding tuple components and forged request headers. Record the checked identity and the observed effect separately. The claim of success should depend on the resulting file, connection or state transition, not on a Boolean returned by an earlier validator.

This matters to AI systems because an agent can supply tool arguments at scale, sometimes from untrusted documents or other callers. Yet none of these reports requires prompt injection as its root cause. A safer design keeps the permission decision attached to the actual object through the final operation. The surrounding model is an exposure path; the mismatched authority binding is the engineering failure.

Research behind this