Phone Number Becomes Full Customer File at an Insurance Company
The Risk
Anyone on the internet with a list of phone numbers could turn each number into the matching insurance customer's full file: legal name, date of birth, email, home address, and live policy number. A phone number that did not belong to a customer simply returned an empty result, so the endpoint also worked as a way to check which numbers in any list belonged to customers of the insurer. Phone numbers appear in every data breach corpus already, so this turns a public identifier into a private dossier across all five sibling brands at once.
The Vulnerability
The message-centre endpoint accepted a contact phone number as a query parameter and returned the matching customer's history. It required only an anonymous bearer token, mintable by anyone from a no-auth endpoint. It had no ownership check, no challenge, and no rate limit at one request per second.
Each response entry contained the brand name and the customer's internal customer number. That customer number then chained into the retrieve-quote, home, and car services to unlock the full record, using a separate, previously reported skip-verification flag on the retrieve-token endpoint.
The endpoint distinguished customer numbers from non-customer numbers by response body shape: populated array for a customer, empty array for a non-customer, identical HTTP status either way. That alone makes it a phone-number validity oracle for the insurer's customer base.
The Attack
Mint a token
One unauthenticated call returned a bearer token usable across all downstream calls.
Probe a phone number
For each candidate Australian mobile, the message-centre endpoint returned either a populated list of customer records (each with a brand identifier and an internal customer number) or an empty list. The proof of concept used two real customer mobiles, both of which returned populated lists. One of the two surfaced three records spanning two different sibling brands from a single call.
Chain each customer number to full PII
For each customer number, the retrieve-token endpoint (with the previously reported skip-verification flag) returned a per-quote token. Calling the relevant product endpoint then returned the full record. Four full PII records were extracted across two distinct customer mobiles in a single browser session against the live host, including:
- Primary policyholder name, date of birth, email, and mobile
- Secondary policyholder name and date of birth
- Full residential address
- In-force policy number, lead state, contents insured amount, specified-valuables total, annual premium
- Driver profile fields (gender, marital status, employment status)
Scale
A bounded 80-candidate validity sweep returned two populated arrays and 77 empty ones, with zero throttling across the sweep. Hit rate against random Australian mobiles was around one percent per attempt. Against a breach-derived list of real Australian mobiles, the effective hit rate trends to 100 percent.
Cross-feed with the quote-number oracle
This finding chains with a previously reported quote-number enumeration oracle on the same host. That oracle produces valid quote numbers with no prior input. Each yields a record that contains the customer's mobile, which feeds back into the message-centre endpoint to fan out to every historical customer number that mobile owns across all five sibling brands. End to end, the attacker starts with zero knowledge and ends with full cross-brand PII fan-out.
The Impact
- Convert any Australian mobile number into the matching insurance customer's full PII record, with no authentication, no ownership proof, no challenge, no rate limit.
- Phone-number validity oracle: enumerate which numbers in any list belong to the insurer's customer base, before doing anything else.
- Coverage spans all five sibling brands. Cross-brand fan-out via the same internal customer numbers.
- Direct regulatory exposure under the Australian Privacy Act and the notifiable data breaches scheme.
- Large-scale identity-theft and fraud enablement, plus targeted-burglary risk via residential addresses and contents valuations.
Remediation
- Require an authenticated customer session on the message-centre endpoint. Anonymous bearer tokens must not unlock customer-keyed lookups.
- Stop returning customer history for arbitrary contact-number queries. The endpoint should only return data for the calling customer.
- Normalise responses to avoid the populated-versus-empty distinguisher even when behind authentication.
- Apply strict per-source rate limiting and anomaly alerting on lookup endpoints keyed by user-supplied contact identifiers.
- Fix the separate quote-retrieval skip-verification flag (reported as its own finding). The two chained together turn a public phone number into full PII.
- Forensic review of access logs to identify the affected customer set for breach-notification purposes.