8 Major Breaches in 12 Months. Continuous Pentesting Would Have Caught 6. A Gap Analysis.

Incident 01

McHire / Paradox.ai — 64 Million Job Applicants Exposed via Password 123456

Researchers Ian Carroll and Sam Curry signed up as a McDonald's franchisee on the McHire platform out of curiosity, ran into the standard admin login at https://www.mchire.com/signin, and tried 123456 / 123456. They were in. The credentials belonged to a Paradox.ai test or franchisee account, no MFA was enforced, and the admin surface they reached was rich enough to look around.

Inside the admin panel, an internal API endpoint returned applicant records keyed by a numeric lead_id. The researchers decremented the ID. The next applicant's full chat transcript came back. They incremented it. The transcript before came back. The endpoint had no authorization check tying the requesting account to the records it could read. With ~64 million applicant IDs in the database, the entire applicant population was enumerable from one logged-in admin session.

This is not a sophisticated attack. The default-credential check is in the first hour of any external pentest playbook. IDOR on numeric-ID API parameters is the OWASP API Security Top 10 #1 risk (API1:2023 Broken Object Level Authorization) and is what every authenticated pentester probes for first when handed two test accounts. A single quarterly pentest of the McHire admin surface would have surfaced both. There is no reasonable interpretation under which annual or biannual testing was the correct cadence for a platform holding 64 million applicants' PII.

Sources: CSO Online — "McDonald's AI hiring tool's password 123456 exposes data of 64M applicants"; HackRead — technical details on the IDOR and chat transcript exposure; Claremont Graduate University Internet Crime & Data Center — postmortem timeline and remediation.

Incident 02

Tea — Open Firebase Bucket Spills 72,000 Verification Selfies and IDs

Tea positioned itself as a safety-focused women-only platform: users uploaded a verification selfie and a government-issued ID to prove identity, and that material was supposed to live behind authentication. It did not. The Firebase Storage bucket holding those uploads was reachable without credentials, and directory listing was enabled, so anyone with the bucket URL could enumerate every file in it.

The discovery played out publicly. A 4chan user posted that the bucket was open and dropped a sample. Within hours, dumps of verification selfies and government IDs were on torrent trackers. The company confirmed the breach later that day. A separate, even more sensitive database containing roughly 1.1 million private DMs surfaced as exposed in the days that followed.

The architectural pattern that produced this outcome — sensitive user uploads in a default-permissive cloud bucket that the application was supposed to gatekeep — is one of the most well-understood failure modes in mobile-app security. External attack-surface scanning routinely fingerprints Firebase, GCS, and S3 buckets referenced from a mobile binary or its API responses, and tests them for unauthenticated read and list access. Reverse-engineering an iOS or Android binary to extract Firebase configuration takes minutes and is a standard component of any mobile-app pentest scope.

Sources: 404 Media — primary reporting on the Firebase bucket and 4chan disclosure; HackRead — confirms 72K image breakdown and pre-Feb-2024 user scope; EFF — year-end retrospective contextualizing the breach.

Incident 03

Pearson — A Public .git/config File Cost an Education Giant Terabytes

The initial foothold was a forgotten developer-environment endpoint with a publicly reachable .git/ directory. Inside that directory was a config file that contained a GitLab Personal Access Token, embedded for some long-ago automation reason and never rotated. Attackers fetched the token, authenticated to GitLab, and pulled internal repositories — many of which contained additional hard-coded credentials for AWS, Google Cloud, Snowflake, and Salesforce. From January through May, those secondary credentials were used to enumerate and exfiltrate production data across multiple cloud environments.

Of every breach in this analysis, this is the one where the time-to-find for an external pentester is measured in seconds. Nuclei templates for exposed .git directories have existed for years. truffleHog and gitleaks identify embedded secrets in any retrieved Git history within a single scan. Continuous attack-surface management tools fingerprint exposed .git directories on every newly-discovered subdomain and path. Once the PAT is in hand, secondary scanning of accessible repositories for hard-coded cloud credentials is also standard pentest practice — and would have caught the same secrets the attackers did.

Pearson's intrusion ran for approximately four months before public disclosure. A continuous external-pentesting program with weekly subdomain enumeration and exposed-file scanning would have flagged the .git directory long before January 2025 — and even if missed initially, would have caught it on the next sweep, almost certainly before the attackers found and weaponized it.

Sources: BleepingComputer — primary reporting confirming .git/config PAT exposure and downstream credential abuse; Hoplon Infosec — GitLab PAT specifics.

Incident 04

FEMA Region 6 and CBP — CitrixBleed 2 on an Unpatched NetScaler

Of every incident in this analysis, FEMA / CBP is the cleanest fit for the continuous-pentesting case. The vulnerability was not a zero-day. Citrix disclosed CVE-2025-5777 on June 17, 2025. Public proof-of-concept exploits were released within weeks. CISA added the bug to its Known Exploited Vulnerabilities Catalog on July 10, 2025.

FEMA's NetScaler was breached on June 22 — five days after Citrix's advisory and well before KEV listing — but the exfiltration attempts and continued exploitation ran into mid-July, by which point the patch had been available for nearly a month and CISA had mandated remediation across federal agencies. The device was internet-reachable, externally enumerable, and unpatched against an actively-exploited CVE on KEV.

Continuous external pentesting and ASM continuously fingerprint internet-facing NetScaler / Citrix devices and match them against the latest KEV-listed CVEs. The lag between "CISA adds CVE to KEV" and "your CPT provider re-tests every internet-facing instance you own and reports the unpatched ones" is, for a competent provider, hours — not the weeks or months a quarterly pentest cadence imposes. This is precisely the gap continuous testing exists to close.

Sources: Nextgov — primary reporting on FEMA / CBP, attribution to CitrixBleed 2, employee terminations; BleepingComputer — CVE-2025-5777 disclosure timeline and public PoC release; Arctic Wolf — vendor-grade technical analysis.

Incident 05

NNSA / SharePoint ToolShell — The Long Tail of an Unpatched RCE

The earliest exploitation of CVE-2025-53770 was a true zero-day on July 18, 2025. We will not pretend continuous pentesting prevents zero-days. But the post-disclosure long tail is where this incident gets interesting from a CPT perspective.

Microsoft published guidance on July 22, 2025. CISA flagged active exploitation on July 20. By that point, Linen Typhoon, Violet Typhoon, and Storm-2603 (Microsoft's attribution) were mass-scanning the internet for unpatched on-prem SharePoint instances. The 400+ compromised servers across 148+ organizations were predominantly hit in the days after Microsoft and CISA published — not in the zero-day window.

For any organization running on-prem SharePoint, a competent CPT provider would have reported "internet-exposed on-prem SharePoint Server — immediate priority" within hours of the Microsoft advisory. For most of the 148+ victim organizations, that would have been days to weeks ahead of when their internal patching cadence got around to it. The pattern is identical to FEMA/Citrix Bleed 2: not zero-day exploitation, but post-disclosure exposure that lingered because no one was continuously checking.

Sources: BleepingComputer — NNSA confirmation, July 18 exploitation date, ToolShell attribution; Microsoft Security Response Center — technical writeup and attribution; CISA advisory and KEV listing.

Incident 06

TeaOnHer — "Spilled in Less Than 10 Minutes"

TechCrunch's reporters documented their full methodology: less than ten minutes of casual web-app inspection. They found the app's user-uploaded driver's licenses and selfies served from publicly accessible URLs — no auth, no signed URLs, just predictable paths. They also found the app creator's admin email and plaintext password sitting on the public server, which would have granted potential admin-panel access on top of the already-unauthenticated PII.

Both findings are first-day pentest playbook items. Discovery of admin panels, testing for unauthenticated access to user-uploaded media, and grepping responses for credential-shaped strings are standard practice. The app was effectively unauthenticated end-to-end for sensitive PII — government-issued ID images, in this case — and had been since launch.

This is the canonical demonstration that the value of pentesting is not just the depth of the engagement but whether the engagement happens at all. TeaOnHer never had a pentest. A junior engagement, even an automated scan with manual triage, would have caught both findings before any user uploaded a driver's license to it.

Sources: TechCrunch — primary disclosure; TechCrunch — "10 minutes" methodology writeup; Malwarebytes — independent corroboration.

Incident 07

Harvard, Envoy Air & The Oracle EBS / Cl0p Wave (Partial)

The activity is attributed by Mandiant to a suspected FIN11 cluster operating under the Cl0p extortion brand — with explicit caveats from Mandiant that the Cl0p name has been used by multiple threat actor groups and that full attribution remains uncertain. Per Mandiant's technical writeup, the operators used CVE-2025-61882 as a true zero-day from at least July 2025 (UiServlet chain) into the larger August 2025 mass-exploitation campaign (SyncServlet chain), deploying GOLDVEIN.JAVA, SAGEGIFT, and SAGELEAF payloads. The first wave of victims were compromised before Oracle was aware of the vulnerability. No testing program would have prevented that.

This is one of two cases in our analysis where we score continuous pentesting as partial rather than fully preventive. But the partial score has nuance, and the nuance favors CPT meaningfully.

First: an externally-facing Oracle E-Business Suite instance is itself an architectural finding that any external pentest would highlight. EBS is an enterprise ERP; in most modern architectures it should be reached through a VPN or zero-trust gateway, not from the open internet. CPT does not require a CVE to exist to flag "your ERP is internet-reachable" as a recommendation.

Second: Oracle patched on October 4, 2025. Multiple victims were compromised after the patch was available. The exploit chain itself was leaked publicly on October 3 by the "Scattered Lapsus$ Hunters" group, providing a working PoC against any EBS instance still discoverable on the internet. For the long-tail victims, this is identical to the FEMA / NNSA pattern — post-disclosure exposure that would have been flagged by continuous re-testing within hours of the Oracle patch.

Sources: Mandiant / Google Cloud — technical writeup, victimology, payload analysis; BleepingComputer — Oracle patch date, CVE details, exploit-chain leak; SecurityWeek — Envoy Air confirmation; Security Affairs — Harvard confirmation and 1.3 TB scale.

Incident 08

2025 Cisco ASA Campaign — CVE-2025-20333 / -20362 (Partial)

This is the second of our two partial cases. The CVEs were true zero-days at first compromise, and several of the technical capabilities used by UAT4356 — ROM modification to survive reboot, shellcode loaders that disable on-device logging — are far beyond what any external pentest would attempt or detect. We are not going to claim CPT prevents a state-actor zero-day campaign with bootkit-grade persistence.

What CPT does contribute, even here, is twofold.

First, the architectural finding: many organizations should not have their Cisco ASA / FTD VPN management web interface internet-reachable at all. Restricting management surfaces to known administrative source IPs, or moving them behind a separate VPN concentrator, is precisely the kind of recommendation an external pentest produces — and it would have removed the entire attack surface for this campaign for any organization that acted on it.

Second, the post-disclosure patching gap. After CISA's Emergency Directive on September 25, every internet-exposed ASA / Firepower instance became a Critical-severity finding for any continuous pentesting program. The follow-on guidance through November 2025 and again in April 2026 makes clear that the long tail of unpatched and uninvestigated devices was substantial — exactly where CPT closes the gap.

Sources: CISA — Emergency Directive ED 25-03; SecurityWeek — Cisco's attribution and technical detail; SecurityWeek — FIRESTARTER backdoor on the unnamed federal agency.