"take a look," the hiring manager told her — and within hours the new hire had sudo-level access to a live production database that contained customer records in the clear.
Sudo-level access to a production server on day one
According to an account published in the PWNED column, a database administrator who asked to be identified as "Joker" described being hired on the spot by one of the USA's leading national cellular carriers and given sudo access to a database server almost immediately. Management "instructed her to 'take a look' at some of the databases," the account says, and those instructions landed her on the main production server for the carrier's data services division.
Master customer table revealed full PII and payment numbers in plaintext
Joker says the table she found — the carrier's master customer table — contained large volumes of personally identifiable information stored without encryption or obfuscation. The record set reportedly included names, addresses, Social Security numbers, billing information, and full 16-digit credit card numbers. The story notes that CVVs were missing from some credit card entries but that many CVVs were present.
Amdocs upstream billing and duplicate payment data
Joker told the reporter: "There was a central billing system upstream on Amdocs servers, but this database also had billing details so they didn't have to reach back upstream to Amdocs if users asked to provision new services." In other words, billing data was duplicated locally to avoid calls to the central Amdocs system, creating an additional, wide-scope repository of sensitive financial and identity data.
Immediate remediation: deletion and a return to upstream lookups
After Joker informed management of what she had found, the company deleted the offending information from the local database and required developers to "go upstream again for billing information," according to the account. That change removed the local duplicate billing details and restored the intended upstream calls to the Amdocs system for provisioning and billing lookups.
How DBAs, procurement leaders, and end users should read this
- DBAs and security teams: Joker assumed — reasonably, by her account — that access to such a table would be tightly controlled and that tokenization would be used to separate PII and payment numbers from customer names and addresses. The account single-handedly illustrates the risk when typical protections (least privilege, token vaults) are bypassed or not implemented.
- Procurement and engineering leads: The presence of duplicate billing data upstream of Amdocs was an architectural choice that simplified provisioning at the cost of broadening the attack surface. The firm-level fix reported in the story was to eliminate the duplicate and force applications to rely on the central Amdocs system again.
- Customers and the public: The record described in the account contained unencrypted Social Security numbers and full credit-card numbers. Joker warned that if an administrator with fewer scruples had gained the same access, they "could have exfiltrated large amounts of sensitive data," underscoring the stakes for affected subscribers.
Contextual notes from the account and a closing observation
The episode took place in the era before the iPhone — the column explicitly places the story in the George W. Bush era — and the author remarks that tokenization is "common in payment systems." The account also notes that Joker later moved to work for a major online retailer where security practices were "front and center," suggesting that some organizations did implement stronger controls even then.
The incident, as described, is a concise case study in three recurring operational failures: excessive privilege on production systems, storage of highly sensitive information in plaintext, and architectural shortcuts that multiply points of exposure. The immediate corrective step reported — deleting the local payment data and forcing upstream lookups to Amdocs — removed the duplicate repository, but the account leaves the broader governance and access-control lapses visible: a new hire with sudo rights, a live-production environment opened for casual inspection, and a chief reliance on manual reporting to surface the problem.
For readers weighing the facts laid out in the PWNED column, the core question the episode poses is procedural: how did a major carrier authorize wholesale access to a production master table to a newly hired DBA, and what controls were enacted afterward to prevent a repeat? The answer in the published account is simple and specific — deletion of the duplicate data and a return to upstream billing calls — but the episode itself stands as a reminder that controls, tokenization, and least-privilege policies matter not in abstract but in the everyday configuration decisions that enable or block mass exposure of customer records.
