When you buy through affiliate links in our content, we may earn a commission at no extra cost to you. Learn 
This week has been a busy one for Starlink, with a potential SpaceX IPO looming over a Reuters report claiming that the company had attempted to jack up the price on its U.S. defense contract after the war in Iran was already underway.
According to the news outlet, tensions brewed between SpaceX and the Pentagon over the cost of using Starshield satellite services during the war. The report states that SpaceX executives argued the military had effectively been getting a premium-tier service at discounted pricing, paying around $5,000 per terminal connection while using a level of service closer to $25,000.
Within hours of the article going live, SpaceX CEO Elon Musk posted on X that the Reuters story was false, adding that the civilian Starlink system had been improperly used “for military purposes” in violation of its terms of service. He said any such use is shut down when discovered, while also stressing there is “a separate network called Starshield” that is operated by the U.S. government and “not under SpaceX control.”
The Pentagon also stepped in with a fairly emphatic denial. Spokesperson Sean Parnell dismissed reports of any serious dispute over pricing, writing on X that SpaceX remains “a strong and valued partner” to the Department of Defense and that media claims about clashes between the two sides were “simply not based in reality.”
SpaceX’s $2.3B Deal Signals a Much Bigger Pentagon Role
The timing of the whole thing was particularly interesting given that SpaceX had just secured a massive $2.29 billion U.S. Space Force contract to build the Space Data Network Backbone, which is essentially a giant military communications network in orbit designed to connect missile-warning systems, weapons platforms, and defense infrastructure through a sprawling low-Earth orbit satellite constellation. In other words, Starlink’s considerably more serious cousin just got an even bigger Pentagon promotion.
The project is reportedly tied to the Pentagon’s “Golden Dome” missile defense ambitions and evolved from the previously classified MILNET program.
The timing also fed into the wider investor frenzy surrounding SpaceX and the booming space sector. Space-related stocks rallied this week as excitement around SpaceX’s reported IPO plans spilled into companies like AST SpaceMobile, Rocket Lab, Redwire, and Firefly Aerospace because, apparently, in 2026, the hottest trade on Wall Street is “things that may eventually orbit Earth.”
To add to the growing list of partners, American Airlines announced this week that it plans to roll out Starlink Wi-Fi across more than 500 aircraft starting in 2027, becoming one of many airlines betting passengers would rather stream Netflix at 35,000 feet than stare at the seatback map for four hours.
Despite the glowing stock reviews, Reuters reported that disagreements between the Pentagon and SpaceX actually extended beyond drones, with the two sides allegedly sparring over pricing for plans to provide direct-to-cell Starlink connectivity inside Iran to help civilians bypass communications blackouts.
So in the space of a few days, Starlink managed to become the center of a geopolitical pricing dispute, a debate over the militarization of commercial satellite networks, and a reminder that SpaceX is increasingly operating more like a critical piece of modern military infrastructure that occasionally also helps people stream Netflix in remote areas.
Also in Tech News
Tech Leaders Are Suddenly Warning About ‘AI Psychosis’
The phrase “AI psychosis” appears to have become Silicon Valley’s favorite new diagnosis. This week, a pair of tech executives helped turn it into the industry’s latest discourse war.
It started when former GitHub CTO and HashiCorp co-founder Mitchell Hashimoto posted a lengthy warning about what he sees as a growing wave of irrational AI optimism sweeping through the software industry. Hashimoto said entire companies are currently operating under “heavy AI psychosis,” arguing that conversations about the limitations and risks of AI systems have become almost impossible inside some organizations.
Drawing comparisons to the cloud infrastructure boom, Hashimoto warned that companies risk “automating themselves into a very resilient catastrophe machine,” where local metrics appear healthy while underlying systems quietly become fragile and incomprehensible. In perhaps the most ominous line of the post, he argued that software teams are increasingly embracing a mentality of “it’s fine to ship bugs because the agents will fix them.”
A day later, Box CEO Aaron Levie entered the chat with what many interpreted as a considerably more diplomatic version of the same concern.
In a widely shared post on X, Levie argued that CEOs are “uniquely prone to AI psychosis” because they are often too removed from the operational reality required to turn flashy AI demos into reliable enterprise systems.
According to Levie, executives frequently see the “happy path” during AI experiments without appreciating the “next 10 or 20 things” required to make those systems production-ready. He pointed to examples like AI-generated code that still requires extensive review before deployment, or AI-generated contracts that still need legal verification and historical context before they can safely go out the door.
Importantly, Levie wasn’t anti-AI. Quite the opposite. He argued the best thing CEOs can do is use AI extensively enough to understand both its upside and the enormous amount of operational work still hiding underneath the demo layer.
The reactions came quickly. Some praised the posts as overdue realism in an industry increasingly fueled by AI hype cycles and investor pressure. Others argued the term “AI psychosis” itself was needlessly inflammatory, though, in true tech industry fashion, that probably only guaranteed it would spread faster.
CrowdStrike and Google Took Down the Weirdest Malware Botnet Yet
CrowdStrike and Google have announced they had dismantled Glassworm — the increasingly infamous botnet that spent the past several months quietly infecting developer environments through poisoned VS Code extensions.
The takedown, carried out alongside the Shadowserver Foundation, targeted all four of Glassworm’s command-and-control channels simultaneously, effectively cutting operators off from infected systems and stopping the malware from delivering new payloads. CrowdStrike described the operation as a coordinated strike against a “developer-targeting botnet” that had spread through the open-source software supply chain.
If the whole thing sounds vaguely dystopian, that’s because Glassworm was essentially malware designed to hide in plain sight. The campaign was first spotted by endpoint security firm Koi Security in October 2025 after researchers discovered malicious VS Code extensions uploaded to the Open VSX marketplace.
What made Glassworm particularly nasty was its use of invisible Unicode characters to conceal malicious code inside extensions. To human reviewers, the payloads often appeared blank or harmless inside editors, while, underneath the surface, the malware was decoding and executing JavaScript designed to steal credentials, compromise developer accounts, and spread further through trusted software ecosystems.
Researchers estimate the compromised extensions were downloaded tens of thousands of times, with Glassworm eventually evolving into a resilient multi-channel botnet using fallback infrastructure that reportedly included blockchain-based command systems, BitTorrent mechanisms, and traditional VPS servers. Because, apparently, normal malware infrastructure is no longer ambitious enough in 2026.
Google Threat Intelligence Group chief analyst John Hultquist summed up the industry mood in a post on X, writing that defenders are increasingly trying to “bring more pain to attackers” when threat actors abuse developer ecosystems and target users.
Which, translated from cybersecurity executive language into plain English, roughly means: the security industry is getting very tired of finding nation-state-grade malware hiding inside theme extensions and developer plugins.
A Tiny Starlette Bug Just Created a Massive AI Security Problem
Just days after researchers dismantled the Glassworm malware campaign, security researchers disclosed CVE-2026-48710, nicknamed “BadHost,” a vulnerability affecting Starlette, the Python web framework underpinning huge chunks of modern AI infrastructure, including FastAPI-based applications, MCP servers, LLM proxies, agent frameworks, and inference platforms.
The issue stems from how Starlette versions prior to 1.0.1 construct request.url using the raw HTTP Host header. Under certain conditions, attackers can manipulate request.url.path into appearing as a completely different endpoint from the one actually being accessed. In practical terms, middleware relying on path-based authentication checks can potentially be bypassed entirely.
Which is bad enough on a normal web app. On AI infrastructure, it gets considerably more terrifying.
Researchers warned the vulnerability could impact MCP gateways, LiteLLM deployments, vLLM servers, AI agent frameworks, and custom enterprise AI systems that use middleware to gate access to sensitive endpoints. MCP servers are reportedly especially vulnerable because the protocol itself often requires unauthenticated OAuth discovery endpoints, creating convenient attack paths for exploitation.
At the same time, security firm Nemesis launched MCP-Scan, a public scanner designed to detect vulnerable MCP deployments and insecure configurations before attackers do. Meanwhile, security researchers and AI infrastructure developers began warning how the bug could potentially expose credentials, internal tooling, local files, and protected APIs.
Anthropic’s Claude-powered “Project Mythos” reportedly failed to identify the vulnerability despite previously uncovering thousands of bugs through automated code analysis. According to the researchers, the issue emerged from the interaction between multiple independent layers, which are ASGI servers passing raw Host headers, Starlette trusting those headers for URL construction, and middleware developers assuming request.url.path was safe for authentication decisions.
In other words, the bug only appeared once several perfectly reasonable systems were combined together in exactly the wrong way, which is either a profound lesson about software complexity or the cybersecurity equivalent of assembling IKEA furniture incorrectly and accidentally creating a flamethrower.
Perhaps the most awkward part is that none of the individual components were technically “broken” on their own. ASGI servers passed the Host header correctly. Starlette constructed URLs as designed. Middleware developers trusted request.url.path. The vulnerability only emerged when all three layers interacted together. It’s a wary reminder that modern AI infrastructure is increasingly becoming a giant stack of perfectly functional abstractions quietly conspiring against each other.
