The Case of the Leaky GitHub Action: A Cautionary Tale for Security Pros

Once upon a time in the mystical land of GitHub, where developers roam free and repositories grow wild, there lived a popular GitHub Action known as tj-actions/changed-files. It was beloved by many, faithfully detecting which files had changed in pull requests and commits. But, as with all great tales, darkness lurked in the shadows.

One day, a nefarious actor slipped through the gates, embedding a malicious payload into the very core of tj-actions/changed-files. And just like that, the keys to the kingdom—secrets including access tokens, private RSA keys, and npm tokens—were exposed in logs for all the world to see. It was like leaving your house key under the welcome mat, only to broadcast the address on national television.

Act I: The Discovery

Step Security was the first to spot the trouble, raising the alarm that CVE-2025-30066 had been born. This wasn't just your everyday bug—this was a full-blown supply chain compromise. Soon, CISA added it to its infamous Known Exploited Vulnerabilities Catalog, and chaos ensued.

Organizations scrambled to understand the scope of the breach. Who was behind it? What was their grand master plan? (Aside from causing widespread panic among DevSecOps teams, of course.) For a while, it seemed like the culprit was a mystery. But then, a clue surfaced: the attackers had compromised a GitHub personal access token (PAT) used by a bot. Ah, the classic tale of a secret in the wrong hands.

Act II: Damage Control

With the poisoned commits now purged and the malicious script vanquished, one question remained: What do we do now?

Security teams across the globe donned their detective hats and got to work.

  1. The Hunt for the Affected Repos – Organizations ran GitHub queries like "where has this action been used?" (hopefully before their managers asked).

  2. Checking the Logs – Like sifting through ancient scrolls, security teams combed through workflow logs for telltale double-encoded base64 strings. If they found one, the repo was compromised.

  3. Secrets Rotation, the Security Ritual – If the repository was public, the exposed secrets needed to be rotated immediately. If private, there was still risk—but at least the leak wasn’t an open invitation to attackers.

Meanwhile, Wiz Threat Research played the role of the cyber Sherlock Holmes, finding dozens of affected public repositories and notifying their unsuspecting owners. (Imagine getting that email: "Hey, just so you know, your secrets are out in the wild. Good luck!")

Act III: Lessons for the Ages

As with any good cautionary tale, there are morals to be learned:

  1. Treat Third-Party Actions Like That One Suspicious Email – Just because it's widely used doesn't mean it’s immune to attack. Always verify the security history of third-party tools before blindly integrating them.

  2. Rotate Secrets Like You Change Your Passwords (Or More Often, Ideally) – If a breach occurs, assume the worst and rotate credentials ASAP. You don’t want your access keys floating around the dark corners of the internet.

  3. Audit, Audit, and Audit Again – Regular security audits of CI/CD pipelines can catch unusual activity before it becomes front-page news.

  4. Short-Lived Tokens Are Your Friend – The good news in this case? GitHub’s ghs_ tokens expire within 24 hours. The bad news? If your pipeline was compromised mid-run, attackers still had their window of opportunity.

The Epilogue: A Secure Future?

With v46.0.1 of tj-actions/changed-files now patched and the immediate crisis mitigated, security teams can finally breathe (slightly) easier. But this story serves as a grim reminder: The supply chain is only as strong as its weakest link.

So, the next time you're about to install a third-party GitHub Action, ask yourself: "Am I about to be the main character in the next IT security horror story?"

Stay safe, stay vigilant, and may your secrets remain secret.

Popular posts from this blog

The Great Patch Panic: A Tale of IT Security Woes and Lessons

  Act 1: The Backup Betrayal Once upon a time, deep in the fluorescent-lit catacombs of IT departments worldwide, a disaster was brewing. It all started with Bob—the ever-vigilant, coffee-powered IT administrator—who prided himself on his ability to keep his company's systems running smoothly. Bob had spent years fine-tuning his Veeam Backup & Replication setup, ensuring that in the event of a catastrophe, he could restore data faster than a sysadmin can type rm -rf / (on purpose, anyway). But lurking in the shadows of his finely tuned system was CVE-2025-23120, a critical vulnerability that allowed remote code execution by authenticated domain users. "No big deal," thought Bob, sipping his fifth coffee of the morning. "Only authenticated users can exploit it. How bad could it be?" Enter Dave, the intern with an unhealthy curiosity and a knack for clicking on things labeled "DO NOT TOUCH." With just a bit of Googling and some light hacking enthusi...
Read more

ClearFake Malware Framework: Latest Variant Analysis and Mitigation Strategies

Overview A recent variant of the ClearFake malware framework has been identified, leveraging fake reCAPTCHA and Cloudflare Turnstile challenges to deceive users into executing malicious PowerShell commands. This evolution marks a significant escalation in the threat’s capabilities, as it continues to exploit Web3 technologies for malware delivery. Evolution of ClearFake ClearFake, first detected in July 2023, initially used JavaScript injections on compromised websites to trick users into downloading fake browser updates. However, by December 2024, it had evolved to incorporate: Fake reCAPTCHA and Cloudflare Turnstile verifications to add legitimacy to phishing pages. Web3 integration , using smart contracts on the Binance Smart Chain (BSC) to store obfuscated JavaScript and PowerShell commands. ClickFix Lure , a deceptive tactic that presents users with error messages prompting them to execute commands in the Windows Run dialog. Emmenhtal Loader & Lumma Stealer as payloads, desi...
Read more