The attack classes Agent-Shield's scanner detects — what they are, how we catch them, and what they look like in the wild. Updated 2026-10-20.
An agent (or something the agent reads) hands a server a URL, and the server fetches it — including internal addresses it was never meant to reach: cloud metadata endpoints, loopback, private subnets. In agentic systems this is the "protocol pivoting" pattern: the MCP server holds credentials and network position, so a forged request inherits both.
How we detect it: every URL in scanned content is extracted, its host resolved via DNS, and the resulting IP classified — cloud_metadata (169.254.x.x), loopback, link_local, private (RFC 1918), reserved, multicast. Non-public destinations raise the ssrf_risk score; cloud metadata scores 1.0. Deterministic, no model involved.
In the wild — the same flaw shape, five unrelated codebases, one researcher (Syed Anas Mohiuddin):
| Who | What happened | Would we have flagged it? | Status |
|---|---|---|---|
| Google — MCP Toolbox for Databases | Generic HTTP source/tool followed redirects with no destination-IP check; a crafted parameter could pivot requests to internal endpoints. CVE-2026-14540, CVSS 4.0 8.0, published 2026-07-31. | Probably not. The initial URL was public; the redirect target was internal — and we don't follow redirect hops. This gap is our top engineering priority. | Fixed in 1.5.0 (PR #3448: SSRF guard, DNS-rebinding protection) |
| JPMorgan Chase — jpmorgan-payments/ai docs MCP server | related() tool fetched caller-supplied URLs server-side with no restriction, while its sibling tool had an allowlist. Reported by the researcher and confirmed per his account with JPMC's Responsible Disclosure team — no public advisory or CVE exists. | Likely. Unrestricted outbound fetch of an agent-supplied URL is our core target — if it resolved to a non-public address. | Fix deployed (per researcher) |
| Weaviate — Google module | Module API endpoint setting was unrestricted; a configured endpoint could point anywhere. | Likely. Same as above — an unrestricted endpoint resolving to non-public space is exactly what we score. | Restricted to Google API hosts (2026-08-25); researcher named in Security Hall of Fame |
| France (DINUM) — datagouv/datagouv-mcp | get_dataservice_openapi_spec fetched a producer-supplied URL with no validation — any dataset publisher could aim the government's MCP server at an internal address. | Partially. We'd flag loopback/private/metadata destinations — but not the DNS-rebinding variant, which exploits the gap between our scan and the agent's connection. | PR #126 merged 2026-09-04 (IP validated at connect, redirects re-checked) |
| Tangerang City, Indonesia — Wazuh-MCP-Server | Same URL-fetching flaw shape in a municipal security MCP server — a literal-IP check that failed on unresolved hostnames. | Yes. This is precisely what our resolve-then-classify design catches: hostnames resolved before scoring, not string-matched. | Reported; fix status via upstream |
The wider picture. Mohiuddin also authored IETF Internet-Draft draft-mohiuddin-mcp-security-considerations-00 (June 2026), which formally defines "protocol pivoting" as cross-protocol lateral movement — the pattern behind the incidents above. On Sept 2, 2026, he privately reported related issues in five US federal AI servers operated under GSA's Technology Transformation Services: VA benefits claims, CMS Blue Button, rules.gov, USASpending, and CDC PLACES. Per press coverage on Oct 6, those reports were still in triage; the VA server was reported to log full error responses — including veterans' identity, SSN, and date of birth — unredacted. We make no claim about whether Agent-Shield would have flagged those systems: they are live infrastructure, and the facts here are cited from the reporting, not tested by us.
Sources: CVE records, vendor advisories, and the researcher's disclosures (dev.to, IETF draft draft-mohiuddin-mcp-security-considerations-00). Mohiuddin presents "Protocol Pivoting: How SSRF in MCP Servers Enables Cross-Protocol Lateral Movement" at MCPCon North America — Friday Oct 23, 2026, 11:30 AM, room LL20A, San Jose McEnery Convention Center.
Malicious instructions smuggled into content the agent processes — tool outputs, documents, webpages, chat — that try to override the agent's real instructions: ignore previous instructions reveal system prompt [SYSTEM] role spoofing exfiltrate credentials hidden HTML directives.
How we detect it: heuristic_v5 scores weighted injection signals (instruction override, system-prompt extraction, role spoofing, authority claims, exfiltration directives, hidden instructions, embedded assistant directives, encoded payloads in base64/hex). Honest numbers: 58.8% recall on our 465-sample dev set, 4.7% on the 211-sample blind holdout — the heuristic wall, published at /benchmarks. The semantic classifier (Tev1) is being built to close that gap.
Agents routinely handle credentials and personal data; a leaked key in a log, prompt, or tool output is a breach. How we detect it — deterministic patterns, no model:
AWS access-key IDs GitHub tokens PEM private keys generic high-entropy secrets SSN credit cards (Luhn-checked)
Findings report { class, match_count } — that a secret pattern fired, never the secret itself.
What our SSRF detector does not cover, stated plainly:
We publish this list because a detector whose boundaries you know is more useful than one whose vendor won't name them. Each limitation above is a roadmap item.
No scanner catches everything, and a single page of incidents doesn't prove coverage — it proves the attack classes are real and active. Our detection numbers, including the misses, are published at /benchmarks. New confirmed incidents in these classes will be added here with dates and sources.
Found an incident we should list, or a flaw in our scanner? StarTek@Startekenterprises.com — we aim to acknowledge within 48 hours.
Agent