News in Brief: GitHub supply-chain attack steals secret keys

Government warning

CISA, the US government’s cybersecurity research-and-alerting group, is warning about a pair of vulnerabilities dubbed CVE-2025-30066 and CVE-2025-30154, which briefly afflicted popular GitHub source code management tools called tj-actions and reviewdog.

These free software tools are designed to perform what are known as GitHub Actions, which are scripts that software maintainers using GitHub can set up to trigger automatically whenever certain things happen to the codebase, such as when files are added or updated.

Typical actions include checking that the code still builds and that it still passes its automated tests.

But more security-conscious projects may also automatically check for components that need updating, push changed files through automated security tests, and refresh the “bill of materials” in the project by generating a list of all the components and version numbers now included.

Ironically, tj-actions/changed-files claims to improve security by “effortlessly [tracking] all changed files and directories relative to a target branch,” and reviewdog describes itself as “a code review dog who keeps your codebase healthy” by looking out for security warnings from automated scanning tools and adding them into the project so they don’t get missed.

RAM scraping in action

Unauthorized changes to these projects apparently modified the set of actions they performed when they were automatically triggered, including mysterious code that looked like this:

When unpacked from its base-64 encoded form, in which legible text appears as a string of unintelligible characters as seen above, this program fragment actually runs an extracted Linux script that looks like this:

This code downloads a Python program called memdump.py from another part of GitHub, which gives it an air of Microsoft-approved legitimacy, but its purpose is entirely malicious.

(The rogue GitHub URL seen above has now been removed, so this particular malware strain can longer complete its malevolent download.)

The downloaded memdump.py program reads the entire “live” contents of the GitHub Action process from memory, most of which will either be unexceptional, such as any official system software components in use, or uninteresting, such as source code that’s being processed so it can be made public anyway.

But out of this memory dump, the malware scrapes any chunks that look like JSON-encoded passwords or authentication tokens that are temporarily in memory while the GitHub Action runs.

This sort of malware is often referred to in the jargon as a RAM scraper, for obvious reasons.

Programs that have been carefully coded to comply with regulations that prohibit certain critical data items from being saved to disk (e.g. credit card security codes and plaintext passwords) may nevertheless be undone by RAM-scraping malware that exploits the system itself to spy on those programs as they run.

Hidden in plain sight

Instead of silently exfiltrating these stolen secrets by uploading them, the criminals chose instead simply to dump them, apparently innocently, into the infected project’s logfiles, after base-64 encoding them twice in succession in an attempt to hide them in plain sight.

The criminals presumably intended to recover the stolen data directly from any compromised project’s own logs, thus not only avoiding the tell-tale signs that rogue data uploads leave behind, but also casually exposing the stolen secrets to anyone else who decided to go looking.

Researchers attempting to figure out how much damage was done by these malicious scripts claim to have found security tokens for DockerHub, Amazon Web Services, GitHub itself, the JIRA ticketing system, and US public-sector cloud service cloud.gov.

Fortunately, the malicious code was quickly removed from the hacked tools, and researchers noted that many of the stolen secrets they found in their search were temporary credentials for the current GitHub Action only, meaning that they might have been exploitable if they were grabbed and abused almost immediately by the attackers, but would very quickly become useless.

What to do?

• If you use either of the affected tools, change any credentials associated with any accounts against which the affected GitHub Action needs to authenticate. The attackers probably don’t have your long-term passwords or API keys, but “probably” is not certain enough.
• If you outsource your source code management to a third party that uses the affected tools, ask them to confirm whether any of the estimated 1000 GitHub jobs compromised in this attack were theirs. Chance are they weren’t affected, but “chances are” is not certain enough.
• If you rely on third-party software projects to help you manage your own GitHub software projects, remember that a compromise in those tools could affect you just as badly as a compromise of your own code. (In fact, a compromised GitHub Action could itself directly compromise your code, and then lie about it, instead of trying to steal access tokens for other services as this malware did.)

Learn more about our mobile security solution that goes beyond traditional MDM (mobile device management) software, and offers active on-device protection that’s more like the EDR (endpoint detection and response) tools you are used to on laptops, desktops and servers:

More About Duck

Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!