Unauthenticated Account Takeover of Any Subscriber via a Forgeable Login Token
The Risk
An attacker could log into the news company's subscription account area as any customer without knowing a password, without anything from the victim, and without the victim doing anything. The only thing needed was the customer's account number, and those numbers ran in a simple counting sequence, so every customer on the platform could be targeted one after another. Once inside, the attacker had full control: change the customer's address, email and phone, add or remove saved payment methods, stop their deliveries, export their personal data, or delete the account. The same flaw worked across more than one of the company's news brands.
The Vulnerability
The subscription self-service portal authenticated users through a backend identity service. Three of that service's endpoints, when chained, let an anonymous caller mint a valid login session for any user:
- A session-seed endpoint that issued a session token and a state value to any anonymous caller, with no credentials.
- A login-token mint endpoint that, given only a target user's external identity string, signed and returned a login token for that user. This endpoint never checked that the caller actually owned that identity.
- A token-exchange endpoint that bound the anonymous session to the victim identity once the forged login token was presented.
The user identity was a sequential integer (observed roughly in the one-million to twenty-million-and-up range), so the entire user base was reachable simply by counting. None of the mint endpoints required authentication, none rate-limited, and none used a challenge: a burst of repeated requests all succeeded.
A separate token endpoint also returned a customer reference field that was only populated for active paying subscribers, giving the attacker a way to filter the whole identity space down to paying subscribers before taking any account over.
The Attack
Minting a Victim Session
The full takeover ran as a short unauthenticated chain with no browser required:
- Call the session-seed endpoint to get a session token and a state value.
- Call the login-token mint with the victim's sequential identity and the brand id, receiving a signed login token for that victim.
- Present that login token to the exchange endpoint, which binds the session to the victim.
- Read the profile endpoint with the now-authenticated session and confirm it returns the victim's identity.
A control request proved the exchange was what established the session: a session token that had not been through the exchange returned an authorization error on every protected route.
Landing in the Browser
The same forged tokens could be injected into the in-scope portal's local storage, after which navigating to the account area rendered the authenticated victim view in place, displaying "logged in as" the victim's identity, in a browser that had never logged in.
Scale and Targeting
Sampling identities across the full range returned a valid token for every one, with no rate limiting. The subscriber-reference field on one of the token responses doubled as a subscriber-targeting oracle, so an attacker could narrow the sequential space to paying subscribers and then take over each in turn.
The Impact
The hijacked session was full account control, not read-only. It was authorized to invoke the portal's state-changing customer routes: change postal and invoice address, update profile, email and phone, add and remove stored payment instruments, share or grant subscription access, stop delivery, plus a full personal-data export and account-deletion flow. A control comparison confirmed these write routes reached the handler under the hijacked session and returned an authorization error without it.
The same chain took over the subscriber portal of a second in-scope news brand by switching the brand identifiers, so the blast radius covered multiple brands and the entire subscriber base of each.
Remediation
- The login-token mint must require authorization proving the caller owns the identity it is minting a token for. An anonymous caller must never be able to mint a login token for an arbitrary user.
- The session seed and the exchange must not let an anonymous caller bind their session to an arbitrary identity.
- Add authentication, rate limiting, and abuse detection on all three endpoints in the chain.
- Stop returning a subscriber-status field on an unauthenticated endpoint, since it acts as a targeting oracle.
- Use non-sequential, unguessable user identifiers so the user base cannot be enumerated by counting.