Of all the companies you'd expect to get breached, HackerOne would be near the bottom of the list. This is the bug bounty platform used by the Department of Defense, Goldman Sachs, Anthropic, GitHub, and Uber. Their entire business model is finding and fixing security vulnerabilities for other companies.
And yet, on Monday, HackerOne disclosed that 287 employees had their sensitive personal data stolen. Social Security numbers, addresses, phone numbers, dates of birth — the works. Not because HackerOne's own systems failed, but because a US benefits administrator called Navia got hacked through a BOLA vulnerability between December 2025 and January 2026.
I spent three hours yesterday tracing through the disclosure filing and the incident timeline, and the lesson here isn't about HackerOne specifically. It's about a problem that affects literally every company with cloud infrastructure: your security is only as strong as the weakest vendor in your supply chain. This mirrors
findings about AWS Bedrock attack vectors where intentional permissions become the attack surface.
What Actually Happened
Let me walk through the timeline because it tells a story that should make every IT admin uncomfortable.
December 22, 2025: Unknown attackers exploit a Broken Object Level Authorization (BOLA) vulnerability in Navia's systems. BOLA means the API let them access data objects they shouldn't have had permission to view — basically, the API checked if you were authenticated but not if you were authorized to see a specific record.
January 15, 2026: The attackers' access window closes. That's 24 days of undetected exfiltration.
January 23, 2026: Navia finally detects "suspicious activity." A full week after the attackers already left.
February 20, 2026: Navia sends letters to affected companies. Almost a month after detection.
March 24, 2026: HackerOne files with Maine's Attorney General and notifies employees. Over three months after the breach started.
See that timeline? Three months from compromise to employee notification. And this is with a security-conscious company like HackerOne on the receiving end. Imagine how this plays out when the affected company doesn't have a CISO.
The BOLA Problem Is Everywhere
BOLA vulnerabilities have been the number one API security risk according to OWASP for three consecutive years. They're absurdly common because they're easy to create and hard to detect with automated scanning.
Here's how they typically work: an API endpoint like
/api/v1/employee/{id}/benefits checks if you're logged in but doesn't verify that you're allowed to see employee record #12345 versus #67890. Change the ID in the URL, get someone else's data. It's authentication without authorization — the digital equivalent of a building that checks your badge at the front door but lets you open any office inside.
"I ran a BOLA scan on our own APIs last month after reading about a similar breach. Found two endpoints in our HR integration that had the exact same problem. They'd been live for eighteen months. I fixed them in an afternoon and then didn't sleep well for a week."
The Vendor Supply Chain Problem
Here's what keeps me up at night about this breach: HackerOne likely did everything right on their end. They probably had SOC 2 compliance, regular penetration testing, endpoint detection, the whole nine yards. None of that mattered because the breach happened at Navia.
The Average Company's Vendor Exposure
The typical mid-size company (500-2000 employees) shares sensitive employee or customer data with:
- 3-5 payroll and benefits providers
- 2-3 cloud infrastructure providers
- 4-8 SaaS tools that process PII
- 1-2 recruitment platforms
- 2-4 marketing/analytics tools
- 1-3 customer support platforms
That's 13-25 third parties with access to your data. Each one is an attack surface you don't control. Each one has its own security practices, its own patching schedule, its own underpaid junior developers writing API endpoints at 2 AM.
"My co-worker calls it the 'shadow infrastructure' problem — all the systems your data touches that don't show up on your architecture diagram."
The Complete Vendor Security Audit Playbook
After the Navia breach, I spent last weekend building a vendor audit checklist that I wish I'd had six months ago. Here's the framework.
Step 1: Map Your Data Flow
Before you can audit vendors, you need to know where your data goes. Create a data flow diagram that answers:
- What PII/sensitive data do we share with each vendor?
- How is it transmitted? (API, SFTP, manual upload, shared database)
- Where is it stored on their end?
- How long do they retain it?
- Who at the vendor has access?
Most companies skip this step because it's tedious. Don't skip it. I used a simple spreadsheet with columns for vendor name, data types shared, transmission method, retention period, and last security review date. It took two days to complete and immediately revealed three vendors I'd forgotten about.
Step 2: Classify Vendors by Risk Tier
Not all vendors need the same scrutiny. Classify them:
Tier 1 (Critical): Vendors with access to SSN, financial data, health records, or authentication credentials. Audit quarterly.
Tier 2 (High): Vendors with access to PII like names, emails, addresses. Audit semi-annually.
Tier 3 (Medium): Vendors that process non-sensitive business data. Audit annually.
Navia would have been Tier 1 for HackerOne — they handled benefits enrollment data including Social Security numbers. Tier 1 vendors should get the most aggressive audit schedule and the strictest contractual security requirements.
Step 3: The Security Questionnaire That Actually Works
Most vendor security questionnaires are checkbox exercises that tell you nothing. Here are the questions that actually matter:
API Security:
- Do you implement object-level authorization checks on all API endpoints? (This is literally the vulnerability that caused the Navia breach)
- When was your last API-specific penetration test?
- Do you use API gateway rate limiting and anomaly detection?
Incident Response:
- What is your contractual notification timeline after a breach? (Navia took a month to notify affected companies — unacceptable)
- Do you have a dedicated incident response team or is it outsourced?
- Can you provide your last incident response drill results?
Data Handling:
- Is our data encrypted at rest? With what algorithm and key management?
- Is our data segregated from other clients' data?
- Do you support data deletion requests, and what's the process?
Access Control:
- How many employees can access our data?
- Do you use least-privilege access principles?
- When was access last reviewed and pruned?
Step 4: Contractual Protections
Your contract with each vendor should include:
- Maximum breach notification timeline (I push for 48 hours, not the 30+ days Navia took)
- Right to audit clauses
- Data processing agreements (DPAs) that specify exactly what they can and can't do with your data
- Indemnification clauses for breaches originating from their systems
- Mandatory cyber insurance minimums
"See that tiny clause in section 14(b) of your vendor agreement? The one about limitation of liability? Yeah, that's where they cap their responsibility for breaching your data at the annual contract value. For a $50K/year benefits provider handling your employees' Social Security numbers. Read your contracts."
Step 5: Continuous Monitoring (Not Just Annual Reviews)
Annual audits are table stakes. What you really need is continuous monitoring:
Attack surface monitoring: Tools like SecurityScorecard, BitSight, or UpGuard continuously scan your vendors' external-facing infrastructure for misconfigurations, expired certificates, open ports, and known vulnerabilities. If Navia had been monitored this way, the BOLA vulnerability might have been flagged before exploitation.
Dark web monitoring: Watch for your company name, domain, and employee data appearing on breach dumps and criminal marketplaces. This won't prevent breaches but it dramatically reduces detection time.
Access log analysis: For vendors that provide API access, monitor the access patterns. Unusual query volumes, access from unexpected IP ranges, or bulk data exports should trigger alerts.
Practical Steps for Cloud Infrastructure Specifically
If you're running cloud infrastructure (and if you're reading this site, you probably are), here are cloud-specific vendor audit considerations.
Your Hosting Provider
Your VPS or cloud provider has root-level access to your infrastructure. If you are choosing between providers, our
Hetzner vs DigitalOcean vs Vultr comparison includes security posture notes. They can theoretically read your data, even with encryption at rest (because they manage the hypervisor layer). Key questions:
- What's their employee vetting process?
- Do they offer confidential computing (encrypted-in-use, not just at-rest)?
- What's their SOC 2 Type II status?
- Have they been breached before? (Google their name + "data breach" — you'd be surprised)
Your DNS Provider
DNS hijacking can redirect all your traffic to an attacker's server. Ask your DNS provider about:
- DNSSEC support
- Two-factor authentication for DNS management
- Audit logs for zone file changes
- Change notification alerts
Your CDN Provider
CDNs terminate TLS connections, meaning they can see your decrypted traffic. Ensure:
- They support customer-managed TLS certificates
- They have strict data retention policies for cached content
- They offer real-time access logs
What To Do Right Now
If you've read this far and you're feeling a little queasy about your own vendor security posture, here's a prioritized action list:
1.
This week: List every vendor that has access to PII. All of them. Including the ones you forgot about.
2.
Next week: Check if your contracts include breach notification timelines. If they don't, start negotiating.
3.
This month: Send the API security questionnaire above to your Tier 1 vendors. The ones who can't answer are the ones you should worry about most.
4.
This quarter: Implement at least one continuous monitoring tool for your critical vendors.
5.
Ongoing: Review vendor access quarterly. People leave companies, roles change, but API keys live forever if nobody revokes them.
The Navia breach is a wake-up call, but it shouldn't be a surprise. Third-party breaches have been the leading cause of large-scale data exposures for three years running. Just last week,
CISA added Wing FTP to its actively exploited list — another reminder that perimeter security alone is not enough. The question isn't whether one of your vendors will get breached — it's whether you'll find out in 48 hours or in three months.
HackerOne found out in three months. You can do better.
