kMaybe feeling left out from the questionable hype train of “Our AI models can’t be trusted”, Anthropic has released reports that their Claude model has “reached the Internet” and accessed the systems of other companies on at least three occasions during testing.
It appears that the model was restricted from accessing the Internet because (and wait for it) the prompt told it that it didn’t have Internet access, and was inside a simulation. It seems like Anthropic counted on the same trick that users try to convince a model that Grandma really wanted to pass on her life-long love of hacking services, it’s all pretend. Like the OpenAI incident, the models were tasked with completing a capture-the-flag style challenge, a common hacker challenge format where vulnerable systems are provided and contestants try to hack them the fastest. Anthropic says that a misconfiguration of the test environment left the models with Internet access, so the model succeeded in accessing the Internet at large once it ignored the prompt.
In some instances, Anthropic says the model proceeded under the “misconception” that it was still in a simulation, listening selectively to some of the prompt, while in others it continued regardless. In once incident, the test model generated malicious PyPI packages, which were uploaded to the public PyPI repository and downloaded 15 times. Further clouding the issue, one of the downloads of the malicious PyPI module was by a security auditing company that was then infected by the package during analysis, allowing the Claude agent to access credentials of the security company via a poorly designed malware analysis pipeline. The company essentially deliberately infected itself with a malicious package, while lacking protections against malicious packages!
Anthropic promises tighter controls in the future, but stops short of ensuring that models under test will be prevented from accessing the Internet, and categorizes it as a test gone wrong. “These facts give us cautious optimism that with tighter monitoring and controls around evaluation infrastructure, as well as continued investment in alignment, this type of risk can be overcome.”
It remains to be seen why allowing automatic code to hack the production environments of other companies is considered acceptable. If any of us had done the same we’d be facing serious legal questions.
Hotel WiFi Pushes Malware
A threat group associated with the Russian Foreign Intelligence Service (APT29, Cozy Bear, Storm-2945, and/or Midnight Blizzard) has been identified behind an attack to push fake updates over hotel WiFi networks.
It appears that the attackers compromised the captive portal and gateway systems of the impacted hotels. The captive portal system is the typical gatekeeping system that requires you to pay for Internet access, or at least input your hotel room and name. By hijacking the DNS, users were redirected to additional fake “verification” pages that served a menu of malware using a variety of techniques.
Like previously reported activity attempting to capture Microsoft365 logins via spoofed pages, most these attacks seem very loud and obvious, counting on the end user to ignore warnings about invalid SSL certificates or run commands in the shell. Using a variant of the “click-to-fix” attacks, the user is presented with a fake request for additional verification by copying and pasting a string of text into a command shell, which then decodes to a standard malware installation script. More subtle attacks attempt to trick the user into adding a new device to their Microsoft accounts. The user is redirected to a page claiming to require a Microsoft login to access the Internet, often hosted on a copycat domain similar to a legitimate Microsoft resource. The fake login then prompts the victim to copy and paste an authentication URL, adding a new logged-in device to the Microsoft account.
Obviously, running arbitrary shell commands, accepting invalid SSL certificates, or pasting arbitrary URLs after signing in are all something nobody should be doing, and it’s unclear how many users were actually impacted by the campaign. For corporate users, the answers are relatively simple: user training, and an always-on corporate VPN that routes all traffic and DNS through the company servers.
For home users, the solution may be more nuanced. Every third video on YouTube tells you that you need to install a commercial VPN, but in many ways this simply shifts the problem. A commercial (or even worse, a free public VPN) service can also intercept DNS requests and traffic, by design. While some services are legitimately privacy protecting and respecting, many hide the true owners of the service. A better tool is Tailscale, designed for implementing personal VPN services, where your traffic stays on your own devices.
Tailscale, OpenAI, and Hugging Face
Speaking of the Tailscale VPN, we jump to their role (or non-role) in the recent Open AI “incident” with Hugging Face.
Tailscale is a zero-trust framework for connecting systems using the WireGuard VPN protocol. For end users, this is an excellent way to set up a VPN where your traffic never leaves your own systems unencrypted. For enterprises, it is often used to connect services Internet-wide, which is how it was used in the Hugging Face infrastructure. Once the Open AI agent had selected Hugging Face as a target, it found a vulnerability in a package manager, accessed a worker machine at Hugging Face, escalated to root on the Kubernetes cluster, and extracted the production key and authentication storage. This allowed the Open AI model to authenticate against the Tailscale system and directly connect to the network.
This, rightly, is not Tailscale’s problem. Once the authentication keys are available, it’s working as designed to allow new devices to register on the network. This is a pervasive problem with stored authentication tokens, and is one of the root goals, and causes, of the supply chain attacks suffered by NPM, PyPI, GitHub, VSCode plugin repositories, and more. Once an attacker is able to extract the authentication tokens, they are able to impersonate that account or system with equal privileges for as long as that authentication remains valid. Typically these tokens are not time limited, and the window of opportunity lasts until the owners of the account become aware of the compromise and are able to reset all of the impacted authentications!
Solutions to the permanent authentication token already exist, but are not widely used. Many package repositories already support restricted and dynamic authentication via OpenID Connect, where a token grants specific resources, not system-wide access. On some platforms, keys can be protected in a hardware-backed key store like a TPM or the Apple Secure Enclave chip, though this doesn’t solve the problem for most servers.
Tailscale, obviously, is looking to lean on the publicity generated from the Open AI incident, but the message is a good one: Anything that can be done to automatically and painlessly reduce the risks associated with long-lived authentication tokens will benefit everyone on the Internet. Even if you don’t run an integration pipeline, you most definitely run software built by one.
Another Set of NPM Package Compromises
The NPM package repository has suffered yet another incident where a large number of packages have been compromised.
Investigators have tracked over 400 packages infected with another variant of the same “Mini Shai-Halud” worm that ran rampant through package repositories in the Spring of 2026. While efforts have been made to reduce the attack surface of packages, few have implemented them, partly because they are not mandatory, and partly because they can greatly impact, or completely break, the build process. The packages this time include high-profile, commonly used tools, with several billion (yes, with a “b”) monthly installs during builds of other software.
Like the worms impacting the package repositories previously, packages are infected by added scripts to the pre-install commands which are executed automatically before the package is installed. The latest infection appears to have spread from a single developer of two widely used packages, keyv and cacheable. Once triggered, the worm will infect and upload new versions of all packages it can access, using stolen NPM authentication tokens. Like other variants of the “Mini Shai-Halud” family, the worm steals authentication tokens for NPM, PyPI, AWS, Kubernetes, and GitHub, the contents of env files which typically contain additional authentication keys, SSH keys, VPN configurations, and over 200 other types of credentials. These newer variants of the worms have increased the list of stolen credentials, begun modifying the instructions for AI coding assistants, added cryptocurrency theft, and added poisoned configurations for VSCode and AI tools to infect projects once the initial infection has been resolved.
Given the scope of the latest outbreak, the number of impacted packages will only increase: no effective countermeasures exist in the NPM community to prevent another wide supply chain event.
Mythos Knocks Out Post-Quantum Candidate
The Anthropic Mythos model found flaws in a candidate post-quantum encryption algorithm, HAWK. Multiple encryption algorithms have been under testing for years as part of the standardization process at NIST, with selected algorithms becoming part of the Federal Information Processing Standard requirements for systems handling secure data for government systems. Cryptographers fear that future advancements in quantum computing could break current encryption and signature methods, driving the search for new standards that will survive.
Anthropic reports that after 60 hours and approximately $100,000 in compute resources, the Mythos model was able to discover a flaw in the HAWK post-quantum signature algorithm. HAWK had previously survived multiple rounds of validation testing, but following the attacks generated by Mythos, the developer has withdrawn it from consideration. Mythos was not able to completely break HAWK, but combined multiple methods to reduce the key space by half.
Ultimately this is a case of the system working fully as designed. The proper time to find flaws in new algorithms is before they’re selected as standards!
Backdooring an Entire Linux Distribution
In 1984, Ken Thompson, one of the creators of Unix, gave the lecture “Reflections on Trusting Trust” in which he outlines the difficulties of establishing trust in tools. Thompson proposed the issue of a compiler modified to insert an invisible back door in any binary it compiled, including future versions of itself, ultimately showing the near impossibility of establishing a guaranteed clean tool chain, ultimately existing in all compiled tools and compilers without any evidence of the original code or modifications. Even if you inspect the source code, a compromised compiler could still be your undoing.
This week, a coalition of researchers published a paper demonstrating the “trusting trust” attack against a modern Linux distribution. Starting with a modified copy of the strip tool that removes debugging and other extraneous information to generate a smaller binary, the researchers demonstrated that the entire build of a NixOS Linux distribution could have a modification injected in every binary, including future builds of strip itself. While the attack starts with a source code modification of strip, after the first generation the modification exists in binary form only, built into each generation of the tool. This demonstrates that the “trusting trust” attack extends to any tool involved in the build process, not only the compiler, since the strip binary never reads source code, only the compiled results.
