Tenable Research discloses critical Remote Code Execution vulnerability in GitHub repository that could affect millions of devices

Tenable Research has disclosed a critical vulnerability that could affect laptops, PCs, printers, scanners and industrial tools. Effectively, anything that uses a Windows driver.

The vulnerability affects a Microsoft GitHub repository that allowed for Remote Code Execution (RCE) and unauthorised access to repository secrets.

Tenable Research added that the repository has been forked 5,000 times and has 7,700 stars, indicating its widespread use.

The researchers explained that the vulnerability stems from a Python string injection flaw. They then outlined these three steps to exploit it:

• Issue Creation: An attacker opens a GitHub issue, which is a feature available to any registered user.
• Malicious Injection: The attacker includes malicious Python code within the issue description.
• Automatic Execution: The GitHub workflow triggers automatically upon the issue’s creation, executing the attacker’s code in the context of the GitHub runner.
• Secret Exfiltration: The exploit allows the attacker to exfiltrate the GITHUB_TOKEN and other potential secrets configured on the repository.

“The CI/CD [continuous integration and continuous delivery/deployment] infrastructure is part of an organisation’s attack surface and software supply chain,” said Rémy Marot, Senior Research Engineer at Tenable. “Without strong safeguards, a vulnerability in a pipeline can be exploited to trigger large-scale supply chain attacks and have critical impacts on downstream systems and users”.

Tenable comment

We asked Tenable to explain three key things:

• How many products could have been infected?
• What advice is it giving to directly affected companies?
• And what should CISOs reading this article do if they fear they might be indirectly affected?

“The blast radius here is that attackers could have performed unauthorised operations on the Windows-driver-samples GitHub repository, which serves as reference for developers to build their Windows drivers for their devices,” said Marot.

“If the reference codes provided in the repository were compromised, this could have led to the creation of drivers embedding malicious code.”

So his advice to directly affected companies? “Companies that suffer from vulnerabilities within their CI/CD pipelines should first ensure that no untrusted input can influence workflow execution, particularly in automated processes triggered by pull requests or external contributions, which is common with open-source projects,” he said.

“They should also conduct a thorough audit of their repository and workflow history to verify that the vulnerability was not previously exploited, ensuring that no authorised changes or persistent backdoors were introduced before the fix was applied.”

And his advice to CISOs? “CISOs should consider this as a reminder that CI/CD pipelines are part of the software supply chain and are not only a developer concern,” said Marot.

“They should ensure that their teams are prepared to continuously monitor software supply chain risks and rapidly assess upstream security disclosures. This includes having processes in place to identify affected components, evaluate exposure, and apply mitigations quickly even when the risk originates outside their direct control.”

How big is the potential impact?

We also asked security experts for their views.

“Seven thousand forks of a single Microsoft repository sounds bad. The real number is worse,” said Omair Manzoor, Founder and CEO of ioSENTRIX. “Every fork inherits the same vulnerable workflow, so you’re not just looking at one repo — you’re looking at thousands of downstream pipelines that could have been running that same exploitable automation without anyone realising it.”

And, pointed out Manzoor, “the Windows-driver-samples repo isn’t some obscure side project. It’s what hardware vendors, OEMs and driver developers use as their starting point. So the actual blast radius extends into drivers that ship with printers, USB devices, networking equipment, storage controllers – basically anything that needs a Windows driver.”

He added that attackers who took advantage of the vulnerability before the patch “could have injected malicious code into driver builds that eventually get signed and distributed through Windows Update or OEM channels. That’s not theoretical. That’s exactly how SolarWinds happened, just through a different door.”

Severity of the threat

This goes a long way to explain why the vulnerability had such a high CVSSv4 score of 9.3.

“[That score] signals not just severity but scalability,” said Ensar Seker, CISO at SOCRadar. “[The] real risk here is the blast radius across shared libraries, embedded components, and downstream dependencies, meaning a single flaw can silently propagate across thousands of products.”

So what can directly affected organizations do? “Immediate patching is necessary but not sufficient – asset inventory validation, dependency mapping, and runtime monitoring are critical to ensure the vulnerability isn’t already being exploited.”

Zbyněk Sopuch, CTO of Safetica, echoes these thoughts. “Right off the bat, the real risk isn’t just where this vulnerability is directly used, but rather it’s how far it can spread through shared components and supply chains. This high score signals exactly that, and could impact many products, integrations, and third party components.”

Brian Fending (CISM), a former CIO who advises on AI governance and supply chain security through Ordovera Advisory, described the 9.3 score as “about as bad as it gets”. Because the affected Microsoft repository is widely forked, he explained, “the real blast radius extends well beyond the original code – any project that built on top of it could be carrying the same vulnerability without knowing it.

“If you’re directly affected, rotate every credential that touched that build pipeline and lock down the default permissions on your GitHub workflow tokens immediately, because those defaults are what made this exploitable in the first place.”

He added: “CISOs on the supply chain side should be asking vendors and partners how they secure their build pipelines. If you haven’t asked, you’re assuming a wide-open door to be locked.”

Actions needed to be taken by developers

Manzoor had firm advice for any companies that might have used the repository – first of all, check if you did. If so, he said, “your fork still has the vulnerable workflow unless you manually pulled the fix. Microsoft patched the upstream repo, but forks don’t auto-inherit patches. That’s the part people miss.”

“Second,” said Manzoor, “audit your GITHUB_TOKEN permissions.” Here, he explains, the problem is that organisations stick with the defaults. “Go through every workflow file in your repos and explicitly set permissions to read-only unless write access is genuinely required.”

The third step is to review your workflow trigger configurations. “This vulnerability was exploitable through the issues trigger – meaning anyone with a GitHub account could fire it. If you have workflows triggered by pull_request_target, issue_comment, or issues events, those are your highest-risk surfaces because external users can trigger them.”

What can CISOs do about this?

“CISOs should treat this as a supply chain visibility problem,” said Seker, hammering home the point. “If you don’t know where this code exists in your ecosystem, you should assume exposure and push for SBOM-driven verification across vendors and partners.”

“The biggest risk here is indirect exposure via supply chains, which means companies could be affected and not even realise it,” added Sopuch. “Some immediate steps to take are: identify where vulnerable components are being used, check dependencies, deploy patches right away, and increase monitoring.”

We’ll give the final word to ioSENTRIX’s Omair Manzoor. “This is the harder problem, and honestly the one that keeps me up at night with our own clients. You might never touch that Microsoft repo directly, but your hardware vendor does. Your embedded systems supplier does. Your cloud provider’s driver stack does.

“The uncomfortable truth is that most organisations have zero visibility into whether their supply chain partners are running vulnerable CI/CD workflows. My advice: start asking.”

This article was updated on 24 April with direct quotes from Tenable’s Senior Research Engineer, Rémy Marot.

Related articles

• Okta vishing is the new dodgy email: here’s how to guard against it
• Have Russian hackers used a router exploit to break into your business?
• How North Korean hackers turn legitimate infrastructure into an attack surface