# Whoever Speaks Owns the Vehicle

*Optional Signing, MAVLink Trust, and the Decade’s Control-Link Default*

**Prepared as a software-assurance analysis**  
Current as of August 19, 2026

---

> **Research premise.** The decade’s control-link pattern is not a new radio chip. It is a default: whoever can speak on the bearer owns the vehicle, and turning on optional signing did not close that path.

## Abstract

**Research premise.** From 2018 through 2026, public records on Micro Air Vehicle Link (MAVLink) and hobby first-person-view radio describe the same trust failure in different institutional languages. An IEEE Access study showed that an on-link peer could stop an in-progress mission because the protocol accepted commands without authentication. A 2020 CVE formalized that property as missing authentication for a critical function; a second CVE recorded that version negotiation could fall back from signed MAVLink 2 to unauthenticated v1. Maintainers treated the first finding as a documented design choice. The official signing specification treated authentication as optional and provided mechanisms for accepting unsigned traffic. A 2020 ArduPilot issue and a 2026 *IEEE Transactions on Communications* paper then argued that anti-replay timestamps can be moved by civil GPS time. In March 2026, CISA restated the unsigned-by-default fact against PX4 and named an unauthenticated shell as the consequence. In parallel, NCC Group and ExpressLRS documented that a hobby “binding phrase” is anti-collision, not a security boundary. This paper treats those records as one argument. The method is source-primary software-assurance analysis, distinguished as fact, inference, judgment, or unknown. The finding is that optional signing is not a Passport: “MAVLink 2 is available” does not establish that the Control Fabric refuses an unauthenticated speaker. The limit is implementation currency. Current builds were not re-tested; “not established” is not treated as safe; Remote ID, firmware-update integrity, and payload-and-peripheral trust are excluded.

_Keywords: MAVLink, message signing, unauthenticated command and control, protocol downgrade, GPS time, PX4, ExpressLRS, software assurance_

## 1. Introduction: The Apparent Puzzle

A reader who encounters MAVLink 2 in a specification, a vendor brief, or an integrator checklist can reasonably conclude that the command link has been solved. The current major version of the protocol “adds support for message signing, which allows a MAVLink system to verify that messages originate from a trusted source.”1 PX4’s own hardening guide now tells production deployers to enable that mechanism and warns, in plain language, that without it any device that can send MAVLink to the vehicle can execute commands, including shell access, mission upload, arming, and flight termination.2 The puzzle is not that a security feature is missing from the literature. The puzzle is that the feature has been optional for the entire decade in which the literature accumulated, and that every major public record still has to remind the reader that the default is open speech.

That default is easy to misread as a vendor defect or a forgotten patch. It is neither. MAVLink v1 has no authentication mechanism. MAVLink 2 adds a signature block and still allows implementations to accept unsigned packets, to start a link in v1, and to treat signing as a configuration rather than a condition of command acceptance.3 Autopilot maintainers have said, on the record, that the absence of authentication in v1 is a documented design choice.4 CISA has now said, also on the record, that the same absence is missing authentication for a critical function on a widely fielded open autopilot, listed against transportation, emergency services, and the defense industrial base.5 Both statements can be factually true. They describe different objects. One describes a protocol that was written for lightweight telemetry. The other describes a kinematic machine that will Sense, Move, and Act on whatever the Control Fabric accepts.

LrrK’s judgment is that the second object is the one that matters. The Control Fabric is the authority layer above every physical capability. If it treats bearer presence as identity, Move and Act belong to whoever can speak. Optional signing does not change that default. It creates a second story—“authentication exists”—that can be checked without checking whether unauthenticated speech is refused. A Product Security Passport that records the second story as if it were the first is a checkbox.

The argument is architectural rather than chronological. The paper reconstructs the v1 property, the optional-signing specification, the 2020 downgrade identifier, the GPS-time argument, the 2026 CISA inventory, and hobby FPV as one failure class, then states what a control-link Passport would have to record. Remote ID, firmware-update chains, and payload-and-peripheral trust are sibling questions and are excluded. Exploit status, where mentioned, is a high-level label from the public record: writeup, catalogued, advisory-only, or not independently reviewed. No attack procedures are provided.

## 2. Unauthenticated Command Acceptance as a Protocol Property

In August 2018, Young-Min Kwon, Jae-Min Yu, Byeong-Moon Cho, Yongsoon Eun, and Kyung-Joon Park published an empirical study of MAVLink as used between a ground control station and a UAV. The paper’s finding, stated in the abstract, was that the protocol’s design permitted an on-link methodology that could stop the attacked aircraft and disable an ongoing mission.6 Secondary indexes place the article in *IEEE Access* volume 6, pages 43203–43212, issued August 2018; the exact calendar day remains unknown.7 The design fact is settled: MAVLink v1 accepts commands from any peer that can speak on the bearer. The physical consequence is a change in Move and Act, not a telemetry leak.

On 30 June 2020, Alias Robotics filed Robot Vulnerability Database entry RVD#3316, “No authentication in MAVLink protocol,” and assigned CWE-306. The ticket’s exploitation field was recorded as “Not available.”8 On 3 July 2020, NVD published CVE-2020-10282 with the same theory: MAVLink version 1.0 “presents no authentication mechanism… (nor authorization).” The CVE text notes that version 2.0 “optionally allows for package signing,” and that the HMAC construction implies a shared symmetric key across devices on the network.9 That is the first formal identifier for the property Kwon and colleagues had demonstrated as an empirical outcome. It is not a claim that a particular 2026 binary still accepts unsigned v1. Whether a given build does so is an implementation question, not settled by the CVE text, and remains unknown without a scoped Lab result.

The maintainer reply is part of the record and should not be flattened. In August 2020 an ArduPilot developer wrote that MAVLink 1.0 “doesn’t provide any system of authentification,” that the ticket therefore was not a vulnerability, and that ArduPilot had been using MAVLink 2.0 by default “since some time.” A later comment compared the CVE to assigning identifiers to UART or protobuf. A third participant argued that a CVE requires a security policy distinguishing authorized from unauthorized access, which v1 never claimed.10 Those replies are facts about how the project reasoned. They relocate the consequence: if the protocol is an open messaging format, assurance moves to the system that places it on a radio, a UDP port, or a serial telemetry link and then obeys it.

LrrK’s inference, at high confidence on the paper and the CVE and at moderate confidence on any particular 2026 image, is that unauthenticated C2 is a protocol property of MAVLink v1 and of default-unsigned MAVLink 2, not a one-off vendor bug. A Kinematic Assurance Topology that runs from radio to autopilot command handler will keep rediscovering the same edge until the Control Fabric refuses the unsigned speaker. Watch should treat later CISA and ICS repeats as inventory of that edge, not as novelty. A Campaign that asks only “does this product speak MAVLink 2?” has asked the wrong question.

## 3. Optional Signing Is Not a Passport

MAVLink 2 signing is real. The official guide describes a 13-byte trailer: a link identifier, a 48-bit timestamp in ten-microsecond units since 1 January 2015, and a 48-bit truncated SHA-256 over the packet and a 32-byte shared secret. Libraries that do not understand the signed-packet incompatibility flag must drop the packet. Incoming signed traffic is supposed to be discarded when the timestamp goes backward, when the computed signature does not match, or when the timestamp is more than one minute behind the local clock.11 None of that is in dispute. The dispute is what “signing exists” is allowed to prove.

The same guide instructs implementations to provide a mechanism that “allows a system to conditionally accept unsigned packets.” Suggested predicates include a parameter, a “secure channel” such as local USB or wired Ethernet, an “unsigned mode,” and a rule that accepts all unsigned packets until a signed packet arrives. RADIO_STATUS is called out as a message that may be accepted without signing “to make life easier for telemetry radios.” Incorrectly signed packets may also be accepted, for example to display position from a lost vehicle, provided the system indicates that the connection is unsafe.12 These are specification features, not integrator accidents. They mean that a stack can be “MAVLink 2 with signing” and still have a defined path for unauthenticated command traffic.

PX4’s production hardening text is blunter, and is a fact of the current documentation rather than a Lab result on every SKU. “By default, all MAVLink messages are unauthenticated. This is intentional for development and testing, but production deployments must enable message signing.” The guide names shell access via SERIAL_CONTROL, file operations, parameter changes, mission upload, arming, and flight termination as capabilities that, without signing, do not distinguish a legitimate ground station from an unauthorized sender. Signing authenticates and protects integrity; it does not encrypt; a small allow-list is accepted unsigned; there is no automatic key rotation; the key file lives on the SD card.13 That is a Control Fabric with an optional lock.

A Passport is the authoritative, append-only assurance record for a specific thing. “MAVLink 2 available” is not that record, nor is “signing can be enabled.” Even “signing enabled” is incomplete if the implementation still accepts unsigned packets, still negotiates v1, or still binds its anti-replay clock to a spoofable Sense source. LrrK’s judgment is that optional signing is a capability, not a condition. Treating a capability as a condition is how an integrator inherits the decade’s default while believing the path was closed.

## 4. The Downgrade Path Breaks the Signed-Link Assumption

On 20 August 2020, NVD published CVE-2020-10283. The description is a protocol-negotiation claim, not a missing-HMAC claim. MAVLink 2.0 “presents authentication mechanisms,” but “in order to maintain backwards compatibility, GCS and autopilot negotiate the version via the AUTOPILOT_VERSION message.” Because that negotiation “depends on the answer,” a peer may cause the autopilot to adopt version 1.0. Given the lack of authentication in that version—explicitly cross-referenced to CVE-2020-10282—the peer may then “interact with the autopilot directly.” Alias Robotics classified the weakness as authentication bypass using an alternate path.14

The official version guide makes the compatibility logic visible without any exploit narrative. If signing is enabled, the vehicle should start sending signed MAVLink 2 immediately. If signing is not enabled and MAVLink 2 is enabled, “the vehicle may choose to start by sending MAVLink 1 and switch to MAVLink 2 on a link when it first receives a MAVLink 2 message.” Vehicles are told to set the MAV_PROTOCOL_CAPABILITY_MAVLINK2 flag even when the link is currently sending v1 packets, because v2 packets “will be accepted and will cause a switch to MAVLink 2.”15 The guide is describing interoperability. CVE-2020-10283 is the security reading of the same handshake: a signed-looking configuration can still accept an unauthenticated peer if v1 remains negotiable.

In the RVD#3316 thread, the reporter wrote that a PX4 demonstration of the negotiation path had been prepared and that ArduPilot had not been similarly tested. The ArduPilot maintainer disputed applicability.16 The disagreement is a fact of the discussion. A public, independently reviewed artifact is not established here. Exploit status is catalogued. What the CVE text establishes is the class of failure: a downgrade from an authenticated dialect to an unauthenticated one. The physical consequence is Kwon’s: command acceptance—ownership of Move and Act—by a speaker the signed-link story had excluded.

LrrK’s inference, at high confidence on the CVE and the version guide and at moderate confidence on current-build applicability, is that any Passport that records only “MAVLink 2 signing enabled” is incomplete without “v1 refused.” Lab work that hashes an HMAC implementation while leaving the handshake unexamined has tested the lock and not the door. Kestrel should correlate the same negotiation claim across PX4 and ArduPilot images rather than treating one stack’s default as the other’s evidence.

## 5. When Sense Sets the Clock

Signing’s anti-replay rule is a clock rule. The timestamp must increase on each logical stream. A device that does not know GMT time is told to take the maximum of GPS time and a stored timestamp when lock is achieved, and to persist the current timestamp so that a reboot cannot walk the clock backward.17 The construction assumes that the time source used to initialize or advance that clock is not an adversary-controlled Sense input. Civil GPS time is not that assumption’s friend.

On 22 March 2020, an ArduPilot issue titled “MAVLink 2.0 message signing can be broken under GPS spoofing” described timestamp manipulation against signing on Copter 3.5.5 running on a Pixhawk1 in a 3DR IRIS+, with the reporter stating that the same condition should apply on master. Maintainers Andrew Tridgell and Peter Barker replied that timestamps are forced only forward and that the signing timestamp is persisted in `hal.storage` with the parameters, not on the microSD card. After clarification, the reporter agreed that the described replay scenario required a storage reset and a spoofed GPS time before a legitimate lock. The issue was closed on 26 March 2020 as applying to that narrow window.18 Those comments are facts of the thread. The operational width of the 2020 scenario remains a maintainer-versus-author dispute and is unknown as a fleet statistic.

In 2026, Zack Colton, Alma Oracevic, and Selma Dilek published a journal treatment in *IEEE Transactions on Communications*, volume 74, pages 2564–2579, claiming a generalizable GPS-time attack against MAVLink 2 signing that does not require knowledge of the secret key. The paper reports evaluation in simulation, hardware-in-the-loop, and hardware, and proposes countermeasures; it is not a stock CVE fix.19 Early-access bibliographic records give a 15 December 2025 publication stamp on the DOI; the journal issue is 2026.20 What the paper changes is not the existence of signing. It changes how an assurance reader is allowed to treat “signing on” as solved.

If anti-replay is bound to a civil GNSS clock, Sense can collapse Control Fabric without the HMAC key. A Passport silent on the time source has recorded a lock whose latch is set by an unauthenticated sensor. KAT should treat GNSS time as an input to link authentication. Watch should also hold the GCS-side complement—Du, Ge, Wang, Zou, Chang, and Fan’s 2024 SIN paper on Mission Planner key update and timestamp examination—as adjacent evidence, not developed here.21 The 2020 issue and the 2026 paper together retire the sentence “signing is on, therefore the link is authenticated.” How wide the GPS-time path remains on current storage-persistent implementations is unknown. “Not established” is not “safe.”

## 6. The Same Property, Now Inventory

On 31 March 2026, CISA published ICS Advisory ICSA-26-090-02 against PX4 Autopilot, CVE-2026-1579. The affected-product string is `v1.16.0_SITL_latest_stable`. The reporter is Dolev Aviv of Cyviation. The sectors listed are Transportation Systems, Emergency Services, and the Defense Industrial Base. Headquarters is listed as Switzerland. CISA names the stack, not an Auterion or Holybro SKU.22

The vulnerability text is the decade’s default written as an OT finding. “The MAVLink communication protocol does not require cryptographic authentication by default. When MAVLink 2.0 message signing is not enabled, any message — including SERIAL_CONTROL, which provides interactive shell access — can be sent by an unauthenticated party with access to the MAVLink interface.” Mitigation is configuration, not a version that removes default-off signing: enable MAVLink 2.0 signing on non-USB links, and follow PX4’s security-hardening and message-signing documentation. CISA states that no known public exploitation specifically targeting the vulnerability had been reported at publication. CWE is again 306.23 Exploit status is therefore advisory-only.

Two readings of the advisory are available. The narrow reading treats the SITL-tagged version pin as the scope and stops. The wide reading treats the pin as oddly narrow for a protocol-default issue and reads the advisory as the first CISA ICS item that places a widely fielded open autopilot into operational-technology inventory for missing link authentication. The version string is a fact. Which commercial images match it is unknown. The wide reading is an inference at high confidence on the design property and at moderate confidence on SKU coverage. LrrK prefers the wide reading because the advisory’s own mitigation points at a protocol configuration, not at a patched SITL build, and because PX4’s hardening guide describes the same default in production language.

An interactive shell on the flight controller is Act with persistence. Kwon’s mission stop is ownership for the duration of a flight; a shell is ownership of the vehicle as a computer. The 2026 advisory is the 2018 property, the 2020 CVE, and the optional-signing specification, restated by an ICS authority. Watch should notice the restatement without inflating it. Campaign should treat unsigned PX4 ports, and the integrator images that ship them, as one class. A Passport that adds “CISA mentioned PX4” without recording signing-required, v1-refused, and time-source evidence has only indexed the advisory.

## 7. A Shared Failure Class on Hobby FPV

ExpressLRS is not MAVLink. Collapsing the two protocols into a single CVE story would be a category error. The reason to place them in one paper is the failure class, not the frame format. In both cases a widely deployed control link treats a pairing convenience as if it were authentication, and the physical consequence of an unauthorized speaker is ownership of the airframe.

On 30 June 2022, NCC Group published a technical advisory by Richard Appleby covering ExpressLRS 1.x and 2.x on 900 MHz and 2.4 GHz. Initial contact with the project was 1 December 2021. Proposed patches were rejected on 5 March 2022. The advisory states the project’s own position in the project’s words: “ExpressLRS states that the binding phrase is not for security, it is anti-collision.” NCC’s impact statement is full control of the target craft, or likely crash of an aircraft already in the air.24 That is Move and Act on hobby airframes and on any dual-use airframe that inherited the same radio.

The project documentation still says the same thing. The binding-phrase page tells pilots that the phrase “need not be complicated or super-secret as it isn’t a password or encryption key,” and answers the question “Is my binding phrase a secret?” with: “The binding phrase is not for security, it is for anti-collision.”25 That is an authoritative primary, not a hostile gloss. A pairing token that is advertised as anti-collision cannot be entered on a Passport as link authentication.

What changed after 2022 is partial. Independent 2026 analysis by Simon Koeck describes ExpressLRS 3.x as hashing the UID in the sync packet, closing the passive UID-on-air path NCC described, while leaving the payload unauthenticated and unencrypted. Koeck presents the piece as a walk through public knowledge, not original research, and does not claim cryptographic security.26 LrrK grades that source as useful, not definitive: 3.x is a partial protocol change, not a CVE patch and not evidence that the payload is authenticated. Field mix of 1.x/2.x versus 3.x is unknown.

The inference, at moderate confidence, is that phrase-bound RC links will keep reproducing the class until a payload-authenticating default is evidenced. Absence of a CVE is not absence of a Control Fabric hole. Lab should distinguish binding from authentication. Watch should challenge any claim that “UID hash” equals security. A Campaign that Passports ExpressLRS only by major version reprints the checkbox error in a different protocol.

## 8. What a Control-Link Passport Must Record

The recurring error is a substitution. Operators, integrators, and sometimes researchers substitute a capability label for a condition of command acceptance. The capability labels are attractive because they are cheap to observe. MAVLink 2 is a version bit. Signing is a configuration surface. A binding phrase is a string in a configurator. GPS lock is a status field. None of those observations answers the only question the Control Fabric poses: will this vehicle refuse an unauthenticated speaker on the bearer that can change Move and Act?

### Table 1. Capability labels versus Passport conditions

| Common label | What the label actually shows | Condition a Passport must record |
| --- | --- | --- |
| MAVLink 2 available | The stack can speak the current dialect | Signing required on every non-USB command link |
| Signing enabled | A key and timestamp may be present | Unsigned command messages refused; allow-list enumerated |
| MAVLink 2 by default | Preferred dialect, not exclusive dialect | v1 refused on that channel; negotiation evidence retained |
| Binding phrase set | Anti-collision / pairing convenience | Payload authenticated, or explicitly recorded as not authenticated |
| GPS lock / “time valid” | A Sense source has published civil time | Signing time source identified; GPS-only initialization flagged |
| “Hardening guide followed” | Documentation exists | Configuration evidence from the running image, not from the PDF |

A Passport is point-in-time and device-specific. It is not certification, approval, a warranty, or a guarantee of safety. For a control link it should identify the aircraft, flight-controller image, radio or telemetry bearer, protocol major version, signing state, v1-refusal state, unsigned-message policy, key-provisioning channel, and time source as a single operational system. It should say whether SERIAL_CONTROL, or the local equivalent of an interactive shell, is reachable from an unauthenticated peer. It should say whether the hobby radio authenticates the payload or only hashes a pairing identifier. It should preserve negative evidence. A Lab result of “not established” on current-build downgrade belongs in the record. It does not authorize a green checkbox.

Honesty about unknowns is operational. This paper has not re-tested CVE-2020-10283 on current builds, mapped the CISA SITL string onto commercial SKUs, or counted ExpressLRS 1.x/2.x still in the field. Those gaps are preserved. Kestrel correlates them across images; Lab closes them under a stated hypothesis; Watch reopens them when the next restatement arrives. None of those roles is discharged by reprinting “signing exists.”

## 9. Implications for Watch, Lab, Campaign, and Kestrel

Watch should subscribe to restatements of the same theory, not to novelty. The indicators that would move the Security Story are few: a PX4 or ArduPilot release that refuses v1 and requires signing on non-USB links by default; a CISA or CNA identifier on ExpressLRS or a successor phrase-bound link; an independent re-test of the 2020 downgrade on current builds; a stock fix, not a journal countermeasure, for GPS-time versus MAVLink 2 anti-replay; a follow-on ICS advisory that names a commercial SKU rather than “PX4.” Until those records exist, Watch challenges the story.

Lab should test the handshake and the time source, not only the HMAC. The scoped hypothesis is whether, on this image and channel, an unsigned or v1 speaker is accepted for a command that changes Move or Act, and which clock initializes anti-replay. Rejected and inconclusive outcomes are preserved. USB evidence does not establish the fact on SiK, UDP, or a companion-computer bridge. Forward-only timestamps after storage is populated do not establish that GPS time cannot initialize an empty store.

Campaign should aim at the topology, not the brand. Unsigned PX4, unsigned ArduPilot, and phrase-bound ExpressLRS are different products and one Control Fabric class: bearer speech as identity. Investigating a single integrator port as a unique defect produces a story that cannot generalize. Investigating the class writes a Registry entry that later images inherit, then challenge. That is how an append-only archive avoids rediscovering Kwon under a new CVE number.

Kestrel correlates the candidate finding—optional authentication on a kinematic command link is not authentication of that link—with the preserved unknowns: current-build downgrade, SKU mapping of the 2026 SITL pin, GPS-time width, and ExpressLRS version mix. A PX4 hardening sentence, an ArduPilot issue, and an ExpressLRS FAQ are one finding in three dialects.

The recommendation is narrow. Do not inventory a command link as authenticated because a specification shows a signature format. Require evidence that the running Control Fabric refuses the unauthenticated speaker, refuses v1 where v1 is a path around that refusal, and does not take its anti-replay clock from civil GNSS. That is a configuration and evidence problem, not a new radio.

## 10. Conclusion

The decade’s control-link pattern is a default. MAVLink v1 accepts an on-link speaker. MAVLink 2 can sign, and by specification can also accept unsigned traffic, start in v1, and take time from GPS. A 2020 CVE named the downgrade. A 2020 issue and a 2026 journal named the clock. A 2026 CISA advisory named the shell and placed the open autopilot in OT inventory. ExpressLRS named its binding phrase as anti-collision. None of those records is a new radio chip. All of them describe a Control Fabric that treats speech as authority.

Optional signing did not close the path because optionality is the path. LrrK’s conclusion is not that MAVLink 2 signing is worthless. It is that signing is not a Passport. Trust is earned by a running configuration that refuses unauthenticated command, refuses v1 on the command channel, and accounts for the Sense source that sets the clock—and by an append-only record that says so, including when the evidence is “not established.”

Whoever can speak on the bearer owns the vehicle until that record exists. Turning on optional signing, without evidence that the unsigned speaker is refused, leaves ownership where the protocol put it in 2018.

Endnotes

1. MAVLink Developer Guide, “Message Signing (Authentication).” https://mavlink.io/en/guide/message_signing.html

2. PX4, “MAVLink Security Hardening for Production Deployments,” PX4 Guide (main), documenting the unsigned default and the command set reachable without signing. https://docs.px4.io/main/en/mavlink/security_hardening

3. MAVLink Developer Guide, “Message Signing (Authentication),” sections on accepting unsigned and incorrectly signed packets; MAVLink Developer Guide, “MAVLink Versions,” section “Negotiating Versions.” https://mavlink.io/en/guide/message_signing.html ; https://mavlink.io/en/guide/mavlink_version.html

4. khancyr, comment on Alias Robotics, “RVD#3316: No authentication in MAVLink protocol,” 7 August 2020; OlivierJB, comment, 22 November 2020. https://github.com/aliasrobotics/RVD/issues/3316

5. Cybersecurity and Infrastructure Security Agency, “PX4 Autopilot,” ICS Advisory ICSA-26-090-02, 31 March 2026. https://www.cisa.gov/news-events/ics-advisories/icsa-26-090-02

6. Young-Min Kwon, Jae-Min Yu, Byeong-Moon Cho, Yongsoon Eun, and Kyung-Joon Park, “Empirical Analysis of MAVLink Protocol Vulnerability for Attacking Unmanned Aerial Vehicles,” *IEEE Access* 6 (2018): 43203–43212. https://doi.org/10.1109/ACCESS.2018.2863237

7. DGIST Scholar record for Kwon et al., issued date August 2018. The exact calendar day used in some secondary indexes was not independently confirmed from the IEEE issue metadata in this pass. https://scholar.dgist.ac.kr/handle/20.500.11750/9227

8. Alias Robotics, “RVD#3316: No authentication in MAVLink protocol,” filed 30 June 2020; exploitation field “Not available.” https://github.com/aliasrobotics/RVD/issues/3316

9. National Vulnerability Database, CVE-2020-10282, published 3 July 2020, CWE-306, CNA Alias Robotics S.L. https://nvd.nist.gov/vuln/detail/CVE-2020-10282

10. See note 4.

11. MAVLink Developer Guide, “Message Signing (Authentication),” frame format and “Accepting Signed Packets.” https://mavlink.io/en/guide/message_signing.html

12. Ibid., “Accepting Unsigned Packets” and “Accepting Incorrectly Signed Packets.”

13. PX4, “MAVLink Security Hardening for Production Deployments”; PX4, “MAVLink Message Signing.” https://docs.px4.io/main/en/mavlink/security_hardening ; https://docs.px4.io/main/en/mavlink/message_signing

14. National Vulnerability Database, CVE-2020-10283, published 20 August 2020. https://nvd.nist.gov/vuln/detail/CVE-2020-10283

15. MAVLink Developer Guide, “MAVLink Versions,” “Negotiating Versions.” https://mavlink.io/en/guide/mavlink_version.html

16. vmayoral and khancyr, comments on RVD#3316, August 2020. https://github.com/aliasrobotics/RVD/issues/3316

17. MAVLink Developer Guide, “Message Signing (Authentication),” “Timestamp Handling.” https://mavlink.io/en/guide/message_signing.html

18. KimHyungSub, “MAVLink 2.0 message signing can be broken under GPS spoofing,” ArduPilot issue #13860, opened 22 March 2020, closed 26 March 2020. https://github.com/ArduPilot/ardupilot/issues/13860

19. Zack Colton, Alma Oracevic, and Selma Dilek, “Timestamp Manipulation-Based GPS Spoofing Attacks on the MAVLink 2.0 Protocol for UAV Communication: An Empirical Study,” *IEEE Transactions on Communications* 74 (2026): 2564–2579. https://doi.org/10.1109/TCOMM.2025.3644474

20. Institutional records at Hacettepe University and AVESİS list volume 74, pages 2564–2579, year 2026; the DOI landing page also carries a 15 December 2025 stamp. https://doi.org/10.1109/TCOMM.2025.3644474

21. Fei Du, Junbo Ge, Wen Wang, Yuwen Zou, Sang-Yoon Chang, and Wenjun Fan, “Exploiting the Vulnerabilities in MAVLink Protocol for UAV Hijacking,” 2024 17th International Conference on Security of Information and Networks (SIN). https://doi.org/10.1109/SIN63213.2024.10871546

22. CISA, ICSA-26-090-02, 31 March 2026. https://www.cisa.gov/news-events/ics-advisories/icsa-26-090-02

23. Ibid.; CVE Record CVE-2026-1579, CNA ICS-CERT, updated 31 March 2026. https://www.cve.org/CVERecord?id=CVE-2026-1579

24. Richard Appleby, “Technical Advisory – ExpressLRS vulnerabilities allow for hijack of control link,” NCC Group, 30 June 2022. https://www.nccgroup.com/research/technical-advisory-expresslrs-vulnerabilities-allow-for-hijack-of-control-link/

25. ExpressLRS, “Binding ExpressLRS.” https://www.expresslrs.org/quick-start/binding/

26. Simon Koeck, “ELRS Security: What’s Actually Possible Over the Air,” 2026. https://simonkoeck.com/blog/elrs-security-what-is-possible

Selected Bibliography

Alias Robotics. “RVD#3316: No authentication in MAVLink protocol.” 30 June 2020. https://github.com/aliasrobotics/RVD/issues/3316

Appleby, Richard. “Technical Advisory – ExpressLRS vulnerabilities allow for hijack of control link.” NCC Group, 30 June 2022. https://www.nccgroup.com/research/technical-advisory-expresslrs-vulnerabilities-allow-for-hijack-of-control-link/

Colton, Zack, Alma Oracevic, and Selma Dilek. “Timestamp Manipulation-Based GPS Spoofing Attacks on the MAVLink 2.0 Protocol for UAV Communication: An Empirical Study.” *IEEE Transactions on Communications* 74 (2026): 2564–2579. https://doi.org/10.1109/TCOMM.2025.3644474

Cybersecurity and Infrastructure Security Agency. “PX4 Autopilot.” ICS Advisory ICSA-26-090-02. 31 March 2026. https://www.cisa.gov/news-events/ics-advisories/icsa-26-090-02

Du, Fei, Junbo Ge, Wen Wang, Yuwen Zou, Sang-Yoon Chang, and Wenjun Fan. “Exploiting the Vulnerabilities in MAVLink Protocol for UAV Hijacking.” 2024 17th International Conference on Security of Information and Networks (SIN). https://doi.org/10.1109/SIN63213.2024.10871546

ExpressLRS. “Binding ExpressLRS.” https://www.expresslrs.org/quick-start/binding/

KimHyungSub. “MAVLink 2.0 message signing can be broken under GPS spoofing.” ArduPilot issue #13860. 22–26 March 2020. https://github.com/ArduPilot/ardupilot/issues/13860

Koeck, Simon. “ELRS Security: What’s Actually Possible Over the Air.” 2026. https://simonkoeck.com/blog/elrs-security-what-is-possible

Kwon, Young-Min, Jae-Min Yu, Byeong-Moon Cho, Yongsoon Eun, and Kyung-Joon Park. “Empirical Analysis of MAVLink Protocol Vulnerability for Attacking Unmanned Aerial Vehicles.” *IEEE Access* 6 (2018): 43203–43212. https://doi.org/10.1109/ACCESS.2018.2863237

MAVLink Developer Guide. “Message Signing (Authentication).” https://mavlink.io/en/guide/message_signing.html

MAVLink Developer Guide. “MAVLink Versions.” https://mavlink.io/en/guide/mavlink_version.html

National Vulnerability Database. CVE-2020-10282. Published 3 July 2020. https://nvd.nist.gov/vuln/detail/CVE-2020-10282

National Vulnerability Database. CVE-2020-10283. Published 20 August 2020. https://nvd.nist.gov/vuln/detail/CVE-2020-10283

PX4. “MAVLink Message Signing.” PX4 Guide (main). https://docs.px4.io/main/en/mavlink/message_signing

PX4. “MAVLink Security Hardening for Production Deployments.” PX4 Guide (main). https://docs.px4.io/main/en/mavlink/security_hardening

Source note. This paper distinguishes protocol-level design facts (MAVLink v1 has no authentication; MAVLink 2 signing is optional and specifies unsigned-acceptance paths; ExpressLRS documents its binding phrase as anti-collision) from implementation-currency questions (whether a given 2026 PX4 or ArduPilot build still accepts a v1 negotiation, which commercial SKUs match CISA’s SITL-tagged string, how wide the GPS-time initialization window is after persistent storage is populated, and what fraction of fielded ExpressLRS radios remain on 1.x/2.x). Catalogued CVEs and an ICS advisory are treated as identifiers and inventory, not as proof of in-wild exploitation; CISA’s “no known public exploitation” clause is preserved. Maintainer disputes are quoted as reasoning, not as closure. Independent 2026 commentary on ExpressLRS 3.x is graded below project documentation and is not promoted to a complete fix. Remote ID, firmware-update integrity, GCS parser cases, and payload-or-peripheral trust were excluded as sibling topics. Kwon’s exact IEEE Access calendar day is taken from a secondary institutional index (August 2018) and is not treated as a verified day-of-month. The analysis is current as of August 19, 2026 and should be revalidated against subsequent PX4 and ArduPilot releases, CISA or CNA identifiers, and any stock (non-journal) change to MAVLink 2 anti-replay time sources.