SSRF at HelloSign leads to AWS private key disclosure

A single unvalidated URL parameter on HelloSign's document-signing platform handed a researcher the keys to Dropbox's AWS environment - temporary cloud credentials delivered directly from the instance metadata service.

The Target

HelloSign (now Dropbox Sign) is an e-signature platform acquired by Dropbox. Hosted at app.hellosign.com, it processes sensitive legal documents on behalf of businesses and individuals. Like many SaaS platforms, it offers functionality that fetches remote resources on the user's behalf - and in this case, that functionality contained an SSRF vulnerability that exposed the underlying AWS infrastructure.

The Vulnerability

The bug was a Server-Side Request Forgery (SSRF) in a document-related endpoint that accepted a user-supplied URL. The HelloSign server fetched the remote URL without validating whether the destination was a legitimate external host or an internal/cloud-reserved address.

The prize target was 169.254.169.254 - AWS's Instance Metadata Service (IMDS). This link-local address is reachable only from within an EC2 instance. It requires no authentication and, on instances using the original IMDSv1, responds to simple GET requests with sensitive data: IAM role names, temporary AccessKeyId / SecretAccessKey / SessionToken credential sets, and other instance-level configuration.

Because the HelloSign application server was an EC2 instance, it had access to the metadata service by design. The SSRF turned a feature meant to fetch documents into a credential-exfiltration tool.

How It Was Found

The researcher identified a URL parameter that the HelloSign backend consumed server-side. Standard SSRF discovery followed: confirm the server makes outbound requests using a callback host, then pivot to internal addresses.

An illustrative request targeting the metadata endpoint:

POST /api/v1/document/import HTTP/1.1
Host: app.hellosign.com
Authorization: Bearer <api_key>
Content-Type: application/json
 
{
  "file_url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
}

The server's response - reflecting the content fetched from the metadata endpoint - would reveal the name of the IAM role attached to the instance. A follow-up request to http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME then returned the full temporary credential set.

Impact

• The researcher confirmed retrieval of temporary AWS IAM credentials (AccessKeyId, SecretAccessKey, SessionToken) for the IAM role attached to Dropbox's HelloSign production EC2 instance.
• These credentials could be used immediately with the AWS CLI or SDK to perform any action permitted by the IAM role's policy - potentially including access to S3 buckets storing signed documents, access to other AWS services in the account, and lateral movement.
• Dropbox awarded a bounty of $4,913, reflecting the high severity of live credential exposure on a production cloud instance.
• User documents, signing data, and any secrets accessible by the IAM role were at risk.

The Fix

Remediation must address the SSRF at both the application and infrastructure levels:

1. Validate and allowlist URL destinations - document import should only accept URLs from trusted external sources, never from RFC 1918, loopback, or link-local (169.254.0.0/16) ranges.
2. Migrate to IMDSv2 - AWS's token-based metadata service requires a PUT request to obtain a session token before any metadata can be read. A basic GET-based SSRF cannot retrieve the token and therefore cannot access the metadata service.
3. Apply restrictive IAM role policies - the instance role should follow least-privilege; it should not have more permissions than the application strictly requires.
4. Enforce network-level egress controls - security groups and NACLs should block outbound requests from application servers to 169.254.169.254 and internal subnets.
5. Perform remote fetches in an isolated execution environment with no metadata service access and no route to internal infrastructure.

What You Can Learn

• 169.254.169.254 is always the highest-priority SSRF target in cloud environments. It is reachable only from within the instance, requires no authentication under IMDSv1, and hands the attacker live AWS credentials.
• IMDSv2 is a direct mitigation for this attack class. Enforcing IMDSv2 (by setting HttpTokens: required on EC2 instances) raises the bar significantly - a basic SSRF cannot satisfy the token-request flow.
• SSRF in SaaS acquisitions is a common finding. Acquired products often have independent security postures; the acquiring company's infrastructure becomes the blast radius when the acquired product has SSRF.
• Temporary credentials are still serious. They expire, but typically have a multi-hour validity window - more than enough time to enumerate permissions, exfiltrate data, or establish persistence.
• Bug bounty scope includes acquired products. When testing a large company's program, map out all subdomains and acquired services; they may have weaker controls than the flagship product.