Meshtastic
CVE-2026-44359
CRITICAL
Severity by source
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
Unauthenticated PR auto-triggers CI code execution (AV:N/AC:L/PR:N/UI:N); secrets and downstream supply chain make it S:C, and repo/runner takeover justifies full C:H/I:H/A:H.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
3DescriptionCVE.org
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.
AnalysisAI
Poisoned-pipeline (pwn request) code execution in the Meshtastic firmware repository's GitHub Actions CI allows any external user to run arbitrary code inside the project's trusted CI context prior to firmware 2.7.21.1370b23. Because main_matrix.yml (and related workflows) triggered on pull_request_target while the check, build, and build-debian-src jobs checked out and executed code from the attacker's fork with no approval gate, a pull request from an author_association of NONE automatically ran attacker-controlled files with access to repository secrets and an elevated GITHUB_TOKEN. This is CWE-94 code injection scoring CVSS 10.0; no public exploit identified at time of analysis, though a linked Google Drive writeup may contain proof-of-concept detail.
Technical ContextAI
The root cause is the well-known GitHub Actions pull_request_target anti-pattern. Unlike the pull_request trigger, pull_request_target runs the workflow in the context of the base repository with read/write GITHUB_TOKEN and access to repository secrets, but it is designed to check out only trusted base-branch code. Here the workflows explicitly checked out the untrusted fork by setting ref: github.event.pull_request.head.ref and repository: github.event.pull_request.head.repo.full_name, then built/executed that code - combining privileged context with attacker-controlled content. CWE-94 (Improper Control of Generation of Code) captures this: the CI effectively executes attacker-supplied build scripts and source as if trusted. The affected asset per CPE cpe:2.3:a:meshtastic:firmware is the meshtastic/firmware repository CI, not the compiled firmware on devices. This issue is distinct from GHSA-6mwm-v2vv-pp96, which fixed a separate github.head_ref command injection in the setup job by moving it to environment variables; the fork-checkout flaw in the check, build, and build-debian-src jobs remained until this patch.
RemediationAI
Vendor-released patch: 2.7.21.1370b23, delivered in commit 5716aeba3bc1e1d34fba9567ff88917ede4a78a5, which switches the main workflow trigger from pull_request_target to pull_request and removes the explicit fork checkout (ref/repository) lines across the check, build, build-debian-src, docker, and test jobs, and gates privileged steps behind github.event_name == 'pull_request'. Maintainers should adopt this patched workflow state, then rotate any secrets (signing keys such as the GPG key, tokens, registry credentials) that a fork PR could have exfiltrated while the flaw was live, and audit self-hosted runners for tampering. As durable compensating controls, avoid pull_request_target for jobs that build or run PR code; if privileged post-processing on PRs is genuinely required, split it into a two-workflow pattern (untrusted build on pull_request with no secrets, privileged step on workflow_run) and require an approval gate/environment protection for first-time contributors - note this adds latency to external PR CI. See the advisory at https://github.com/meshtastic/firmware/security/advisories/GHSA-mjx5-98jq-q736.
The Compal Broadband Networks (CBN) CH6640E and CG6640E Wireless Gateway 1.0 with firmware CH6640-3.5.11.7-NOSH have a d
Multiple cross-site request forgery (CSRF) vulnerabilities on the TP-LINK WR1043N router with firmware TL-WR1043ND_V1_12
The Compal Broadband Networks (CBN) CH6640E and CG6640E Wireless Gateway 1.0 with firmware CH6640-3.5.11.7-NOSH allows r
The Compal Broadband Networks (CBN) CH6640E and CG6640E Wireless Gateway 1.0 with firmware CH6640-3.5.11.7-NOSH allows r
Multiple cross-site request forgery (CSRF) vulnerabilities in Compal Broadband Networks (CBN) CH6640E and CG6640E Wirele
Cross-site scripting (XSS) vulnerability in Compal Broadband Networks (CBN) CH6640E and CG6640E Wireless Gateway 1.0 wit
Authentication bypass in Tenda router firmware (AC10, AC5, AC6, FH1201, W15E) lets any user log in as administrator via
Anonymous MQTT access in Yarbo firmware v2.3.9 allows remote unauthenticated attackers on the local network to fully con
Hardcoded administrative credentials in Yarbo firmware v2.3.9 allow remote unauthenticated attackers to gain full device
Denial of service in Meshtastic firmware prior to 2.7.23.b246bcd allows a single node whose User.long_name contains malf
Undocumented persistent backdoor in Yarbo firmware v2.3.9 grants remote privileged access that survives factory reset an
The firmware in Lenovo Ultraslim dongles, as used with Lenovo Liteon SK-8861, Ultraslim Wireless, and Silver Silk keyboa
Same weakness CWE-94 – Code Injection
View allShare
External POC / Exploit Code
Leaving vuln.today