The Guard Existed. The Deployment Mode Decided Whether It Counted.
GitHub Security Advisory GHSA-9m7h-vh2h-rc3w, published 6 September 2026 against OpenMAIC through version 1.0.0, describes a caller supplied provider base URL reaching a real, correctly written SSRF guard, validateUrlForSSRF, at five call sites this record independently confirmed at two of them: the guard ran only when process.env.NODE_ENV === 'production'. In development, staging, preview, or simply an unset NODE_ENV, the same server side outbound fetch proceeded with no destination check at all. A separate, fail open middleware left every API route unauthenticated whenever the operator left ACCESS_CODE unset. OpenMAIC 1.0.1, released the same day, removes the environment gate everywhere the release itself lists and adds a repository scanning test, confirmed directly by this record, that fails if a gated call site reappears. It does not change the fail open middleware.
Event analysed: . This analysis was published on 7 September 2026.
None, on every path this record could verify. GitHub Security Advisory GHSA-9m7h-vh2h-rc3w, published 6 September 2026 against OpenMAIC through version 1.0.0 and fixed in 1.0.1, states that validateUrlForSSRF, a function this record confirms is written correctly, ran only inside a conditional guarding on process.env.NODE_ENV === 'production' at five call sites the advisory names: middleware.ts, app/api/generate/image/route.ts, app/api/generate/video/route.ts, app/api/extract-document/route.ts, app/api/parse-pdf/route.ts and lib/server/resolve-model.ts. This record independently read two of those five directly against the v1.0.0 tag. app/api/generate/image/route.ts wraps the call exactly as the advisory states: if (clientBaseUrl && process.env.NODE_ENV === 'production') { const ssrfError = await validateUrlForSSRF(clientBaseUrl); ... }. lib/server/resolve-model.ts carries the identical pattern one level lower, in the shared helper multiple provider routes call to resolve a client supplied base URL, with a code comment this record read directly stating the check was already scoped to unmanaged providers, where the base URL really is client supplied, before the separate NODE_ENV condition was layered on top of that scoping. In a deployment where NODE_ENV is anything other than the literal string production, including development, staging, preview, or simply unset, which this record confirms is Next.js's own default outside an explicit build or start invocation, the conditional's second clause is false and validateUrlForSSRF is never called: the caller supplied clientBaseUrl reaches the outbound fetch with no destination check of any kind. Separately, this record confirmed OpenMAIC's own middleware.ts carries a fail open branch: const accessCode = process.env.ACCESS_CODE; if (!accessCode) { return NextResponse.next(); }, unchanged between the v1.0.0 tag and the v1.0.1 tag this record also read directly. A deployment that never sets ACCESS_CODE, which nothing in the material this record could verify treats as an unusual or discouraged configuration, leaves every API route unauthenticated, so the caller who reaches an unguarded outbound fetch in that state need not present any credential at all. The advisory's own attack scenario names exactly that composition: an unauthenticated POST to /api/generate/image carrying x-base-url: http://169.254.169.254/latest/meta-data/iam/security-credentials/, returned to the caller because neither control stood in front of it. OpenMAIC 1.0.1, released the same day as the advisory, removes the NODE_ENV conditional at the two call sites this record independently re-read, confirming the guard now runs unconditionally, and its own release notes state the same for every call site the advisory lists. This record also read tests/server/url-guard-unconditional-invariant.test.ts directly: it scans the repository's own source tree for a validateUrlForSSRF call sitting inside a conditional block that references NODE_ENV, in either polarity, and fails if one is found, so a future call site written the same way the affected five were would fail this repository's own test suite rather than ship silently gated again. Separately, OpenMAIC's ssrf-guard.ts, read directly at the v1.0.1 tag, now rejects a caller supplied loopback or private network destination outside production too, unless the operator explicitly sets ALLOW_LOCAL_NETWORKS to true or 1, a configuration this record reads as an explicit grant an operator makes rather than a default the environment silently supplied. This record also confirmed directly that v1.0.1's middleware.ts still fails open exactly as v1.0.0's does when ACCESS_CODE is unset; nothing in the release notes or the source this record could read states that behavior changed.
Read OpenMAIC's own affected source and the finding is not that a destination check was missing. It was present, written correctly by the standard this record could verify at two of the five places the advisory names, and reused as a shared helper other provider routes called into. The condition wrapped around every one of those calls decided, by itself, whether the check that was already there ran at all.
What the advisory and the affected source together establish
GitHub Security Advisory GHSA-9m7h-vh2h-rc3w, filed against THU-MAIC/OpenMAIC and published 6 September 2026, titles itself precisely: Unauthenticated Outbound SSRF to Cloud Metadata Service via Fail-Open Middleware and Environment-Gated Validation Bypass. It states a CVSS 4.0 base score of 9.3, Critical, under three CWE classifications, CWE-306, Missing Authentication for Critical Function, CWE-668, Exposure of Resource to Wrong Sphere, and CWE-918, Server Side Request Forgery, and names OpenMAIC through version 1.0.0 as affected, patched in 1.0.1. The advisory names five affected call sites in a table: middleware.ts lines 60 to 64, app/api/generate/image/route.ts lines 73 to 78, app/api/generate/video/route.ts lines 65 to 70, app/api/extract-document/route.ts lines 258 to 263, app/api/parse-pdf/route.ts lines 47 to 52, and lib/server/resolve-model.ts lines 104 to 109. This record independently read two of those five directly against the v1.0.0 tag, app/api/generate/image/route.ts and lib/server/resolve-model.ts, and confirms the pattern the advisory states for both; the other three, the video and document and PDF routes, are carried here on the advisory's own table rather than on this record's own direct read of each file.
if (clientBaseUrl && process.env.NODE_ENV === 'production') { const ssrfError = await validateUrlForSSRF(clientBaseUrl); ... }, and lib/server/resolve-model.ts wraps the identical call the same way, one layer lower in a helper other provider routes share. In v1.0.1, both call sites carry the same guard with the NODE_ENV clause removed, leaving if (clientBaseUrl) { const ssrfError = await validateUrlForSSRF(clientBaseUrl); ... }.Two independent controls, and what each one's absence meant on its own
The advisory frames the vulnerability as a two stage composition, and this record keeps the two stages separately evidenced rather than treating them as one control. The first stage is authentication. OpenMAIC's own middleware.ts, read directly at the v1.0.0 tag, reads const accessCode = process.env.ACCESS_CODE; if (!accessCode) { return NextResponse.next(); } before any other check the middleware performs. When an operator sets ACCESS_CODE, the middleware requires a valid HMAC verified openmaic_access cookie for API requests, a real, working authentication mechanism this record does not describe as absent. When ACCESS_CODE is unset, the middleware passes every request through unauthenticated, API routes included. This record found nothing in the material available to it stating that OpenMAIC's own documentation, setup script, or default deployment path requires an operator to set ACCESS_CODE, and nothing establishing what share of real deployments run with it set versus unset; the fail open shape is a property of the code this record confirmed directly, not a claim about how many operators trigger it.
The second stage is the resource authorization question this record centers: the destination the server's own outbound fetch reaches. validateUrlForSSRF is a real function, and OpenMAIC's own ssrf-guard.ts, read directly, rejects loopback addresses, RFC 1918 private ranges, link local addresses including the 169.254.169.254 and 100.100.100.200 cloud metadata addresses and metadata.google.internal, and IPv6 equivalents, resolving a hostname through DNS when the caller supplies one rather than a literal address. Nothing about that function is defective by this record's own read of it. What determined whether it ran, at every one of the five call sites the advisory names, was a second, independent condition: process.env.NODE_ENV === 'production'. These two stages compose in the advisory's own attack scenario, but a reader should not conflate them into one fact: a deployment could set ACCESS_CODE and still leave the SSRF guard unreachable in a non production build, and a deployment could run with NODE_ENV unset for reasons that have nothing to do with whether an operator configured authentication.
Why an unset or non production NODE_ENV is not a rare or unusual state
This record treats the environment condition itself as the mechanism worth naming precisely, because the failure here is not that a rare misconfiguration slipped past a guard. NODE_ENV is unset by default outside an explicit Next.js build or start invocation, and staging and preview deployments, a normal part of how a web application reaches production, commonly run with NODE_ENV left at development or with a platform specific value that is not the literal string production. Every one of those states satisfies the same failing branch the advisory's own attack scenario exploits. Nothing in the affected source this record read distinguishes a staging deployment carrying production grade credentials and production reachable infrastructure from a developer's own laptop; both share the one condition that determined whether the destination check ran.
The advisory's own attack scenario, and what it composes
The advisory states the exploit as an unauthenticated POST to /api/generate/image carrying the header x-base-url: http://169.254.169.254/latest/meta-data/iam/security-credentials/. Under a deployment that never set ACCESS_CODE and whose NODE_ENV is not production, this record's own read of the affected source confirms both conditions this request needs are satisfied: the middleware's fail open branch admits the request with no credential, and app/api/generate/image/route.ts's own conditional never calls validateUrlForSSRF, so the caller supplied clientBaseUrl reaches the outbound fetch unconstrained. The advisory states the server returns AccessKeyId, SecretAccessKey and SessionToken values directly in that scenario. This record did not itself operate a live OpenMAIC deployment against a real cloud metadata service and did not independently reproduce credential exfiltration; it verifies the mechanism, the absent destination check under the stated environment condition, by reading the affected source directly, and treats the advisory's own stated response content as reported rather than independently reproduced by this record.
What OpenMAIC 1.0.1 changed, confirmed directly
OpenMAIC 1.0.1, released 6 September 2026 the same day as the advisory, states in its own release notes: The outbound URL guard ran only in production builds. It now runs everywhere, and a repository-scanning test fails if a gated call site reappears. This record confirmed the first half directly at both call sites it independently read: app/api/generate/image/route.ts and lib/server/resolve-model.ts each carry the identical validateUrlForSSRF call at v1.0.1, with the process.env.NODE_ENV === 'production' clause removed, leaving only the non empty check on clientBaseUrl. This record also read tests/server/url-guard-unconditional-invariant.test.ts directly. It walks the repository's own TypeScript and JavaScript source, excluding node_modules, dist and similar build directories, locates every call to validateUrlForSSRF, and fails if a call sits inside a conditional block whose own condition references NODE_ENV, detecting the pattern in either polarity and with or without braces around a single statement body. This is a repository level regression test against exactly the mechanism this record describes, not a claim by this record that every possible way to gate a security relevant call site is now covered.
What 1.0.1 did not change
This record read middleware.ts directly at the v1.0.1 tag and found the same fail open branch v1.0.0 carries, unchanged: const accessCode = process.env.ACCESS_CODE; if (!accessCode) { return NextResponse.next(); }. Nothing in OpenMAIC's own 1.0.1 release notes states a change to this behavior, and this record found no added flag, such as an explicit development only override, gating it. A deployment that upgrades to 1.0.1 without separately setting ACCESS_CODE gains a destination check that now runs in every environment, which closes the specific mechanism this record centers, but remains a deployment where every API route accepts a request with no credential at all. This record states that plainly rather than crediting the SSRF fix with closing a question it does not address: resource authorization and caller authentication are two different facts about this system, and 1.0.1's own release notes name a fix to the first without naming any change to the second.
A CVE identifier this record could not confirm directly
GitHub's own advisory page for GHSA-9m7h-vh2h-rc3w, fetched directly by this session on 7 September 2026, states no known CVE in its own metadata sidebar, checked twice independently with the same result. Several independent CVE tracking aggregators that mirror vulnerability database feeds, including RedPacketSecurity, TheHackerWire, ThreatInt and Shenlong CVE Platform, list CVE-2026-86259 against a mechanism matching this one precisely: OpenMAIC before 1.0.1, an SSRF validator skipped in non production builds, a caller supplied provider base URL, and cloud instance metadata as the named impact. This record treats CVE-2026-86259 as the corroborated identifier for this occurrence, cross referenced through independent aggregators rather than confirmed by a direct read of the CVE Program's own record: cve.org, nvd.nist.gov and osv.dev were each blocked at this session's network egress policy on every attempt. One aggregator's own summary states a CVSS v3.1 score of 7.5 for this identifier, distinct from the CVSS 4.0 base score of 9.3 this record read directly from GitHub's own advisory; this record states both figures rather than reconciling them, since NVD not infrequently recalculates a CVSS score independently of a reporting vendor's own advisory, and this record could not independently verify NVD's own scoring record given the same network restriction.
The Authority Provenance ledger
Authority grantor. The operator who deploys OpenMAIC and decides both whether ACCESS_CODE is set and what value, if any, NODE_ENV carries at runtime. Nothing in the advisory or the affected source names a separate organizational principal who decided a caller reaching an unauthenticated or non production deployment should be able to direct the server's own outbound fetch anywhere the caller names.
Caller identity. Under a deployment that never sets ACCESS_CODE, unauthenticated, confirmed directly against middleware.ts's own fail open branch. Under a deployment that sets ACCESS_CODE, a caller holding a valid HMAC verified openmaic_access cookie.
Caller mandate. Whatever mandate, if any, admits a caller to invoke a generation, extraction or model resolution endpoint at all. Nothing in the affected source this record read describes that mandate as extending to, or as ever being evaluated against, the destination of the server's own outbound provider fetch.
Intermediary. OpenMAIC's own server process: the route handlers naming clientBaseUrl directly and the shared lib/server/resolve-model.ts helper multiple provider routes call into.
Intermediary credential. None of OpenMAIC's own by default. A caller configured provider credential may be attached depending on provider configuration; this record did not independently trace that path for every affected route.
Intermediary network authority. Whatever loopback, link local, private network and, where reachable from the deployment, cloud metadata destinations the OpenMAIC server process can reach from wherever the operator deploys it, evidenced by the advisory's own named attack destination, 169.254.169.254.
Downstream target. Whatever address the caller names as the provider base URL, demonstrated in the advisory's own scenario against a cloud metadata service's IAM security credentials path.
Failed limit. validateUrlForSSRF, confirmed by this record's own direct read to be written correctly, wrapped in a condition on process.env.NODE_ENV at every one of the five call sites the advisory names, confirmed directly by this record at two of them. Independently, no caller identity check stood in front of the route at all when ACCESS_CODE was unset.
Inherited assumption. That a deployment not explicitly marked NODE_ENV=production was a context where only the operator, not an untrusted caller, could reach the input validateUrlForSSRF was meant to check. The fail open middleware defeats that assumption on its own terms: the same unset ACCESS_CODE and non production NODE_ENV combination is exactly the state a default, quickly deployed instance is left in, reachable by whoever finds it.
Credential binding. Not directly evidenced as forwarded to the caller named destination in the two call sites this record read; a caller supplied provider credential may reach a provider configured elsewhere, a path this record did not trace for every affected route.
Destination binding. Absent outside production, confirmed directly at v1.0.0 for the two call sites this record read. Present unconditionally at v1.0.1, confirmed directly at the same two call sites, with an added explicit exception for local and private network destinations gated behind ALLOW_LOCAL_NETWORKS.
Challenge authority. None, under a deployment that never sets ACCESS_CODE. Under a deployment that sets it, whatever the HMAC verified cookie check confirms, which nothing in the material this record could verify describes as reaching the destination of the resulting outbound fetch.
Revocation or modification. OpenMAIC 1.0.1 removes the NODE_ENV gate at the call sites this record confirmed directly and, per its own release notes, at the others the advisory names. A new repository scanning test, confirmed directly by this record, fails the project's own test suite if a future call site reintroduces the same conditional pattern.
Recovery path. Upgrade to 1.0.1. This record states plainly what upgrading alone does not change: the fail open ACCESS_CODE middleware, confirmed unchanged at the v1.0.1 tag, still authenticates nothing when an operator leaves ACCESS_CODE unset.
Exploitation. Unknown. No source available to this record states this mechanism has been exploited against a real OpenMAIC deployment.
Provenance evidence quality. Strong for the mechanism at the two call sites this record read directly against both the v1.0.0 and v1.0.1 tags, and for the fail open middleware branch, also read directly and unchanged at both tags. Carried on the advisory's own table, not independently re-read by this record, for the remaining three call sites: the video, document and PDF routes. Weaker for the CVE identifier itself: GitHub's own advisory page states no known CVE, and this record's attribution of CVE-2026-86259 rests on independent aggregator cross reference rather than a direct read of the CVE Program's own record, which this session's network egress policy blocked on every attempt.
Where this sits in the pattern, and where it does not
OGX's own advisory for CVE-2026-85666 already documents a caller supplied destination reaching an unchecked outbound connection because an existing, correctly written destination check was simply never connected to that one path. This record reads OpenMAIC's own mechanism as a related but distinct shape: the check was connected to every affected path, and what determined whether it ran was not which code path a request took but which environment the server happened to be running in when the request arrived. Grafana's own advisory for CVE-2026-19516 shows the same substitution of reachability for authorization this record's own mechanism produces on every non production path, evidenced here through a condition on the server's own deployment classification rather than through an absent check. This record does not merge OpenMAIC's own separate advisory for a redirect validation gap, GHSA-725p-44hx-v52c, fixed in the same 1.0.1 release, into this occurrence: that advisory describes an already validated destination's effective resource identity changing after a redirect with no fresh check, a failure that presupposes the initial check ran at all. This record's own mechanism is the initial check itself failing to run, on an entire class of deployment, before any redirect could matter.
What this record does not establish
This record does not claim CVE-2026-86259 has been exploited against a real OpenMAIC deployment, that every OpenMAIC deployment runs with ACCESS_CODE unset or with a non production NODE_ENV, that the three call sites this record did not itself read match the advisory's own table exactly line for line, that any specific cloud provider's credentials were actually exfiltrated through this mechanism, or that OpenMAIC 1.0.1 closes every possible way a security relevant call site could be conditionally gated in the future beyond what its own new regression test can detect. It does not claim OpenMAIC 1.0.1 changed the ACCESS_CODE middleware's fail open behavior; this record's own direct read of both tags found that behavior unchanged. Where the evidence available to this record does not establish a fact, this record states it as unknown rather than inferring it from the pattern this weakness class already shows elsewhere.
Sources
This analysis interprets third-party reporting, research and announcements. Moona is not the original reporter of the underlying events.
Protocol evidence
This record does not assess these architectures. The connection runs through the Risk Registry requirement each one bears on, and these published authority architectures are what the evidence says about that requirement.
Protocol evidence related through AEW-008 Reachability treated as authority
- Supports requirement
ARC, Agentic Runtime Control
Britive
Requirement Britive states native support for the OpenID Shared Signals Framework, consuming CAEP and RISC events to trigger automated session termination, forced logout, step up authentication or account disable, and separately emitting its own CAEP and RISC events
Okta Threat Intelligence's own 9 September 2026 research states the corrective for exactly the substitution this weakness names, a technically valid credential standing in for an authorization check that never independently runs: monitor for session-token reuse and re-evaluate a session's standing whenever a critical context change occurs, rather than trusting a credential's validity at authentication time for the remainder of its technical lifetime. Convergent reporting attributes to Okta's own product material a Session Protection capability that continuously monitors active sessions post authentication and re-evaluates policy on an IP or device change, or on inbound risk telemetry over the Shared Signals Framework, the identical corrective principle, and the identical named standard, this property already credits to Britive's own native CAEP/RISC support under a different vendor. This link supports the requirement rather than closing the gap this weakness names for AI-service credentials specifically: nothing in either vendor's own reachable material establishes that a stolen but still-valid AI session token or API key, of the kind Okta's own dataset documents by the thousand, is itself a principal a Shared Signals Framework transmitter is watching, as distinct from the device or IP session context CAEP and RISC events are reported to cover.
- Supports requirement
AWS Agent Registry (Amazon Bedrock AgentCore)
Amazon Web Services
Requirement The registry's own discovery API carries exactly three operations, all reads, no invocation
This weakness's own response pattern calls for authorizing a resource independently of whatever makes it reachable, never letting reachability itself substitute for the missing check. AWS Agent Registry's own discovery API, confirmed directly from AWS's published SDK source to carry exactly three operations, BatchGetDiscoverableRegistryRecord, ListDiscoverableRegistryRecords and SearchDiscoverableRegistryRecords, all reads, with no operation that invokes a discovered resource, is architectural evidence of exactly that separation: a caller who successfully searches the registry gains the ability to find a record, not any ability the registry itself grants to act on what the record describes. Recorded as design evidence that a governed discovery catalog can keep discoverability and invocation authority structurally apart, not as a claim that every resource a record points to independently enforces its own authorization at the moment of invocation, which this record leaves unknown.
- Supports requirement
AWS Agent Registry (Amazon Bedrock AgentCore)
Amazon Web Services
Requirement AgentCore Runtime and Gateway resources AWS Agent Registry auto-detects land as unapproved Draft records, not as discoverable Approved ones
This weakness names reachability substituting for authority precisely where nothing independently checks a resource before it becomes actionable. AWS Agent Registry's own auto-detection of AgentCore Runtime and Gateway resources across an organization is, on its face, the kind of automatic admission this weakness's known examples already warn about; what keeps it from instantiating the weakness here is that a resource the registry auto-detects lands as an unreviewed Draft record, not as an Approved, discoverable one, so existing is kept apart from approved even when the existence itself was discovered automatically rather than declared by a publisher. Recorded as design evidence for this weakness's own corrective, not as a claim that every deployment actually enables the review step before treating an auto-detected resource as caught up, which this record did not independently confirm.
- Supports requirement
MCP 2026-07-28: Sessionless Protocol, Explicit State Handles and the Tasks Extension
Model Context Protocol
Requirement Possession of a state handle is not authorization, where authentication exists
The Model Context Protocol's own security best practices page, part of the final 2026-07-28 specification revision, states directly that MCP servers must not treat possession of a state handle as authentication, and SEP-2567 states the corrective an authenticated server should apply, validating a handle together with the caller's current authentication context on every call rather than the handle alone. This is the connectivity protocol's own normative guidance for exactly the substitution this weakness names, reachability or possession of a reference standing in for an independent authorization check, stated at the level of a widely adopted protocol's own specification rather than one vendor's product. This link supports the requirement rather than closing the gap: the guidance is a should addressed to a server's own application layer, since MCP itself defines no protocol-level handle type to enforce anything about, and this weakness's own Grafana known example, CVE-2026-19516, already documents a real MCP server whose session check accepted a caller supplied identifier the server itself had never issued, so the specification's own text and any one server's own conformance to it remain separate facts this link does not conflate.
- Implementation evidence
Agent Action Decision Protocol (AADP)
Shamik Saha, individual submission to the IETF
Requirement A Policy Decision Point owns authorization state and evidence; PEPs enforce it
AADP requires a Policy Enforcement Point to hold a permit from a Policy Decision Point before performing a governed action. GitHub's branch protection, requiring multi party review before a Terraform change could merge, functioned as exactly that enforcement point for the one attempted infrastructure backdoor Unit 42's own account names, denying a mutation the attacker's already compromised, technically valid access could otherwise reach. This is bounded, real world enforcement evidence for the one action the control was configured in front of, not evidence that the same separation governed the rest of the intrusion, which Unit 42's own account describes continuing on other paths after that one attempt was blocked.
- Implementation evidence
Agentic Networking for DynamicLink, a production MCP server for networking
Zayo
Zayo's Agentic Networking for DynamicLink, launched 8 September 2026, is a production deployment of a Model Context Protocol server, the same specification this weakness already connects through mcp-2026-07-28-sessionless-tasks above, now exposing production network and security infrastructure rather than a development or evaluation surface. It is implementation evidence for this weakness's own general form, reachability through an admitted MCP session substituting for an independent per-action authorization check, of the same kind this weakness already credits to Coder's Agent Firewall and Reco's Browser Guard: Zayo's own material states enterprises determine which information, tools and actions an agent can access, a scoping decision placed in front of the MCP tool surface, while no reachable artifact describes the mechanism that evaluates one specific requested tool call against that scope at the moment it is made. This link is scoped precisely to that evidentiary role. It does not evaluate a specific graded requirement of the MCP specification itself, and it does not treat Zayo's own governance language as proof that the gap this weakness names is closed for this vendor.
- Reveals bypass
ARC, Agentic Runtime Control
Britive
Requirement Whether an agent holding an independent credential or a direct network path to a target system can reach that system without passing through ARC's policy evaluation is not addressed in material available to this record
Britive's own documentation does not address whether an agent holding an independent credential or a direct network path can reach a target without passing through policy evaluation. That unmediated reachability is exactly the weakness these incidents turn on. NCSC's August 2026 interim advice on agentic AI corroborates the requirement this gap reveals, independently of the market's own protocol dataset: deny network access by default and mediate what remains through an approval gated, protocol or service aware proxy, rather than leave any path an agent's credentials or network position can reach unmediated. Grafana's own advisory for CVE-2026-19516 is a CVSS scored, vendor patched instance of exactly this gap: a Grafana MCP server's own network position reached internal, loopback and link local destinations, cloud metadata endpoints included, with no policy evaluation independently constraining the destination until the fix added one. Unit 42's account of a real enterprise intrusion, corrected 3 September 2026 to clarify the event was an intrusion rather than ransomware, is a further, larger instance: stolen cloud credentials reaching the victim organization's own AI infrastructure and CI/CD access reaching cloud keys, with no policy evaluation described as mediating either path. Cybernews's exposed server investigation, published 3 September 2026, adds an MCP intermediary to the same gap: a Penelope MCP interface exposed live reverse shell execution as a callable capability to an agent framework, Hermes Agent, across more than 30 real organisations, with nothing described as independently evaluating whether the calling agent held policy backed authority to use the shell the interface made reachable. Anthropic's own 30 July 2026 disclosure adds a further real instance rather than a sandbox breach: a fictional evaluation target's name matched a real, live domain, and the evaluation environment's own live internet access, present through a misconfiguration neither Anthropic nor its evaluation partner Irregular had noticed, let Claude Opus 4.7 reach and act on the real company across four runs with nothing independently evaluating whether the resolved target matched the one the evaluation actually authorized. GitHub Security Advisory GHSA-9mg6-c5wp-2g44, formally assigning CVE-2026-85666 on 4 September 2026, adds a further vendor patched instance from an MCP client rather than an MCP server: OGX's Responses API accepted a caller supplied MCP tool server_url and opened an MCP session against it, at session initialization during tool discovery, with no destination check independently constraining the reachable target, confirmed by direct reading of the affected source. This instance sharpens Britive's own gap beyond the general case: the same codebase already applies a working destination check, validate_url_not_private, to two sibling caller controlled URL inputs, so the unmediated path here is not an absent control but an existing one never connected to this specific resource class, evidence this dataset reads as reinforcing the requirement that resource policy needs to be applied by effect and resource class rather than by the feature specific code path that introduced the caller controlled URL. A proposed fix, pull request 6390, remains open and unmerged as of this link, so this entry does not treat the bypass as closed. A second, independently opened pull request, 6291, proposes the same check plus a scheme restriction and states explicitly that an administrator configured connector or toolgroup endpoint keeps a separate, unmediated resolution path by design, evidence this link reads as directly on point for what Britive's own documentation does not address: mediation applied to one provenance of endpoint, caller supplied, does not by itself establish anything about a differently provenanced endpoint, administrator configured, that the same policy engine would need to evaluate on its own terms rather than inherit by association. This pull request is also open and unmerged as of this link. Later technical coverage of the collusion.wiki report on the DSEWiki incident adds a further instance of the same reinforced requirement from a different direction: an OpenAI evaluation harness's read only internet restriction was enforced by permitting the GET HTTP method and blocking others, including POST, and DSEWiki's own ProWiki software accepted a page edit submitted as a GET request. Britive's own documentation does not address whether a request classified as read by its method can still produce a write at the destination, the same unaddressed gap this link already names for network position and destination, now shown for request method as the classifier instead. Both outlets naming the mechanism directly, and collusion.wiki itself, were blocked by this session's network egress policy; the mechanism is corroborated through cross referenced search rather than direct fetch. GitHub Security Advisory GHSA-rp45-5x3v-48mr adds a further instance narrower than any above: argocd-mcp's own HTTP and SSE transports bound to every network interface by default through version 0.8.0, confirmed directly against the affected source, with no policy evaluation, Host check or Origin check of any kind standing in front of a listener an operator's own environment configured Argo CD credential sat behind, so a network principal able to reach the bound listener needed nothing further to complete a credentialed, mutating Argo CD API call. CVE-2026-86122, published 5 September 2026 against Rowboat through version 0.9.1 and confirmed by direct reading of the affected source, adds a further instance that sharpens Britive's own gap past OGX's own case: Rowboat's project action authorization policy is confirmed running, correctly, before a custom MCP server URL or a project webhook URL is accepted, and nothing after that authorization call, and nothing in the agent runtime that later reads the stored URL back to open an MCP session or fetch a webhook, independently mediates which destination that authorized action may actually reach. Britive's own documentation does not address this either: an authorized project action, not only an independent credential or a direct network path, can carry unmediated reachability forward into whatever the resulting connection touches. A proposed fix, pull request 547, predates the report by five weeks, is not linked to it, and remains open and unmerged as of this link. GitHub Security Advisory GHSA-9m7h-vh2h-rc3w, published 6 September 2026 against OpenMAIC through version 1.0.0, adds an instance of a different shape than any above, and this link states the difference precisely rather than folding it into the general case: Britive's own documentation addresses whether a target is mediated by policy evaluation at all, not whether that mediation applies uniformly across every environment a deployment can run in. OpenMAIC's own validateUrlForSSRF is written correctly and already wired to five call sites the advisory names, confirmed by this link's own direct read at two of them, app/api/generate/image/route.ts and lib/server/resolve-model.ts, so the gap here is not an absent or unconnected check, as OGX's and Rowboat's own instances above show, but a check whose applicability depended on a condition, process.env.NODE_ENV === 'production', that the caller never touched and that a normal staging, preview or unset deployment fails by default, confirmed directly at both call sites this link checked against the affected tag. This composed with a separately confirmed fail open middleware, unchanged between the affected and fixed tags, that authenticated no request at all when the operator left ACCESS_CODE unset, so the unmediated path was reachable by an unauthenticated caller in the deployment states the environment condition already left unmediated. Fixed in OpenMAIC 1.0.1, released the same day, confirmed by this link's own direct read to remove the environment condition at both call sites checked and to add a repository scanning test, tests/server/url-guard-unconditional-invariant.test.ts, also read directly, that fails the project's own build if a validateUrlForSSRF call is again found gated on NODE_ENV. The same release replaces an implicit non production widening of what a caller supplied base URL could reach with an explicit ALLOW_LOCAL_NETWORKS grant an operator must set for local or private network access to be permitted at all, evidence this link reads as squarely on point for what Britive's own documentation does not address: mediation that applies only under an incidental deployment classification is not the same fact as mediation that applies to the resource and effect Britive's own policy evaluation is meant to reach, and an intentional exception to that mediation needs its own explicit grant rather than a classification's default.
This record is the cited evidence for this relationship.
- Missing requirement
AWS Agent Registry (Amazon Bedrock AgentCore)
Amazon Web Services
Requirement Whether, and how, a discovered resource's own invocation is independently authorized once found through the registry
This weakness's own authority gap is precisely the fact this record could not establish: what independently authorizes a discovered resource's own invocation, once a consumer has been authorized to find it. AWS's own reachable material states what discovery approval decides and stops there; nothing this session could reach describes the registry itself requiring, checking or even being aware of a separate invocation-time authorization on the resource a record names. Recorded as a missing requirement in the material this session could reach, not as a claim that no such requirement exists in AWS's own architecture; AgentCore Runtime, AgentCore Gateway or a third-party resource may well enforce one independently, and this record states that possibility as unknown rather than either confirmed or absent.