Latest edition · Monday, 31 August 2026 · Bengaluru Mission desk active

Space cybersecurity

Preprint finds regional security gaps among exposed Starlink-connected hosts

A Censys snapshot tied about 33,000 exposed IPs inside Starlink’s network to higher operating-system vulnerability and legacy-protocol rates in several regions, but it did not test Starlink infrastructure, prove exploitability or establish cause.

Report a correction
Add us as a preferred source on Google
Editorial data graphic comparing about 33,000 exposed hosts in Starlink’s autonomous system with a 1.78 million-host non-Starlink sample, highlighting ninefold and sixfold operating-system vulnerability gaps in Haiti and Colombia and regional weak-protocol clusters
The study compared about 33,000 exposed hosts in Starlink’s network with a country-capped 1.78 million-host non-Starlink sample and found uneven operating-system and protocol-security patterns. Its data came from an April 7, 2025 Censys snapshot; it did not test Starlink infrastructure. Editorial graphic: Space Exploration .IN
~33,000exposed Starlink-network hosts
1.78Mhosts in the comparison sample
Haiti OS-CVE rate gap
Apr. 7, 2025Censys scan snapshot

A measurement paper posted to arXiv on August 17 reports that publicly exposed hosts using SpaceX’s Starlink network were more likely than a country-capped comparison set to be associated with outdated operating systems, known vulnerability records and weak or legacy protocols. Its sharpest reported gaps appeared in parts of Latin America, Eastern Europe, Southeast Asia and West Africa. The finding concerns devices and services visible through Starlink connectivity; it is not evidence of a breach of Starlink satellites, user terminals or SpaceX’s network, and the paper reports no regulatory action.

UCLA researchers Omar Elamri, Isaac-Neil Zanoria, Jacob Zhi, Ben Du and Liz Izhikevich wrote the study. Although version 1 reached arXiv on August 17, 2026, the record identifies it with an ACM workshop on policy-relevant internet measurements held in October 2025. The underlying scan is older still, from April 7, 2025. The upload puts the dataset and argument into the current public record, but it should not be read as a live assessment of Starlink-connected systems.

What the researchers measured

The team used a Censys snapshot of responsive IPv4 and IPv6 services. Censys represents a host as an IP address with network, location and service observations, and says it attempts to identify an operating system from network behaviour and service banners. The researchers classified services within Starlink’s autonomous system—a network-routing group—as Starlink hosts and every other observed service as non-Starlink. That procedure identifies where an exposed IP was routed, not who owned or administered the responding device.

The scan yielded about 33,000 exposed Starlink hosts. The original non-Starlink pool contained roughly 230 million hosts, which the researchers reduced by randomly selecting no more than 10,000 per country. That produced a 1.78 million-host comparator and prevented one country from contributing more non-Starlink records than the largest Starlink country sample. It also means the reported rates compare Starlink observations with a constructed, country-capped sample rather than with all 230 million other hosts.

For the operating-system analysis, the researchers collected Common Vulnerabilities and Exposures records dated from 2020 through 2025 from the National Vulnerability Database, then matched affected product descriptions to the Common Platform Enumeration strings associated with observed hosts. NIST describes CPE as a structured naming scheme for information-technology systems, software and packages. The paper says it used wildcard matching to create pairs between CVE records and hosts. Because that method links reported product and version information rather than testing the host, the result is best read as a potential match to an affected range, not proof that a particular device was unpatched or exploitable.

Regional pattern is the study’s main result

Routers made up a large share of the exposed Starlink set, but the operating-system mix differed by continent. In South America, the paper reports that 70% of exposed Starlink hosts ran Fortinet FortiOS, compared with 15.72% of non-Starlink hosts there. In Europe, FortiOS accounted for less than 20% of the Starlink sample. Those differences matter to the security comparison because regions with different device and operating-system mixes also inherit different sets of possible vulnerabilities.

The largest country gaps shown for operating-system vulnerability matches were in Haiti and Colombia. The paper reports a ninefold Starlink-to-comparator increase for Haiti and a sixfold increase for Colombia. Its chart measures the fraction of observed hosts associated with operating-system CVEs, not a share of either country’s population. The short paper does not publish the underlying host count for each bar, confidence intervals or a test showing whether Starlink connectivity itself explains the disparity.

The protocol analysis produced a similar but broader geographic pattern. The researchers counted old TLS versions, weak SSH cipher suites and legacy SMBv1, then calculated a country-level ratio between their prevalence among Starlink hosts and the comparison population. A ratio above one meant insecure protocol use was more common in the Starlink set. The paper highlights Central and South America, Eastern Europe and Southeast Asia, while its map caption also identifies West Africa. It does not provide the country-level ratios behind the map or uncertainty estimates for lightly observed markets.

What the finding does not establish

The dataset covers internet-facing services that answered Censys, not Starlink’s full customer base. Devices with no publicly responsive service do not enter the analysis, and Censys location fields describe geography associated with an IP address rather than a surveyed user. The study therefore measures the security characteristics of a visible subset of hosts routed through Starlink on one date. It does not estimate how common those configurations are across all Starlink connections.

The comparison also does not isolate a Starlink effect. The paper itself shows that its Starlink sample is unusually router-heavy and that operating-system composition changes by region. It does not report matching hosts by device type, operator, software age or administrative setting. The authors suggest that regional technical capacity, regulation and user awareness may be related to the pattern, but they do not test those explanations. On the evidence presented, the network is the grouping variable, not a demonstrated cause of weak configuration or delayed patching.

The authors argue that internet service providers, manufacturers, governments and the measurement community should consider stronger defaults and security-awareness efforts as satellite connectivity expands. That is a policy recommendation from the paper, not a government mandate or a response announced by SpaceX. The useful next checks would be repeated scans, publication of per-country denominators and uncertainty, comparisons within the same device families, and direct confirmation of patch status. Until then, the study is an early warning about an exposed population and its regional concentration, not a finding that Starlink’s platform was compromised.

Reporting trail

Primary sources

Companies in this story