Before it was patched, a change to the BeEF project’s GitHub automation allowed anyone with a GitHub account to extract repository credentials and execute arbitrary code. The vulnerability, rated 9.3 in severity, gave threat actors a way to seed the software supply chain at will, given that no maintainer approval was required for successful exploitation.
The vulnerability was discovered in the Browser Exploitation Framework (BeEF), a powerful tool primarily designed to automate the testing of cross-site scripting (XSS) vulnerabilities. Anthony Feddersen, VP of Engineering at NetRise, will present the firm’s research on Tuesday at the RSAC 2026 conference.
In emailed comments, Feddersen described the mechanics of the flaw to Security Point Break, noting that web pages consist of code which, like all code, can include vulnerabilities.
One such technique is XSS (Cross-Site Scripting), a top-tier threat. Attackers might inject code into a vulnerable comment section, which then runs when another user loads the page, allowing threat actors to steal login cookies. According to Contrast Security’s August 2024 data, XSS was the most frequent attack type blocked. Research shows 80% of applications have at least one XSS vulnerability, despite it being on the OWASP Top 10 for over 15 years.
The Latest Poison Apple
The BeEF compromise is the latest symptom of a growing plague of code repository poisonings affecting the software industry. The disclosure coincides with the one-year anniversary of the highly publicized XZ Utils attack, reinforcing the systemic risk posed by untrusted open-source contributors.
According to research from Legit Security’s State of GitHub Actions Security Report (Registration Required), nearly all — 98% — of workflow references lack dependency pinning, 86% fail to limit token permissions, and 98% of workflows are susceptible to exploitation through insecure configurations. Researchers anticipate this trend will rapidly escalate. As Feddersen noted, “This attack vector will only increase in popularity as the success rate gets higher (…and that’s happening).”
Flaw Found During Code Reconnaissance with U.S. Air Force
NetRise initially identified the BeEF vulnerability on January 12, 2026, during a targeted engagement with the U.S. Air Force to analyze 77 GitHub repos used by their Red Team. “This came up during the analysis,” Feddersen explained.
The critical vulnerability in BeEF stemmed from a minor continuous integration and continuous delivery (CI/CD) configuration change. An individual operating under the handle “zinduolis” modified the project’s GitHub Actions workflow file by changing the trigger from pull_request to pull_request_target and removing explicit SHA pinning. This alteration creates what security professionals term a “pwn request” vulnerability.
Badda Bing, Badda Boom: Just Fork the Repo & Open A Pull Request
The pull_request_target trigger introduces significant structural risks because it instructs the workflow to run code from a submitted pull request, but executes it within the elevated context of the base repository rather than the submitter’s fork. This change created an attack path with extremely low complexity: an individual only needed to fork the repository and open a pull request.
Because the untrusted code ran in the base repository’s context, it gained immediate access to sensitive environment variables, exposing BrowserStack credentials. More critically, the flaw allowed the extraction of the repository’s GITHUB_TOKEN. With “write” permissions enabled, an attacker could push malicious code directly to the master branch, modify workflows for persistence, merge their own pull requests, and publish compromised software releases, effectively completing a full repository takeover.
Utilizing AI-powered contributor intelligence, NetRise de-anonymized the contributor behind the malicious commit, determining that the individual using the “zinduolis” handle and the email ilgakulnis[@]gmail[.]com is operating from Moscow.
NetRise validated the exploit in an isolated environment before providing a responsible disclosure package to the BeEF maintainers. The project contributors formulated an immediate containment strategy, blocking the malicious commit, flagging the account, and rotating the compromised secrets.
Short-Term/Long-Term Remediation
To permanently secure the workflow, NetRise presented several remediation options. While developers could simply revert the trigger back to pull_request, this limits the ability to run automated tests on code submitted from forks. NetRise’s recommended long-term fix involves splitting the CI/CD process into two separate workflows: one that runs safely without secrets on the initial pull request, and a second that runs trusted code with access to necessary secrets only after the pull request is merged. The project has since fixed the issue using these remediations and additional branch protection measures, confirming the immediate danger has passed.
How to Secure the Software Supply Chain
While BeEF is patched, the vulnerability is just the most recent indication of the structural fragility in open-source development that extends far beyond one project. Protecting the software supply chain requires a multi-layered approach that focuses on visibility, risk intelligence, and proactive defense. Some elements of this approach:
- Establish Comprehensive Visibility: Organizations must gain full visibility into all software components, including custom, commercial, and open-source libraries. This includes generating a Software Bill of Materials (SBOM) to catalog dependencies and their versions.
- Leverage End-to-End Risk Intelligence: Use platforms that continuously monitor the entire software development lifecycle. This provides risk intelligence across build, test, and production, identifying vulnerabilities and licensing risks in third-party libraries and their transitive dependencies.
- Prioritize Findings with Context: Avoid alert fatigue by focusing on targeted, actionable findings. Vulnerabilities should be correlated with actual runtime usage—only flagging libraries that are actively invoked—reducing false positives and enabling teams to prioritize fixes effectively.
- Protect in Production When Patching Isn’t Possible: When updating or patching a vulnerable library isn’t feasible (due to breaking changes or lack of maintenance), runtime protection rules can be used to defend against exploitation in real-time.
(Lisa Vaas is a seasoned freelance journalist and content marketing professional with over 25 years of experience writing about technology, cybersecurity, careers, science, and health. She can be reached at lisavaas@lisavaas.com, lisavaas@securitypointbreak.com or via LinkedIn.)
