AEW-020

An operation blocked in one syntactic form is authorized in an equivalent one

A policy checks the name of a consequential operation, or the identity of a resource, and works correctly wherever the operation or resource reaches the check in the form the check's own author tested. The identical operation or resource, produced by the same parser or the same addressing scheme, can instead be represented through a container, an encoding, or a transition format the policy's own logic does not recognize, and inside that alternate representation the same check never runs.

Status: publishedExecution Authority

Description

This weakness names a specific way a working check can still fail to cover what it was built to cover. A policy that validates an operation by its name, its type or its identity, or a resource by its address, is only as complete as the traversal or the classifier that walks whatever structure a parser, serializer or addressing scheme produces on the way to that operation or resource. Where a grammar, a schema, a wire format or an addressing standard offers more than one way to express the same underlying action or the same effective destination, the policy's own author may write and correctly test the check against the common or expected representation, while a distinct representation nests the identical operation one or more containers deeper, inside a tuple, a wrapped object, an alternate field, a synonym path, or embeds the identical resource inside a different literal encoding, such as a standardized transition address family carrying the same address in its low order bits, than the check was written to recognize. The check itself is not wrong; it is never asked the question, because the traversal or the classification that would carry the operation or the resource to it stops short of, or never opens, the representation it happens to be sitting in. This differs from an action executing with no applicable policy at all (AEW-001), where the gap is structural and no check exists for the action anywhere in the system: here a check exists, is correctly written, and demonstrably works on at least one representation of the same operation or resource. It differs from reachability substituting for authority in the absence of any check (AEW-008), which concerns a target being within reach with nothing gating it at all, not a specific check failing to extend across equivalent forms of one operation or one resource. It differs from an operation's authority being equated with authority over whatever it resolves against (AEW-013), which concerns a single sided target argument being reinterpreted in shape by the same actor within one request; here the operation or the resource itself is unchanged and its identity is not in question, only which of several equally valid representations carries it past or around an existing check.

The authority gap

The authority presented is whatever passes a check that exists, is correctly written, and is proven to work against at least one representation of the operation or resource. The authority required is a policy decision that reaches the operation or the resource regardless of which of several equivalent, parser produced or address encoded forms it takes, and the two are silently treated as the same guarantee.

Failure conditions

A policy validates a consequential operation, or a resource's identity, by inspecting a specific node, field, object type or numeric range produced by a parser, schema, serializer or addressing scheme.
The same underlying grammar, schema, wire format or addressing standard can express the identical operation or the identical effective resource through more than one distinct representation.
The policy's own traversal or classification logic recognizes representations only as far as the one it was written and tested against, without generically covering every container or encoding an alternate representation uses for the same operation or resource.
Nothing in the system treats an unrecognized or unopened container or encoding as a reason to deny by default; the operation or resource inside it is treated as though no policy applied.

Consequences shown by the evidence

A function, command or action a policy was built specifically to block executes anyway, with the same effect as if the policy did not exist, once expressed through an alternate representation of the identical operation.
A destination a policy was built specifically to keep out of reach is reached anyway, with the same effect as if the guard did not exist, once addressed through an alternate encoding of the identical resource.
An audit or design review that exercises only the common representation concludes the policy is complete, because every test it ran against that representation passed.

Detection signals

A security relevant traversal or classification function contains isinstance, type or numeric range checks enumerating specific node, container or address types rather than a generic descent or canonicalization covering everything the parser or addressing scheme can produce.
A fix for an incident adds a new branch or a new range to an existing traversal or classification function rather than introducing a new check, confirming the original check was correct but incompletely reached.
The same named operation, or the same effective resource, produces two different validation outcomes depending solely on which representation carried it to the check, with no other variable changed.

Known examples

Postgres MCP Pro's SafeSqlDriver validates a PostgreSQL function call's name against an explicit allow list whenever pglast represents the call as a FuncCall node, reached directly by the validator's own recursive walk, and this record confirmed directly that the same check correctly blocks pg_read_file, pg_ls_dir, pg_read_binary_file and pg_stat_file called this way. The identical function named inside a FROM clause instead parses as a RangeFunction node whose own functions attribute nests the same FuncCall one further container deep, inside a Python tuple pairing it with an alias, and the validator's recursive walk checks only whether each item in a list or tuple attribute is itself a syntax tree node, never unwrapping the nested tuple to find the FuncCall it contains. This record independently ran the real, unmodified validator from the affected v0.3.0 source and confirmed the same four functions all execute when reached this second way, while a write control, CREATE TABLE, remains correctly blocked throughout, isolating the gap to function name coverage on one grammar path. GHSA-cm87-gp55-7cgj formally assigns CVE-2026-85620 on 4 September 2026. A proposed fix, pull request 200, adds the missing traversal step; this record ran the patched validator directly and confirmed it closes the gap while leaving an allow listed FROM clause function, unnest, unaffected. As of this record, the pull request remains open and unmerged, and the identical bypass this record ran against the tagged v0.3.0 release also reproduces, confirmed directly, against the project's current default branch.
MCPHub's isBlockedIpv6 rejects an IPv6 destination by comparing its parsed, 128 bit numeric value against a fixed set of ranges, and this record confirmed directly, by reading the source at the commit immediately before the fix, that this comparison correctly blocked the unspecified and loopback addresses, the fe80::/10 link local range, the fc00::/7 unique local range, and both IPv4 mapped and IPv4 compatible embeddings, the address forms MCPHub's own existing test suite already exercised. Three IPv6 transition address families, each a standardized way of embedding the same 32 bit IPv4 address behind a distinct, fixed high order prefix, the NAT64 well known prefix 64:ff9b::/96, the deprecated 6to4 prefix 2002::/16, and the Teredo prefix 2001:0::/32, produced no match against any range the check tested for, so a private IPv4 address a caller could not name directly reached the same effective destination once named through one of these three encodings. GHSA-pr4x-3pc7-2fhw formally assigns CVE-2026-79749 on 23 August 2026. Remediation commit d382b36, merged in pull request 1069 as a56b4a17e25e2ebf09323a10882e1f83e445b2a8 and shipped in MCPHub 1.0.32, adds checks for exactly the three named families, this record confirmed directly against the diff, alongside two further ranges, site local addressing and multicast, that the same commit hardens without the advisory attributing them to this vulnerability specifically.
AWS Labs' postgres-mcp-server, an unrelated codebase maintained by a different organization from Crystal DBA's own Postgres MCP Pro, enforces its own read only mode through a keyword and function blocklist rather than an allow list, and GHSA-pwr4-hmph-gqgc, formally assigning CVE-2026-85787 on 4 September 2026 under CWE-184, Incomplete List of Disallowed Inputs, states that versions before 1.1.7 carried an incomplete list of disallowed inputs that could let an authenticated user's own submitted content modify data beyond the intended read only scope. This record fetched that advisory directly, and separately fetched the project's own current README, which states in its own words that this blocklist is a best effort, defense in depth mechanism, not a security boundary, naming obfuscation, quoted identifiers and new server or extension functions as categories a blocklist cannot enumerate in full, exactly the same shaped gap this weakness already names in general: a check that correctly blocks the representations and inputs it was tested against is not, on that basis, coverage of every representation or every input the same effect can be reached through. Unlike the two known examples above, this record could not independently reproduce the specific omitted input, since AWS's own advisory names no proof of concept and no source at the exact pre 1.1.7 version was reachable to this session; the corrected version, 1.1.7, was also already two months old at the advisory's own publication date, with five further releases shipped since, a materially different lifecycle position from Crystal DBA's own occurrence, where the identical bypass this record ran against a tagged release also reproduces, unpatched, against that project's current default branch.

Recorded instances

AEV-2026-0028 Postgres MCP Pro restricted mode allow list does not reach a function called in a FROM clause (CVE-2026-85620) AESS 7.7 high Confirmed
AEV-2026-0033 MCPHub's IPv6 destination guard misses NAT64, 6to4 and Teredo transition addresses (CVE-2026-79749) AESS 7.7 high Confirmed

Protocol evidence

Published authority architectures whose artifacts bear on the requirement this weakness names: which satisfy it, which expose a way past it, and which leave it unanswered.

Supports requirement
Agent Control Standard (ACS)
OWASP GenAI Security Project, originally Zenity
Requirement The specification does not guarantee complete mediation of every consequential action a host can take
ACS's own conformance document states directly that the specification does not guarantee complete mediation of every consequential action a host can take, and that a primitive bypassing its own toolCallRequest hook is invisible to policy. Postgres MCP Pro's restricted mode is concrete evidence for exactly the concern that admission names in the abstract: a mediation point that is present, correctly implemented and independently confirmed to work against one representation of a consequential operation still does not guarantee coverage of every representation the same underlying grammar can produce for it. This entry's own execution of the real, patched and unpatched validator against the same four functions supports the requirement that policy coverage be verified against the full range of representations a parser can produce, not only the one a mediation point's own author tested against. MCPHub's isBlockedIpv6 is the same admission read against a destination guard rather than a tool call hook: this entry's own direct reading of the pre fix and post fix source confirms a mediation point that correctly and completely covered every address form its own test suite exercised still left three standardized transition encodings of the same prohibited resource unmediated, supporting the requirement that coverage be verified against every representation an addressing standard can produce, not only the ones a guard's own author tested against.
View protocol evidence
Supports requirement
Verifiable Attenuated Delegation for AI Agent Chains (draft-asor-wimse-agent-delegation-chain)
Rafael Asor, Attenu
Requirement A verifier encountering an unrecognized constraint type must deny rather than treat it as unconstrained
This draft's own verified requirement is that a verifier encountering an unrecognized constraint type must deny rather than treat it as unconstrained, so that a newer, unrecognized restriction is never silently read as no restriction at all. Postgres MCP Pro's SafeSqlDriver shows the inverse failure at a different layer, its own recursive AST traversal encountering a container it does not open, the tuple nested inside RangeFunction's own functions attribute, and treating what it never inspected as though it carried nothing requiring a check, rather than denying by default. This entry's own execution of the real validator confirms the same allow list check works correctly wherever the traversal does open the container it needs to, which is exactly why an unopened one silently passing is the more precise finding here, direct evidence for why a verifier's default posture toward a structure it does not fully parse matters generally, not only for this one draft's own constraint objects. MCPHub's isBlockedIpv6 supports the same requirement at a resource identity boundary rather than a syntax tree boundary: an IPv6 address encoded through the NAT64, 6to4 or Teredo transition prefixes was an unrecognized representation isBlockedIpv6 silently treated as unconstrained, returning false rather than denying by default, until the fix taught the function to recognize those three encodings as the blocked addresses they carry.
View protocol evidence

Most direct sources

Postgres MCP Pro through 0.3.0 contains a restricted mode bypass permitting arbitrary server side file read via a FROM clause function (CVE-2026-85620) (GitHub Advisory Database)
[Security] Restricted (read only) mode bypass: arbitrary server side file read via FROM clause function (crystaldba/postgres-mcp (GitHub Issues))
fix: Block dangerous functions in FROM clause (RangeFunction allowlist bypass) #178 (crystaldba/postgres-mcp (GitHub Pull Requests))
safe_sql.py at the v0.3.0 tag (SafeSqlDriver._validate_node and _validate) (crystaldba/postgres-mcp (GitHub, source))
SSRF Guard Bypass via IPv6 Transition Addresses in URL Validation (CVE-2026-79749) (samanhappy/mcphub (GitHub Security Advisories))
fix(security): close open security advisory findings (SSRF, authz, OAuth PKCE) (Pull Request 1069) (samanhappy/mcphub (GitHub Pull Requests))
fix(security): block SSRF via IPv6 transition addresses in URL guard (commit a56b4a1, on branch as d382b36) (samanhappy/mcphub (GitHub, commit))
src/utils/ssrf.ts at commit dd5c7d7 (isBlockedIpv6 immediately before the fix) (samanhappy/mcphub (GitHub, source))
src/utils/ssrf.ts at commit a56b4a1 (isBlockedIpv6 after the fix) (samanhappy/mcphub (GitHub, source))
An incomplete list of disallowed inputs in the SQL validation component of Amazon awslabs postgres-mcp-server (CVE-2026-85787) (awslabs/mcp (GitHub Security Advisories))
postgres-mcp-server README (read only enforcement, best effort framing, least privilege guidance) (awslabs/mcp (GitHub, documentation))
awslabs.postgres-mcp-server release history (Python Package Index (PyPI))

Related weaknesses

Change history

2026-09-05
Created from a formally assigned CVE whose mechanism this session independently ran, rather than only read about, and which is distinct from every existing weakness in this registry: a function name allow list that is present, correctly written, and demonstrably works against a function call reached one way, paired with the identical function call reaching execution unreached by that same check when the same parser represents it through a different, equally legitimate syntax tree container. Deliberately not folded into AEW-001, action without applicable policy, since a policy does exist here and this session confirmed directly that it correctly blocks the same functions when they reach it through the common representation; the gap is in the traversal's reach, not in the absence of a rule. Deliberately not folded into AEW-008, reachability treated as authority, since that weakness describes a target being reachable with no gating check at all, while here a gating check exists, runs, and works, on one syntactic path.
2026-09-05
Published: a formally assigned CVE, CVE-2026-85620 and GHSA-cm87-gp55-7cgj, with a mechanism this session confirmed by running the real, unmodified validator from the affected source directly, by parsing the bypass query with the same parser library the validator itself uses to confirm the exact nested container structure, and by applying and running the proposed fix's own diff to confirm what it closes. Published on the same evidentiary basis this dataset already applied to AEW-013, AEW-014 and AEW-018: one clearly evidenced, independently reproduced mechanism with a precisely stated authority gap, even though the proposed fix remains open and unmerged and no released version contains it.
2026-09-06
Added a second known example and broadened this weakness's own summary, description, failure conditions, response patterns, consequences and detection signals from a parser container specific statement to one that also names resource address encoding directly: GHSA-pr4x-3pc7-2fhw, formally assigning CVE-2026-79749 on 23 August 2026, documents MCPHub's isBlockedIpv6 correctly rejecting every IPv6 address form its own test suite exercised while never checking three standardized transition encodings, NAT64, 6to4 and Teredo, each capable of embedding an otherwise blocked IPv4 address behind an unrecognized high order prefix. This record confirmed the mechanism directly by reading src/utils/ssrf.ts at the commit immediately before remediation commit d382b36 and at that commit itself. This is the same general shape Postgres MCP Pro's own known example already established here, a check that is present, correctly written and demonstrably works against the representation it was tested with, left unreached by an equally valid alternate representation of the identical operation or resource, evidenced now at a network address canonicalization boundary rather than only at a syntax tree traversal boundary. Deliberately not folded into AEW-008, reachability treated as authority, for the same reason the first known example was not: a gating check exists here, runs, and works correctly against every address form MCPHub's own author tested. Not merged with CVE-2026-79747, GHSA-9wx9-prgc-gmjr, published the same day against the same product: that advisory describes an authorization gap over who may configure a destination at all, a distinct mechanism this dataset keeps separate.
2026-09-06
Added AEW-028, a capability's enforcement gate wired to one caller instead of the executor every caller shares, to relatedAews, created the same day from CVE-2026-59726. Both weaknesses concern a working check that some path around it never reaches, but the shape differs: this weakness's own known examples are a check whose traversal or classification logic runs on every path but fails to recognize an alternate representation of the identical operation or resource; AEW-028's known example is a check that never runs at all on a bypassing path because it was written into one caller's own handler rather than into the shared function that caller and the bypassing path both invoke. This connection does not affect this weakness's own published status and adds no known example here; the new evidence is recorded on AEW-028 instead, where its mechanism belongs.
2026-09-07
Added a third known example from a second, independently maintained vendor: GHSA-pwr4-hmph-gqgc, formally assigning CVE-2026-85787 on 4 September 2026, documents AWS Labs' postgres-mcp-server, unrelated to Crystal DBA's own Postgres MCP Pro, enforcing read only mode through a keyword and function blocklist that, before version 1.1.7, carried an incomplete list of disallowed inputs, CWE-184. This record fetched the advisory and the project's own current README directly and confirmed the vendor's own words describing that same blocklist as a best effort, defense in depth mechanism, not a security boundary, naming obfuscation, quoted identifiers and new server or extension functions as categories it cannot enumerate in full, the same shaped gap this weakness already names in general between a check proven against the representations and inputs it was tested with and coverage of every representation or input the same effect can be reached through. This known example is deliberately written at a lower confidence than the two above it: AWS's own advisory names no proof of concept and no specific omitted input, no source at the exact pre 1.1.7 version was reachable to this session, and the corrected version had already shipped two months before the advisory published, with five further releases since, so this record states the specific mechanism as unknown rather than assuming it matches Crystal DBA's own, separately reproduced RangeFunction traversal gap. Strengthens rather than extends this weakness's own scope: no change to summary, description, failure conditions or response patterns was needed, since CWE-184, incomplete list of disallowed inputs, already sits inside the representation and encoding coverage gap this weakness's own description already names.