In the first five months of 2025, organizations ranging from health insurers to global manufacturers experienced third-party data breaches. These security failures started outside their networks but had direct consequences inside. 

The exposed data included location histories, Social Security numbers, dates of birth, and payment information. As vendor ecosystems expand, assumptions about who manages what increase. Attackers thrive in the gaps between controls, contracts, and communication. 

What Recent Breaches Reveal About Third-Party Risk 

January: Gravy Analytics

A third-party data vendor left an AWS bucket publicly accessible. Attackers accessed it and downloaded vast amounts of sensitive location data. This data included some tied to government agency personnel, including FBI employees. These records were collected via mobile apps, and the exposed data included movement patterns tied to places like military bases, religious sites, and hospitals.
Lesson: This was a technical failure AND a privacy and national security risk. If your vendor collects or stores data that could endanger people, visibility into their cloud security practices is critical. 

March: Oracle Cloud

An over-permissioned token tied to a third-party integration gave attackers more access than it should have. The attackers moved laterally through identity systems and exposed user credentials.
Lesson: Federated access sounds efficient until it bypasses your controls. If your vendors can provision tokens, they can also misconfigure them. 

May: SAP NetWeaver

CVE-2025-31324 was public and well-documented. But in vendor-managed SAP environments, it stayed unpatched. Hundreds of systems remained open until attackers uploaded malicious code and executed it.
Lesson: If you don’t confirm patch status across your vendor-hosted systems, someone else eventually will. 

May: Adidas

A help desk vendor stored credentials in plaintext. There was no MFA, no alerting, and no resistance. Once attackers got in, they moved straight to customer records.
Lesson: Access starts small. Weak controls at the edge of your vendor network can lead straight to sensitive data. 

Together, these breaches point to a well-known pattern. Low-effort attacks have high-impact results because of overlooked controls in third-party systems. 

The exploitation of this pattern is increasing. According to Verizon’s 2025 Data Breach Investigations Report, 30 percent of last year’s breaches involved third-party vendors. That number is up 50 percent from the year before.  

How Carson & SAINT Validates Third-Party Security 

Vendor questionnaires and policy documentation don’t show you how systems behave under pressure, or how well a vendor’s controls stand up to real threats. 

At Carson & SAINT, we help you uncover what your vendors may be missing: 

• Third-Party Risk Assessments that evaluate how sensitive data is stored, accessed, managed, and protected across vendor relationships 

• Penetration Testing that mimics attacker techniques across vendor connections, integrations, and identity paths 

• SAINT for AWS scans vendor-managed AWS-hosted environments to flag misconfigurations, weak permissions, and unpatched systems 

These services replace guesswork with evidence your team can use to secure your actual attack surface. 

Third-Party Risk Is Your Problem To Fix 

Each third-party data breach in this post started with something simple: a missed patch, an open storage bucket, a token with too much access, or a help desk that wasn’t built to handle sensitive data. 

You can’t close every gap across your vendor ecosystem. But you can decide where to look first, and how much risk you’re willing to carry by default. 

Start with the vendor you trust the most. Trust often leads to assumptions, and assumptions are where attackers find space to move. If the safest-looking vendor reveals a problem, you’ll have a clearer view of what’s happening everywhere else. 

After all, the worst time to investigate a vendor is after someone else already has.