SNI proxy SSRF vulnerabilities: Misconfigurations, exploitation, and defense

Misconfigured reverse proxies have long been a source of subtle but serious security issues. One lesser-known example is SNI proxy SSRF – a class of vulnerabilities where routing decisions based on TLS metadata can be abused to access unintended backend systems.

What was once considered a fairly niche misconfiguration has become more relevant in modern environments. Research over the past few years has shown that, under specific conditions, SNI-based routing can be used to reach sensitive cloud services such as instance metadata endpoints. At the same time, changes in protocols and tooling have shifted how defenders should think about this risk.

This article explains what SNI proxy SSRF is, when it becomes exploitable, and what practical steps security teams can take to reduce exposure.

What is SNI proxy SSRF?

Server Name Indication (SNI) is a TLS extension that allows a client to specify the hostname it wants to connect to during the initial handshake. This enables multiple domains to share the same IP address while still presenting the correct certificate.

An SNI proxy – more accurately, a load balancer or TCP proxy using SNI – inspects this value and uses it to decide which backend system should handle the connection. This typically happens before any HTTP request is processed, at the TLS handshake or TCP routing layer rather than the application layer.

If the SNI value is used too directly in routing logic, security problems arise. When an attacker can influence the SNI field and the proxy maps that value to a backend destination without strict validation, the proxy can be turned into a forwarding mechanism. In effect, it becomes a server-side request forgery (SSRF) primitive.

This attack pattern was originally explored in earlier Invicti research on SNI proxy misconfigurations – see the analysis by Aleksei Tiurin for a deeper technical walkthrough of proxy configurations and routing behavior.

Instead of just sending requests to intended application backends, a vulnerable setup may allow an attacker to:

• Route traffic to internal services
• Access management interfaces
• Reach cloud metadata endpoints
• Interact with systems that are otherwise not exposed externally

While it’s conceptually similar to reverse proxy SSRF at the HTTP layer, SNI proxy SSRF operates earlier in the connection lifecycle and can bypass controls that assume HTTP-level visibility or validation.

Why SNI proxy misconfigurations matter today for AWS and Azure

SNI proxy misconfiguration vulnerabilities are no longer just an edge-case concern. Published proof-of-concept research has shown that misconfigured SNI proxies can be used to reach AWS and Azure instance metadata services under specific deployment conditions, as demonstrated in AWS IMDSv2 exploitation research and extended to Azure environments in subsequent research on Azure metadata access.

These attacks typically require the proxy to:

• Terminate TLS or otherwise allow attacker-controlled HTTP requests
• Forward traffic to port 80
• Omit blocking headers such as X-Forwarded-For
• Resolve attacker-controlled hostnames to metadata endpoints

Cloud metadata services often expose highly sensitive information, including credentials, tokens, and configuration data.

SNI proxy SSRF on AWS

AWS IMDSv2 uses a session-oriented flow: a PUT request to /latest/api/token with the X-aws-ec2-metadata-token-ttl-seconds header obtains an instance-specific token, and subsequent requests include that token.

In an SNI proxy SSRF scenario, exploitation requires the proxy to allow the necessary methods and headers through. AWS rejects IMDSv2 token requests that contain an X-Forwarded-For header, and the default IMDSv2 response hop limit can prevent token responses from crossing additional network hops. In practice, a proxy running on the same instance is a more realistic risk than a remote intermediary.

AWS has also moved toward IMDSv2-by-default in newer instance types and launch configurations, but existing environments and some configurations may still allow IMDSv1 unless explicitly restricted.

SNI proxy SSRF on Azure

Azure IMDS exploitation has similar constraints but different protocol details. Azure metadata requests require the Metadata: true header and must not include X-Forwarded-For. Token exposure is only high-impact when a managed identity is enabled and has useful permissions.

Published research shows that exploitation is possible when an SNI proxy terminates TLS, forwards HTTP to port 80, allows attacker-controlled headers, and resolves attacker-controlled hostnames to the metadata endpoint.

The key takeaway is that SNI proxy SSRF is now not just about misrouting traffic – it can become a path to high-impact cloud compromise when combined with specific proxy behaviors and deployment patterns.

When do SNI proxy misconfiguration vulnerabilities become exploitable?

Not every SNI-based routing setup is vulnerable. Exploitation depends on a combination of configuration choices and environmental factors.

A common example is an SNI proxy that maps *.example.com dynamically to backend hosts using the supplied hostname. If DNS resolution is not tightly controlled, an attacker could supply a hostname that resolves to an internal IP such as a metadata service, causing the proxy to forward the connection internally.

The most common SNI proxy risk patterns include:

• Direct mapping of SNI values to backend destinations: If the proxy constructs upstream destinations directly from values such as $ssl_preread_server_name or $ssl_server_name without strict allowlisting, attackers may be able to control where traffic is sent.
• Insufficient validation of allowed backends: If there is no strict allowlist of backend systems, or if DNS resolution is not tightly controlled, attacker-supplied hostnames may resolve to internal or sensitive services.
• TLS termination with flexible forwarding: When the proxy terminates TLS and forwards decrypted traffic, it may allow attacker-controlled methods and headers to reach internal services.
• Reachability of internal or cloud services: The proxy must be able to reach the target systems. In cloud environments, this often includes metadata endpoints such as 169.254.169.254.
• Lack of defensive controls in the proxy layer: If the proxy does not enforce restrictions such as blocking sensitive destinations or validating upstream targets, it may forward requests that should never leave the edge.

Note that these conditions can arise in dynamic routing, containerized, cloud, and multi-tenant environments.

The impact of modern cloud environments in SNI proxy risks

Cloud platforms amplify the risk of SNI proxy SSRF because they introduce high-value internal services that are reachable from application infrastructure.

Instance metadata services are the most prominent example. They are designed to provide applications with credentials and configuration data without exposing them externally. However, they rely on the assumption that access is limited to software running within the instance or VM network context. When a proxy is misconfigured, that assumption can break down.

Because these services are not exposed over the public internet, traditional perimeter defenses offer limited protection once an edge proxy is able to route traffic inward. Other controls – such as egress filtering, security groups, host firewalls, and metadata service protections – still play an important role.

Why SNI-based routing is becoming harder to rely on

SNI proxy SSRF also needs to be understood in the context of broader changes in tooling and protocols. These changes don’t just introduce new risks – they make SNI-based routing itself a less stable and reliable design choice.

One example was the disclosure of CVE-2023-25076 in the widely used sniproxy project. This critical vulnerability affected wildcard backend configurations and allowed specially crafted traffic to trigger a buffer overflow and potentially achieve remote code execution – the same configuration pattern that often enables SNI proxy SSRF. While this was patched and some downstream distributions shipped fixes, the project has since been deprecated by its maintainer as no longer necessary with the other proxy tools now available.

These issues highlight a broader point: SNI-based proxying is not only sensitive to misconfiguration but can also be fragile at the implementation level.

At the same time, protocol changes are making simple SNI-based routing less dependable. HTTP/2 connection coalescing allows requests for multiple origins over a single TLS connection under specific certificate, authority, and origin conditions, which weakens the assumption that one connection maps cleanly to one hostname. HTTP/3 further changes deployment assumptions by moving HTTP semantics onto QUIC over UDP, which may bypass or complicate TCP-only SNI proxy designs.

Encrypted Client Hello (ECH), standardized as RFC 9849, goes even further by encrypting the inner TLS ClientHello, including the true server name, while exposing only an outer/public name used for routing to the ECH-capable service. This reduces the reliability of plaintext SNI for routing decisions and makes architectures that depend on it increasingly brittle.

Taken together, these developments mean that SNI-based routing is not just risky when misconfigured – it is also becoming a less viable long-term pattern. Existing implementations should be reviewed carefully, and new designs should avoid relying on plaintext SNI for security-sensitive routing decisions.

How to reduce the risk of SSRF with SNI proxies

Mitigating SNI proxy SSRF is primarily about controlling how routing decisions are made and ensuring that proxies cannot be used to reach unintended destinations. While no single fix will eliminate the risk entirely, there are several defensive practices to minimize it:

• Avoid direct use of client-controlled values in routing logic: Do not construct upstream destinations from values such as $ssl_preread_server_name, $ssl_server_name, Host, or :authority without strict allowlisting.
• Enforce allowlists for backend systems: Only permit routing to explicitly defined and trusted destinations. Avoid wildcard mappings and dynamic resolution wherever possible.
• Block metadata endpoints at multiple layers: Restrict access to metadata services such as 169.254.169.254 and, where applicable, IPv6 endpoints like fd00:ec2::254 using proxy rules, host firewalls, and cloud controls.
• Harden DNS resolution paths: Ensure that backend resolution cannot be influenced by untrusted input.
• Understand proxy behavior at the HTTP layer: Be aware of how your proxy handles methods and headers after TLS termination. Header injection or forwarding behavior can directly impact exploitability.
• Limit proxy capabilities with care: Non-terminating TCP forwarding may prevent HTTP-level manipulation against metadata services, but it can still enable arbitrary TCP connectivity to internal HTTPS services.
• Use cloud-native protections: For AWS, enforce IMDSv2 using account defaults, AMI settings, IAM policies, and instance metadata options. For Azure, use least-privilege managed identities and track developments such as the Metadata Security Protocol for hardened environments.
• Monitor and test edge infrastructure: Reverse proxies and load balancers should be treated as part of the application attack surface and included in security reviews.

Why SNI proxy SSRF often goes unnoticed

SNI proxy SSRF sits at the intersection of networking, TLS, and application security, which makes it easy to overlook as someone else’s problem.

In many organizations, reverse proxy configurations are treated as infrastructure concerns rather than part of the application attack surface. Application security teams often focus on HTTP-level behavior, while infrastructure teams manage proxy routing.

Because the routing decision happens at the TLS layer, logs and monitoring systems that focus on HTTP traffic may never capture the malicious request path. Without visibility into this layer, it is easy to miss how client-controlled values influence routing decisions.

The result is a low-visibility issue that can persist unnoticed in otherwise mature environments.

Practical takeaways for application security testing

The risk of SNI proxy SSRF highlights a broader lesson: the application attack surface extends beyond the application itself. Edge components such as reverse proxies, load balancers, and API gateways can introduce vulnerabilities when they make routing decisions based on client-controlled data.

Testing should also include edge-routing behavior, not only application routes. This means checking whether SNI, Host, and :authority can be desynchronized, whether wildcard backend rules perform unsafe DNS resolution, and whether outbound requests can reach internal or metadata addresses.

Automated scanning can help identify SSRF behaviors in applications, but SNI proxy SSRF often also requires configuration review and targeted testing of the proxy layer. Tools such as Acunetix can support this process by identifying SSRF-related issues in exposed applications that may be combined with misconfigurations at the edge.