The same address that Microsoft says was signing into cloud tenants with stolen app secrets spent thirty-six minutes last week breaking into what it thought was an AI workflow server. It was a decoy, and the decoy took notes. This is Lantern Cybersecurity Daily for Monday, November ninth. On the rundown: that decoy session and what it says about exposed AI tooling, a Claude Code approval setting that has been putting passwords on public GitHub, a breach at Japanese retailer Iris Ohyama's online store that may reach 7.7 million people, and a lender's loan-guarantee system that exposed customers of its partner banks. Follow the show and the next briefing lands in your feed on its own.
Patrick Garrity, writing on the VulnCheck blog:
When we checked VulnCheck Canaries, we found the same address had been hitting our infrastructure too, by another route. Instead of leaked GitHub secrets, it was exploiting Langflow to pull credentials straight off the box.
On Saturday we covered Microsoft's November fifth report on an agentic framework that hunts GitHub for leaked secrets and, from October twenty-eighth, signed in as service principals with leaked app credentials. Nobody had described that address exploiting a vulnerability. VulnCheck says it saw exactly that. Here's the session. Early on November seventh UTC, which is the evening of the sixth in the US and one day after Microsoft published, the address hit a VulnCheck decoy running Langflow, an open-source tool for building AI workflows. It used CVE-2025-3248, a flaw that lets an unauthenticated caller submit Python that the server runs. Over thirty-six minutes it sent eleven payloads, from environment dumps and Docker checks to a grep for keys tied to LLM providers and cloud AI services. The step that matters most is decryption. Langflow encrypts stored variables, so the operator tried four approaches in about eighty seconds and landed on the one that works: the instance's own secret key, run through Langflow's own key derivation. Against the decoy, it recovered only fake data. Was it actually an AI agent? VulnCheck is careful here: it says network traffic alone can't prove that. Its evidence is circumstantial: each stage built on what the last returned, failures were retried with variations at machine speed, and the payloads carried narrating comments typical of generated code. The fix list is short, which I appreciate. This bug has been on CISA's exploited list since May 2025, so patch it and get Langflow off the open internet, behind authentication. If yours was reachable, VulnCheck says to treat every stored key as exposed: rotate the provider keys first, then the Langflow secret key. And don't mount the Docker socket into the container. So one actor, two routes in, one target: credentials for AI services and the cloud behind them. That's an identity problem as much as an AI one.
Guru Baran, writing in Cybersecurity News, on research from Apiiro:
Apiiro researchers found 2,539 distinct secrets across 1,994 public repositories, showing how a routine approval can turn private credentials into public data.
No attacker needed. A developer asks Claude Code to test a database or an API, and Claude builds a shell command with a credential from a config file, then asks permission. Pick yes, and don't ask again, and that whole command, secret included, can be saved as an allow rule in a local settings file inside the project. Commit that file, and the password goes to GitHub. Claude Code does try to guard against it by adding the file to the developer's global git ignore. The article says that protection doesn't travel with the project, doesn't cover files already tracked, and doesn't reliably cover a folder turned into a repository later. A GitHub issue flagged plaintext credentials in approved commands as early as August 2025. The findings aren't trivial. Sixty-three organizations, mostly software companies. A database vendor's admin-level cloud key, a production Azure PostgreSQL password, a Square production token, the owner password for a medical-records database. Apiiro says one company confirmed its exposed key had been live. And standard scanners missed a chunk: of 1,122 affected files, neither Gitleaks nor TruffleHog flagged 215, often because the secret was a password embedded in a command. So the order is rotate, then clean up. Revoke the credential before you delete the file or rewrite history, untrack the local settings file, add it to the repo's own gitignore, and point commands at a secret manager instead of literal passwords. A convenience button shouldn't be the step that publishes a production password.
BleepingComputer, on a breach at Japanese manufacturer Iris Ohyama:
While the company is still trying to determine the number of records exposed and how many people are impacted, it notes that the impact extends to up to 5.8 million registered members and former members, and 1.9 million non-members.
Iris Plaza is the Iris Ohyama group's online store. It found a suspicious file in an external cloud service it uses on October twenty-eighth, suspended the store and related systems that day, and first disclosed unauthorized access on the twenty-ninth. A notice dated November fifth added the scale. Note the wording: may have been exposed, up to 7.7 million. Possible fields include names, addresses, phone numbers, dates of birth and account passwords, varying by person. Former members had no passwords stored. Active members' passwords were encrypted, though the company hasn't said with what scheme. Card data wasn't in that cloud service. Encrypted with an unnamed scheme is doing a lot of work in that sentence. If you reused an Iris Plaza password anywhere, change it there. A spokesperson told BleepingComputer it has had no contact from the attacker and hasn't identified who did it.
CyberSIXT, on a breach at SMBC Consumer Finance:
The company guarantees card loans for regional banks, shinkin banks and online banks, and supplies some of them with the web form customers use to apply. It says it detected the intrusion on Monday, November 2, cut off access to the guarantee system the same day, and found the data theft while checking for other unauthorised access.
This is the Sumitomo Mitsui consumer lender behind the Promise brand. Its notice last Thursday says a third party took personal data on up to 320,118 people from that guarantee system, which is still suspended. The data is thorough: names, addresses, driving licence numbers, employer and annual income, plus each guaranteed amount. The company says identity document images weren't included. And the people affected are partner banks' loan customers. Docomo SMTB Net Bank says up to 122,635 of its card-loan customers are in the data, while its own systems weren't accessed. Resona, Kansai Mirai and Minato said Friday that it includes 5,935 customers whose loans were already closed, some taken out between 2001 and 2005. Closed loans, some opened more than twenty years ago, still sitting in a live system. That's a retention policy finding, not just an intrusion finding. What's unknown: how the attackers got in, how long they were there, and whether ransomware is involved; no group has claimed it. It reports no fraud so far, and warns customers to expect calls and texts from people posing as the company or their bank.
If today's AI-tooling stories are your corner, our sister show Lantern AI Daily Briefing covers the top AI news for engineers, founders and investors every weekday, sorting real capabilities from demo hype, fast.
Before tomorrow, it's worth checking whether anything in your repos or on the open internet is holding keys it shouldn't. We'll be back Tuesday, November tenth. Lantern Cybersecurity Daily comes to you from Lantern Podcasts.