Missing Auth on Chatbot Subscription Endpoint Enables Mass Phone-to-SIM Lookup of National Carrier Subscribers

The Vulnerability

Six chatbot backend endpoints accepted unauthenticated POST requests and returned live subscriber records keyed by either the customer's phone number or their SIM card identifier. The frontend application generated a session-id-shaped string in the browser and sent it in every request body, but the backend never validated it. No authorization header, cookie, or token was ever sent or required.

Frontend code from the public chatbot bundle:

function generateSessionId() {
  return `${new Date().toJSON().slice(0, 10).replaceAll(/-/g, "")}-${random()}`
}
const body = { sessionId: generateSessionId(), ... }
const result = await axios.post(checkSubscriptionUrl, body)

The server accepted any string in sessionId. Setting the platform field to the brand identifier was the only requirement for the lookup to resolve against the live subscriber database.

The Attack

All testing was performed against a researcher-owned line on the carrier. Per-target field data was not inspected, logged, or retained for any number other than the researcher's own.

Phone number to SIM card lookup

A POST with a phone number returned the live subscription record: current SIM card identifier, terminated prior SIM identifiers, service type (prepaid or postpaid), SIM type (physical or eSIM), status (active, terminated, suspended), plan expiry, sales channel code, and last status code. The terminated prior SIM identifiers reveal that the customer has changed SIMs in the past and when.

SIM card identifier to phone number lookup

The same endpoint accepted a SIM card identifier and returned the live phone number, plan expiry, sales channel, SIM type, and status. SIM card identifiers are printed on physical SIM cards, embedded in eSIM activation QR codes, and visible in carrier store inventory. A photographed or stolen SIM resolves directly to its owner's phone number.

Internal account identifier leak

A separate getUserInfo endpoint, given a phone number, returned an internal self-care account identifier that encoded the exact provisioning timestamp and the provisioning batch source. This is a stable cross-system identifier per subscriber.

Auxiliary financial and behavioural lookups

Three more endpoints exposed: bounced-payment status (a financial-distress signal), overseas roaming status (a travel-pattern signal), and refund eligibility with offer details. Together these enable fine-grained victim selection.

Enumerability proof

A controlled probe of 100 sequential phone numbers around the researcher's own (50 either side, throttled to 2 requests per second) returned 21 real subscriber records with zero rate-limit responses, zero CAPTCHA, and zero authentication challenges. Average response time was around 400 ms, consistent with real database lookups. Per-number field values were discarded immediately; only aggregate hit/miss counts were retained.

A 21 percent hit rate in a small contiguous range, combined with the country's mobile address space and the absence of throttling, demonstrates that an unauthenticated attacker can sweep the entire subscriber base without operational difficulty.

Cross-host parity

Two public hostnames fronted the same backend and returned byte-identical responses to every request. One vulnerability, two brand customer bases.

The Impact

Per-target data exposed unauthenticated, given only a phone number or a SIM card identifier:

• Phone number to SIM card identifier resolution and the reverse
• Current SIM card identifier and the full history of SIMs the customer has had on the line
• Service type, SIM type, current status, and plan expiry date
• Sales channel code (revealing specific retail outlet or online provisioning)
• Internal self-care account identifier with provisioning timestamp and batch source
• Bounced-payment status (financial distress)
• Overseas roaming and travel status
• Refund eligibility and refund offer details

Real attack scenarios

1. Mass extraction. Iterate the country's mobile address space against the lookup endpoint and build a database mapping every subscriber's phone number to their SIM identifier, plan, account history, payment status, and roaming status
2. SIM-swap social engineering. Walk into a retail store, claim to be the customer, prove identity by quoting their SIM card identifier, prior SIM history, and original sales channel. Once the SIM is swapped, defeat SMS-based two-factor on every banking, social, and email account tied to the number
3. eSIM hijack reconnaissance. Stolen or photographed eSIM activation QR codes contain a SIM identifier. The lookup resolves it directly to the owner's live phone number
4. Targeted financial and behavioural profiling. Filter the harvested base for subscribers with bounced payments, subscribers currently roaming overseas, or prepaid lines expiring soon
5. Recent SIM-swap victim discovery. Records that show a recent terminated SIM followed by a new active one identify customers who recently changed SIMs, useful for follow-on fraud targeting

Remediation

• Require a server-issued, cryptographically signed token on every subscription, user-info, payment, roaming, and refund endpoint. The frontend-generated session string provides zero security and must be replaced with a token bound to a verified subscriber session, issued only after phone-number ownership is proven via a one-time code sent to that number and validated server-side
• Apply strict per-IP and per-phone-number rate limiting on subscriber lookup endpoints. The current zero-throttle behaviour allows mass extraction
• Remove the SIM card identifier from the response. The bidirectional phone-number-to-SIM lookup has no legitimate chatbot use case and is a direct SIM-swap enabler
• Remove the internal self-care account identifier from responses, or require authentication to receive it
• Remove historical and terminated subscription records from the response. Even after authentication is added, only the active subscription should be returned
• Suppress backend stack traces from API error responses. The current null-customer error path leaks internal class paths and DTO names