Read the researcher's report on HackerOne
A CI job could reach cloud instance metadata on a pipeline rerun, although the first run appeared protected. The report demonstrates metadata access but does not establish the broader claims about creating service tokens or retrieving private files.
How it was found
- The researcher configured a CI job to make an HTTP request to the instance metadata service.
- The first pipeline run showed no metadata output.
- On rerunning the pipeline, the request returned metadata resource listings, confirming access.
- Access needed
- A user account · an account
- User interaction
- Needed
- Whose object
- No object involved
- Boundary crossed
- A CI job reached the cloud instance metadata service from the runner.
- Root cause
- CI runner network restrictions did not consistently block requests to the instance metadata service on subsequent runs.
- Impact
- A malicious CI job could retrieve instance metadata and potentially use exposed credentials to access resources available to the runner.
- Payload class
- HTTP request to a cloud metadata service
- Components
- CI runner, cloud instance metadata service
- Confidence
- medium
This analysis is CyberSIXT's own summary of the public report, written by a model and checked automatically. It may be wrong: the researcher's report is the source. Written 2026-11-14. Ask for a correction or removal.
| Report | Access | Whose object | Boundary crossed |
|---|---|---|---|
| Server Side Request Forgery (SSRF) via Analytics Reports | No account | No object involved | Attacker-controlled report content caused the application server to request internal resources. |
| Server-Side Request Forgery using Javascript allows to exfill data from Google Metadata | A user account | The attacker's own | A researcher-controlled page caused the import browser to access the hosting instance's cloud metadata service. |
| SSRF on project import via the remote_attachment_url on a Note | A user account | The attacker's own | Project import caused the application server to make requests to attacker-chosen or internal destinations. |
| Server Side Request Forgery mitigation bypass | A user account | The attacker's own | A webhook request reached internal network addresses and returned their responses. |
| Blind SSRF to internal services in matrix preview_link API | No account | No object involved | The public preview API made requests from the server to internal services. |
| TURN server allows TCP and UDP proxying to internal network, localhost and meta-data services | Not clear from the report | No object involved | The TURN relay forwarded attacker-controlled traffic into internal networks, including localhost and metadata services. |
| SSRF leaking internal google cloud data through upload function [SSH Keys, etc..] | Not clear from the report | No object involved | The upload feature reportedly enabled requests from the application server to internal cloud resources. |
| Full read SSRF in www.evernote.com that can leak aws metadata and local file inclusion | No account | No object involved | A public fetch endpoint accessed local files and internal network resources from the server. |
| SSRF in graphQL query (pwapi.ex2b.com) | Not clear from the report | No object involved | A caller-controlled URL caused the application server to make outbound requests. |
| Unauthenticated blind SSRF in OAuth Jira authorization controller | No account | No object involved | An unauthenticated caller caused the application server to make a request to an attacker-selected destination. |
| SSRF in webhooks leads to AWS private keys disclosure | A user account | The attacker's own | A webhook delivery crossed from the public-facing application to cloud metadata and returned the response to the attacker. |
| Stored XSS & SSRF in Lark Docs | Not clear from the report | No object involved | Stored document content could cause a server-side browser to make requests from the server. |