Evertec, the NYSE-listed payment processor serving banks across Latin America and the Caribbean, confirmed on June 9 that an unauthorized party had accessed debit card numbers and transaction records belonging to Banco Popular de Puerto Rico customers via a third-party support platform.
Evertec discovered the intrusion on May 13, 2026, and notified its financial institution clients two days later. The company filed an SEC Form 8-K on June 9, with Investing.com reporting that the unauthorized access originated from a third-party support platform used to service financial institution accounts, not from Evertec's core payment processing systems. The company stated the attacker no longer has access, that law enforcement was notified, and that no service disruption occurred.
Popular, Inc., parent of Banco Popular de Puerto Rico, filed a separate 8-K confirming it was notified on May 15 and has deployed enhanced fraud monitoring for affected customers. The full record count remains under investigation. The exposed data includes debit card numbers, transaction records, and in some cases customer names and contact details. That combination is sufficient to execute payment card fraud without any further access to Evertec's own systems.
Two things stand out from the reporting.
What scanners would have missed
This was not a code vulnerability. No SQL injection. No deserialization flaw. No CVE.
The attacker reached production payment data through an authorized support platform. That platform held a legitimate credential because support workflows require access to customer records. The authorization was intentional. The data was there by design.
Security scanning tools have no view of this. SAST scans Evertec's code. DAST probes Evertec's application endpoints. SCA checks open source dependencies. None of those tools ask: which external parties currently hold live credentials with access to PCI-scope data, under what conditions, and with what scope limits?
CVSS scores have no vector for "authorized vendor with unconstrained data access." If every CVE in Evertec's codebase scored zero, this access path would remain open. A scanner reporting "no critical findings" would be technically accurate and practically useless.
The reachability question that matters here is not "can an attacker reach this endpoint from the internet?" It is "which third parties currently hold production credentials that touch payment data, and what is the blast radius of each one?" Scanners are not designed to answer that. They scan the code, not the access graph around it.
Support platform credentials are frequently granted with "full access" for a specific support engagement and never subsequently narrowed. The credential becomes ambient. The access becomes invisible to any tool that only reads source.
What Sekura would have shown
Phase 2 of Sekura's pipeline is recon. The recon agent maps the real attack surface: not just public endpoints, but the full graph of entities with privileged access to the target environment. That includes OAuth tokens issued to third-party platforms, API keys held by support tooling, and service accounts created for vendor integrations.
For a payment processor like Evertec, recon would produce findings like:
- Support platform holds a service account with read access to the production transaction database, including PAN-bearing columns.
- The credential scope covers the full customer table, not a subset restricted to open ticket records.
- No query-level audit log retention is attached to that service account.
- The credential has not been rotated in over a year.
I think none of those findings require code review. They require enumerating what is connected to the production environment and what each connection can read. For a fintech handling payment data, that means knowing which support tools hold a service account, what that account can query, and whether the access scope was ever narrowed from the initial grant.
Sekura's exploit-chain analysis phase would then trace what an attacker can do with that credential: pull card records at scale, correlate with transaction history, exfiltrate under traffic patterns indistinguishable from normal support queries. The proof is the data access path, not a code execution chain.
We would not have prevented this breach. We would have produced a finding showing the support platform held a credential capable of bulk-reading PCI-scope records, with a working proof of access.
The bigger pattern
Vendor access failures have become a structural breach pattern in 2025 and 2026. The scenario repeats: a third party with legitimate, authorized access to production data becomes the entry point. The victim's own code is clean. Their own endpoints are patched. Their own team is not compromised.
The attack surface extended to a vendor. The security testing did not.
Most organizations can name their top critical CVEs. Fewer can enumerate every external party currently holding a live credential with access to sensitive production data. Fewer still can answer: what can that credential read, in bulk, right now?
The gap between those two questions is where breaches like this one happen. Vendor ecosystems are growing, and the access grants they accumulate rarely shrink on their own. The Evertec incident is a visible data point in a pattern that is not new but is not improving either.
If you want to map the full graph of what can reach your production data, see how Sekura differs from conventional scanners.