Major US Carrier Stored Customer Credit Card Data in Plaintext, New Hire Discovered on First Day
A newly hired database administrator at a major US cellular carrier discovered that the company stored customer PII, including full credit card numbers and CVVs, in plaintext on a production database.
A major US cellular carrier stored customer personally identifiable information (PII), including full 16-digit credit card numbers and CVVs, in plaintext on a production database, according to a report published by The Register. The exposure was discovered by a newly hired database administrator (DBA) on her first day of work, after she was granted sudo-level access to the company's main production server.
The DBA, identified under the pseudonym "Joker," was hired on the spot after a successful interview and within hours was given full administrative privileges to a database server. She was instructed to "take a look" at some of the databases, and quickly found herself accessing the main production server for the company's data services division, which oversaw all services for the mobile web. This incident occurred in the mid-2000s, before the iPhone era, when mobile web services were delivered via compressed versions of websites for BlackBerries and flip phones.
Upon exploring the database, Joker discovered that she had access to the master customer table, which contained a nightmarish trove of PII: names, addresses, Social Security numbers, billing information, and full 16-digit credit card numbers. All of this data was stored in the clear, with no encryption or obfuscation. CVVs were missing from some credit card entries, but many were present. The database was intended to provision new services without reaching back to the upstream billing system on Amdocs servers, but the decision to store sensitive data in plaintext represented a catastrophic security failure.
Joker immediately informed management about the security lapse. The carrier responded by deleting the offending data and forcing developers to query the upstream billing system for billing information, as they should have been doing all along. The remediation was swift but reactive, highlighting a fundamental lack of security awareness and a failure to implement least-privilege access controls.
The incident underscores several critical security lessons. First, the company violated the principle of least privilege by granting a new employee sudo-level access on her first day. Second, sensitive data such as credit card numbers and Social Security numbers should never be stored in plaintext; tokenization or encryption should be standard practice. Joker noted that tokenization, which links sensitive data to tokens stored in a secure vault, is common in payment systems and should have been implemented.
If Joker had been less ethical, or if another malicious actor had gained admin access, the consequences could have been devastating. The exposed data could have been exfiltrated and used for identity theft, financial fraud, or sold on the dark web. The carrier's failure to secure customer data represents a breach of trust and a violation of basic security principles.
Joker later moved on to work for a major online retailer, where security was front and center, demonstrating that some organizations did prioritize security even in the early 2000s. This incident serves as a cautionary tale for organizations today: security must be baked into every layer of the infrastructure, from access controls to data encryption. The carrier's reactive approach—deleting data only after discovery—is no substitute for proactive security measures.
The story, published in The Register's PWNED column, highlights the importance of security awareness and the need for organizations to implement robust data protection practices. While the incident occurred years ago, the lessons remain relevant: never store sensitive data in plaintext, enforce least-privilege access, and ensure that security is a priority from day one.