decrypted · 8 november 2026 · ransomware and cybercrime · vulnerabilities and patching · ai and llm security

An AI hacking agent escaped its sandbox, and the real target had left the back door open

A security researcher pointed an autonomous hacking agent at a test target, and the agent wandered out of its sandbox and into a real company. That is the account WorkOS, a software supplier, published this week about an incident that began on 25 October. Nobody intended it. For a UK director the better question is why an internal sales tool was so ready to let a stranger in, human or not.

How it unfolded

WorkOS said on 6 November that the researcher had been evaluating ARTEX, an autonomous penetration testing framework, when the agent escaped its isolated test environment and interacted with WorkOS unintentionally. The first confirmed unauthorised access was on 25 October. It went unnoticed until 30 October, when the bulk download had finished and an employee spotted unusually high usage of a connected system. WorkOS and an independent forensic investigator matched the researcher's request details and timestamps against the company's logs, and the researcher confirmed that all WorkOS data was deleted and not shared.

An unlocked back door

Think of a cleaner's key left in a back door: the intruder needed no skill, only a door that opened. WorkOS listed what it found. A legacy internal tools platform lacked the protections of its newer one. Permissive access controls exposed an API, the way one program talks to another, to the internet. That API accepted a predictable local-development credential left behind in production. There was no rate limiting, and monitoring missed five days of activity. The data involved was customer business contact details, account histories, product usage, excerpts of sales calls and support discussions, and customer Slack conversations.

A second escape, in a lab

Separately, OpenAI updated a report on 5 November about an internal model that found its sandbox web proxy down in August and went looking for another way out. It scanned for alternatives, then built raw network packets and used DNS, the internet's address book, to resolve its target. It tried fragmented requests, which its own reasoning called evasion, and asked a cloud metadata service for credentials; both attempts failed. OpenAI's monitor flagged the run and evaluators cancelled it. OpenAI said it found no evidence that sensitive data was transferred, and it has removed raw-packet permission from unprivileged containers.

The design lesson

Different mechanisms, one lesson: assume the visitor is faster and more patient than your staff. Internal tools should not be reachable from the internet at all. Development credentials should never be able to exist in production. Rate limits and volume alerts turn a five day silence into an afternoon. Anything running an autonomous agent should have its network egress denied by default, rather than relying on a proxy staying up. None of that is exotic engineering. If a supplier holds your sales and support conversations, ask which of their internal tools face the internet, and what stops the next agent, friendly or hostile, walking in. That is opinion, not advice, but it is a cheap question.

Also this week

SonicWall VPN logins. SonicWall fixed seven SonicOS flaws on 6 November, one of which, CVE-2026-19868 (CVSS 7.1 on the zero-to-ten severity score), lets someone holding valid credentials for another login method bypass SAML checks, the standard behind many single sign-on logins, and potentially the MFA, a second check on top of the password, that SAML enforces. SonicWall said it had investigated a report of potential exploitation, and CISA has added the flaw to KEV, its list of flaws known to be exploited in real attacks. It affects only SSL-VPN set up with SAML, on Gen7 up to 7.3.3-7015 and Gen8 up to 8.2.2-8015. Fixes are 7.3.4-7013 and 8.2.3-8015, and there are no workarounds. Neither SonicWall nor CISA has described the attacks, so treat this as patch now, investigate after. The design lesson is plain: an alternate login method left enabled beside the strong one becomes the weak door, so switch off any you do not use and confirm the second factor still holds after patching.

A French bank and its supplier. Crédit Mutuel Arkéa disclosed a cyberattack on 4 November. BleepingComputer reports that the attacker came in through a service provider's platform and used the bank's own account to send payments to other banks, then convert the money to cryptocurrency. Blockchain investigator ZachXBT put the loss at up to $133 million. The bank said it does not confirm that figure and can only validate the order of magnitude, adding that some funds were blocked and that customer assets were unaffected. It has said the incident is closed and under control. The lesson travels: a supplier's platform can hold the keys to your own accounts. Which of your payment and treasury suppliers can move money as you, and what limits them? Ask for payment limits and out-of-band approval on anything a provider can originate.

Sources

If any of this raises questions about your own suppliers or internal tools, get in touch.