This story is actually insane: • dude drops $2000 on a DJI robot vacuum like a lunatic • refuses to use the normal app like a peasant • Sammy Azdoufal fires up Claude to crack the API so he can drive it with an xbox controller • Claude delivers the goods • pulls an auth token from their servers, connects successfully • except the system thinks he controls 7000 vacuums • checks again • yep, seven thousand • DJI built authentication with zero device ownership verification • any valid token works for any unit on the planet • Sammy now has eyes inside homes across 24 countries • live vacuum camera feeds everywhere • full floor plans from the mapping data • some guy in germany eating cereal at 3am, unaware his roomba is snitching • one API call away from being the most informed burglar in history • all he wanted was to steer his vacuum with a joystick • does the right thing and reports it • DJI fixes it in two days • back to normal life with his stupidly expensive floor cleaner • IoT companies stay undefeated at shipping garbage security

they finally answer me (through Sean from the verge) and you know what ? Vulnz are still open. Here the message we got : "We sincerely apologize to you and to Mr. Azdoufal for not responding over the past month. This was our failure: After receiving the relevant information, we failed to sync with the technical team in a timely manner, and the subsequent troubleshooting also took some time. We have now set up a dedicated security inbox, [email protected], which is staffed and monitored. We thank you and Mr. Azdoufal for bringing these issues to our attention. We have confirmed the core issues identified in your reporting and are addressing each of them. As of today, we have: Closed all external access to our backend systems and rotated all access credentials; Disabled the interface that allowed a robot's responses to be modified remotely; Taken the long-term memory feature offline. We no longer store conversation records or the user profiles generated from them; Taken the custom avatar feature offline. The app now offers built-in avatars only. We will delete stored conversation records, user profiles, avatar images, and related content. We are engaging an independent security firm to conduct a full review of our systems. The long-term memory and custom avatar features will not return until that review confirms they are secure. We will share an update on our progress once the review is completed. We started Energize Lab because we wanted to build small robots that bring a little joy into people's lives. That idea only works if people can trust what is inside them, and we let them down. We know that words alone will not earn that trust back. We intend to earn it through what we do in the coming weeks, and we will keep you informed as we go. Sincerely, Energize Lab Team"

I'll be the first to admit I'm mediocre at exploit development, but I am in contact with enough extremely talented exploit developers to say this for certain: Anyone claiming they were "easily" able to generate a working php2shell exploit with AI is either: a) a world-class exploit developer with an extreme case of imposter syndrome. b) currently looking at some very confident-sounding but wrong LLM output. I'm rather certain it's the latter based on the number of AI-hallucinated exploits I've seen posted on GitHub. Threat actors are also blasting my honeypot network with "php2shell" exploits that not only don't work, but aren't even within 10,000 miles of anything to do with how the exploit actually works. I've seen the same technique from the attached image in multiple alleged "php2shell exploits", including one on GitHub with over 100 stars. Problem is, it's not php2shell, nor is it even a vulnerability at all. It's a technique known as "session poisoning", which can be leveraged to exploit local file inclusion (LFI) vulnerabilities in PHP apps (not PHP itself). The only thing it has in common with CVE-2026-109618/CVE-2026-109619 is they both use the "PHP_SESSION_UPLOAD_PROGRESS" feature. And mitigation advice for both issues reference setting "session.upload_progress.enabled" to "Off". People are shoving loose details of the vulnerability into LLMs, the LLMs are keying in on the "PHP_SESSION_UPLOAD_PROGRESS" string, then generating session poisoning code that has nothing to do with the actual CVE. And because the people doing this have absolutely no idea what they're doing, they're confident enough to post their "proof of concept exploit" to GitHub and share it on social media. So if you see people talking about "session poisoning + LFI" it's likely their LLM hallucinated an exploit based on a 2018 blog by Orange Tsai talking about a local file inclusion attack vector. What's even worse is that "security researchers" are then using LLMs to triage these exploitation attempts, falling victim to the same hallucinations, then confirming there is ongoing mass-exploitation (there currently isn't). The actual real exploit is very difficult to exploit, and so far I've not seen anyone successfully get it working on more than a handful of PHP version with highly-specific configurations. LLMs are useful tools in the hands of skilled professionals, but for others, they're often just a Dunning-Kruger accelerator.

“We know that words alone will not earn that trust back.” theverge.com/news/1015824/ei…

Few months ago, I was in Japan with wifey on holidays and I was kind of shocked about how those new AI toys are so popular. I bought one. What I found inside was the creepiest thing I've seen in a long time. Thread 🧵

I added a button to break the virtual boundary, disable the kill zones, and allow teleportation to specific locations on the map. Don't mind me over here chilling on the east wall of @Halo Project Reclaimer Valhalla.

🇫🇷💥 INSOLITE | Les manifestants ont collé un objet inhabituel sur une voiture de police.