L-Re · Incidental Research

Signed Firmware Was the Story

# Signed Firmware Was the Story

*Update Channels, Phone-Side Installers, and the MAVLink Filesystem as the Decade’s Actual Trust Boundaries*

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

---

> **Research premise.** Signed firmware was the story. The decade’s public record is that the update channel, the phone-side installer, and the MAVLink filesystem were the actual trust boundaries, and they failed in public.

## Abstract

**Research premise.** For ten years the dominant public claim about unmanned-aircraft software trust has been that a cryptographic signature on a firmware image is the hard boundary between an official vehicle and an unofficial one. That claim is administratively convenient and technically incomplete. The public record from 2017 through 2026 shows three failures of a different object: the path that delivers code, the installer that seats it, and the filesystem that a command-and-control peer can rewrite. In 2017, community research on DJI’s Assistant-mediated update path and the associated DUML / RedHerring writeups demonstrated that asymmetric firmware signing plus a desktop updater was not a hard boundary on flying products, and that geofence, altitude, and distance policy sat behind that boundary. In 2020, Synacktiv and GRIMM documented a Play Store–bypassing forced-update path in the Android DJI GO 4 application, the pairing channel through which a million-plus-install fleet received GEO and safety patches. In March 2026, PX4’s assigned CVE for unauthenticated MAVLink FTP showed the same class on the open stack: any MAVLink peer can read, write, create, delete, and rename files on the flight-controller filesystem. This paper treats those three events as one argument, not as a recap of five signals. It distinguishes fact of record from inference and judgment, names what remains unknown, and refuses to treat “not established” as safe. Remote identification, default MAVLink signing, and cloud-key exposure are adjacent problems and are left to sibling papers except as a one-line contrast. The durable assurance object is not a signature ceremony. It is a Passport over the update channel, the installer, and the filesystem, watched as a Campaign and validated in Lab.

_Keywords: software assurance, firmware trust, update channel, mobile installer, MAVLink FTP, product security passport, unmanned aircraft systems, control fabric_

## 1. Introduction: The Apparent Story

A signature on a firmware image is the sentence most buyers, regulators, and even security reviews reach for first. The image is hashed. A vendor key signs the hash. The bootloader or the update handler verifies the signature before the vehicle is allowed to run the new code. If that ceremony holds, the argument goes, the aircraft is running what the manufacturer intended, and the geofence, the altitude ceiling, the mission file, and the parameter set inherit that intention. The sentence is memorable. It is also the wrong unit of analysis.

The decade’s public record does not show that signatures were unused. It shows that they were not the boundary that failed. In 2017 the dominant consumer OEM’s update path and on-device filesystem were demonstrated, in public writeups and contemporaneous press, to admit unofficial firmware and policy bypass on products then in the air. There was no CVE. There was a public record. In 2020 the same OEM’s phone-side pairing application was shown to install code outside a store review path, and the vendor itself described that path as a safety feature against “hacked” GEO and altitude-limit bypass. In 2026 the leading open autopilot assigned a CVE to an unauthenticated filesystem protocol that any ordinary MAVLink peer could speak. Three stacks. One class.

This is not a claim that signed firmware is worthless. **Fact:** signatures constrain who can produce a well-formed official image, and they raise the cost of a casual rewrite. **Judgment:** they do not, by themselves, establish that the channel that delivers the image, the installer that seats it, or the filesystem that a live peer can rewrite is a hard trust boundary. A Passport that records “signed firmware: yes” and stops there has measured a ceremony, not a system.

The argument developed here is therefore narrow. It does not reopen the radio-authentication debate that belongs with MAVLink signing-as-default. It does not reopen Remote ID as a location sensor. It does not reopen cloud-key exposure as a pairing-and-data boundary. Those are sibling papers. This paper asks a single question: when the public record is read as software assurance rather than as a highlight reel, what objects actually failed, and what would a product-level assurance record have to contain before “the firmware is signed” could be treated as evidence rather than as a story.

## 2. What a Signature Does Not Bind

A firmware signature binds, at most, a specific image to a specific key at a specific verification step. It does not bind the desktop or mobile program that chooses which image to send. It does not bind the protocol that carries the image onto the aircraft. It does not bind the filesystem once the image is installed, or once a live command-and-control peer is allowed to create, delete, and rename files that the flight controller will later treat as parameters, missions, geofences, or logs. It does not bind the phone that the operator must run in order to fly. Those are different objects. They sit on the Control Fabric: the set of channels, installers, filesystems, and pairing applications through which Sense becomes Move and, when a payload or a policy decision is in play, Act.

LrrK treats that fabric as inventory, not as atmosphere. A Passport is point-in-time and device-specific. It is not certification, approval, a warranty, or a guarantee of safety. It is an append-only record of what was claimed, what was observed, and what remains unknown. For update-and-filesystem trust the relevant Passport fields are not “does a signature exist.” They are: which key generation produced the image; which channel delivered it; which installer seated it, and whether that installer was a store, a sideload, or an in-app forced path; whether a live C2 peer can rewrite the flight-controller filesystem; and what evidence exists that those properties still hold on the unit in service. Kestrel’s job is to correlate key-rotation events and extractor-class publications across the Registry without collapsing them into a single “keys leaked” headline. Watch’s job is to keep unofficial firmware, forced-update flags, and FTP-on as Campaign items rather than as folklore. Lab’s job is to test the handler, not the brochure. KAT’s job is to walk the trust path from the phone or the GCS, through the update or filesystem protocol, to the physical consequence on the airframe.

**Inference, moderate confidence:** organizations that accept a vendor’s “signed updates” statement as a complete assurance claim will systematically under-count the objects that have already failed in public. **Unknown:** how many in-service fleets still treat that statement as sufficient. The unknown is not a finding of safety.

The rest of this paper takes the three public failures in chronological order and then returns them to a single assurance object. Exploit status is a high-level label only. No procedure, payload, key material, or tool command line is reproduced.

## 3. 2017: The Update Channel on Flying Products

On 27 June 2017, Freek van Tienen published a public repository of tools for reverse-engineering DJI product firmware.1 The same date is recorded in community key-comment metadata as the first widely cited publication of several firmware encryption and authentication labels used on then-current Phantom and Mavic families.7 Nine days later, on 6 July 2017, a public issue on the o-gs/dji-firmware-tools repository announced that the RedHerring root writeup then circulating as P0VsRedHerring applied across Phantom 4, Inspire 2, Mavic Pro, and Spark.2 The writeup itself described an Assistant-mediated path, an FTPD directory-traversal class, and a subsequent assistant-less DUML variant maintained in companion repositories.3 There was no CVE. There was no vendor advisory that mapped the issue to a closed set of versions. There was a public record, copied widely enough that contemporaneous press treated unofficial firmware as a market fact rather than as a rumor.

Motherboard, then published under Vice, reported in July 2017 that DIY modification of DJI firmware had moved from paid third-party services into public forums and Slack groups, that DJI was removing vulnerable firmware from its own servers and pushing updates “without further announcement,” and that Kevin Finisterre had released a public root writeup documenting a 2016 jailbreak mention by a user known as P0V.4 Finisterre told the outlet that the writeup was “more powerful” than first expected and that it extended across the product line. DJI’s technology security director, Victor Wang, said unauthorized modification was “not recommended” and that the company was “not responsible for the performance of a modified drone.” A company statement said a recent firmware update “fixes reported issues and ensures DJI’s products continue to provide information and features supporting safe flight.” A 14 July 2017 follow-up in the same outlet restated the physical consequence: manufacturer altitude and distance restrictions no longer applied to a modified Spark.5 The Register, on 11 July 2017, quoted DJI listing recent updates across Phantom, Mavic, Spark, and Inspire families.6

**Fact:** the 2017 record establishes a public, multi-product demonstration that the Assistant / DUML update path and the on-device filesystem were not a hard boundary, and that GEO, altitude, and distance policy sat behind that boundary. Community notes on the RedHerring repository later recorded that Spark aircraft firmware V01.00.0500 and Mavic firmware V01.03.1000 addressed the original FTPD/tar variant by making `/system` read-only and by changing archive-link behavior. **Unknown, preserved:** whether those mitigations, or the subsequent PUEK / PRAK / RREK rotations that continued into later years, closed the class on every in-service airframe, controller, and goggle. Completeness is forum and GitHub testimony, not a formal vendor advisory. **Not established is not safe.**

The LrrK reading is not that 2017 proved “DJI firmware can be decrypted.” That is a key-extraction headline, and key extraction is only one input to the actual failure. The failure was the update channel: a desktop installer and a device-side protocol that could seat unofficial images, and a filesystem that, once writable, made root and policy bypass a persistence problem rather than a one-shot radio trick. Campaign should treat unofficial firmware as evidence that a Passport failed, not as a how-to. Lab should treat the update handler as its own object. Kestrel should record key-rotation events separately from the extraction class, so that a later republication is not mistaken for a new exploit.

## 4. Keys as a Fact of Record, Not a New How-To

Six years later, a peer-reviewed paper at the 2023 Network and Distributed System Security Symposium stated the 2017 leak as a fact of record. Schiller, Chlosta, Schloegel, and colleagues, writing on DJI firmware and the OcuSync physical layer, noted that DJI encodes firmware in a proprietary format encrypted with AES and signed with RSA, that different modules and use cases use different keys, and that “some of these encryption keys have been leaked by individuals from the DJI community to decrypt parts of the firmware; we confirmed that these keys are valid.”8 That sentence is the only use this paper makes of the NDSS result. The paper’s headline finding concerned a tracking broadcast and is a sibling subject. What matters here is the confirmation: as of early 2023, leaked community keys still decrypted firmware modules. The signature ceremony had not, by itself, retired the 2017 record.

Currentness, not novelty, is the right frame for what happened next. On 4 November 2025, according to the commit comment later merged on 9 November, a joint team at the DF&C Lab at Kookmin University and the Cyber Security Team at the Korea Atomic Energy Research Institute republished a Programming Update Encryption Key labeled PUEK-2017-09 into the o-gs/dji-firmware-tools key-comment table. The comment records a first discovery in February 2018 by Jan Dumon, a first use on 20 September 2017, and a narrow version window on two airframe families. The commit added six lines of comment and a key label.9 It was not a CVE. It was not a new class. It was not a recipe. It is recorded here only to establish that the 2017 key-generation story was still being written, as bibliography, in late 2025.

**Judgment:** a Passport that lists “firmware keys rotated” without a generation identifier, a version window, and a Kestrel cross-reference to public extractor-class events is measuring a press release. **Inference, moderate confidence:** the 2023 NDSS confirmation and the 2025 key-comment republication together imply that “we sign firmware” remained, for some modules and some years, compatible with community decryption of those modules. Compatibility is not the same as a live exploit. It is also not a finding that the boundary held.

2017 also produced a public cloud-and-pairing failure, covered then by CyberScoop, the Register, and Ars Technica.10 That is a sibling object. This paper is about the failure that seated unofficial code on the airframe.

## 5. 2020: The Phone as the Installer

By 2020 the pairing application, not the desktop Assistant, was the ordinary way a DJI aircraft met its operator. Synacktiv’s 23 July 2020 analysis of the Android DJI GO 4 application, independently validated the same month by GRIMM, established the phone as a kinematic trust path.11 The recommended way to pilot the aircraft was to connect a phone to the remote controller and run GO 4. Synacktiv tested with a Mavic 2 and stated that GO 4 was used for most DJI drones. Google Play listed more than a million installs.

The versions under analysis were public: V4.1.22 from December 2017, V4.3.25 released 9 October 2019, and v4.3.36_200426, updated 12 May 2020. After de-obfuscation, Synacktiv located a self-update manager that queried a DJI upgrade endpoint and could force installation when a flag in the server’s JSON answer was set. The application then downloaded an APK from a vendor-controlled URL and prompted the user to install it, outside Google Play’s review path. GRIMM reproduced the forced-update flag and showed that a modified server answer could point the same dialog at an arbitrary APK.12 Both teams also documented a Weibo SDK command path capable of prompting installation of an additional application, identifier-collecting SDKs in earlier versions, and—on Android, not iOS—an application that did not terminate when the user swiped it closed. Synacktiv’s conclusion was that assessments of a given GO 4 build were “strongly limited because potential malicious code can be pushed by DJI afterwards through this auto-update mechanism.”

CyberScoop, on 23 July 2020, carried the research and a DJI statement.13 Brendan Schulman, speaking in a statement also shared with the New York Times,15 called the forced path a safety feature: “This safety feature in the Android version of one of our recreational flight control apps blocks anyone from trying to use a hacked version to override our safety features, such as altitude limits and geofencing. If a hacked version is detected, users are prompted to download the official version from our website.” The same statement said the feature was not in the government-edition software. A CyberScoop spokesperson quote added that future versions would also offer a Google Play download “if it is available in their country,” and that an unauthorized version would be disabled if the user did not consent. DroneLife, on 29 July 2020, recorded DJI characterizing the findings as “hypothetical vulnerabilities” and “potential bugs,” restating the anti-hack rationale, and disputing the swipe-to-close restart.14 Ars Technica the same week reported that both teams had seen the automatic update mechanism trigger and install a vendor APK, and that they had not seen evidence the installer had been used to target individuals.16

**Fact:** a million-plus-install pairing application could seat code on the phone outside store review, and the vendor publicly defended that path as the mechanism that keeps GEO and altitude policy on the aircraft. **Fact:** the iOS build, per Synacktiv, did not carry the hidden update mechanism. **Unknown:** whether any in-the-wild targeting of the forced path occurred. Both research teams said they had not seen it. Absence of observed targeting is not a finding that the path cannot be used that way. **Not established is not safe.**

The LrrK object is the installer. Passport fields that matter are store versus sideload versus in-app, the presence of a force flag, and whether GEO or NFZ unlocks are gated on the same channel. Sense, on this path, is who is on the phone—identity, permissions, and which build is actually running. Act is the policy the aircraft will obey once that build is allowed to fly. Watch should keep enterprise Pilot on a separate ledger from GO 4. The next section is why.

## 6. Safety Feature, Store Bypass, and an Unclosed Path

DJI’s reply did not deny the mechanism. It redescribed it. A forced update that can disable a modified client is, in the vendor’s telling, how a manufacturer keeps altitude limits and geofences consistent across a consumer fleet. That description can be true as a safety intention and still fail as an assurance claim. The Control Fabric question is not whether the vendor prefers official builds. It is whether the path that enforces that preference is itself a reviewable, attributable, non-targeted installer.

On 31 July 2020, by DJI’s later account, the company updated Android GO 4, removed a collecting SDK, and began directing automatic safety-related updates to Google Play rather than to its website.18 On 5 August 2020, after Synacktiv published a follow-on analysis of the enterprise Pilot application, DJI told SecurityWeek that the new claims were “false” and “misleading,”17 that no Pilot version used the collecting SDK at issue, and that the Play Store build of Pilot updated only to official Play Store versions. Website-distributed Pilot, DJI said, was a different channel for countries where Play was unavailable. Local Data Mode, the vendor added, blocks some geofence unlocks by design; government-edition aircraft have no geofencing; and the Qualified Entities Program can unlock a region after an initial activation. SecurityWeek recorded both the vendor’s safety-rationale language and the fact that Synacktiv had not used the bug-bounty channel before publishing.

**Fact:** GO 4’s forced path is a matter of two independent public analyses, contemporaneous press, and a vendor statement that names the path and defends it. **Fact:** Pilot’s forced-update and SDK claims are vendor-disputed, and no third-party analysis of later Pilot builds has, in the sources consulted for this paper, closed that dispute. **Inference, moderate confidence:** Local Data Mode does not close a forced-update path that lives on the phone, because the mode’s documented effect is to restrict some safety-unlock workflows, not to retire the installer. **Unknown:** the complete version map of which GO 4 and Pilot builds, in which regions, still carry a non-store installer. Subsequent coverage in 2021 recorded that Android GO 4 and DJI Fly were no longer receiving current versions through Play and were being distributed from DJI’s website.19 That later sideload posture is consistent with the 2020 finding that the phone-side channel is a trust path. It does not, by itself, prove that the 2020 force flag remained on every later build.

**Judgment:** a safety feature that can also seat arbitrary code is still an installer, and an installer belongs on the Passport whether or not the vendor’s intention is benign. Campaign should record unofficial or force-updated clients as evidence about the pairing application, not as a moral claim about operators. Lab should treat “store-only update” as a hypothesis to be established or left not established, never as a default.

## 7. 2026: An Unauthenticated C2 Peer Rewrites the Flight-Controller Filesystem

The open stack produced the clean CVE. On 13 March 2026, PX4 published GitHub security advisory GHSA-fh32-qxj9-x32f.20 On 16 March 2026, NVD published CVE-2026-32709.21 The assigned description is the argument of this paper in one paragraph. Prior to 1.17.0-rc2, an unauthenticated path-traversal vulnerability in PX4’s MAVLink FTP implementation allowed any MAVLink peer to read, write, create, delete, and rename arbitrary files on the flight-controller filesystem without authentication. On NuttX targets the FTP root was an empty string, so peer-supplied paths were passed to filesystem calls without a prefix or sanitization on read. On POSIX targets—Linux companion computers and SITL—the write-path validation function unconditionally returned true. A time-of-check/time-of-use race on NuttX bypassed the only existing write guard. The advisory’s impact statement named the objects that sit behind that filesystem: configuration, logs, cryptographic keys, parameters, mission plans, and geofence files. Physical consequence, as the advisory put it, included loss of vehicle control, crashes, or override of geofence boundaries. The fix is the 1.17.0-rc2 tag.

NVD’s initial analysis assigned CVSS 3.1 6.8 Medium (adjacent, high complexity, privileges none, integrity and confidentiality high). The GitHub CNA assigned 5.4 Medium (adjacent, low complexity, privileges none, integrity and confidentiality low).22 CISA’s ADP enrichment, recorded on the NVD change history, set SSVC exploitation to `poc`, automatable to `no`, and technical impact to `partial`. The advisory is referenced as a vendor advisory and as an exploit writeup. It is not in the CISA Known Exploited Vulnerabilities catalog.23 Exploit status, as a label: public writeup; needs a MAVLink peer; not KEV.

**Fact:** this is the first clean assigned CVE that a normal MAVLink peer can rewrite the flight-controller filesystem. **Inference, moderate confidence:** any integrator still on 1.17.0-rc1 or earlier with FTP enabled inherits the condition. **Unknown:** the in-service population that still ships FTP-on as a default, and whether companion-computer POSIX targets were inventoried separately from NuttX flight controllers. A Passport that says “we use MAVLink 2” has not spoken to this CVE. The evidence that matters is the rc2 tag, the FTP-enabled bit, and the root-path configuration.

The contrast with the 2017 OEM case is architectural, not moral. DJI’s 2017 failure was a signed-update bypass on a proprietary channel, without a CVE. PX4’s 2026 failure is an unauthenticated filesystem rewrite on a standard C2 protocol, with a CVE, a GHSA, and an NVD record. The class is the same: the peer that is already allowed to talk is allowed to persist. A sibling paper treats unauthenticated command and shell messages on the same bearer; this paper’s object is the filesystem those messages can rewrite. Signing-as-default on the radio is a different control and is not re-argued here.

Watch should campaign FTP-on across PX4 ports. Lab should treat the FTP root and the write-validation function as bench objects, and should preserve a negative result if a given port has FTP compiled out. Kestrel’s correlation is the advisory identifier and the rc2 tag, not a general “MAVLink is unsafe” smear. KAT’s path is short and physical: C2 peer, filesystem primitive, parameter or geofence file, aircraft behavior.

## 8. Three Failures, One Trust Object

The three events are easy to file under three vendor names and three years. That filing system hides the argument.

### Table 1. Public update-and-filesystem failures as assurance objects

| Year | Public record | Apparent story | Actual trust object | Class of failure | Physical / policy consequence | Exploit status |
| --- | --- | --- | --- | --- | --- | --- |
| 2017 | o-gs / RedHerring writeups; Motherboard/Vice; no CVE | Firmware is signed; Assistant is the official updater | OEM update channel and on-device filesystem | Signed-update bypass on a public writeup | Root and GEO / altitude / distance policy sit behind a writable path | Public writeup; not KEV |
| 2020 | Synacktiv; GRIMM; CyberScoop; vendor statement | The phone app is a convenience; Play Store is the review path | Phone-side installer on the pairing application | Forced mobile installer outside store review | GEO / NFZ and safety patches delivered by a channel that can seat arbitrary APKs | Public writeup; not KEV |
| 2026 | GHSA-fh32-qxj9-x32f; CVE-2026-32709; NVD; CISA SSVC | MAVLink is a telemetry protocol; FTP is a convenience | Flight-controller filesystem reachable by any C2 peer | Unauthenticated filesystem rewrite | Parameters, missions, geofences, logs, and keys are peer-writable; behavior change or brick | Public writeup; SSVC `poc`; not KEV |

What the table does not contain is as important as what it does. It does not contain a score. It does not contain a recipe. It does not collapse key-extraction, installer abuse, and path traversal into a single “drones are hackable” sentence. Each row is a different mechanism on a different stack. Each row fails the same Passport question: is the path that changes what the vehicle will do itself authenticated, reviewable, and scoped?

**Judgment, high confidence:** the decade’s pattern is not that signatures were omitted. It is that signatures were asked to cover objects they do not bind. **Inference, moderate confidence:** any fleet that still inventories “signed firmware” as a binary and does not inventory channel, installer, and filesystem will mis-classify the next public writeup as a novelty. **Unknown:** the share of public-safety, infrastructure, and defense-adjacent fleets whose acceptance records still stop at the signature. That unknown is an assurance gap, not a residual-risk acceptance.

A one-line contrast, and no more: unauthenticated MAVLink command traffic, plaintext Remote ID, and 2017 cloud-key exposure are real, public, and adjacent. They are not this paper’s object. Treating them as interchangeable with an update-channel failure is how a five-signal recap replaces an argument.

## 9. From Signing Claims to Product Assurance

If the unit of analysis is the Control Fabric, the remedy is not another adjective on the word “signed.” It is a record that can be wrong in public and then corrected in public.

A Passport for an in-service aircraft should identify the airframe, the controller, the goggles, the companion computer, and the pairing application as separate inventory lines. For each line it should record the firmware or application generation, the key-generation label if one exists, the channel that last delivered an update, and the installer class: store, sideload, in-app, or unknown. Unknown is a first-class value. For open-stack vehicles it should record whether MAVLink FTP is enabled, what the FTP root is, and whether the running tag is at or after 1.17.0-rc2. For OEM vehicles it should record whether unofficial firmware has been observed on the unit, and it should treat that observation as a Passport failure rather than as operator misconduct. Kestrel should attach key-rotation and extractor-class events to generations, not to brands. Watch should keep three Campaign items open until evidence closes them: unofficial firmware on OEM fleets, force-update or website-only installers on pairing applications, and FTP-on across PX4 ports.

Lab’s role is to constrain those claims. A bench that confirms a store-only update path has established a scoped fact. A bench that cannot confirm it has produced a not-established, which is not a pass. A bench that confirms FTP compiled out has rejected a hypothesis for that build. A bench that is never run is not evaluated. LrrK’s method forbids promoting any of those four outcomes into a safety score.

KAT should walk one path per Campaign and stop when the path leaves the object. For 2017 the path is Assistant or DUML-class updater, to on-device filesystem, to policy. For 2020 it is the phone, to the in-app installer, to the build that is allowed to fly, to the GEO or altitude rule the aircraft will obey. For 2026 it is the MAVLink peer, to FTP, to a file the controller will read as a parameter, a mission, or a geofence, to Move. Sense is who is speaking. Move is what the airframe does. Act is the policy or payload decision that follows. The path is the argument. The signature is a node on the path, or it is not.

**Recommendation, not a finding:** acceptance programs that still treat “the firmware is signed” as a complete control should add the three Passport fields this paper names and keep them current as Watch items. Unofficial firmware, a forced installer, and FTP-on should be Campaign evidence, not folklore and not a how-to.

What would change the argument is also easy to state. A formal DJI advisory that maps the 2017 DUML and key issues to versions would retire part of the unknown in section 3. A third-party analysis of current enterprise Pilot, not the vendor’s 2020 reply, would retire part of the unknown in section 6. A tagged PX4 release that is unambiguous for adjacent filesystem and serial-passthrough defects would tighten the 2026 inventory, but those adjacent defects are not this paper’s object. Until those records exist, the honest disposition is not established.

## 10. Conclusion

Signed firmware was the story because it is easy to say and easy to check at a distance. The decade’s record is that the story was about the wrong object. In 2017 the update channel on the dominant OEM’s flying products failed in public, without a CVE, and GEO and altitude policy sat behind it. In 2020 the phone-side installer on the pairing application failed in public, and the vendor called the failure a safety feature. In 2026 the MAVLink filesystem on the open autopilot failed in public, with a CVE, and a normal C2 peer could rewrite the files that define how the vehicle moves. The 2023 NDSS confirmation that leaked keys still decrypted modules, and the 2025 PUEK-2017-09 key-comment republication, are currentness. They are not a new class and they are not instructions.

LrrK’s claim is modest and operational. A Passport that stops at the signature has not measured the Control Fabric. A Watch that does not campaign unofficial firmware, forced installers, and FTP-on will treat the next public writeup as news. A Lab that does not bench the handler will keep promoting vendor sentences into facts. The systems at issue sense, move, and act. The path that changes what they will do is the trust boundary. It failed in public. The record is the argument.

Endnotes

1. Freek van Tienen, dji_rev repository, created 27 June 2017. https://github.com/fvantienen/dji_rev

2. o-gs/dji-firmware-tools, issue 39, “Red Herring root exploit now works on P4, I2, Mavic & Spark (universal DJI jailbreak),” opened 6 July 2017. https://github.com/o-gs/dji-firmware-tools/issues/39

3. MAVProxyUser, P0VsRedHerring repository, public RedHerring writeup (repository created 1 July 2017; community notes record Spark V01.00.0500 and Mavic V01.03.1000 as addressing the original FTPD/tar variant). https://github.com/MAVProxyUser/P0VsRedHerring

4. Motherboard / Vice, “DJI Is Locking Down Its Drones Against a Growing Army of DIY Hackers,” July 2017. https://www.vice.com/en/article/3knkgn/dji-is-locking-down-its-drones-against-a-growing-army-of-diy-hackers

5. Motherboard / Vice, “We Talked to the Guy Selling a Pre-Hacked Drone on eBay,” 14 July 2017. https://www.vice.com/en/article/we-talked-to-the-guy-selling-a-pre-hacked-drone-on-ebay/

6. The Register, “Hackers able to turbo-charge DJI drones way beyond what's legal,” 11 July 2017. https://www.theregister.com/security/2017/07/11/hackers-able-to-turbo-charge-dji-drones-way-beyond-whats-legal/750937

7. o-gs/dji-firmware-tools, dji_imah_fwsig.py key-comment table (community publication dates, including 27 June 2017 van Tienen labels). https://github.com/o-gs/dji-firmware-tools/blob/master/dji_imah_fwsig.py

8. Nico Schiller, Merlin Chlosta, Moritz Schloegel, Nils Bars, Thorsten Eisenhofer, Tobias Scharnowski, Felix Domke, Lea Schönherr, and Thorsten Holz, “Drone Security and the Mysterious Case of DJI's DroneID,” Network and Distributed System Security Symposium, 27 February–3 March 2023. https://www.ndss-symposium.org/ndss-paper/drone-security-and-the-mysterious-case-of-djis-droneid/ ; PDF: https://www.ndss-symposium.org/wp-content/uploads/2023/02/ndss2023_f217_paper.pdf

9. o-gs/dji-firmware-tools, commit 93507d2, “dji_imah_fwsig: Add PUEK-2017-09,” merged 9 November 2025; comment dates public republication to 4 November 2025 by DF&C Lab, Kookmin University, and KAERI Cyber Security Team. https://github.com/o-gs/dji-firmware-tools/commit/93507d23ca7d153c1bac5a2e3a92071fc0678832

10. CyberScoop, “DJI bug bounty program has turned into a PR nightmare.” https://cyberscoop.com/dji-bug-bounty-drone-technology-sean-melia-kevin-finisterre/

11. Synacktiv, “DJI Android GO 4 application security analysis,” 23 July 2020. https://synacktiv.com/publications/dji-android-go-4-application-security-analysis

12. GRIMM, “DJI Privacy Analysis Validation,” July 2020. https://grimmcyber.com/dji-privacy-analysis-validation/

13. Shannon Vavra, “App for Chinese DJI drones could give hackers full control of users' phones, researchers say,” CyberScoop, 23 July 2020. https://cyberscoop.com/dji-drones-china-android-application/

14. Jim Magill, “DJI Responds to Reports of Potential Go App Security Problems,” DroneLife, 29 July 2020. https://dronelife.com/2020/07/29/dji-go-app-security-problems/

15. New York Times, “Popular Chinese-Made Drone Is Found to Have Security Weakness,” 23 July 2020. https://www.nytimes.com/2020/07/23/us/politics/dji-drones-security-vulnerability.html

16. Dan Goodin, “Chinese-made drone app in Google Play spooks security researchers,” Ars Technica, July 2020. https://arstechnica.com/information-technology/2020/07/chinese-made-drone-app-in-google-play-spooks-security-researchers/

17. Eduard Kovacs, “Drone Maker DJI Says Claims About Security of Pilot App 'Misleading',” SecurityWeek, August 2020. https://www.securityweek.com/drone-maker-dji-says-claims-about-security-pilot-app-misleading/

18. DJI, “DJI Statement On Further Misleading Claims About App Security,” 5 August 2020, as reprinted in full by DroneDJ, “DJI refutes allegations against Android 'Pilot' app,” 5 August 2020. https://dronedj.com/2020/08/05/dji-denies-claims-that-its-android-pilot-app-has-security-issues/

19. Skyzr, “DJI Apps - Errors with Play Store versions on Android” (subsequent coverage that GO 4 from 4.3.37 and Fly from 1.2.4 were no longer current on Play). https://www.skyzr.com/en/dji/dji-fly-app/dji-apps-errors-with-play-store-versions-on-android/

20. PX4, GHSA-fh32-qxj9-x32f, “PX4 Autopilot MAVLink FTP Unauthenticated Path Traversal (Arbitrary File Read/Write/Delete),” 13 March 2026. https://github.com/PX4/PX4-Autopilot/security/advisories/GHSA-fh32-qxj9-x32f

21. National Vulnerability Database, CVE-2026-32709, published 16 March 2026; CISA-ADP SSVC recorded on the NVD change history. https://nvd.nist.gov/vuln/detail/CVE-2026-32709

22. CVE Program, CVE-2026-32709. https://www.cve.org/CVERecord?id=CVE-2026-32709

23. CISA, Known Exploited Vulnerabilities Catalog (CVE-2026-32709 not listed as of the collection cutoff). https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Selected Bibliography

CISA. Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog

GRIMM. “DJI Privacy Analysis Validation.” July 2020. https://grimmcyber.com/dji-privacy-analysis-validation/

National Vulnerability Database. CVE-2026-32709. 16 March 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-32709

o-gs. dji-firmware-tools. https://github.com/o-gs/dji-firmware-tools

PX4. GHSA-fh32-qxj9-x32f. 13 March 2026. https://github.com/PX4/PX4-Autopilot/security/advisories/GHSA-fh32-qxj9-x32f

Schiller, Nico, Merlin Chlosta, Moritz Schloegel, Nils Bars, Thorsten Eisenhofer, Tobias Scharnowski, Felix Domke, Lea Schönherr, and Thorsten Holz. “Drone Security and the Mysterious Case of DJI's DroneID.” NDSS, 2023. https://www.ndss-symposium.org/ndss-paper/drone-security-and-the-mysterious-case-of-djis-droneid/

Synacktiv. “DJI Android GO 4 application security analysis.” 23 July 2020. https://synacktiv.com/publications/dji-android-go-4-application-security-analysis

van Tienen, Freek. dji_rev. 27 June 2017. https://github.com/fvantienen/dji_rev

Vice / Motherboard. “DJI Is Locking Down Its Drones Against a Growing Army of DIY Hackers.” July 2017. https://www.vice.com/en/article/3knkgn/dji-is-locking-down-its-drones-against-a-growing-army-of-diy-hackers

Source note. This paper distinguishes three public update-and-filesystem failures (2017 DUML / RedHerring, 2020 DJI GO 4 forced installer, 2026 PX4 MAVLink FTP) from adjacent decade records treated in sibling papers: Remote ID and AeroScope, MAVLink signing-as-default and unauthenticated command/shell, and 2017 cloud-key / pairing exposure. PUEK-2017-09 (4 November 2025 republication; 9 November 2025 merge) is cited only as currentness of a key-comment commit, not as a new CVE or a method. Enterprise Pilot forced-update behavior remains vendor-disputed and is labeled as such. No formal DJI advisory mapping 2017 DUML or key issues to versions was located. CVE-2026-32709 is not in KEV. The analysis is current as of August 19, 2026 and should be revalidated against subsequent GHSA, NVD, CISA, vendor, and Play-distribution notices. No exploit steps, key material, or tool command lines are included.