CVE-2026-44359 in Meshtastic
Summary
by MITRE • 07/20/2026
Meshtastic is an open source mesh networking solution. Prior to version 2.7.21.1370b23, the Meshtastic GitHub repository's main_matrix.yml workflow is triggered by pull_request_target and multiple jobs check out the attacker's fork code and execute it with access to repository secrets and elevated GITHUB_TOKEN permissions. No approval gate exists. Pull requests from external users with author_association: "NONE" triggered the CI workflow automatically. The workflow directly executes attacker-controlled files from the fork checkout. This issue could have resulted in supply chain compromise, self-hosted runner compromise, and/or repository takeover for the repo. This issue is separate from GHSA-6mwm-v2vv-pp96, which addressed a command injection via github.head_ref in the setup job of the same workflow. That fix correctly moved to environment variables. However, the more critical fork checkout vulnerability across the check, build, and build-debian-src jobs was not addressed. Version 2.7.21.1370b23 contains a patch for thie issue.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/20/2026
The Meshtastic mesh networking project faced a critical supply chain vulnerability in its GitHub Actions workflow prior to version 2.7.21.1370b23. This vulnerability stemmed from the main_matrix.yml workflow configuration that utilized the pull_request_target event trigger, which poses inherent security risks when combined with improper access controls and execution patterns. The workflow structure allowed external contributors with author_association set to "NONE" to automatically trigger CI processes without any approval mechanisms or access restrictions. When such pull requests were submitted, the workflow would checkout code from the attacker's fork repository and execute it directly with elevated GITHUB_TOKEN permissions that granted access to repository secrets and sensitive infrastructure resources.
The technical flaw exploited multiple jobs within the workflow including check, build, and build-debian-src processes that all performed direct checkout operations from untrusted fork repositories. These jobs executed attacker-controlled code without proper sanitization or isolation measures, creating a pathway for malicious actors to inject arbitrary commands into the CI environment. This design pattern directly violates security best practices for continuous integration systems and represents a classic example of unsafe code execution in automated workflows. The vulnerability falls under CWE-78 and CWE-434 categories, specifically addressing command injection through untrusted input processing and insecure direct object references respectively.
The operational impact of this vulnerability was severe and multifaceted, potentially enabling attackers to achieve full repository compromise, supply chain poisoning, and self-hosted runner exploitation. An attacker could have gained access to sensitive credentials stored in GitHub secrets, potentially leading to further infrastructure compromise beyond the specific repository. The elevated permissions granted through the GITHUB_TOKEN allowed for actions including repository modification, secret exfiltration, and even potential takeover of the entire project's CI/CD infrastructure. This vulnerability aligns with ATT&CK technique T1059.001 for command and script injection, and T1531 for establishing persistence through compromised build systems.
The security patch implemented in version 2.7.21.1370b23 addressed the core fork checkout vulnerability by modifying the workflow configuration to prevent execution of untrusted code from external forks. This fix likely incorporated mandatory approval gates, restricted access controls, and proper isolation mechanisms for pull request processing. The mitigation approach should have included implementing proper input validation, using trusted sources for code execution, and applying least privilege principles to CI/CD workflows. Organizations maintaining similar open source projects should adopt defensive measures including automated security scanning of pull requests, implementation of approval workflows for external contributions, and regular security auditing of CI/CD configurations to prevent similar vulnerabilities in their own software supply chains.
The incident highlights the critical importance of securing continuous integration environments against untrusted code execution and demonstrates how seemingly minor workflow configuration flaws can result in major security breaches. It serves as a reminder that open source projects must implement robust access controls and automated security measures to protect against supply chain attacks, particularly when dealing with external contributions from users who may not have repository write permissions but could still exploit workflow vulnerabilities to gain elevated privileges through CI/CD processes.