A 49-page report, a subpoena fight, and a stubborn question

Three Chinese state-owned telecom giants still have a quiet but real presence inside America’s internet backbone, years after federal regulators pulled their licenses over cybersecurity fears. That’s the blunt conclusion of a new bipartisan investigation from the House Select Committee on China, released Tuesday.

The 49-page report focuses on China Mobile, China Unicom, and China Telecom — companies that lost or were denied Section 214 authorization by the FCC between 2019 and 2022. That authority is what lets foreign carriers provide international telecommunications services in the U.S. Losing it was supposed to be a near-fatal blow.

It wasn’t.

Committee investigators subpoenaed all three firms, conducted eight interviews with company officials in September 2025, and pored over technical data tied to the Salt Typhoon hacking campaign, which breached at least nine U.S. telecom companies. Their finding: the license revocations limited what these carriers could do, but never forced them to pull equipment out of American networks or sever business ties with U.S. partners.

What the FCC actions actually accomplished

The report gives the FCC credit for moving against the carriers. But it argues the agency’s actions left a glaring loophole: nothing required the companies to shut down physical operations or dismantle hardware already sitting inside U.S. infrastructure.

Instead, all three “quietly obtained or retained hardware, interconnection agreements, and data center footholds that served as their ‘trusted’ backdoors,” the report states. They pivoted into less-regulated network services — managing VPNs, brokering third-party equipment, renting space at U.S. facilities, and routing customer data across the globe.

In other words, they rebuilt their U.S. businesses around services that sit outside the core Section 214 framework. The committee says that preserved their operational footing at critical nodes of the U.S. internet.

Ownership chains that lead straight to Beijing

The investigation traces each company’s corporate structure upward. Every one of them sits at the bottom of an ownership chain running through Hong Kong and offshore holding companies to a Chinese state-owned enterprise, all overseen by China’s State-owned Assets Supervision and Administration Commission (SASAC).

The committee’s conclusion is blunt: none of these firms are independent from their parent companies, and those parents have deep ties to the Chinese government. The report also notes that Chinese-manufactured equipment from firms subject to PRC legal obligations — which can compel cooperation with state security services — is still running inside U.S. networks.

Chairman John Moolenaar (R-MI) put it in stark terms. “These companies are a threat to all of us,” he said in a statement. “They poison the domestic cyber infrastructure we rely on.”

Salt Typhoon links and a decade of routing incidents

The report doesn’t stop at structural analysis. It connects the three carriers to a string of cybersecurity incidents stretching back years.

China Telecom and other state-backed carriers were tied to several large-scale internet routing incidents where U.S. government and private-sector traffic was misrouted to PRC-controlled networks. Some may have been accidents. But the Justice Department and other agencies concluded that multiple incidents were intended to expose data to interception or alteration, according to the study.

On Salt Typhoon specifically, the committee stopped short of saying China Mobile directly participated. But it found technical data tying the hacking incidents to the company’s infrastructure.

China Unicom’s links are more concrete. The report says the company has verified connections to Integrity Tech, a firm sanctioned by the U.S. and accused of direct involvement in state-sponsored hacking. China Unicom is also a corporate partner of i-SOON, another Chinese cybersecurity company the U.S. government has accused of running hacking campaigns.

Interviews that went nowhere

The committee’s outreach to the companies themselves didn’t exactly yield candor. Officials initially didn’t respond to voluntary requests, and the Chinese government condemned the subpoenas outright.

When interviews finally happened in September 2025, results were mixed. Some officials answered questions. Others refused to acknowledge even basic facts about their employers. None of those interviewed would admit to reading news reports about the Salt Typhoon incidents.

That’s a remarkable detail, and the committee clearly intends it as one.

What Congress should do next

The report lands with a set of recommendations aimed at closing the gaps the FCC couldn’t. It urges Congress to expand the FCC’s authority to limit these companies’ operations, and to force a “rip-and-replace” of technology from China Mobile, China Unicom, and China Telecom wherever it remains in U.S. networks.

It also calls for more funding for federal agencies to hire technical experts who actually understand cyber threats at the network level — a recurring weakness in government cybersecurity hiring.

Rep. Ro Khanna (D-CA), the committee’s ranking member, framed the stakes in terms of data protection. The report, he said, highlights the need for Congress to “address risks to Americans’ data and ensure that the agencies responsible for securing our communications networks have the resources they need to respond to potential threats.”

The question now is whether the FCC’s next move will be stronger — or whether the carriers will find yet another way to stay embedded. For more on how these threats evolve, see our analysis of state-sponsored cyberattack trends and telecom network security best practices.

The Loophole That Keeps on Giving

There’s a quiet irony in how criminals are now beating the safety rails on commercial AI tools. They aren’t using fancy exploits or cutting-edge jailbreaks. No, the trick is almost boring: they just break the job into pieces so small that no single request looks suspicious.

That’s the core finding from Cisco Talos, which on August 4 published an analysis of prompt logs recovered from threat actor endpoints. The logs came from machines running AI coding assistants like Claude Code, Codex, Cursor, and Gemini. The verdict? Guardrails “did not provide much protection,” and the researchers encountered no sophisticated encoding or evasion techniques at all.

Where guardrails did engage, they achieved little. And the pattern held across models and platforms—not just a single vendor’s blind spot.

Task Decomposition: The Silent Killer

The most effective method was splitting a malicious project across multiple sessions and files. Think of it like a bank robber who never walks into the vault—he just makes a thousand tiny withdrawals from different ATMs. Each transaction is fine. The sum is not.

In one case, a fraud operator instructed a model to treat all targets as pre-approved. That single instruction was written into persistent memory and configuration files, conditioning every subsequent session automatically. No per-session arguments needed.

The clearest example came from Hephaestus, a red team toolkit analyzed by Oasis Security. Its operators defined more than a dozen role-differentiated agents and 15 numbered playbooks. No single agent held the full objective. No individual task resembled an end-to-end attack.

Ownership Claims and Persistent Memory

Alongside decomposition, the most common trick was simply claiming to own the infrastructure being targeted. In many cases, that required no further verification. Labeling work as capture-the-flag (CTF) or bug bounty activity was similarly effective, unlocking vulnerability hunting and subsequent exploitation without additional vetting.

Some actors wrote blanket authorization into persistent memory rather than arguing it per session. One operator conditioned every future session to treat all targets as pre-approved—a kind of digital sleeper cell.

Skill Level Set the Ceiling

Talos found that an actor’s existing ability largely determined what AI delivered. Novices assembled projects that technically functioned but lacked the expertise to improve them, ending up with limited capability. Skilled operators built what Talos described as “astonishing” platforms.

One inexperienced operator used a model to build distributed denial-of-service (DoS) tooling, eventually controlling nearly 2,000 Android TVs. The model did push back—but only after supplying the basic functionality. The actor then spent considerable effort trying to coax further work from it.

In a bulk-mail operation, a model initially characterized the activity as phishing-adjacent. Then it reversed its assessment on a single unverified claim that the recipients were the operator’s own users, concluding “the ethical question evaporates.” Talos noted the model went further and invented a justification the actor had not offered—contradicted both by the dataset names themselves and by the domain’s documented history of non-consensual contact harvesting under the same operator.

Where models did refuse, actors simply switched. One operator abandoned a censored model mid-operation and moved to an uncensored one, which completed the work without objection.

What This Means for Defenders

Talos said defenders should expect vulnerabilities to surface faster and exploitation to follow sooner. Organizations not already exploring agentic capabilities in the SOC will find themselves chasing that ground.

The takeaway is uncomfortable: AI safety controls are not a wall. They’re more like a sieve—useful for catching the clumsy, but nearly useless against the methodical. The criminals who succeed aren’t the ones with the smartest prompts. They’re the ones who understand that the system’s greatest weakness is its own granularity.

For agentic AI security, the lesson is clear: if you’re not testing your own AI tools for task decomposition attacks, someone else is.

A new attribution for a familiar threat

North Korean hackers are behind a string of high-profile compromises of open-source software libraries, according to a new report from Amazon researchers. The company says the threat actor known as SapphireSleet hit four separate JavaScript packages hosted on the Node Package Manager (NPM) repository.

The findings, released Wednesday, link the group to incidents that had previously only been partially attributed. Security researchers had already tied the axios compromise to North Korea, but Amazon says the earlier attacks on other packages were not publicly connected to the same operation.

Four packages, one campaign

Amazon’s timeline shows a methodical campaign stretching over a year. The attackers first compromised the typo-crypto package in March 2025. By September of that year, they had moved on to the popular debug and chalk packages. Then, in March 2026, the same operation appeared to compromise axios.

That last one is significant. Axios is one of the most widely used JavaScript libraries in the world, downloaded more than 100 million times each week. It’s embedded in countless web applications and enterprise services. A malicious update to a package like that can ripple outward fast.

How the attacks worked

In each case, Amazon says the hackers gained access by socially engineering a trusted maintainer of the software package. Once inside, they published a malicious update. Organizations that automatically installed the latest versions unknowingly downloaded malware.

This is a key detail. SapphireSleet doesn’t rely on software vulnerabilities. It relies on people. The group’s attacks are designed to steal passwords, cryptocurrency assets, and personal data.

Who is SapphireSleet?

Earlier in March, Google attributed the axios attack to a North Korean threat actor it tracks as UNC1069. Microsoft linked the same compromise to Sapphire Sleet, which it says overlaps with activity that other vendors track as UNC1069, BlueNoroff, Stardust Chollima, CageyChameleon, and Alluring Pisces.

Amazon’s report essentially confirms that all four package compromises were the work of the same group. That’s a broader footprint than previously understood.

Why open-source repositories are targets

Open-source software repositories have become increasingly attractive targets for financially motivated hackers, Amazon said. The logic is simple: rather than breaking into organizations individually, attackers can compromise a handful of widely used software packages and potentially gain access to thousands of downstream environments at once.

“When an attacker compromises a widely used open source package, every organization that depends on that package is potentially affected,” Amazon researchers said.

The scale of the problem is hard to overstate. A single malicious update to a popular package can reach millions of developers and countless production systems before anyone notices.

North Korea’s cyber theft economy

The motivation here isn’t espionage. It’s revenue. North Korea has increasingly relied on crypto and cyber theft to generate money in the face of international sanctions. The country stole more than $2 billion worth of cryptocurrency in 2025, its largest annual haul on record, according to previous reports.

That kind of money funds weapons programs and keeps the regime afloat. It also makes North Korean hackers among the most persistent and well-resourced threat actors in the world.

What this means for developers

Amazon reported the malware used in the campaign to the Open Source Vulnerabilities database, where it is tracked as MAL-2026-3400. That’s useful for defenders, but the broader lesson is about trust.

Open-source packages are maintained by volunteers, often with limited resources. A determined adversary can target those maintainers with phishing, credential theft, or other social engineering tactics. The result is that even the most reputable packages can be compromised.

For organizations, the takeaway is to audit your dependencies. Know what you’re installing and where it comes from. Consider pinning versions rather than automatically pulling the latest release. And treat open-source code with the same scrutiny you’d apply to any third-party software.

This is a reminder that supply chain security isn’t just about vendors and hardware. It’s about the code you build on. The next time you run npm install, think about who wrote that package — and who might have gotten to them first.