The Path Argument Named a Document. The Join That Resolved It Named Nothing At All.
GHSA-9gfj-28hw-jchp, published by knowns-dev on 16 August 2026 against the Knowns MCP server, describes path traversal in the docs and memory tools an agent calls through Knowns to read, write and delete a project's own Markdown files. This record independently cloned knowns-dev/knowns and read the affected and fixed source directly: before the fix, every doc storage operation, get, create, update, rename and delete, built its local file path by trimming a caller supplied path string and joining it onto the project's own docs directory with no check the result stayed inside it, and every memory operation built its filename by concatenating a caller supplied ID with no format check at all. Nothing in either path resolved to a bounded root; a path or ID carrying parent directory segments simply carried the join wherever those segments walked it. This record also confirmed, by reading the current permission registry directly, that a second, distinct authority gap the same advisory describes, a tool that deletes a file while classified only as a write, is not addressed by the containment fix and remained present in the latest commit this record could read.
Event analysed: . This analysis was published on 9 September 2026.
Because nothing downstream of the permission check ever asked where the resolved path actually pointed. Knowns is an MCP server that gives an agent docs and memory tools scoped, by design, to one project's own .knowns directory. This record independently cloned knowns-dev/knowns and confirmed, by reading the source directly at the last affected release, v0.29.1, that the doc storage layer resolved a caller supplied path by trimming a leading slash and a trailing .md extension and joining the remainder onto the project's docs directory with Go's plain filepath.Join, a function that performs no check the result still sits inside that directory. The memory storage layer was narrower in shape but identical in kind: a caller supplied ID was concatenated directly into a filename, memory-{id}.md, with no format restriction before the fix, so an ID carrying its own parent traversal segments carried the join with it. GitHub Security Advisory GHSA-9gfj-28hw-jchp, published 16 August 2026, states plainly that this let an attacker read, create, overwrite and delete files outside the project sandbox reachable by the server process. The permission that authorized calling docs.get or memory.add on the current project was real; it was never authority over whatever file path the join actually produced, and until the fix, nothing separately checked the two were the same thing.
A path argument to a tool that operates on a project's own documents looks, on its face, like a narrow thing: a string identifying which file, inside a directory the tool already knows about. GHSA-9gfj-28hw-jchp is what happens when the code that turns that string into an actual filesystem path never checks that the result is still inside the directory it started from.
What the advisory states
GitHub Security Advisory GHSA-9gfj-28hw-jchp, fetched directly in this session including its structured JSON record, documents "Unrestricted Path Traversal leading to out-of-bounds arbitrary .md file read, write, and deletion in MCP Docs + Memory Tools" against the npm package knowns, published 16 August 2026 at 10:52:25 UTC. Its structured record carries no CVE ID: this session's own direct fetch of the GitHub Security Advisories API for this exact GHSA returned a null cve_id field, confirmed on the advisory's own web page as well, which states "No known CVE" beside the GHSA identifier. The advisory's own description states that storage layer functions "concatenate user-controlled paths using filepath.Join() without validating that resolved paths remain within intended directories," permitting an attacker to "read, write, and delete arbitrary files outside the project sandbox," and separately that the docs.update action's newPath parameter "performs file deletion but is classified as CapWrite rather than CapDelete," letting a caller restricted to a read-write-no-delete permission preset delete files anyway. CVSS 3.1 base score 8.8, High, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H; CWE-22, Improper Limitation of a Pathname to a Restricted Directory, CWE-306, Missing Authentication for Critical Function, and CWE-863, Incorrect Authorization. Affected versions through 0.29.1, patched in 0.30.0, credited to reporters uziii2208 and hoanggxyuuki.
Third party trackers, vuldb.com and OffSeq's Threat Radar, independently found through web search, associate this same mechanism, package and affected range with CVE-2026-86439. Both vuldb.com and radar.offseq.com were blocked to direct fetch by this session's network egress proxy on every attempted route, and nvd.nist.gov and services.nvd.nist.gov were blocked identically, so this record cannot independently confirm CVE-2026-86439 against a fetched primary CVE record. This record states the CVE identifier as search corroborated only, distinct from GHSA-9gfj-28hw-jchp itself, which this record confirmed directly carries no CVE ID in GitHub's own structured advisory data as of this session.
A join with nothing downstream to check it
This record read internal/storage/doc_store.go directly at git tag v0.29.1, the exact version GHSA-9gfj-28hw-jchp states as the last affected release. DocStore.Get, the function backing the docs.get MCP tool, took a caller supplied path, trimmed a single leading slash with strings.TrimPrefix and a trailing .md extension with strings.TrimSuffix, and built absPath = filepath.Join(ds.docsDir(), filepath.FromSlash(path)+".md"). Neither trim touches a parent directory segment; strings.TrimPrefix and strings.TrimSuffix operate only on the exact leading and trailing substrings named, and "..", however many times it appears in the middle of a path, passes through both untouched. filepath.Join itself performs Go's standard lexical cleaning, which collapses a literal ".." segment against whatever segment precedes it, walking the resolved path upward one level per occurrence, with no floor at the root argument's own boundary. This record confirmed the identical unchecked construction, with the same absence of any containment check anywhere in the function, in DocStore.Create, DocStore.Update, DocStore.Rename and DocStore.Delete, the functions backing docs.create, docs.update and docs.delete, at the same tag.
The memory storage layer's own vulnerable construction is narrower in shape, since a memory ID has no directory structure of its own, but identical in kind. This record confirmed, by reading internal/storage/memory_store.go and internal/models/memory.go directly at v0.29.1, that MemoryStore.Get, GetInLayer, Create, Update, Delete and moveLayer, the functions reachable through the memory.get, memory.add, memory.update and memory.delete tools, each resolve a caller supplied ID into a file with models.MemoryFileName(id), which returns the literal string concatenation "memory-" + id + ".md", joined onto the memory directory with filepath.Join, and that no function anywhere in the affected version restricted what characters or segments id itself could contain. This record independently tested the consequence of that concatenation with Go's own filepath.Join: an id of "../../etc/cron.d/x" produces the joined path fragment "memory-../../etc/cron.d/x.md", which Go's own path cleaning resolves by first cancelling the literal segment "memory-.." against the ".." immediately following it, then, once the literal prefix is exhausted, treating any further ".." segments in the same id as an ordinary upward traversal from the memory directory. One additional ".." segment in the same id is enough to carry the resolved path outside the project's .knowns root entirely, this record confirmed directly rather than assumed, by running the identical join against a representative id carrying one further traversal segment.
The fix, read directly against the affected commit
This record read the complete diff of commit 09c5a96fd5817b941dc86669278c1a17db10ed4e, "fix(security): contain filesystem paths," directly from the cloned repository. Authored and committed 14 August 2026, per its own author and committer dates, and confirmed by this record, through git merge-base --is-ancestor, to be an ancestor of release tag v0.30.0 and not an ancestor of v0.29.1, the two tags GHSA-9gfj-28hw-jchp names as the fixed and last affected releases respectively; v0.30.0 itself carries a commit date of 16 August 2026, the same day the advisory was published. The commit touches eleven files, adding a new package, internal/safepath, of 145 lines, plus 92 lines of new tests across three files exercising the exact containment behavior the package adds.
internal/safepath/path.go, read directly, defines Resolve, ResolveProject and ResolveProjectReal, each built on one internal resolve function. Before any join, resolve rejects an empty path, a path containing a NUL byte, a Windows volume prefix such as C:\ or a UNC path unless the caller explicitly opts into a contained absolute path on Windows, and, critically, any path whose slash separated segments include a literal ".." anywhere in the string, not only at the start, closing exactly the gap this record confirmed the pre fix TrimPrefix and TrimSuffix calls left open. After that rejection pass, resolve joins the remaining candidate onto the root and calls requireWithin, which computes filepath.Rel between the root and the candidate and rejects the join if the relative path is "..", is itself absolute, or begins with "../". This record confirmed requireWithin alone would already have blocked every traversal string this record traced above.
A second layer, resolveWithin, is what the task description's own "symlink-escape check" names precisely: it calls resolveProspectivePath on both the root and the already traversal checked candidate, a function this record read directly that walks upward from the candidate to its nearest actually existing ancestor directory, since a path being created does not yet exist to canonicalize, calls filepath.EvalSymlinks on that existing ancestor to resolve any symlink in it to its real, canonical target, then rejoins the not yet existing remainder onto that canonical result. requireWithin is then re-applied to the two canonicalized paths. This record confirmed the effect directly: a symlink sitting inside the project's own docs directory but pointing at a real directory outside it no longer passes containment merely because its own name, syntactically, still reads as a path under docs; the check follows the symlink to its actual target before deciding whether the result stays inside the root.
internal/storage/doc_store.go, read directly against this commit's diff, replaces the unchecked joins this record traced above in Get, Create, Update, Rename and Delete with a shared resolveDocPath helper that calls safepath.Resolve and rejects the operation on any error, and template_store.go and the template preview route in internal/server/routes/templates.go, read directly, are rewired the same way. The memory storage layer takes a different, narrower fix matched to its own narrower vulnerable shape: internal/models/memory.go, read directly, adds ValidateMemoryID, which rejects any ID not matching the regular expression ^[A-Za-z0-9][A-Za-z0-9._-]{0,127}$ or ending in a literal period, called at the start of every one of the six memory storage functions this record traced above as vulnerable. A regex anchored to alphanumerics, underscore, period and hyphen with no slash and no leading period rejects every traversal segment and every Windows volume or alternate data stream character this record tested against safepath's own rejection list, without needing to resolve the ID against a root at all, since MemoryFileName never lets an ID's own directory structure exist in the first place once the format is closed.
The tests added in the same commit, read directly, exercise the fix against the exact mechanism this record traces above rather than a synthetic case: TestDocStoreRejectsTraversalAndSymlinkEscape asserts Create, Get and Delete all reject "../outside", a literal backslash variant, an absolute /tmp path and a Windows volume path, then separately creates a real symlink inside the project's own docs directory pointing at an external directory and asserts a create through it both fails and leaves no file on disk at the external target; TestMemoryStoreRejectsUnsafeIDs asserts Create, Get and Delete all reject "../escape", a backslash variant, a nested "nested/id", a Windows volume path and an NTFS alternate data stream ID.
What the same fix does not touch
GHSA-9gfj-28hw-jchp's own description states a second, distinct finding: "the docs.update action with a newPath parameter performs file deletion but is classified as CapWrite rather than CapDelete, allowing bypass of deletion restrictions in read-write-no-delete permission presets." This record confirmed the underlying mechanism directly. handleDocUpdate, in internal/mcp/handlers/doc.go, sets doc.Path from a caller supplied newPath argument and calls store.MutateDocWithHistory, which this record traced through mutation_transaction.go into DocStore.Rename, a function this record confirmed calls os.Remove on the document's own prior file path once the new one is written, a genuine file deletion, not a metaphorical one. This record confirmed, by reading internal/permissions/registry.go directly, that docs.update is declared in the ActionRegistry as {Capability: CapWrite, Target: TargetDoc, Risk: RiskMedium}, with no separate entry or override for the case where a newPath argument is present, at three separate points in this repository's own history this record checked directly: the tag GHSA-9gfj-28hw-jchp states as the last affected release, v0.29.1, the tag carrying the path containment fix, v0.30.0, and the latest commit this record's own clone could reach, c6ed4cb8548c266930910d3b24b7605fa2c21150, dated 5 September 2026 and tagged v0.33.0. Commit 09c5a96 does not modify internal/permissions/registry.go at all, confirmed directly from its own file list; a later commit on 16 August 2026, the same day, adds a separate docs.hard_delete registry entry under CapDelete without altering docs.update's own classification. This record found no commit in the history it could read that changes docs.update's declared capability. On the evidence this record could gather, a caller whose permission is scoped to CapWrite alone, deliberately excluding CapDelete, can still cause an existing document to be deleted by supplying newPath to docs.update, independent of whether the path the operation resolves against is contained correctly.
Two separate authority questions, not one
The task framing this record was given states the distinction precisely: tool permission and authority over the resolved filesystem target are separate questions, and this vulnerability's own two findings sit one on each side of that line. The containment fix, commit 09c5a96, answers the second question: once a tool call is permitted to operate on docs or memory at all, does the specific file it resolves against stay inside the root that permission was scoped to. This record confirmed that question is now answered correctly, with both a traversal check and a post resolution symlink check, and confirmed directly that the fix's own new tests exercise the exact mechanism this record traced as vulnerable beforehand. The CapWrite and CapDelete classification gap answers the first question, and answers it wrong: it is not a resolved path escaping a root, it is a tool's own declared capability failing to describe the effect the tool, correctly and entirely inside the project's own root, actually produces. A permission system that grants CapWrite while withholding CapDelete is stating an intended authority boundary; docs.update's own rename path crosses that boundary while remaining, on every check this record could find, indistinguishable from an ordinary write.
The Authority Provenance ledger
Source principal. An MCP client permitted to call Knowns' docs.* or memory.* tools against a given project, confirmed by this record's own reading of the source as needing no filesystem authority beyond whatever the MCP connection itself already grants, and, for the classification gap, no authority beyond a CapWrite scoped permission that deliberately excludes CapDelete.
Interpreting action. Knowns' own doc and memory storage layer, specifically DocStore.Get, Create, Update, Rename and Delete in internal/storage/doc_store.go and MemoryStore.Get, GetInLayer, Create, Update, Delete and moveLayer in internal/storage/memory_store.go, confirmed directly by this record's own reading of the source as the exact functions that resolve a caller supplied path or ID into a local filesystem path before the fix, with no containment check of any kind.
Semantic role before the crossing. A relative document path or a memory entry identifier, confirmed by this record as intended only to select which file, inside an already bounded project directory, an operation would act on.
Semantic role after the crossing. A literal filesystem path or filename fragment, joined or concatenated with no containment check before the fix, confirmed directly by this record's own reading of the pre fix source as reaching Go's own filepath.Join or a plain string concatenation unmodified, with nothing downstream reverifying the result stayed inside the project's own docs or memory directory.
Execution principal and environment. The Knowns MCP server process itself, running with whatever filesystem privileges the account that started it holds; this record found nothing in the advisory or the source establishing what account typically runs that process, and states the specific privileges available as unknown, while confirming the mechanism itself reaches beyond whatever the project's own task scoped directory was meant to bound.
Failed limit. Two, confirmed separately: first, that a resolved doc or memory path was never checked against the project's own root before the fix, for any of the affected operations; second, and unaddressed by the fix this record read, that docs.update's own declared capability, CapWrite, does not account for the file deletion its newPath argument triggers.
Recovery path. The first failed limit: closed in commit 09c5a96, confirmed directly by this record's own reading, through a new safepath package performing parent traversal rejection, Windows volume and alternate data stream rejection, and post resolution symlink escape detection, plus a memory ID format check serving the same purpose for the narrower memory ID shape. The second failed limit: this record found no fix for it in the commit history it could read, through the latest commit reachable from this record's own clone, c6ed4cb, tagged v0.33.0.
Recovery timing. The containment fix authored and committed 14 August 2026, first released in v0.30.0 on 16 August 2026, the same day GHSA-9gfj-28hw-jchp itself was published, confirmed directly by this record's own tag ancestry check. The classification gap remains open as of the latest commit this record's own clone could reach, 5 September 2026.
Tracking state. GHSA-9gfj-28hw-jchp itself, fetched directly including its structured JSON, carries no CVE ID. A CVE identifier, CVE-2026-86439, associating the same mechanism, package and affected range, was found through independently phrased web search against vuldb.com and OffSeq's Threat Radar; both, and nvd.nist.gov, were blocked to direct fetch by this session's network egress proxy on every attempted route, so this record states that identifier as search corroborated rather than independently confirmed against a fetched primary CVE record.
Exploitation. Unknown. Neither GHSA-9gfj-28hw-jchp, fetched directly, nor any source this record could reach states this mechanism was exploited against a real deployment; the advisory describes a disclosed and, for its first finding, fixed defect, not an incident.
Provenance evidence quality. Strong for the mechanism, both findings, and the first finding's own fix: this record cloned knowns-dev/knowns directly and read the exact vulnerable joins and concatenation, the exact fix commit and its own new tests, the exact permission registry entries at three separate points in the repository's history, and independently tested the memory ID join's own traversal arithmetic with Go's own filepath.Join rather than reasoning about it from the advisory's prose alone. Weaker for the CVE identifier: vuldb.com, OffSeq's Threat Radar and nvd.nist.gov were each blocked to direct fetch in this session, so CVE-2026-86439 itself rests on search corroboration rather than a fetched primary source, kept separate here from GHSA-9gfj-28hw-jchp, which this record did fetch directly.
Where this sits in the pattern
amazon-ssm-agent's own aws:downloadContent plugin shows the same unchecked join reaching outside a destination directory, but with a working, containment checked sibling function already present in the same codebase and simply not called at the one vulnerable site. Knowns' own mechanism is the plainer, earlier failure that sibling case presupposes: before commit 09c5a96, no containment function existed anywhere in this codebase for either the doc path join or the memory ID concatenation, so there was no safe alternative to have called instead. AgentScope's own add_skill method shows the same shape split across the two sides of one transfer operation, a destination correctly confined and a source never checked at all; Knowns' own doc and memory operations are each single sided, read, write or delete against one caller named location, so the gap this record traces here sits underneath that distinction rather than inside it. This desk's wider argument that execution authority has to be evaluated against the action a system actually takes, not the action a principal was nominally authorized for, holds twice over in this one advisory: once for the resolved filesystem target a permitted tool call actually reached, and once more, on evidence this record found unaddressed, for the file deletion a tool declared only as a write actually performs.
What this record does not establish
This record does not claim GHSA-9gfj-28hw-jchp has been exploited against a real Knowns deployment, that CVE-2026-86439 is confirmed against a fetched primary CVE record rather than search corroborated secondary trackers, that every Knowns deployment runs its MCP server under privileges this record could characterize precisely, or that no commit outside the history this record's own clone could reach, made after 5 September 2026, has since closed the docs.update capability classification gap this record confirms was still open at that point. 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 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.
- 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.