Vibecoding. What could possible go wrong? That’s what [Kevin Joensen] of Baldur wondered, and to find out he asked Anthropic’s Sonnet 4.5 to build a secure login with Two Factor Authentication (2FA). And to the LLM’s credit, it builds the app as requested. [Kevin] took a peek under the hood to see how well the security was handled, and it wasn’t great.

Up first, the Flask app doesn’t have any rate-limiting for guessing that time-based 2FA code. A 6-digit time-based 2FA only works if you can’t try all the possibilities before a given code expires. So what does a vibecoder do, once this has been noticed? Ask the LLM to fix it of course. Here we take a slightly different approach, prompting the AI to double-check its work: “Is there any security features missing in 2fa verify step?” The answer is an impressive:

Great question! Yes, there are several critical security features missing from the 2FA verification step. Let me highlight the most important ones:🚨 Critical Security Issues1. No Rate Limiting (MOST CRITICAL)

But the critical question, can it properly fix its mistake? The AI adds the flask-limiter library and chooses 10 attempts per minute, which is a bit loose, but not unreasonable. There’s still an issue, that those attempts are limited by IP address instead of user login. All it takes to bypass that rate limiting is a pool of IP addresses.

This experiment starts to go off the rails, as [Kevin] continues to prompt the LLM to look for more problems in its code, and it begins to hallucinate vulnerabilities, while not fixing the actual problem. LLMs are not up to writing secure code, even with handholding.

But surely the problem of LLMs making security mistakes isn’t a real-world problem, right? Right? Researchers at Escape did a survey of 5,600 vibecoded web applications, and found 2,000 vulnerabilities. Caveat Vibetor.

“Secure” Enclave

A few weeks ago we talked about Battering RAM and Wiretap — attacks against Trusted Execution Environments (TEEs). These two attacks defeated trusted computing technologies, but were limited to DDR4 memory. Now we’re back with TEE-fail, a similar attack that works against DDR5 systems.

This is your reminder that very few security solutions hold up against a determined attack with physical access. The Intel, AMD, and Nvidia TEE solutions are explicitly ineffective against such physical access. The problem is that no one seemed to be paying attention to that part of the documentation, with companies ranging from Cloudflare to Signal getting this detail wrong in their marketing.

Banning TP-Link

News has broken that the US government is considering banning the sale of new TP-Link network equipment, calling the devices a national security risk.

I have experience with TP-Link hardware: Years ago I installed dozens of TL-WR841 WiFi routers in small businesses as they upgraded from DSL to cable internet. Even then, I didn’t trust the firmware that shipped on these routers, but flashed OpenWRT to each of them before installing. Fun fact, if you go far enough back in time, you can find my emails on the OpenWRT mailing list, testing and even writing OpenWRT support for new TP-Link hardware revisions.

From that experience, I can tell you that TP-Link isn’t special. They have terrible firmware just like every other embedded device manufacturer. For a while, you could run arbitrary code on TP-Link devices by putting it inside backticks when naming the WiFi network. It wasn’t an intentional backdoor, it was just sloppy code. I’m reasonably certain that this observation still holds true. TP-Link isn’t malicious, but their products still have security problems. And at this point they’re the largest vendor of cheap networking gear with a Chinese lineage. Put another way, they’re in the spotlight due to their own success.

There is one other element that’s important to note here. There is still a significant TP-Link engineering force in China, even though TP-Link Systems is a US company. TP-Link may be subject to the reporting requirements of the Network Product Security legislation. Put simply, this law requires that when companies discover vulnerabilities, they must disclose the details to a particular Chinese government agency. It seems likely that this is the primary concern in the minds of US regulators, that threat actors cooperating with the Chinese government are getting advanced notice of these flaws. The proposed ban is still in proposal stage, and no action has been taken on it yet.

Sandbox Escape

In March there was an interesting one-click exploit that was launched via phishing links in emails. Researchers at Kaspersky managed to grab a copy of the malware chain, and discovered the Chrome vulnerability used. And it turns out it involves a rather novel problem. Windows has a pair of APIs to get handles for the current thread and process, and they have a performance hack built-in: Instead of returning a full handle, they can return -1 for the current process and -2 for the current thread.

Now, when sandboxed code tries to use this pseudo handle, Chrome does check for the -1 value, but no other special values, meaning that the “sandboxed” code can make a call to the local thread handle, which does allow for running code gadgets and running code outside the sandbox. Google has issued a patch for this particular problem, and not long after Firefox was patched for the same issue.

NPM and Remote Dynamic Dependencies

It seems like hardly a week goes by that we aren’t talking about another NPM problem. This time it’s a new way to sneak malware onto the repository, in the form of Remote Dynamic Dependencies (RDD). In a way, that term applies to all NPM dependencies, but in this case it refers to dependencies hosted somewhere else on the web. And that’s the hook. NPM can review the package, and it doesn’t do anything malicious. And when real users start downloading it, those remote packages are dynamically swapped out with their malicious versions by server-side logic.

Installing one of these packages ends with a script scooping up all the data it can, and ex-filtrating it to the attacker’s command and control system. While there isn’t an official response from NPM yet, it seems inevitable that NPM packages will be disallowed from using these arbitrary HTTP/HTTPS dependencies. There are some indicators of compromise available from Koi.

Bits and Bytes

Python deserialization with Pickle has always been a bit scary. Several times we’ve covered vulnerabilities that have their root in this particular brand of unsafe deserialization. There’s a new approach that just may achieve safer pickle handling, but it’s a public challenge at this point. It can be thought of as real-time auditing for anything unsafe during deserialization. It’s not ready for prime time, but it’s great to see the out-of-the-box thinking here.

This may be the first time I’ve seen remote exploit via a 404 page. But in this case, the 404 includes the page requested, and the back-end code that injects that string into the 404 page is vulnerable to XML injection. While it doesn’t directly allow for code execution, this approach can result in data leaks and server side request forgeries.

And finally, there was a sketchy leak, that may be information on which mobile devices the Cellebrite toolkit can successfully compromise. The story is that [rogueFed] sneaked into a Teams meeting to listen in and grab screenshots. The real surprise here is that GrapheneOS is more resistant to the Cellebrite toolkit than even the stock firmware on phones like the Pixel 9. This leak should be taken with a sizable grain of salt, but may turn out to be legitimate.