Skip to main content
What a Four-Year-Old GitHub Token Reveals About Your Vendor Risk ProgramSupplier & Third-Party
4 min readFor Compliance Managers

What a Four-Year-Old GitHub Token Reveals About Your Vendor Risk Program

The Challenge

On June 11, 2026, the hacking group Icarus injected malicious code into Klue's integration service using a GitHub Personal Access Token (PAT) that had been inactive since 2022. This token was initially issued for a short-term pilot with a third party. When the pilot concluded, the token wasn't revoked.

This oversight allowed attackers to access OAuth tokens Klue stored for pulling data from customer systems on Salesforce and Gong. Icarus then accessed data directly from customer instances, including those of HackerOne, Huntress, Jamf, Recorded Future, Snyk, and LastPass.

The attack worked because stolen OAuth tokens appear legitimate until revoked. Icarus made REST calls against Salesforce and Gong instances just like an authorized customer would. Salesforce detected the unauthorized activity and alerted Klue on June 12.

Lack of Visibility

Klue's customers had no insight into Klue's internal operations. Their vendor risk programs likely approved the integration through questionnaires and moved on. For many security teams, SaaS vendor audits are one-time events: once the vendor completes the questionnaire and gets approved, it's considered done.

The downstream victims couldn't foresee this through initial due diligence. Salesforce confirmed the incident was "limited to Klue's app connection and does not arise from a vulnerability within the Salesforce platform," placing monitoring responsibility on the customer who authorized the integration. Both Salesforce and Gong halted connections via Klue's app. Tanium blocked Klue entirely.

LastPass revealed that customer names, email addresses, phone numbers, physical addresses, support case details, and sales-related data were exposed. The company cut off all employee access to Klue. Huntress reported that Icarus had published a data dump on its dark web site and threatened to release more data, affecting over 200 companies.

Klue's Response

Klue's security posture failed at credential lifecycle management. The GitHub PAT should have been revoked when the 2022 pilot ended, creating a four-year exposure window.

After the breach, Klue banned Personal Access Tokens and switched to different authentication methods. It improved audit logging and tightened controls over software development pipelines.

These are reactive steps. The real question is what Klue's customers should have done to protect themselves from such supplier failures.

Lessons Learned

The breach impacted security-focused companies advising others on managing these risks. The victim list includes firms that should have had strong vendor monitoring.

Salesforce notified Klue within 24 hours of detecting unauthorized activity. While quick detection is important, it happened after the breach. Attackers accessed OAuth tokens to pull data directly from customer systems without triggering alarms.

Rethinking Vendor Risk Programs

Klue's customers relied on point-in-time vendor assessments, assuming suppliers maintain the security posture shown during initial reviews. The four-year gap between token issuance and exploitation proves that assumption wrong.

An effective vendor risk program would require Klue to show continuous compliance with credential lifecycle requirements. ISO/IEC 27001 Control A.5.18 mandates documented rotation schedules for API keys and tokens. Consistent application of this control would have flagged the four-year-old PAT before Icarus exploited it.

However, A.5.18 addresses Klue's internal responsibilities. Klue's customers needed different controls, specifically A.5.19 through A.5.23, which cover supplier relationships.

Control A.5.22 requires regular monitoring, reviewing, and auditing of supplier services. Not just during onboarding, but regularly. This means scheduled reviews of how suppliers manage credentials, what tokens they're storing, and whether they follow their procedures.

Control A.5.21 requires security requirements to extend to sub-processors, and sub-processor usage must be recorded in supplier agreements. This is crucial because Klue wasn't just managing its infrastructure. It stored OAuth tokens to access your data on Salesforce and Gong. These relationships should have been documented and reviewed.

Takeaways for Your Team

First, transform your annual vendor questionnaire into a live register of integrations, credentials, and token grants. When you approve a SaaS integration, you're not just authorizing access today. You're trusting that supplier to maintain security controls over time. Document what tokens they're storing, how they manage credential rotation, and what sub-processors they're using.

Second, integrate supplier monitoring into your ISMS as operational planning and control, not as a compliance checkbox. Control A.5.22 isn't about sending a follow-up questionnaire every 12 months. It's about reviewing audit logs, checking for credential hygiene, and verifying that your suppliers deprovision access when pilots end.

Third, initiate the deprovisioning conversation when any pilot or limited engagement ends. The GitHub PAT used in the Klue breach was issued for a limited pilot in 2022. Someone should have asked: "What credentials did we issue? Have they been revoked?" That conversation didn't happen, and the credential sat dormant for four years.

Fourth, document sub-processor relationships in your supplier agreements. When Klue stores OAuth tokens to access your Salesforce instance, Salesforce becomes a sub-processor in your vendor relationship with Klue. You need visibility into how Klue manages those tokens and what happens if Klue's security posture declines.

Finally, ensure your vendor risk program accounts for credential lifecycle failures at your suppliers. Control A.5.16 requires managing the full lifecycle of every identity from provisioning through deprovisioning. Your suppliers should apply the same discipline to the credentials they use to access your systems. If they don't, your vendor risk assessment should reflect that gap.

The Klue breach happened because a four-year-old credential was never revoked. Your vendor risk program should be designed to catch that failure before attackers do.

You Might Also Like