Meshtastic CVE-2026-44359

Exploitation required only that the target repository used the pull_request_target trigger with jobs that checked out the fork head (ref: github.event.pull_request.head.ref / repository: head.repo.full_name) and had no environment approval gate - all true for meshtastic/firmware before 2.7.21.1370b23. A PR from any external account with author_association NONE was sufficient and the workflow ran automatically, so no maintainer interaction, no repository membership, and no prior authentication were needed. The practical limits: the flaw is exploitable only against the project's own CI (not against firmware running on end-user devices), the malicious PR is visible in the public PR list (some forensic exposure for the attacker), and value depends on the secrets/permissions actually granted to the runner. Post-patch (pull_request trigger, no fork checkout in privileged context) the conditions no longer hold.

The signals are largely consistent and point to genuine high priority for the maintainers, though the exposure is unusual. The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N with a 10.0 score reflects unauthenticated, low-complexity, network-reachable exploitation with a scope change (CI secrets and downstream supply chain). Any GitHub user could open a PR and automatically trigger execution - no maintainer approval was required - which is as low-friction as CI attacks get. No EPSS score, KEV listing, or confirmed POC is provided, so there is no evidence of active exploitation; the risk is the ease and impact of exploitation rather than observed abuse. One caveat: this is not a vulnerability in deployed Meshtastic devices - the blast radius is the project's build infrastructure, secrets, self-hosted runners, and the supply chain of published artifacts, so 'who is affected' is the project and its downstream consumers rather than end-user nodes. The A:N in the supplied vector is arguable given that repository takeover and self-hosted runner compromise plausibly impact availability.

An external attacker forks meshtastic/firmware, adds a malicious build script or modified source to their branch, and opens a pull request; because the workflow triggers on pull_request_target with author_association NONE and no approval gate, the check/build jobs automatically check out and execute the attacker's code with repository secrets and an elevated GITHUB_TOKEN. From there the attacker exfiltrates secrets, poisons build artifacts, or compromises self-hosted runners, potentially achieving repository takeover and downstream supply chain compromise. No public exploit is confirmed, but the linked Google Drive document may contain a proof of concept.