You Wouldn’t Hack a Satellite: Unbundling NASA’s ION-DTN

By Riccardo Nannini

Networking is hard enough on Earth already. Now add space to it, and it quickly becomes a mess.

Persistent end-to-end path between two nodes? Go tell that to a Mars satellite when it goes behind the Sun for two weeks. Short latency? One-way light time can exceed four hours from Earth to the outer Solar System. Symmetric links? Dynamic routing convergence? Small end-to-end losses? You get the point. Many of the assumptions that make terrestrial networking possible rarely hold when it comes to space communications.

Last spring I was looking for a research project that I could carry out on the side. I remembered reading our Cybersecurity for Satellites whitepaper and I found in our internal research whiteboard the proposal for a fuzzing campaign in the satellite networking domain. "Space hacking? Sounds cool," six-months-ago-me probably thought. "You can finally show your parents you do a real job," my subconscious envisioned.

Regardless of the inner work of my psyche, six months later NASA Jet Propulsion Laboratory released 8 ION-DTN security advisories as a result of my research work: 4 Critical security issues (CVSS 9.1-9.8) concerning remote, unauthenticated out-of-bound writes and 4 High severity vulnerabilities (CVSS 7.5), this time in the form of remote Denial-of-Service.

DTN

Delay-tolerant and disruption-tolerant networks (DTN) was our answer (our as in humankind) to the specific challenges of bringing internet to space. RFC 4838 in 2007 laid the architecture specifically for "a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration."

Oversimplifying, the basic idea is to create an overlay where Bundles are exchanged as the new message unit. The Bundle Protocol (BP) is one layer higher than the classic ISO protocol stack and is designed to function both on top of "regular" internet as well as nodes that only use space communication links. This overlay follows the store-and-forward philosophy: DTN nodes employ persistent storage (in simpler terms, they save Bundles to disk) to help combat network interruptions. The deep space telescope you want to reach is behind the Sun for a few weeks? The intermediate hop you've routed your Bundles to will store and forward them once the next hop becomes viable again.

ION-DTN

ION-DTN is NASA's implementation of the DTN architecture. It's designed to operate on a wide range of systems from real-time operating systems in flight hardware to Linux servers in ground stations.

ION-DTN was first flight-validated in 2008 on NASA's EPOXI spacecraft and has been deployed on the International Space Station and several of its scientific payloads since 2016. It's currently used as part of active missions including NASA's PACE and South Korea's Danuri

Vulnerability research

I used libFuzzer and AddressSanitizer ("ASan") to fuzz several surfaces of the ION-DTN protocol including the BPv7 extension-block parsers, LTP, admin-record parsing, DTPC, the BPv7 Saga message handler and CFDP.

The main hurdle was figuring out ION's memory use. Turns out the library doesn't use malloc. It employs instead two shared memory systems: System Data Recorder (SDR) and Personal Space Management (PSM), each managing their own memory pool shared by the different daemons comprising ION. I built a fake SDR/PSM allocator that redirected every allocation through malloc instead in order to make it visible to ASan which otherwise wouldn't catch overflows. I also capped allocations at 256MB to simulate the memory limit of real in-orbit hardware. Crashes identified this way were then tested on a stock release to confirm the issues were not a byproduct of my scaffolding (which happened more than I'd like to admit).

By the end of this campaign, I reported 10 vulnerabilities between May and July 2026. As of the time of writing, NASA published 7 ION-DTN security advisories. 1 more was accepted and fixed but is not yet public, 1 has been discarded as duplicate, and 1 is still untriaged.

• [GHSA-3wf8-7pcp-hw6c] Remote Out-of-Bounds Write in ION-DTN BPv7 Bundle-Sequence Parser on 32-bit Builds.
• [GHSA-j2vh-x3qc-7rr9] Remote Out-of-Bounds Write in ION-DTN LTP Parser on 32-bit Builds.
• [GHSA-gc93-87v8-hpfx] Remote Unauthenticated Out-of-Bounds Stack Write in ION-DTN BPv7 Extension-Block Parser.
• [GHSA-rccp-mvf8-xg2f] Remote Unauthenticated Heap Out-of-Bounds Write in ION-DTN BPv7 IMC Extension-Block Parser.
• [GHSA-7jr3-qpvf-r9rx] Remote Denial of Service in ION-DTN DTPC Aggregated ADU Parser.
• [GHSA-726f-742m-j49q] Remote Denial of Service in ION-DTN BPv7 Saga Message Handler.
• [GHSA-hpw7-8j6m-px2p] Remote Denial of Service in ION-DTN LTP Green Data Segment Handler.
• [GHSA-6929-2cwm-cfvh] Advisory assigned but unpublished