PayPal code flaw exposed SSNs and user PII for six months via access control failure, triggering fraud risk and regulatory scrutiny.

Continue reading
PayPal has disclosed that a prolonged exposure of sensitive customer data on its PayPal Working Capital (PPWC) loan platform was caused by an application-level coding defect. The flaw persisted for nearly six months — from July 1, 2025 to December 13, 2025 — allowing unauthorized parties to retrieve highly sensitive personally identifiable information (PII), including Social Security numbers and dates of birth. The incident highlights deep weaknesses in application access control, change governance, and monitoring frameworks in fintech systems.
PayPal’s formal breach notification reveals that a software change in the PPWC loan application interface inadvertently relaxed access controls, resulting in unauthorized access to PII associated with roughly 100 customers. The impacted dataset included:
The erroneous code was rolled back within a day of discovery, and PayPal reset account credentials for affected users. The company also offered two years of three-bureau credit monitoring through Equifax.
Initial analysis indicates the breach resulted from an application logic regression introduced by a code change, not from an infrastructure-level intrusion. In technical terms, the flaw falls into the category of Excessive Data Exposure / Broken Access Control, a variant of the OWASP API Security Top 10 risk model where APIs return more data than permitted. The coding change likely removed or weakened predicates that validate whether a requestor is authorized to fetch specific PII fields.
This kind of defect does not require credential theft, SQL injection, or privilege escalation. Instead, attackers or automated tools can simply make requests to an endpoint that now returns sensitive fields. Because the defect existed at the application layer, traditional network-level defenses would not detect it.
For six months, the misconfiguration remained in production without detection. This suggests gaps in one or more of the following areas:
In mature DevSecOps environments, these defenses are standard. Their absence here points to systemic oversight in application change governance.
From a threat modeling perspective, the compromised vector can be summarized as follows:
Unlike SQL injection or remote code execution, this flaw required no privilege escalation. Public details do not confirm whether the flaw was actively exploited by multiple actors, but a “small number” of unauthorized transactions suggest at least some exploitation before patching.
Exposed SSNs and DOBs are classified as high-sensitivity identifiers. Unlike dynamic tokens or transactional data, SSNs are permanent, allowing attackers to:
PayPal reported that unauthorized transactions took place on a subset of affected accounts and were subsequently refunded. While refunds mitigate immediate financial loss, the exposure of permanent identifiers presents long-term risk beyond these transactions.

A third-party software flaw inside one of Japan's largest telcos exposed login credentials for up to 14.2 million email accounts across six ISPs. The passwords? Some were hashed. Some may not have been