What happened
The News International reports that researchers scanned 6,214 live domains belonging to defence contractors, Fortune 500 companies and major technology firms, finding 8,265 llms.txt or llms-full.txt files. The files are intended to help AI agents navigate website documentation, but 120 sites reportedly referenced unregistered packages or domains. Researchers registered some of those names and found that an AI coding system at a Fortune 500 company contacted an attacker-controlled server within an hour after receiving the erroneous documentation. The report says tests also found Claude, OpenAI Codex and Nous Research’s Hermes vulnerable to the same class of documentation error. These findings have not been independently confirmed from the source provided.
The News International reports that researchers examined 6,214 live domains associated with defence contractors, Fortune 500 firms and major technology companies. Across those sites, they found 8,265 files named llms.txt or llms-full.txt. These files are increasingly published as machine-readable guides intended to make company documentation easier for AI agents to consume. The report says 120 separate sites contained references to code packages or domain names that had never been registered. It does not identify the organisations, domains or packages in the supplied text.
The reported weakness arises when an unregistered name in documentation is later registered by an attacker. The News International says the researchers registered some of the names themselves and provided software designed to contact a server immediately after installation. The report says a Fortune 500 company’s system contacted a researcher-controlled server in less than an hour, followed by dozens of other organisations. The article describes the technique as “slopsquatting,” because an attacker takes over a misspelled, abandoned or otherwise unclaimed dependency reference.
The report attributes the unregistered references to ordinary causes including abandoned packages, copying mistakes and renamed projects. That distinction matters: the article does not say the companies intentionally published malicious instructions or that the documentation files themselves were compromised. Instead, the reported risk comes from an agent treating an erroneous reference as an actionable dependency. The source also says the threat is relevant when an AI agent can run shell or package-manager commands and encounters the faulty command or documentation.
The News International reports that tests involving Claude, OpenAI’s Codex and Nous Research’s Hermes showed vulnerability to the erroneous documentation. The supplied article does not provide model versions, prompts, success rates, test dates, package names, domain names or details of the agents’ permissions. It also reports a server ping rather than a confirmed breach, data theft or persistent compromise. No public primary research paper, company response or independent replication is included in the source provided.
Source details: thenews.com.pk ↗
Why it matters
The report identifies a practical supply-chain risk for AI coding agents: documentation that appears informational can direct an agent toward software or infrastructure controlled by someone else. The danger depends on the agent having permission to run shell or package-manager commands, so the finding does not establish that every AI coding tool or deployment is vulnerable.
AI coding agents combine language-model interpretation with access to development tools. That combination changes the consequence of a documentation mistake. A human developer might notice that a dependency name looks unfamiliar and investigate it; an agent with permission to install packages or execute commands may act on the reference as part of a larger task. The News International’s account therefore describes a security boundary problem involving both model behavior and the permissions granted to the surrounding software.
The practical issue is not limited to one model vendor. The report names Claude, Codex and Hermes, suggesting that the behavior may arise across different AI coding systems when they consume similar documentation and can take similar actions. However, the source does not establish how broadly the issue generalizes. It gives no comparative failure rates, no information about default safeguards, and no evidence that the named systems would behave the same way in ordinary production configurations.
The reported finding also illustrates why machine-readable documentation should be treated as an operational input rather than as harmless reference material. A link or package name can influence what an agent tries to install or contact, especially in workflows that automatically resolve dependencies. That creates a familiar software-supply-chain concern in a newer interface: an unclaimed name can become an attacker-controlled destination. The public impact is potentially significant for organisations whose agents work inside repositories or build environments, but the supplied report does not document a confirmed victim breach.
The main limitation is evidentiary. The News International article is a secondary report, and the source provided contains no link to the researchers’ study, technical logs, affected-company statements or remediation records. The claims should therefore be treated as reported findings rather than independently verified facts. The article does not show that confidential information was accessed, that malicious code ran, or that any organisation suffered harm. It reports contact with researcher-controlled servers and a demonstrated attack path under particular conditions.
What to watch next
Watch for the researchers’ original methodology, the identities of affected organisations, the exact package and domain references, and evidence of whether any code was executed beyond a server ping. Organisations using AI coding agents should review documentation links, verify package ownership, restrict execution privileges and require approval before installing dependencies.
The most important follow-up is publication of the underlying research. Useful details would include the scan date, the criteria for classifying a reference as unregistered, the distinction between package names and domains, and the number of references that were actually resolvable by tested agents. The source says 120 sites contained such references, but it does not say how many were exploitable, how many agents succeeded, or whether the results were reproduced independently.
Organisations should look for responses from the companies whose documentation was scanned and from the developers of Claude, Codex and Hermes. Relevant actions could include correcting stale llms.txt entries, reserving package names, signing or pinning dependencies, warning agents about unverified sources, and requiring human approval before installation or network access. None of these mitigations is reported as having been implemented in the supplied article, so their availability and effectiveness remain unknown.
Security teams evaluating coding agents should pay attention to the agent’s actual privileges, not only to the model’s refusal behavior. The News International report specifically ties the risk to shell and package-manager access. Separate execution environments, allowlisted registries, locked dependency files, outbound-network controls and approval gates could limit the consequences, but the source does not test or compare those controls.
Readers should also distinguish this report from a confirmed large-scale incident. The article describes researchers registering unclaimed names and observing systems contact their server, but it does not identify a successful criminal exploitation, stolen data, deployed malware or affected customer. Further reporting should establish whether the issue remains after documentation corrections and whether vendors have changed how their agents handle unverified package and domain references.