The profile API trusted a client-supplied debug role header. With that header set, an unauthenticated request was treated as a privileged reader and the response included another user's legal name, email, date of birth, and home city and country.
The edge cache keyed on the URL and did not include that header. A personalized response was stored and then served to a later request that did not send the header. Repeating the plain request was enough to hit the cached copy. A request with no header and a cache miss did not return the profile. That is the negative control.
What we proved
Real profile fields for other users, first with the header, then without it once the response had been cached. The same user id without a warm cache entry did not leak.
What this is not
Not a write, not an account takeover, and not a full database dump in one call. It is unauthenticated read of identity fields the product does not show on the public profile, amplified by the cache.
Why a scanner misses it
The header looks like an internal test switch. A single unauthenticated request often misses, because the leak depends on a cached variant. Tools that do not vary cache state call the endpoint safe.
Buyer takeaway: A debug role header is a credential. If a cache sits in front of it, the header has to be part of the cache key, or the response must not be cacheable.
