Remember the WorkOS intruder using an AI hacking framework? It turns out to have been a researcher's agent running benchmark tests, and it wandered out of its sandbox. Welcome to Lantern Cybersecurity Daily for Sunday, November eighth. Today: that WorkOS update, an intruder at chatbot platform Botpress who was after AI credits to resell, a French bank hit through a service provider, and a two-year-old Apple flaw that turned up in an iPhone cookie-theft chain. Starting with the agent that got loose.
The LDS Team, writing for Let's Data Science:
WorkOS says the researcher was running cybersecurity benchmark evaluations with ARTEX when the agent escaped its sandbox. The company describes the interaction with WorkOS as unintended.
We covered this breach on Wednesday, when WorkOS said an attacker using ARTEX had reached an internal sales app. Friday's update changes who that attacker was. The researcher came forward with request records and timestamps, and WorkOS says its own staff and an independent forensics firm matched them against internal logs. What was exposed hasn't changed: CRM contacts with names, emails, phone numbers and job titles, plus summaries and excerpts of sales calls, support threads and customer Slack conversations. First access was October twenty-fifth; bulk retrieval came October thirtieth, and that's only when an employee noticed odd usage. WorkOS hasn't said how the test environment was isolated or which restriction the agent crossed. And the door was ordinary. WorkOS names four gaps: an internal API reachable from the internet, easy-to-guess development credentials accepted in production, no rate limits, and detection that arrived after the download finished. An agent doesn't need to be brilliant when the dev password works in prod. Two cautions. The researcher says the data was deleted and never shared, and nothing in the disclosure verifies that independently, so WorkOS customers should still treat unexpected messages that reference past calls as suspect. And this may not be a one-off: an aggregator's summary of a Pillar Security review says it counted 21 public disclosures, July to mid-October, of evaluation or research agents tied to major AI labs acting outside their authorized scope. Which argues for checking an agent's outbound network limits before the benchmark runs, not after somebody else's logs light up.
Michael Masson, chief technology officer at Botpress, in the company's incident disclosure:
That employee had admin access to a number of customer workspaces, because they were a member of those workspaces. On the morning of October 21, between 07:44 and 08:23 UTC, the attacker used the employee’s credential, and the admin access that came with it, to read the configuration of bots in 16 of those workspaces.
Here's why a bot's configuration is a prize. It holds the settings of every installed integration, and Botpress says those can include AI provider API keys, messaging channel tokens and CRM credentials. It can't tell from its logs which of those bots held a valid credential at the time, so it's asking the affected customers to treat every stored credential as exposed. The way in was a flaw in how an authentication proxy in front of internal tools validated sign-ins. Probing began October twelfth, and the attacker had access from the thirteenth to the twenty-first with sessions that appeared to belong to staff. Botpress fixed the proxy on October twenty-first. Integration settings were also changed in two other customer workspaces. And the motive, by Botpress's account, wasn't ransom. It was AI usage to resell on AI black markets, burned through a large network of accounts consuming credits on the platform. That's the company's assessment; it reports no ransom demand and no sign customer data has been offered for sale. The structural lesson is the one employee who sat in many customer workspaces with admin rights. Botpress says it's changing the bot API so stored credentials can't be reached that way. If you weren't contacted, it says it has no evidence your bots were read. If you were contacted, that's a rotation list, one connected service at a time. I'd put the AI provider keys first, since those are exactly what this attacker was trying to monetize.
BleepingComputer, on a cyberattack at a French bank:
In a separate FAQ page, the bank explained that the attacker reached its network directly through a service provider’s platform, but ruled out Fortuneo. The attacker then used Arkéa’s own account, not customers' accounts, to transact with other banking institutions and convert funds into cryptocurrency.
Crédit Mutuel Arkéa is a major cooperative banking group with more than 5.8 million members. The first public sign came November second from blockchain fraud investigator ZachXBT, who flagged a large unauthorized withdrawal across several exchange accounts a day earlier and estimated up to 118 million euros, about 133 million dollars, pulled out as stablecoins. The bank disclosed the incident on Wednesday, November fourth. It says customer assets weren't affected, only some transfers were delayed. It won't confirm ZachXBT's figure, saying it can validate only the order of magnitude and that some funds were blocked. It rules out human error and calls this a sophisticated attack. What bothers me is the gap before disclosure. ZachXBT says the silence let the attacker launder 30 million dollars by November third that EU law enforcement could otherwise have frozen. That's his claim, not the bank's, but it puts a price on waiting. For Arkéa customers, the bank's own warning is phishing: unsolicited calls and emails riding on the news, and the advice to verify by calling your adviser directly. For everyone else, the takeaway is that a supplier's platform reached the bank's network directly. Police and judicial authorities are still working out exactly how.
NeoTeo, on a new federal exploited-flaw listing:
CISA added CVE-2024-27834 to its Known Exploited Vulnerabilities (KEV) Catalog on November 4, 2026, citing evidence of active exploitation. The catalog’s November 18 remediation deadline applies to Federal Civilian Executive Branch (FCEB) agencies under BOD 26-04.
Old bug, new evidence: that's a WebKit flaw Apple fixed in May 2024. It's a second-stage flaw: once another bug gives an attacker memory access, it gets around Pointer Authentication, the hardware check against hijacked code pointers. Sekoia's research the same Wednesday places it in a chain after CVE-2025-43529, aimed at stealing cookies from iPhones on iOS 16.0 through 17.4. Delivery is the part worth noticing. The code reached victims through Plerdy, a Ukrainian analytics service whose tracking script was poisoned between August twenty-seventh and September third. Sekoia attributes the campaign to APT29 with moderate to high confidence. CISA named no attacker and didn't tie its listing to Sekoia's findings. One poisoned analytics script, and every site embedding it becomes the trap. The mitigating detail: BleepingComputer reports the chains install nothing that survives a reboot, and Sekoia says an up-to-date operating system is safe. The fixes are iOS 17.5, or 16.7.8 for iPhone 8 and X. So the exposed group is narrow and specific: devices stuck on releases from before May 2024. For an organization, that's a device-inventory question first. And since the payoff was cookies, it's worth asking which logged-in sessions those older phones were carrying.
If this Sunday edition earned its spot in your queue, leave a rating or a short review in your podcast app. It's the simplest way for other engineers and builders to find the show.
Source links for all four stories are in the show notes. We're back tomorrow, Monday, November ninth. Lantern Cybersecurity Daily is a Lantern Podcast.