CVE-2026-44359: Meshtastic GitHub Actions Supply Chain Flaw
TL;DR - Meshtastic fixed a critical CI/CD flaw where untrusted PR code could run in a privileged GitHub Actions context. - Affected versions are prior to 2.7.21.1370b23. - Upgrade immediately and audit GitHub Actions secrets, tokens, and runner exposure.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-44359 |
| CVSS | 10.0 (Critical) |
| Attack vector | Remote via GitHub pull request workflow context; exact CVSS vector string not confirmed in available source data |
| Privileges required | Not explicitly published in the source material; defenders should assume an external contributor capable of opening a pull request could trigger exposure conditions |
| Patch available | Yes |
| Fixed version | 2.7.21.1370b23 |
| Affected product | Meshtastic firmware repository workflow / Meshtastic GitHub Actions CI |
| Public PoC | Evidence of a demo/PoC video reference exists |
| Confirmed exploitation in the wild | Not confirmed in CISA KEV as of 2026-07-20 |
This CVE is not a bug in Meshtastic radio traffic handling or a flaw in the mesh networking protocol itself. It is a repository and build pipeline security issue affecting how the Meshtastic GitHub repository handled untrusted pull requests in GitHub Actions. That distinction matters operationally: the primary risk is to maintainers, build infrastructure, secrets, and downstream release integrity.
The severity is still critical because the vulnerable workflow design could have exposed repository secrets, allowed abuse of elevated GITHUB_TOKEN permissions, compromised self-hosted runners, or enabled repository takeover. In practical terms, that is a supply chain scenario: the CI system becomes the path to broader compromise.
What Is This Vulnerability?
According to the NVD description, the vulnerable Meshtastic workflow used pull_request_target and then checked out and executed code from an attacker-controlled fork in multiple jobs. That combination is dangerous because pull_request_target runs in the security context of the target repository, not the contributor fork. If the workflow then fetches and runs code from the fork, it collapses the trust boundary that pull_request_target requires maintainers to preserve.
The reported problem specifically involved the main_matrix.yml workflow, where multiple jobs checked out attacker-controlled code and executed it while secrets and elevated token permissions were available. The issue was also notable because there was no approval gate for external contributors with author_association: "NONE". In other words, a pull request from an untrusted external account could automatically trigger a privileged workflow path.
This issue is also explicitly separate from the earlier GitHub advisory GHSA-6mwm-v2vv-pp96. That earlier issue addressed command injection via github.head_ref in a setup job, and the project reportedly fixed that by moving data handling into environment variables. However, the more severe design flaw remained: privileged jobs still checked out and ran fork-controlled code in the check, build, and build-debian-src jobs.
From a root-cause perspective, this is a classic CI/CD trust-boundary failure. The dangerous pattern is not merely “using pull_request_target,” but using it in a workflow that executes untrusted code, exposes secrets, or grants broad token scope. When those conditions coexist, the workflow effectively gives attacker-controlled pull request content access to privileged repository resources.
Technical Notes
A representative risky pattern in GitHub Actions looks like this:
on:
pull_request_target:
jobs:
build:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@v4
with:
repository: ${{ github.event.pull_request.head.repo.full_name }}
ref: ${{ github.event.pull_request.head.sha }}
- run: ./build.sh
The problem is not just the trigger. The critical issue is checking out and executing code from the PR fork under a workflow context that can access secrets, elevated token scopes, or trusted runner resources.
A safer model is to avoid running untrusted fork code in a privileged context, require maintainer approval for external contributors, and minimize token permissions:
permissions:
contents: read
on:
pull_request:
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: make lint
Who Is Affected?
The affected product, based on the available source data, is the Meshtastic firmware repository workflow and related GitHub Actions automation. The issue is described as affecting Meshtastic prior to version 2.7.21.1370b23. That is the clearest published affected-version boundary in the current source material.
If your organization consumes Meshtastic release artifacts without maintaining the repository or CI pipeline, your direct exposure is different from that of project maintainers. End users are not described as being directly exploitable through device runtime behavior here. The higher-risk population includes project maintainers, organizations mirroring or forking the repository, anyone running similar workflow logic, and any environment using self-hosted runners or repository secrets in PR-triggered jobs.
Specific affected range, as published: all Meshtastic versions prior to 2.7.21.1370b23. Specific fixed version, as published: 2.7.21.1370b23. Because the issue centers on repository workflow behavior, defenders should also review historical workflow revisions, repository settings, organization-level secrets, and runner registrations used before the fix was applied.
If you have a fork of Meshtastic or copied its workflow patterns into your own GitHub Actions files, you may still be exposed even after the upstream project patched its repository. In that case, your risk is no longer tied to Meshtastic’s version number alone but to whether your own workflow definitions still use the same unsafe pattern.
Technical Notes
To identify whether your repository has a similar exposure, review workflow files for the following indicators:
grep -R "pull_request_target" .github/workflows/
grep -R "github.event.pull_request.head" .github/workflows/
grep -R "actions/checkout" .github/workflows/
grep -R "secrets\." .github/workflows/
Also inspect repository and organization settings for self-hosted runners and secrets available to workflows. Any workflow that combines pull_request_target, fork checkout, script execution, and broad permissions deserves immediate review.
CVSS Score Breakdown
The published base score is 10.0 (Critical). The exact CVSS vector string was not confirmed in the source material provided here, so defenders should avoid assuming precise metric values for each subcomponent beyond what the public score and description clearly support. The lack of a confirmed vector string means analysts should treat the numeric score as authoritative but not overstate unverified dimensions such as attack complexity or scope values.
That said, the score aligns with the described impact. The NVD text explicitly says the issue could have led to supply chain compromise, self-hosted runner compromise, and repository takeover. Those outcomes imply very high impact to confidentiality, integrity, and availability in the context of the source repository and its build pipeline. Exposure of repository secrets alone can cascade into additional compromise, while abuse of an elevated GITHUB_TOKEN can allow destructive or persistent changes.
The attack scenario also appears low-friction from an adversary perspective if the workflow automatically ran for external pull requests with no approval gate. That kind of trigger path tends to support a high severity assessment because the attacker does not need shell access to infrastructure first; the workflow itself becomes the initial execution path.
Because the exact vector string is unconfirmed, practitioners should document it internally as CVSS 10.0, vector not confirmed from currently available source data. That is more defensible than reverse-engineering a vector from narrative text and presenting it as official.
Exploitation Status
There is evidence of a public proof of concept or demonstration artifact. The NVD references include a Google Drive link titled github_actions_meshtastic_poc.mov, which strongly suggests a PoC or exploit demonstration video exists. For defenders, that means the vulnerability should be treated as reproducible and operationally relevant, not merely theoretical.
However, active exploitation in the wild is not confirmed from the source set provided here. The CISA Known Exploited Vulnerabilities catalog lookup indicates on_kev: false, which means there is no CISA KEV confirmation of in-the-wild exploitation as of the publication date. That is an important distinction: public exploitability evidence exists, but verified real-world abuse has not been established in the referenced data.
Security teams should avoid two opposite mistakes here. The first is downplaying the issue because KEV does not list it. The second is claiming confirmed exploitation when only a PoC is known. The correct position is: PoC/demo evidence exists; in-the-wild exploitation is not confirmed in the cited sources.
In practice, a critical CI/CD vulnerability with public demonstration material should be treated with high urgency anyway. Attackers do not need broad adoption of a product to abuse a CI workflow if they can identify a target repository with the vulnerable pattern still present.
Technical Notes
Look for historical workflow runs triggered by external contributors and correlate them with secret access or privileged token use. In GitHub audit and Actions history, useful review points include:
- workflow runs started by
pull_request_target - actor or author association showing untrusted external users
- jobs that checked out
github.event.pull_request.head.sha - subsequent access to secrets, release jobs, or write-enabled API actions
A practical search pattern in workflow definitions is:
grep -R -nE "pull_request_target|head\.repo|head\.sha|author_association" .github/workflows/
How to Detect It
Detection is partly a repository review problem and partly an event-monitoring problem. First, inspect workflow YAML for unsafe combinations: pull_request_target, checkout of fork-controlled refs, execution of repository scripts from the checked-out fork, broad permissions, and any direct secret use. If those conditions exist together, assume exploitable exposure until proven otherwise.
Second, review historical GitHub Actions runs and audit logs for evidence that external contributors triggered workflows automatically. The NVD description specifically notes that pull requests from users with author_association: "NONE" were allowed to trigger the workflow without an approval gate. That makes author association a useful detection signal when triaging old runs.
Third, inspect whether any self-hosted runners were involved. If a self-hosted runner executed attacker-controlled code in a privileged context, the blast radius is larger than repository-level compromise. You should then pivot into host telemetry, runner persistence checks, credential rotation, and artifact integrity validation.
Technical Notes
A concrete log and configuration review checklist:
# Find risky workflow triggers and fork checkouts
grep -R -n "pull_request_target" .github/workflows/
grep -R -n "github.event.pull_request.head.repo.full_name" .github/workflows/
grep -R -n "github.event.pull_request.head.sha" .github/workflows/
grep -R -n "permissions:" .github/workflows/
Example risky patterns to flag in workflow files:
on:
pull_request_target:
permissions:
contents: write
packages: write
steps:
- uses: actions/checkout@v4
with:
repository: ${{ github.event.pull_request.head.repo.full_name }}
ref: ${{ github.event.pull_request.head.sha }}
- run: make build
Example hunting query logic for GitHub event data or exported audit logs:
event_type = "pull_request_target"
AND author_association = "NONE"
AND workflow_file = "main_matrix.yml"
If you have access to Actions run metadata, also search for jobs named check, build, or build-debian-src tied to pull requests from forks. Those job names are specifically called out in the vulnerability description.
Mitigation and Patching
The published fix is to upgrade to Meshtastic version 2.7.21.1370b23 or later. If you maintain the Meshtastic repository or a derivative that pulled in the vulnerable workflow logic, update immediately and review the patch commit referenced by the project: 5716aeba3bc1e1d34fba9567ff88917ede4a78a5. Because this is a CI/CD flaw, patching should not end with updating code tags alone. You also need to inspect workflow definitions currently present in the default branch and verify that the dangerous execution path is gone.
Workarounds are available if you cannot update immediately. Remove or disable pull_request_target workflows that execute untrusted code from forks. Require maintainer approval for first-time or external contributors before any privileged workflow runs. Reduce GITHUB_TOKEN permissions to the minimum required, and ensure secrets are unavailable to jobs handling untrusted pull request content. If self-hosted runners were exposed, isolate them from sensitive networks and rotate any credentials they could access.
A complete response should also include post-exposure hygiene. Rotate repository secrets, organization secrets, package registry credentials, cloud credentials, and any deploy keys accessible to the workflow. Validate recent release artifacts and tags if there is any chance untrusted code executed before the fix. Review repository settings for branch protection bypass, workflow write permissions, and environment protection rules.
Technical Notes
If you are updating a local clone or derivative repository, a basic upgrade flow may look like:
git fetch --tags origin
git checkout 2.7.21.1370b23
git log --oneline -n 20
To inspect the upstream fix directly:
git show 5716aeba3bc1e1d34fba9567ff88917ede4a78a5
If you need an immediate workaround in GitHub Actions, disable risky workflows or change the trigger and permissions. For example:
on:
pull_request:
permissions:
contents: read
And explicitly remove fork-code execution from privileged contexts. If you must keep pull_request_target for metadata-only tasks, do not check out or run PR fork code in that workflow.
A practical emergency action list:
# Review current workflow files
grep -R -nE "pull_request_target|head\.repo|head\.sha|secrets\.|permissions:" .github/workflows/
# Rotate credentials out of band after any suspected exposure
# Exact commands depend on your secret backends and GitHub org configuration.
If you cannot confirm whether secrets were exposed, assume they may have been and rotate them. That is the safer operational stance for a critical repository workflow compromise path.
References
The primary source for the vulnerability description is the NVD entry for CVE-2026-44359, which states that prior to version 2.7.21.1370b23, Meshtastic’s main_matrix.yml workflow used pull_request_target in a way that allowed attacker-controlled fork code to execute with access to repository secrets and elevated GITHUB_TOKEN permissions. The same description explicitly mentions possible outcomes including supply chain compromise, self-hosted runner compromise, and repository takeover.
Additional references include the Meshtastic patch commit and GitHub security advisory pages associated with the issue. A separate Google Drive reference titled github_actions_meshtastic_poc.mov provides evidence that a PoC or demonstration artifact exists. The CISA KEV lookup result available in the source set shows the CVE is not listed there as of 2026-07-20.
- NVD CVE record: CVE-2026-44359
- Patch commit: https://github.com/meshtastic/firmware/commit/5716aeba3bc1e1d34fba9567ff88917ede4a78a5
- Likely primary GitHub advisory for this CVE: https://github.com/meshtastic/firmware/security/advisories/GHSA-mjx5-98jq-q736
- Related but separate advisory: https://github.com/meshtastic/firmware/security/advisories/GHSA-6mwm-v2vv-pp96
- PoC/demo reference: https://drive.google.com/file/d/1GdHT2s5hMYCiHt4zrWt1q58mvL7WQC0M/view?usp=sharing
For defenders, the actionable takeaway is straightforward: if your workflows still combine pull_request_target with fork checkout and code execution, treat this CVE as a concrete warning sign and remediate that pattern immediately, whether or not you run Meshtastic.
For further reading on CI/CD security practices, consider checking our CICD Security Hardening Checklist and our FAQ on Cloud Security Posture Management (CSPM).
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.