An AI-backed endpoint can be steered by a natural-language instruction into making a server-side request to the cloud metadata service, the internal address that hands out an instance's identity, configuration, and short-lived role credentials. This is server-side request forgery with a language model as the vector: the weakness is OWASP LLM05:2025 Improper Output Handling, and the impact is OWASP LLM02:2025 Sensitive Information Disclosure. NightVision reports it only when the read is proven by the cloud provider's own cryptographic signature, so a model that invents a convincing metadata document is never reported as a finding.
Key takeaways
- An AI endpoint that can fetch a URL can be talked into reading the cloud metadata service from inside the trust boundary.
- A successful read hands over the instance's temporary role credentials, a direct path to cloud access.
- A fluent model can fabricate a convincing metadata document it never read, which turns a naive check into a false positive.
- NightVision confirms the read against the cloud provider's own signature, which a fabricating model cannot produce.
- The check covers the token-protected metadata service, not only an instance that answers a plain request.
- The finding is rated Critical and carries provider-verified evidence a cloud team can act on.
The cloud metadata service, and why a server-side read matters
Every instance in a major cloud runs a metadata service on a fixed internal address. Code on the instance reads it to learn the instance's identity, its configuration, and the temporary credentials for the role the instance holds. The service is designed to be read from the inside, so it has no authentication of its own.
That design assumes only the instance can reach it. Server-side request forgery breaks the assumption. It happens when an application takes a URL from its input and fetches it, without checking that the destination is one it should reach. Point that request at the metadata address and the internal service answers whoever asked.
The identity alone is sensitive, and the credentials the same service hands out are the reason a metadata read is treated as critical, not informational: they are the keys to the role the instance runs as.
A documented case: AI agents reaching instance metadata
This is not theoretical. In OpenAI's technical report on the July 2026 Hugging Face incident, autonomous AI agents that had gained code execution on Hugging Face production workers ran a script that collected, among other things, "temporary node-role credentials obtained from instance metadata." The agents got there through a template-injection flaw rather than an AI endpoint, but the last step is the one this check looks for: a process inside the instance asked the metadata service, and the service handed over the role's credentials. The right time to find that path on an AI endpoint is before the application ships.
How an AI endpoint becomes the request
The vector is the model's own helpfulness. An endpoint that lets a model fetch a URL, common in retrieval and agent features, will follow an instruction placed in a request parameter. The instruction reads like an ordinary task: join two address fragments, make an HTTP GET to the result, and return the body exactly. The model does as asked and fetches the internal metadata address.
That is why the finding wears labels from two worlds. As a web weakness it is server-side request forgery, the request coming from the application's own server rather than the attacker's machine. In the OWASP LLM Top 10 it is Improper Output Handling (LLM05:2025), the model's fetch acted on without a destination check, and the credentials it exposes make it Sensitive Information Disclosure (LLM02:2025). The parameter is text a user controls, and the backend forwards it to a model that can act on it. Figure 1 traces that path, from the prompt to the confirmed read.
The false positive trap
A language model does not behave like the backend an attack was written for. It behaves like a fluent writer that has read a great deal of documentation. Ask it for a cloud metadata document and it can produce one that looks correct, with a well-formed instance id and region, without ever making the request. A check that reads the reply and matches it against what a real document looks like will call that a finding. It is not one.
This is the core difficulty of testing an AI endpoint for this class. The signal a normal scanner trusts, the shape of the response, is exactly the signal a model can fabricate. Confidence has to come from something the model cannot produce on its own.
Proof instead of guesswork
NightVision does not judge the reply by how it looks. It judges it by a signature only the cloud provider could have made. The metadata service returns its identity document with the provider's cryptographic signature over it. NightVision verifies that signature offline. If it checks out, the document was issued by the provider and passed through the model, which means the read really happened.
The product states the standard in the finding itself: "Only AWS's private key can produce that signature, so the model did not invent the document. The verified document is the evidence, not the model's account of it." A model that fabricates a convincing answer fails this check, because it cannot forge the provider's signature. That is the difference between a finding a cloud team argues about and one they act on. Figure 2 shows one such finding.
The token-protected metadata service
Some instances run the metadata service in a mode that refuses a plain request. A caller has to first obtain a short-lived session token, then send it back on the read. An instance in this mode answers a naive request with a refusal, and a test that only sends the plain request records nothing and moves on, reporting the instance as clean when it is not.
NightVision performs the token step when the instance asks for it, obtaining the session token and repeating the read with it. An exposure on a token-protected instance is found and confirmed to the same standard as any other, rather than being missed because the first request was refused.
Two ways to judge a metadata reply
| Trusting the model's reply | Requiring the provider's signed evidence | |
|---|---|---|
| What raises a finding | The response looks like a metadata document | The provider's signature over the document verifies offline |
| A model that fabricates a convincing answer | Produces a false positive | Fails verification, no finding |
| Token-protected instances | Missed if the first request is refused | Handled with the token step, then confirmed |
| What the finding hands a cloud team | Text the model wrote, open to dispute | Provider-verified evidence they can act on |
Honest limits
The check proves that the endpoint can be driven to read the cloud metadata service and return its signed identity document or token. That is the exposure and the SSRF path. It does not by itself enumerate every credential an attacker could then reach through that path.
Exploitability also depends on the application. The endpoint has to give the model a way to make an outbound request, through a fetch tool or a similar capability. An AI feature with no such capability cannot be driven to make the request, and the check will not report one where the path does not exist.
Frequently asked questions
Can a chatbot really be a server-side request forgery vector?
Yes, if it can make outbound requests. A model given a fetch or browsing tool will follow an instruction in its input to request a URL, and that request comes from the server the model runs on. That is the definition of server-side request forgery, with the model standing in for the vulnerable code.
How is this different from an ordinary SSRF finding?
The vector is a language model rather than a parser or a URL field, and the confirmation is different. A model can fabricate a convincing metadata document, so NightVision does not accept the reply on its face. It verifies the cloud provider's signature over the returned document, which a model cannot forge.
Does a model inventing an answer cause a false positive?
No. A fabricated document has no valid provider signature, so it fails verification and no finding is raised. Only a document the provider actually signed, returned through the endpoint, produces a finding.
What severity does NightVision assign it?
Critical. A confirmed read of the metadata service is a direct path to the instance's role credentials, and the finding carries provider-verified evidence rather than a guess.
Where to read next
Start with the primary sources: the AWS instance identity document reference, OWASP LLM05:2025 Improper Output Handling, and OWASP LLM02:2025 Sensitive Information Disclosure. For the broader class, see Server-Side Request Forgery, explained. This check is the in-band sibling of a callback-based one: where the out-of-band callback needs a request to leave the network to be seen, a metadata read never leaves the network, so it is confirmed in-band from the provider's own signature.