← GrokBot Source Archive

L-Re · Incidental Research

The Airframe Is Not the Trust Object

Source-imported record. This page is not a QSVFF-sealed filing or a verification certificate.
Recorded date
2026-08-19
Drive source path
quiet-systems-archive/L-Re/2026-08-19-dksr-04-payload-peripheral.md
Imported-content SHA-256
fe777f5632b140a52fda6be8f9f79596e08378a6c5218ae370dbd25ffa1ad05b
Imported representation
Drive UTF-8 text
Open original Drive locator ↗ · View source Markdown
# The Airframe Is Not the Trust Object

*Payloads, Peripherals, and Power on the Kinematic Path*

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

---

> **Research premise.** The airframe is not the only trust object. Cloud keys, a camera heartbeat on a naval uncrewed surface vessel, a shared media-transfer SDK, civil GPS, and a smart-battery CAN driver all sat on the kinematic path and failed in public; labels that stop at hull, SKU, or NDAA compliance do not audit those objects.

## Abstract

**Research premise.** Procurement, program assurance, and operator practice still treat the airframe—the hull, the SKU, the named OEM—as the unit of trust. That habit is administratively convenient and technically incomplete. Over a decade of public record, five failures that were not the aircraft radio sat on the same Sense–Move–Act path: 2017 cloud-key exposure at the dominant OEM; an August 2026 camera heartbeat from Royal Navy K3 Scout USVs to a China IP, on modules described as NDAA-compliant; a 2024 shared media-transfer SDK with CVEs across consumer Mavic and enterprise Matrice; civil GPS still spoofable in 2022 chamber tests on current DJI and Autel airframes; and a 2026 optional PX4 smart-battery CAN driver shown to crash the autopilot. This paper is a software-assurance analysis of those five objects as one argument. It does not reprint a watch brief, does not treat “not established” as safe, and does not treat an NDAA label as a firmware-behavior audit. Unpublished OEM names, IPs, and field outcomes are residuals, not findings of absence.

_Keywords: unmanned systems, software assurance, payload security, GNSS authentication, battery management, supply-chain labels, product security passport, kinematic path_

## 1. Introduction: The Apparent Puzzle

A buyer can name the airframe. A program office can name the hull and the contract. An operator can name the SKU on the ramp or on the boat. Those names feel like trust objects because they are the things one can photograph, inventory, and write into a bill of materials. They are not a complete description of what has to be true for the vehicle to remain under the intended operator.

The puzzle is easiest to misunderstand when a failure is narrated as a story about “the drone.” The 2017 DJI cloud-key exposure was not a radio compromise of a Phantom. The August 2026 K3 Scout case was not a finding that the British hull had been reverse-engineered. The 2024 QuickTransfer CVEs were not a demonstration that one Mavic airframe had been uniquely neglected. The 2022 chamber results on civil GPS were not a software defect in a named firmware revision. The 2026 Tattu CAN advisory was not a field report of a vehicle falling out of the sky. Each event is easier to file if it is treated as a curiosity attached to a famous brand or a famous boat. Filed that way, the five records look like a recap. Read as software assurance, they are one argument: the kinematic path has more than one trust object, and several of those objects failed in public while the airframe remained the thing people named.

LrrK’s vocabulary is useful here only because it names the path rather than the hull. Control Fabric is the set of channels, identities, and services that bind operator intent to machine state. Sense includes pairing telemetry, flight logs, battery reports, and the GNSS solution the controller treats as position, not only the camera the mission paid for. Move is navigation state becoming actuator command. Act is the physical consequence. A Product Security Passport is the signed record of those objects—firmware lineage, shared libraries, cloud endpoints, observed egress, optional drivers—not a brochure claim of compliance. Watch is the live question a new public case opens. Kestrel treats an identical module on another hull as the same object until evidence says otherwise. Lab scopes a claim and either establishes it or leaves it not established. KAT is the chain from an input the vehicle believes to an actuator it will obey.

This paper defends a single claim. Assurance that stops at the airframe will keep being surprised by cloud keys, payload heartbeats, shared SDKs, unauthenticated GNSS, and powertrain drivers. The five cases are evidence for that claim, not a catalog of every adjacent vulnerability class. Command-link signing, Remote ID, and update-path deep dives belong to sibling papers. They are omitted here on purpose.

## 2. The Path Has More Trust Objects Than the Hull

A kinematic system is an argument from perception to motion. The operator’s trust is that Sense will report the world and the self, that Move will compute a lawful trajectory, and that Act will apply force only as commanded. The airframe is the mechanical envelope in which that argument runs. It is not the argument.

Five public failures, spanning 2017 to 2026, sit on that path without being the airframe radio. They are different components, different vendors, and different years. What they share is a misplaced unit of analysis.

### Table 1. Trust objects on the kinematic path that are not the airframe

| Object | Failure class | What became public | What a common label does not prove |
| --- | --- | --- | --- |
| OEM cloud pairing | Cloud-key exposure | 2017: private SSL, AWS, and firmware material in public view; flight logs and identity images described as visible | An offline “local data” mode is not a retrospective accounting of keys that were already public |
| Third-party payload camera | Out-of-band payload heartbeat | 2026: heartbeat / squark traffic from cameras on a naval USV to a China IP | An NDAA-compliant sticker is not a firmware-behavior audit |
| Shared media-transfer SDK | Shared-library credential and memory-safety class | 2024: one `v2_sdk` service across Mavic and Matrice SKUs, including enterprise | A per-SKU firmware number is not evidence of a unique codebase |
| Civil GNSS receiver | Unauthenticated civil GPS | 2022: COTS DJI and Autel remain spoofable in chamber over-the-air tests | An authentication-service brochure is not evidence that this receiver verifies this signal |
| Optional BMS CAN driver | Unauthenticated smart-battery CAN reassembly | 2026: unbounded copy in a Tattu 12S path can crash PX4 | “Battery” is not a trust boundary; a CVE that demonstrates crash is not a demonstrated field drop |

**Fact.** Each row is grounded in a named public primary treated in the sections that follow. **Inference, moderate confidence.** Shared on-vehicle SDK services and optional BMS drivers will keep producing fleet-wide CVEs because one library or one CAN module ships on many SKUs. **Judgment.** Treating the airframe as the trust object is a category error, not a conservative default. **Unknown.** How long the 2017 keys were public, whether the 2026 heartbeat carried location, and whether a Tattu CAN crash becomes loss of control in flight are not independently established. Not established is not safe.

The Control Fabric in this reading is larger than the command link. It includes the cloud endpoints that pair the aircraft to an identity, the payload module that can open its own channel, the on-vehicle service that moves media off the sensor, the GNSS input the navigator believes, and the powertrain bus the flight controller polls. A Passport that records only airframe serial and “latest firmware” has not named those objects. A Watch that waits for a CVE titled after the hull will miss them. A Lab that tests only the radio will certify a path it did not examine.

## 3. Cloud Pairing Failed Before the Radio Did

On 16 November 2017, Kevin Finisterre published an eighteen-page account under the title “Why I walked away from $30,000 of DJI bounty money.” The Register reported the same day; Ars Technica and BBC News followed that week.1–3 The technical finding was not a novel airframe exploit. Developers had left, in public GitHub repositories, the private key for a wildcard HTTPS certificate covering DJI web domains, credentials for Amazon Web Services accounts, and firmware AES material. Poorly configured S3 buckets held customer data. Finisterre described seeing unencrypted flight logs and images of passports, driver’s licenses, and other identification cards. Contemporary press added that some logs were associated with government and military domains.1,2 DJI revoked the exposed HTTPS certificate and obtained a new one in September 2017.1 How long the keys had been public, and what third parties actually retrieved, was not independently measured then and has not been measured since.

The process failure was public in the same week. Finisterre had contacted DJI in September under a newly announced bounty program, was told servers were in scope, and on 28 September was notified that the report had earned the $30,000 top reward. The subsequent agreement, in his account and in contemporaneous press, offered no protection against legal action. DJI’s legal department referenced the Computer Fraud and Abuse Act. He walked away and published. DJI’s 16 November statement called him a “hacker,” said the access was unauthorized, and said it had engaged an independent firm. The first public bounty process of the dominant OEM collapsed into a CFAA-tinged dispute and then into public terms.

**Fact.** The keys, the buckets, the described contents, the revoked certificate, the $30,000 offer, and the public quarrel are in the 2017 record. **Unknown.** The historical exposure window and third-party retrieval are not established. **Judgment.** This remains the first widely reported proof that the dominant OEM’s customer-data and pairing boundary had failed, not merely that an aircraft radio had been studied. It is still the citation that belongs next to the August 2017 U.S. Army halt and DJI’s subsequent Local Data Mode, and it should not be replaced by a later gloss titled “2017 DJI data breach.”

The Army memo of 2 August 2017 directed a halt on DJI products for unspecified “cyber vulnerabilities.”4 DJI announced Local Data Mode on 14 August 2017 as an application setting that prevents the control app from sending or receiving internet traffic.5 That mode is a useful control for a future flight. It is not a retrospective fix for keys that had already sat in public repositories, and it does not reconstruct who held copies. A Passport that records “Local Data Mode enabled” as if it closed 2017 has recorded a configuration, not an accounting.

For LrrK the 2017 case is a Control Fabric and Passport problem before it is an airframe problem. Cloud endpoints and key-material handling are objects. Flight logs and identity documents are Sense about the operator and the aircraft. Firmware keys feed an update path that is out of scope here; they are mentioned only to note that the same exposure touched more than customer data. Watch any later claim that recycles “2017 DJI data breach” without this primary. Campaign work that treats pairing as a signed field, rather than as a brand assumption, is the durable response.

## 4. A Naval Camera Heartbeat Is Not a Provenance Sticker

On 10 August 2026, the BBC reported that cameras on the Royal Navy’s new K3 Scout uncrewed surface vessels had sent a squark—also called a heartbeat communication—to a Chinese IP address.6 The Ministry of Defence said the finding came from a “routine cyber vulnerability assessment.” An MoD spokesperson said: “A thorough investigation found no evidence of MoD data or systems being accessed, compromised or transmitted externally.”6 The BBC noted that a squark can signal that a system is switched on and functioning, and that it can also carry location information. The report did not state that this heartbeat did. The story was first reported by *The Telegraph*. *The Independent*, *Naval Technology*, and BetaNews published confirming accounts the same week.7–9

The boats are not a consumer airframe. The Royal Navy bought twenty K3 Scout vessels from Kraken Technology Group, a British contractor in Fareham, under Operation Beehive. *Naval Technology* places the order in March 2026 and the reported handover between May and June. The cameras were an unnamed third-party payload. Kraken told *Naval Technology*: “We are aware that some third-party, NDAA compliant cameras had a small number of components originating from outside the UK.” After a joint audit with the Royal Navy, the company said it was confident that no sensitive information had been shared outside intended channels and that “any potential vulnerabilities have been identified and closed.”8 Secondary reports said internet connectivity was removed from the affected cameras. The MoD did not confirm or deny that cut.8,9

**Fact.** Heartbeat traffic from third-party cameras on RN K3 Scouts to a China IP, found in a routine MoD cyber assessment, with the quoted MoD and Kraken statements, is in the August 2026 record. **Unknown.** Camera OEM, firmware revision, the IP, whether location left the boat, the unpublished assessment calendar date, and whether connectivity was in fact cut remain unpublished. **Inference, moderate confidence.** “NDAA compliant” will keep being treated as a Passport it is not. Section 889 of the U.S. National Defense Authorization Act restricts named manufacturers. It does not verify the network behavior of firmware already on a module, and it does not inspect every subcomponent inside a camera sold as compliant.

This is the live Watch item of the argument. It is also the cleanest recent demonstration that Sense can open an undeclared Control Fabric channel. The camera is the payload the mission paid for. The heartbeat is a channel the bill of materials did not declare. A hull that is British, a camera that is labeled NDAA-compliant, and a vendor statement that vulnerabilities have been “closed” can all be true in the sense that they were said, and still leave firmware behavior unaudited. Lab work that is worth the name here is egress-deny on the payload module: observe what the camera talks to, on first power, off the boat’s intended fabric, and write the observation into the Passport as behavior rather than as a sticker. Kestrel is the uncomfortable next sentence. Identical camera modules on other Registry hulls are the same object until a signed difference is shown. Waiting for a CVE or a vendor name is waiting for a label. The channel already existed.

**Judgment.** NDAA-label is not a firmware-behavior audit. Treating it as one is how a naval USV acquires an out-of-band payload heartbeat and still looks, on paper, like a trusted platform. **Unknown** is not a finding that location was not transmitted. The BBC’s modal verb—“can carry”—is the honest bound. A Passport that records “no evidence of MoD data transmitted” as if it were “no channel existed” has collapsed a negative finding into a safety claim. LrrK method does not permit that collapse.

## 5. One Library, Many SKUs

On 29 March 2024, Nozomi Networks Labs published advisories against a Wi-Fi media-transfer path DJI calls QuickTransfer, implemented in a shared on-drone service (`dji_vtwo_sdk` / `libv2_sdk.so`) listening on port 10000.10,11 The NVD records followed on 2 April 2024.12–16 The affected list is not a single consumer toy. It includes Mavic 3 Pro, Mavic 3, Mavic 3 Classic, Mavic 3 Enterprise, Matrice 300, Matrice M30, and Mini 3 Pro, each below a named firmware revision. QuickTransfer is the payload-egress path for photographs and video. The same library shipped on enterprise airframes used for inspection and public-safety work.

The published class is not mysterious and does not need a recipe. CVE-2023-6951 is use of weak credentials on the drone-generated Wi-Fi network: an adjacent party may derive the WPA2 PSK and join the access point that QuickTransfer exposes when the aircraft is on the ground. CVE-2023-51454 is an out-of-bounds write in the shared SDK service. CVE-2023-51455 is improper validation of an array index in the same service. CVE-2023-51456 is improper input validation in the same service. Nozomi assigned the memory-safety trio a CVSS 6.8 vector with high confidentiality, integrity, and availability impact on the service; CISA’s SSVC on 6951 recorded exploitation as none. None of the four is in CISA’s Known Exploited Vulnerabilities catalog. Exploit status is advisory-only. A related record, CVE-2023-6949, describes missing authentication on a media HTTP service. DJI disputed it, arguing that fixing the weak PSK removed the remote vector and that a compromised mobile device is the user’s problem.16,17 **Fact:** the disputed tag is on the NVD record. **Judgment:** do not treat 6949 as confirmed.

DJI issued firmware that Nozomi describes as addressing seven of nine reported issues; the NVD pages name the version floors for each SKU. “Upgrade to latest” is a necessary control and an incomplete assurance statement. Latest on one SKU does not disclose that the vulnerable object was a shared library living on seven product lines.

**Fact.** One SDK, many products, including enterprise Matrice, with weak credentials plus memory-safety bugs on the media-egress path, is the 2024 record. **Inference, moderate confidence.** Other OEM “quick transfer” Wi-Fi access points deserve the same Passport field, because the pattern is an on-vehicle service that exists to move Sense off the aircraft and that is reused to save engineering cost. **Judgment.** This is the cleanest modern example that SDK and firmware commonality beats per-airframe hardening. A program that Passports each Matrice as if it were a unique codebase will be surprised by the next shared-library CVE in the same way it was surprised by this one.

For LrrK this is Control Fabric and Kestrel. Payload egress sits in Sense. The Passport field that earns its keep is not “Mavic 3, latest.” It is the hash and version of the shared library, recorded across the Mavic and Matrice lines, so that a finding on Mini 3 Pro is immediately a finding on Matrice 300 until a signed difference appears. Watch the disputed 6949 record only if a third party reproduces it; until then it remains a disputed claim, not a confirmed hole and not a proof of safety.

## 6. Civil GPS Is Still Capture of Navigation State

In August 2022, at USENIX Security in Boston, Harshad Sathaye, Martin Strohmeier, Vincent Lenders, and Aanjhan Ranganathan published chamber over-the-air results on commercial DJI and Autel aircraft. The paper’s finding, stated in the authors’ own words, is that “although COTS UAVs remain vulnerable to GPS spoofing attacks, a complete takeover and control of the UAV requires careful manipulation of the spoofing signals in real-time.”18 There is no CVE, because unauthenticated civil GPS is a property of the broadcast service, not a software defect in a named firmware revision. There is no patch at the receiver-protocol layer. Exploit status is a public writeup, with an implementation released to researchers. It is not in KEV.

The pre-window citations are still the right ones to keep on the shelf and the wrong ones to treat as closed history. Shepard, Bhatti, and Humphreys demonstrated spoofing against a civilian UAV in 2012.19 Kerns, Shepard, Bhatti, and Humphreys, in the *Journal of Field Robotics* in 2014, analyzed capture and post-capture control and reported a field test in which a rotorcraft UAV suffered unrecoverable navigation errors.20 Sathaye et al. is the in-window stack update: current COTS DJI and Autel, chamber OTA, and a careful distinction between nuisance diversion and precise takeover. The paper does not claim that every spoof is a complete hijack. It claims that the vehicles remain spoofable and that fine-grained control is hard. Both clauses matter. **Fact:** COTS DJI and Autel remained spoofable in that chamber. **Fact:** precise takeover, in that work, required real-time, fine-grained spoofing. **Unknown:** how any particular field aircraft, with vision sensors on, at a given altitude, would behave. Chamber results are not a flight-test of every configuration.

On 24 July 2025, Galileo Open Service Navigation Message Authentication was declared operational. Receivers that implement the protocol and hold certified public keys can verify that a Galileo navigation message came from the system and has not been modified.21 u-blox and other vendors advertise firmware support. **Inference, moderate confidence.** OSNMA and similar services will appear in Passports as mitigations. **Judgment.** They are not proof that the class is closed. Message authentication is not anti-replay. A brochure that says “OSNMA capable” is not evidence that this serial number, this firmware, this constellation mix, and this mission mode are verifying the signal that the controller is using. A Passport field for GNSS authentication has to be evidenced—constellation, protocol, key provenance, and observed behavior—or it is marketing copied into an assurance document.

This is Sense collapsing into Move. The vehicle believes a position. The controller converts belief into actuator command. KAT, in LrrK use, is exactly that chain: from an RF input the receiver accepts, to a navigation state the estimator publishes, to an actuator the mixer obeys. Lab work that is honest distinguishes takeover from nuisance spoof and does not promote a chamber result into a field-drop claim. Campaign work that records GNSS authentication as a boolean without the evidence listed above has not recorded a control. It has recorded a hope.

## 7. Power on the Flight CAN Is Not Just a Battery

On 13 March 2026, PX4 published GHSA-wxwm-xmx9-hr32.22 NVD published CVE-2026-32707 on 16 March.23 The affected object is not “PX4” in the abstract. It is PX4-Autopilot at or below 1.17.0-rc1 with the Tattu smart-battery CAN driver compiled and started—`CONFIG_DRIVERS_TATTU_CAN` plus `tattu_can start`. The advisory is explicit that this is typically vendor or custom firmware and is not commonly enabled in default upstream builds. The failure class is unbounded reassembly of a multi-frame Tattu 12S battery message: a CAN-injection-capable party can trigger a crash and memory corruption. CISA-ADP SSVC records exploitation as poc. The CVSS vector is physical (AV:P). The fix is 1.17.0-rc2, or do not start the driver. The advisory demonstrates crash and memory corruption. It does not demonstrate an in-flight vehicle drop. Secondary write-ups that infer loss of control are not treated here as proven.

**Fact.** A published CVE exists in which a smart-battery driver on the flight CAN can crash the autopilot. **Unknown.** Whether that crash becomes loss of control in flight, in a vehicle that has the driver enabled, is not established. **Inference, moderate confidence.** Other vendor CAN-BMS modules deserve the same Watch even without a CVE, because the trust error is architectural: telemetry from a powertrain peripheral is parsed on the same controller that commands actuators. **Judgment.** This is the closest in-window case to “a BMS that can drop a vehicle,” and it is still physical-CAN and module-optional. Calling it a field-drop CVE is a promotion the advisory does not support. Calling it “only a battery bug” is a demotion the architecture does not support.

A battery is not a trust boundary. A smart battery is a computer on the power bus that speaks a protocol the flight controller has chosen to parse. Sense, in this case, is BMS telemetry. Act, if the parser dies, is a flight-controller crash. The Control Fabric runs across power, not only across radios. A Passport that records cell count and does not record whether `tattu_can` is enabled, and whether the build is at or after 1.17.0-rc2, has inventoried energy and ignored a parser. Lab work that treats CAN-BMS as a trust path—optional module, physical access assumption, crash versus control as separate claims—is the minimum honest experiment. Campaign work that waits for “independent BDA that tattu_can corruption produces loss of control in flight” should wait, and should also not file the wait as a safety result. Not established is not safe.

## 8. What a Passport Has to Name

The five cases do not ask for a new kind of panic. They ask for a different unit of record. A Product Security Passport that is worth the name treats the vehicle as a system of objects: airframe, payload modules, on-vehicle services and shared libraries, cloud pairing endpoints, GNSS receiver and authentication state, and optional powertrain drivers. Each object has a lineage, a configuration, an observed behavior, and a residual unknown. The Passport is point-in-time and device-specific. It is not a certification, not an NDAA sticker, and not a warranty.

The fields that the public record now forces are specific. Cloud endpoints and key-material handling are recorded separately from airframe firmware; Local Data Mode is a configuration, not a closure of 2017. Camera firmware behavior is recorded as egress observed in Lab, not as a compliance adjective; Kestrel copies the finding onto identical modules in the Registry until a signed difference appears. Shared-library hashes are recorded across SKUs that ship the same SDK, so that a Mavic finding is a Matrice finding by default. GNSS authentication is recorded as evidenced protocol and key state, not as “OSNMA capable” copied from a datasheet; Lab distinguishes takeover from nuisance. The Tattu path is recorded as enabled or not, and as patched or not; crash is recorded as crash; field drop is recorded as not established.

Watch, in this series, has a short list that is still open as of 19 August 2026. The camera OEM, firmware, and IP for the K3 Scout case, or a CVE that names them. A second naval or government USV or UUV payload-egress case with a named module. Independent battle-damage assessment that tattu_can corruption produces loss of control in flight. Those are questions. They are not licenses to invent answers. Autel’s missing vendor advisory for a geofence CVE, and the absence of a published UAV-cited u-blox, OpenIPC, ESC, or dock-update CVE that met the collection bar, belong to other filings; they are noted here only as a boundary. This paper does not wander into MAVLink signing, Remote ID, or DUML update-path analysis.

Campaign is the decision to investigate a named object rather than to wait for a hull-level headline. Control Fabric is the map of channels the investigation is allowed to see, including the ones the bill of materials did not draw. Lab is where egress-deny, shared-library identity, GNSS-authentication evidence, and CAN-BMS parsing are scoped. KAT is how a finding on Sense is walked to Move and Act without being sold as a field-drop. Sense, Move, and Act remain the only honest summary of consequence: a log about the operator, a heartbeat from a camera, a media path off a sensor, a false position, a crashed parser.

**Judgment.** A two-layer model is the minimum coherent response. The first layer is categorical and already exists in policy: provenance screens, NDAA clauses, trusted-partner lists, airframe bans. The second layer is evidentiary and mostly missing: product-level records that say what the payload, the SDK, the cloud, the receiver, and the battery driver actually do. The first layer can keep a named manufacturer out of a program. It cannot see a heartbeat. The second layer can see a heartbeat and still must record when it cannot see the OEM.

## 9. Conclusion

The airframe is a necessary trust object. It is not a sufficient one. Cloud keys in 2017 showed that pairing and customer-data Sense can fail while the aircraft radio is not the story. A camera heartbeat on a naval USV in 2026 showed that a payload can open a Control Fabric channel that the hull’s nationality and the module’s NDAA sticker do not mention. A shared media-transfer SDK in 2024 showed that one library can place the same credential and memory-safety class on consumer and enterprise SKUs at once. Civil GPS, re-measured in 2022 on current DJI and Autel airframes, remains an unauthenticated input to navigation state; OSNMA is a mitigation to evidence, not a class that closed on 24 July 2025. A smart-battery CAN driver in 2026 showed that powertrain telemetry is a parser on the flight controller, and that a demonstrated crash is not yet a demonstrated drop.

The honest residuals are part of the finding. The 2017 exposure window is unmeasured. The 2026 camera OEM, IP, and location-exfil question are unpublished. The disputed media-HTTP CVE is disputed. The Tattu field-drop is not established. None of those residuals is a safety result. A Watch that converts them into “no evidence of harm, therefore safe” has left the method.

What LrrK owes a buyer is not another list of famous incidents. It is a Passport that names the objects on the path, a Lab that is allowed to watch a payload boot, a Kestrel that refuses to treat two copies of one module as two mysteries, and a Campaign that investigates cloud, camera, SDK, GNSS, and BMS as first-class trust objects. The airframe will remain in the photograph. It should no longer be the only thing in the record.

Endnotes

1. Kevin Finisterre, “Why I walked away from $30,000 of DJI bounty money,” 16 November 2017; reported the same day in The Register, “Drone maker DJI left its private SSL, firmware keys open to world+dog on GitHub FOR YEARS.” https://www.theregister.com/security/2017/11/16/drone-maker-dji-left-its-private-ssl-firmware-keys-open-to-worlddog-on-github-for-years/354019

2. Sean Gallagher, “Man gets threats—not bug bounty—after finding DJI customer data in public view,” Ars Technica, 17 November 2017. https://arstechnica.com/information-technology/2017/11/dji-left-private-keys-for-ssl-cloud-storage-in-public-view-and-exposed-customers/

3. BBC News, “Drone maker DJI in cyber-security row over bug bounty,” 20 November 2017. https://www.bbc.com/news/technology-42052473

4. U.S. Army, memorandum “Discontinue Use of Dajiang Innovation (DJI) Corporation Unmanned Aircraft Systems,” 2 August 2017, as published by sUAS News. https://www.suasnews.com/2017/08/us-army-calls-units-discontinue-use-dji-equipment/

5. Devin Coldewey, “DJI adds an offline mode to its drones for clients with ‘sensitive operations,’” TechCrunch, 14 August 2017. https://techcrunch.com/2017/08/14/dji-adds-an-offline-mode-to-its-drones-for-clients-with-sensitive-operations/

6. Jonathan Beale and Rachel Flynn, “No evidence of data breach after Chinese-made component found in Navy drones, MoD says,” BBC News, 10 August 2026. https://www.bbc.com/news/articles/c4gwl3n7ne7o

7. *The Independent*, “Royal Navy drone cameras linked to China raise security concerns,” August 2026. https://www.independent.co.uk/news/uk/home-news/royal-navy-drone-cameras-china-mod-b3030094.html

8. *Naval Technology*, “UK MoD plays down leak fears over China-linked K3 USV cameras,” August 2026. https://www.naval-technology.com/news/uk-mod-k3-usv-china/

9. Camila Nogueira, “Royal Navy drone cameras sent heartbeat signals to China, MoD confirms,” BetaNews, 11 August 2026. https://betanews.com/article/royal-navy-drones-china-heartbeat-signals/

10. Nozomi Networks Labs, “CVE-2023-6951 — Use of Weak Credentials,” 29 March 2024. https://www.nozominetworks.com/labs/vulnerability-advisories-cve-2023-6951

11. Nozomi Networks Labs, “CVE-2023-51454 — Out-of-bounds Write,” 29 March 2024. https://www.nozominetworks.com/labs/vulnerability-advisories-cve-2023-51454

12. National Institute of Standards and Technology, National Vulnerability Database, CVE-2023-6951, published 2 April 2024. https://nvd.nist.gov/vuln/detail/CVE-2023-6951

13. National Institute of Standards and Technology, National Vulnerability Database, CVE-2023-51454, published 2 April 2024. https://nvd.nist.gov/vuln/detail/CVE-2023-51454

14. National Institute of Standards and Technology, National Vulnerability Database, CVE-2023-51455, published 2 April 2024. https://nvd.nist.gov/vuln/detail/CVE-2023-51455

15. National Institute of Standards and Technology, National Vulnerability Database, CVE-2023-51456, published 2 April 2024. https://nvd.nist.gov/vuln/detail/CVE-2023-51456

16. National Institute of Standards and Technology, National Vulnerability Database, CVE-2023-6949 (disputed), published 2 April 2024. https://nvd.nist.gov/vuln/detail/CVE-2023-6949

17. Nozomi Networks Labs, “DJI Mavic 3 Drone Research Part 2: Vulnerability Analysis,” 2 April 2024. https://www.nozominetworks.com/blog/dji-mavic-3-drone-research-part-2-vulnerability-analysis

18. Harshad Sathaye, Martin Strohmeier, Vincent Lenders, and Aanjhan Ranganathan, “An Experimental Study of GPS Spoofing and Takeover Attacks on UAVs,” 31st USENIX Security Symposium, Boston, August 2022. https://www.usenix.org/conference/usenixsecurity22/presentation/sathaye

19. Daniel P. Shepard, Jahshan A. Bhatti, and Todd E. Humphreys, “Drone Hack: Spoofing Attack Demonstration on a Civilian Unmanned Aerial Vehicle,” *GPS World*, 2012.

20. Andrew J. Kerns, Daniel P. Shepard, Jahshan A. Bhatti, and Todd E. Humphreys, “Unmanned Aircraft Capture and Control Via GPS Spoofing,” *Journal of Field Robotics* 31, no. 4 (2014): 617–636. https://doi.org/10.1002/rob.21513

21. European GNSS Service Centre, “Galileo Open Service Navigation Message Authentication (OSNMA).” Initial Service declared operational 24 July 2025. https://www.gsc-europa.eu/galileo/services/galileo-open-service-navigation-message-authentication-osnma

22. PX4/PX4-Autopilot, “Stack buffer overflow in tattu_can due to unbounded memcpy in frame assembly loop,” GHSA-wxwm-xmx9-hr32, 13 March 2026. https://github.com/PX4/PX4-Autopilot/security/advisories/GHSA-wxwm-xmx9-hr32

23. National Institute of Standards and Technology, National Vulnerability Database, CVE-2026-32707, published 16 March 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-32707

Selected Bibliography

Beale, Jonathan, and Rachel Flynn. “No evidence of data breach after Chinese-made component found in Navy drones, MoD says.” BBC News, 10 August 2026. https://www.bbc.com/news/articles/c4gwl3n7ne7o

European GNSS Service Centre. “Galileo Open Service Navigation Message Authentication (OSNMA).” https://www.gsc-europa.eu/galileo/services/galileo-open-service-navigation-message-authentication-osnma

Finisterre, Kevin. “Why I walked away from $30,000 of DJI bounty money.” 16 November 2017. Contemporary report: The Register, 16 November 2017. https://www.theregister.com/security/2017/11/16/drone-maker-dji-left-its-private-ssl-firmware-keys-open-to-worlddog-on-github-for-years/354019

Gallagher, Sean. “Man gets threats—not bug bounty—after finding DJI customer data in public view.” Ars Technica, 17 November 2017. https://arstechnica.com/information-technology/2017/11/dji-left-private-keys-for-ssl-cloud-storage-in-public-view-and-exposed-customers/

Kerns, Andrew J., Daniel P. Shepard, Jahshan A. Bhatti, and Todd E. Humphreys. “Unmanned Aircraft Capture and Control Via GPS Spoofing.” *Journal of Field Robotics* 31, no. 4 (2014): 617–636. https://doi.org/10.1002/rob.21513

Nozomi Networks Labs. “DJI Mavic 3 Drone Research Part 2: Vulnerability Analysis.” 2 April 2024. https://www.nozominetworks.com/blog/dji-mavic-3-drone-research-part-2-vulnerability-analysis

PX4/PX4-Autopilot. GHSA-wxwm-xmx9-hr32. 13 March 2026. https://github.com/PX4/PX4-Autopilot/security/advisories/GHSA-wxwm-xmx9-hr32

Sathaye, Harshad, Martin Strohmeier, Vincent Lenders, and Aanjhan Ranganathan. “An Experimental Study of GPS Spoofing and Takeover Attacks on UAVs.” 31st USENIX Security Symposium, August 2022. https://www.usenix.org/conference/usenixsecurity22/presentation/sathaye

U.S. Army. “Discontinue Use of Dajiang Innovation (DJI) Corporation Unmanned Aircraft Systems.” 2 August 2017, via sUAS News. https://www.suasnews.com/2017/08/us-army-calls-units-discontinue-use-dji-equipment/

Source note. This paper distinguishes five public failure classes—cloud-key exposure (2017), out-of-band payload heartbeat (August 2026), shared on-vehicle media-transfer SDK (2024), unauthenticated civil GNSS (2022 chamber results; OSNMA operational 24 July 2025), and optional BMS CAN reassembly (2026)—from sibling topics deliberately excluded: MAVLink signing, Remote ID, and DUML or other update-path analysis. It treats NDAA compliance as a provenance label, not a firmware-behavior audit; treats CVE-2023-6949 as disputed; and treats a demonstrated autopilot crash as not established for in-flight loss of control. *The Telegraph* first reported the K3 Scout cameras; this paper relies on BBC, *The Independent*, *Naval Technology*, and BetaNews for quoted MoD and Kraken statements and does not cite a *Telegraph* URL that was not retrieved. Finisterre’s eighteen-page PDF is cited from contemporaneous Register, Ars, and BBC reporting; a stable public PDF URL was not independently retrieved. Collection is current as of 19 August 2026 and should be revalidated against a named camera OEM or CVE for the K3 Scout case, any later MoD or Kraken technical disclosure, NVD updates to the QuickTransfer and tattu_can records, and receiver-level evidence of GNSS authentication in field aircraft.