Full Disclosure mailing list archives
Amplitude customers using domain proxies should update their configuration immediately.
From: shed riot
Date: Tue, 21 Jul 2026 09:17:13 +0100
After receiving live analytics requests intended for `api2.amplitude.com`, I contacted `security () amplitude com` and was invited to submit the issue through Amplitude's private Bugcrowd programme. In my view, Amplitude's handling of the report, including closing it as "Not applicable" despite evidence of intercepted customer traffic, caused by insecure configurations and documentation, constitutes a negligent approach to protecting customer data, and a bad-faith bug bounty programme. Two conditions combined to make interception possible. 1. Stale DNS and ephemeral IP reuse Amplitude infrastructure used ephemeral addresses from an AWS public IP pool. After an address was released, it could be reassigned to another party, while systems with a cached DNS answer continued sending traffic to it until the cached record expired. This is not a conventional dangling-CNAME takeover. It is an IP "afterlife" condition involving stale DNS resolutions and recycled public-cloud addresses. 2. Missing upstream TLS certificate validation Amplitude's documentation recommends using a domain proxy to front its services. However, its example NGINX configuration does not enable validation of the upstream TLS certificate. Similar certificate-validation gaps also exist in default or commonly deployed configurations for some cloud load balancers, CDNs and WAFs. Consequently, affected customer proxies accepted invalid or self-signed certificates when forwarding requests towards `api2.amplitude.com`. The combination of stale address resolution and missing certificate validation enabled traffic intended for Amplitude to be intercepted by a party controlling a reassigned cloud address. The duration and full scope of the exposure are not known. The sample intercepted traffic provided privately to Amplitude contained requests originating from the following sites: * `www.f5.com` * `uplatform.team` * `mystylus.ai` No captured traffic, identifiers, payloads or user data are being disclosed. Timeline: * 26 June 2026: Contacted `security () amplitude com`. * 9 July 2026: Received an invitation to Amplitude's private Bugcrowd programme and submitted the report. * 16 July 2026: Amplitude disputed that the evidence demonstrated interception. * 17 July 2026: I clarified that the requests contained data categorised as personal data in Amplitude's own documentation, including persistent device identifiers, session identifiers and linkable usage data. * 18 and 20 July 2026: Reported additional batches of live traffic. * 20 July 2026: Identified that Amplitude's recommended NGINX domain-proxy configuration omitted upstream certificate validation. * 21 July 2026: Amplitude acknowledged that the captured traffic had passed through customer domain proxies that did not validate upstream certificates. Bugcrowd subsequently closed the report as "Not applicable". Recommended action: Amplitude should contact affected customers, advise them of the potential interception of personal data, review its DNS and load-balancer architecture, and revise its domain-proxy documentation so that upstream certificate and hostname validation are enabled by default. Customers should enable certificate-chain and hostname validation on every HTTPS connection from a proxy, CDN, WAF, service mesh or load balancer to Amplitude. Customers should also review DNS caches and forwarding logs, identify traffic sent to previously assigned cloud addresses, assess whether analytics events were intercepted or lost, and rotate any sensitive values present in affected requests. _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/
Current thread:
- Amplitude customers using domain proxies should update their configuration immediately. shed riot (Jul 22)