Prosper Marketplace Database Breach: Unauthorized Queries Exfiltrate Borrower Data for Three Months

Prosper Marketplace, Inc., one of the largest peer-to-peer lending platforms in the United States with over $24 billion in loans originated since 2005, disclosed a data breach on December 9, 2025 after attackers queried customer and applicant databases for three months before detection. The California Attorney General filing confirms that between June and August 2025, unauthorized actors obtained personal information through database queries, though the notification letter does not specify the number of affected individuals or the exact data fields compromised. Prosper discovered the breach on September 1, 2025 -- 30 days after the final unauthorized query -- and is offering an unusually long 24 months of credit monitoring, double the industry-standard 12 months, suggesting the company's risk assessment concluded the exposure warrants extended protection.

This is not a typical external attack. The notification letter describes "unauthorized activity on our systems" and references "queries on company databases that store customer and applicant data." This language -- queries, not bulk file downloads or ransomware encryption -- indicates the attackers had authenticated access to database systems and used legitimate query interfaces to extract data selectively. For a fintech platform like Prosper, which stores borrower financial profiles, credit histories, loan applications, and repayment records, database-level access represents total compromise of customer data.

Timeline: Three Months of Queries, Three Months to Notify

June-August 2025: Unauthorized actors executed queries against Prosper's customer and applicant databases. The notification letter does not specify how many queries, what data was targeted, or whether the activity escalated over time. The three-month window is long enough to suggest either a very stealthy intrusion or a gap in Prosper's database activity monitoring.

September 1, 2025: Prosper discovered the unauthorized activity. The letter states Prosper "acted quickly to stop the activity and enhance our security measures" the same day. Same-day containment after a three-month intrusion suggests the attackers either made a mistake that triggered an alert or Prosper deployed new monitoring tools that flagged historical anomalies.

September 1, 2025 (same day): Prosper engaged a "leading cybersecurity firm" to investigate and reported the incident to law enforcement. The immediate involvement of external investigators and law enforcement is standard for incidents of this scale at regulated financial services companies.

September-November 2025: Prosper analyzed the impacted data to determine which individuals' personal information was obtained. The notification letter describes this as "time consuming," consistent with a scenario where the attackers executed hundreds or thousands of individual queries rather than downloading a single file. Each query result would need to be reconstructed to identify affected individuals.

November 26, 2025: Prosper completed its data review, 86 days after discovering the breach. The three-month analysis period is on the longer end for fintech breaches, though not unprecedented for incidents involving fragmented data extraction.

December 9, 2025: Consumer notification letters went out, 99 days after discovery. This falls within California's "without unreasonable delay" standard (California Civil Code Section 1798.82), particularly where the delay is explained by the need to identify affected individuals.

March 31, 2026: Enrollment deadline for the complimentary Experian IdentityWorks credit monitoring. The four-month enrollment window (December to March) is longer than the typical 60-90 days, giving affected individuals more time to act.

The total timeline -- June intrusion to December notification -- is six months. While long, the delay is driven by the investigation and data review required to match query results to individuals. This is fundamentally different from a bulk file theft where a single CSV contains all affected records. That said, three months of undetected database queries at a company that processes loan applications and repayment data is a control failure. Prosper's database monitoring should have flagged unusual query patterns -- high volumes, after-hours access, queries by service accounts not associated with normal operations -- within days, not months.

What Data Was Exposed in the Prosper Breach

The notification letter is remarkably vague about what data was obtained. It states "data containing personal information was obtained through queries on company databases that store customer and applicant data" and includes a template variable indicating that specific data elements "were obtained" for each recipient. But the letter does not list those data types.

Based on Prosper's business model and regulatory disclosures, the databases queried likely contained:

Names, addresses, dates of birth -- required for all loan applicants
Social Security numbers -- collected for credit checks and IRS reporting
Income and employment information -- verified during underwriting
Bank account numbers -- for loan disbursement and repayment via ACH
Credit scores and credit report data -- obtained from bureaus and stored for underwriting decisions
Loan amounts, interest rates, and repayment histories -- transactional data for active borrowers
Application statuses -- approved, denied, withdrawn -- for all applicants

The fact that Prosper is offering 24 months of IdentityWorks, rather than the standard 12 months seen in breaches involving only names and account numbers, strongly suggests SSNs and other high-risk identifiers were in the compromised datasets.

The notification letter explicitly states "there was no evidence of unauthorized access to customer accounts and funds." This means the attackers did not log in to customer-facing dashboards or initiate fraudulent transactions. But if they extracted SSNs, bank account numbers, and financial profiles, they have everything needed for synthetic identity fraud, account takeover at other institutions, and targeted phishing attacks that reference the victim's Prosper loan details.

Prosper's databases also contain applicant data -- people who applied for loans but were denied or withdrew their applications. These individuals have no ongoing relationship with Prosper, may not remember applying, and will be surprised to receive breach notifications. This is a recurring issue in fintech breaches: companies retain rejected application data indefinitely, and when breached, they must notify thousands of people who thought their interaction with the platform ended years ago.

How the Attack Happened: Authenticated Database Access

The notification letter describes "unauthorized activity on our systems" and "queries on company databases." This is not ransomware, phishing, or malware. It is authenticated database access -- the attackers had credentials or exploited a vulnerability to query production databases directly.

There are several ways this could have occurred:

Compromised service account credentials: An attacker obtained a username and password for a database service account with read access to customer data. Service accounts are often poorly monitored, have overly broad permissions, and use static credentials that are not rotated regularly.
SQL injection vulnerability: A flaw in Prosper's web application allowed attackers to inject SQL commands and query the backend database. However, three months of sustained access via SQLi is unlikely -- automated scanners would typically be detected or application restarts would terminate sessions.
Compromised employee credentials: An attacker phished or purchased credentials for a Prosper employee with database access -- a data analyst, engineer, or customer support representative. This is consistent with the three-month timeframe, as the attacker could query data intermittently to avoid detection.
Insider threat: A Prosper employee or contractor with legitimate database access exfiltrated data. The letter does not mention any internal personnel actions, making this less likely.
Third-party vendor compromise: A contractor or integration partner with access to Prosper's databases was breached, and the attacker pivoted from that vendor's environment into Prosper's systems.

The letter does not specify which scenario occurred, likely because Prosper's forensic investigation could not definitively attribute the access method or because disclosing the root cause could invite further attacks.

What the letter does confirm is that the attackers used "queries" rather than bulk extraction. This suggests they were either:

Targeting specific high-value records (VIP customers, high loan balances) and cherry-picking data
Avoiding detection by querying small batches over time rather than downloading entire tables
Limited by their access level to query interfaces but not full database dumps

The fact that Prosper's data review took three months to identify affected individuals strongly supports the second scenario: thousands of small queries spread across June, July, and August, each returning a handful of records.

Database query logging should have flagged this. Any modern database platform -- PostgreSQL, MySQL, Microsoft SQL Server, Oracle -- can log all SELECT queries, track execution times, and alert on anomalies. If Prosper had query logging enabled and connected to a SIEM or database activity monitoring (DAM) tool, the three-month intrusion should have generated alerts. The fact that it did not suggests either the logging was not configured correctly, alerts were not tuned for this threat model, or the attacker modified their behavior to stay under thresholds.

This pattern of database compromise through authenticated access is increasingly common in fintech. The Lemonade, Inc. breach, disclosed in April 2025, also involved a vulnerability. The Payactiv, Inc. breach, disclosed days earlier, similarly referenced a technical vulnerability affecting database access. These are not isolated incidents -- they reflect a broader challenge in fintech security: rapid product development, frequent schema changes, and high employee turnover create environments where database access controls drift and monitoring gaps emerge.

Who Is Affected

The notification letter does not specify the number of affected individuals. Prosper's California AG filing would normally include this count, but the filing is not publicly searchable in detail. The company operates in all 50 states, so the affected population could span tens of thousands to hundreds of thousands of borrowers and applicants.

Prosper's business model creates two distinct affected populations:

Active borrowers: Individuals with current Prosper loans who have ongoing accounts, repayment obligations, and stored bank account information for ACH debits. These individuals are at risk for account takeover, fraudulent loan modification requests, and targeted phishing.
Applicants: People who applied for loans -- whether approved, denied, or withdrawn -- whose data remains in Prosper's systems. These individuals may not even remember applying, particularly if their application was denied years ago. They are at risk for identity theft and synthetic identity fraud using their SSNs and personal data.

Prosper has processed millions of loan applications since its founding in 2005. Even a 1% exposure rate would affect tens of thousands of individuals.

The notification letter's state-specific addenda reference California, District of Columbia, Iowa, Kentucky, Maryland, Massachusetts, North Carolina, New Mexico, New York, Oregon, Rhode Island, Arizona, Montana, Washington, and West Virginia -- at least 16 jurisdictions, indicating a nationwide impact.

Regulatory and Legal Implications

Prosper Marketplace is not a bank. It is a fintech platform that facilitates peer-to-peer lending by connecting borrowers with investors. Prosper does not hold deposits or issue loans directly; instead, it partners with WebBank, a Utah-chartered industrial bank, to originate loans that are then sold to investors. This structure creates a complex regulatory environment.

Prosper is subject to:

SEC regulation: Prosper's investment notes sold to lenders are securities registered with the SEC. The company files quarterly and annual reports (Forms 10-Q and 10-K) disclosing material risks, including cybersecurity incidents.
CFPB oversight: As a nonbank financial services provider involved in consumer lending, Prosper falls under the Consumer Financial Protection Bureau's supervision for compliance with consumer protection laws.
State lending laws: Prosper is licensed in most states as a loan broker or servicer, subject to each state's data security and breach notification statutes.
GLBA applicability: Though not a bank, Prosper is a "financial institution" under the Gramm-Leach-Bliley Act because it facilitates consumer financial transactions. The FTC's Safeguards Rule, updated in 2023, requires covered nonbank financial institutions to implement comprehensive information security programs, including encryption, access controls, and multi-factor authentication.

The three-month gap between the final unauthorized query (August 2025) and detection (September 1) suggests a potential Safeguards Rule deficiency. The updated rule specifically requires:

Monitoring and logging of system activity to detect unauthorized access
Periodic risk assessments identifying foreseeable internal and external risks
Incident response plans tested and updated regularly

The FTC can impose civil penalties for Safeguards Rule violations. Recent enforcement actions, including a $5.3 million settlement with Drizly in 2023 for inadequate data security, demonstrate the FTC's willingness to pursue nonbank fintechs for security failures.

Prosper's SEC disclosures will also come under scrutiny. Under the SEC's 2023 cybersecurity disclosure rules, public companies must disclose material cybersecurity incidents on Form 8-K within four business days of determining materiality. Prosper is not publicly traded, so this requirement does not apply directly, but private companies with registered securities must still include cybersecurity risk factors in offering documents.

State attorneys general in the 16+ jurisdictions affected may open investigations. California, New York, and Massachusetts have been particularly active in pursuing fintech data security cases. The Massachusetts Attorney General's office has authority under Massachusetts General Laws Chapter 93A to investigate unfair or deceptive practices, which can include inadequate data security.

Class action exposure is high. Plaintiffs will argue that Prosper's three-month failure to detect database queries constitutes negligence, and that affected individuals face imminent risk of identity theft. The 24-month credit monitoring offer creates a factual record that Prosper itself assessed the risk as significant. However, plaintiffs will still need to demonstrate concrete harm -- actual identity theft, fraudulent accounts, or monetary loss -- to establish Article III standing in federal court.

The Bigger Picture: Database Security in Fintech

Prosper's breach is part of a troubling pattern in fintech: database-level compromises driven by vulnerability exploitation or credential theft. Unlike phishing attacks that target individual employees or ransomware that encrypts files, database breaches allow attackers to selectively extract exactly the data they want -- SSNs, bank accounts, credit scores -- without triggering the alarms that file exfiltration or lateral movement might generate.

Our financial sector breach tracker shows that fintechs face distinct threats compared to traditional banks. Banks are heavily regulated, subject to annual OCC/FDIC/Federal Reserve examinations, and required to meet FFIEC standards for database security. Fintechs, operating under state licensing and FTC oversight, often lack the same level of regulatory scrutiny and may prioritize rapid feature development over hardening database access controls.

The NIST Cybersecurity Framework emphasizes database protection as a Tier 1 control:

Identify: Asset inventory must include all production databases and classify them by data sensitivity
Protect: Access controls should enforce least privilege, require MFA for database connections, and encrypt data at rest and in transit
Detect: Database activity monitoring (DAM) should log all queries, flag anomalous patterns, and alert on exfiltration attempts
Respond: Incident response plans should include procedures for database compromise, query log preservation, and data breach notification
Recover: Backup and recovery procedures must account for selective data corruption or deletion by attackers with database access

Prosper's three-month detection window suggests gaps in at least the Detect function. Modern database monitoring solutions from vendors like Imperva, IBM Guardium, or native cloud provider tools (AWS RDS Performance Insights, Azure SQL Database Auditing) can flag unusual query patterns in real time. A customer database table that normally sees 50 SELECT queries per day suddenly receiving 500 queries from an unfamiliar IP address or service account should generate an immediate alert.

The fintech industry is under increasing pressure to adopt bank-grade security controls. The New York Department of Financial Services Cybersecurity Regulation (23 NYCRR Part 500), which applies to licensed lenders operating in New York, requires:

Access controls based on least privilege (Section 500.07)
Multi-factor authentication for accessing nonpublic information (Section 500.12)
Monitoring and testing to detect cybersecurity events (Section 500.05)
Penetration testing and vulnerability assessments annually (Section 500.05)

If Prosper holds a New York lending license, NYDFS may investigate whether the company met these requirements and whether the three-month breach window demonstrates compliance failures.

Action Items

For Prosper customers and applicants who received notifications:

Enroll in Experian IdentityWorks before March 31, 2026. Visit www.experianidworks.com/1bcredit and use the activation code from your letter. The 24-month monitoring period is twice the industry standard, and the $1 million insurance policy covers identity restoration costs.
Place a credit freeze at all three bureaus (Equifax, Experian, TransUnion). If your SSN was in the compromised data, freezing your credit prevents new account fraud. Freezes are free and can be lifted temporarily when you apply for credit.
Monitor your bank accounts for unauthorized ACH debits. If Prosper had your bank account number on file for loan repayment, fraudsters could attempt to initiate ACH transactions. Enable transaction alerts and review statements weekly.
Request an IRS Identity Protection PIN at irs.gov/ippin. If your SSN was exposed, tax refund fraud is a real risk. The IP PIN prevents anyone from filing a return using your SSN without the PIN.
Be alert for targeted phishing referencing your Prosper loan or application. An attacker with your loan amount, interest rate, or application status can craft very convincing phishing emails. Always verify requests by logging into Prosper's website directly, not clicking email links.

For fintech companies and nonbank lenders:

Deploy database activity monitoring (DAM) with anomaly detection. Tools like Imperva SecureSphere, IBM Guardium, or cloud-native solutions (AWS RDS Enhanced Monitoring, Azure SQL Auditing) log all queries and flag unusual patterns. Configure alerts for high query volumes, after-hours access, and queries returning large datasets.
Enforce least privilege for database access. No service account or employee should have SELECT access to entire customer tables unless their job function requires it. Use views, row-level security, and column masking to limit exposure.
Require MFA for database connections, even for service accounts. Solutions like HashiCorp Vault or CyberArk can manage database credentials with short-lived tokens and enforce MFA for human access.
Conduct quarterly access reviews. Audit who has database credentials, what permissions they hold, and when they last authenticated. Revoke access for former employees and contractors immediately upon separation.
Implement query rate limiting and alerting. If a service account normally executes 10 queries per hour, configure database firewalls or application logic to block sustained bursts of 100+ queries and alert security teams.
Test incident response for database compromise scenarios. Tabletop exercises should include queries by unauthorized actors, insider threats, and SQLi exploitation. Document query log preservation procedures, since logs are critical evidence for forensic investigation and breach notification analysis.
Evaluate FTC Safeguards Rule compliance if you are a nonbank financial institution. The updated rule's monitoring and logging requirements are specifically designed to prevent breaches like Prosper's. Work with legal counsel to ensure your security program meets the standard.