A researcher chained two Unitree G1 flaws to gain root access remotely and showed how a compromised robot could attack others nearby.
Security researcher Olivier Laflamme spent about three months digging into the Unitree G1 humanoid robot and eventually found a way to fully compromise it without plugging in a single cable. In his technical write-up, he details two vulnerabilities, CVE-2026-76639 and CVE-2026-76640, that can be chained across Bluetooth, Unitree’s cloud infrastructure, the mobile app, and the robot’s firmware to gain unauthenticated root access to any G1 within Bluetooth range.
The first bug lives entirely inside the robot itself, no wireless attack surface needed if you can reach it over Ethernet. The G1’s AI chatbot service accepts a “knowledge” upload with almost no validation on the filename it writes to disk, and a classic path traversal payload lets an attacker write an arbitrary file anywhere on the filesystem, including into a directory that a separate service called bashrunner treats as trusted. Restart bashrunner, tell it to run the newly planted file, and you’ve got root-level shell execution with five DDS messages and zero authentication.
The second chain is the one that should worry anyone deploying these robots at scale. It starts with a Bluetooth characteristic that accepts writes without pairing, something The Hacker News also covered in its own report on the disclosure. An unpaired device can request the robot’s encrypted key bootstrap blob, and Unitree’s cloud API would decrypt that blob for any free, logged-in Unitree account without ever checking whether the account actually owned that specific robot.
“The blob is RSA-encrypted & the corresponding RSA private key is held by Unitree’s cloud infrastructure. This, in theory, is safe.. This is the security boundary Unitree appears to have relied on. Nearby devices can request the bootstrap blob, but only Unitree owns the RSA private key capable of opening it.” reads Laflamme’s report. “However, the Unitree mobile app reassembles the BLE notification chunks and slingshots that shit via a POST to Unitree’s cloud API /device/bindExtData on global-robot-api.unitree.com and the app stores the response body as gcmKey.”
That decryption oracle is the crux of the whole chain, and Laflamme doesn’t undersell how convenient it made everything.
“This single AES-128 key unlocks both the BLE protocol and the WebRTC signaling channels.” continues the report.
Once an attacker has obtained it, they can authenticate to the robot’s Bluetooth handshake and unlock WiFi configuration commands that were previously locked behind that same key. From there, an oversized WiFi password triggers a fallback code path in Unitree’s own configuration script that inserts attacker-controlled text directly into a config file without escaping it, letting the attacker force the robot to join a hotspot they control, no physical access needed at any point.
Going from “the robot connects to my Wi-Fi” to a full root shell required a buffer overflow in the G1’s Bluetooth server, and this is where the research gets particularly impressive. The server used a 500-byte buffer without proper bounds checking, allowing Laflamme to overwrite nearby memory with a carefully crafted 1,050-byte payload. He used that payload to create a fake cleanup structure that the program later interpreted as a legitimate function pointer, causing it to execute an attacker-controlled command with root privileges.
There was one more obstacle: randomized memory addresses. To make the exploit work reliably, Laflamme first needed to discover where the vulnerable program was loaded in memory. He solved that by turning the first vulnerability into an information leak and using the result to make the second exploit work. In other words, one bug effectively helped unlock the other.
The wormability is what turns this from an interesting security flaw into a much more serious operational risk. Once an attacker compromises one G1, that robot can use the same attack against other G1 robots within Bluetooth range, without requiring additional discovery or configuration.
Laflamme tested the technique on just two robots in the same room, so the real-world reach of a chain reaction remains unclear. In a warehouse, laboratory, or campus where dozens of these robots operate close to each other, however, the possibility of one compromised machine spreading the attack to others is difficult to ignore.
Unitree’s response gets genuine credit in the writeup, and it’s worth noting given how often vendor disclosure stories go badly. The company patched the cloud ownership-check flaw within about two months of the report, paid out a combined $5,000 bounty across both chains, and worked through verification quickly enough that Laflamme calls the collaboration close to ideal.
“July 1-6 August, 2026 — Unitree implemented an account-to-robot cloud binding ownership check before returning the AES-128 key. Patching the “cloud-oracle” vulnerability discovered back in May.“August 6, 2026 — a $5,000 USD bounty was paid out, $4,000 for the BLE RCE and $1,000 for the chat_go RCE.”
The BLE pairing and buffer overflow issues themselves, notably, sit deeper in the firmware and represent a harder, slower fix than a simple cloud-side ownership check.
None of this required exotic tools or some cutting-edge attack technique. That is probably the detail that should get the most attention from anyone who still sees robot security as a niche problem.
This was a $20,000 humanoid robot, the kind increasingly used in research labs and universities and likely to appear in more workplaces, compromised with a decompiled Android app, a firmware encryption scheme that researchers had already broken years ago, and a familiar class of buffer overflow that predates humanoid robots by decades.
If your organization has a G1 sitting in a lab, lobby, or workspace, checking its patch status should be a priority. A 90-pound robot losing its collision-detection capabilities is not the kind of security incident you want to discover the hard way.
“You could use the G1 to spy on people through audio and video, make it say obscene shit in public, swap out or backdoor the ResNet onboard AI models, tamper with perception and movement logic, disable collision detection and other safety checks (it weighs ~90lbs having that run into a kid, a wall, or even step on your toe will do some serious damage).” concludes the researcher. “They also cost a lot! I’d be pissed off if someone hacked into my G1, took control of it, and walked it off my factory/campus.”
Hoje, pode parecer que há uma câmera nos observando em cada canto: na campainha com vídeo na entrada, na webcam de um notebook no escritório de casa, na babá eletrônica IP no quarto das crianças, na smart TV com câmera e microfone no quarto, no robô aspirador com câmera de navegação… Até um alimentador inteligente para gatos pode estar espionando você! E qualquer uma dessas câmeras pode facilmente se transformar em uma ferramenta de extorsão, chantagem ou curiosidade mal-intencionada.
Neste artigo, analisamos exatamente de onde vem a ameaça e apresentamos cinco regras que podem reduzir bastante as chances de você virar a estrela do show de um voyeur.
Casos reais de vigilância
Pornografia de hotel por assinatura
Infelizmente, relatos sobre câmeras em miniatura encontradas em quartos de hotel e apartamentos alugados se tornaram quase rotineiros. Tecnicamente, elas pertencem a uma categoria diferente de dispositivos: “câmeras espiãs” disfarçadas de tomadas, detectores de fumaça ou despertadores. Mais adiante, explicaremos como detectá-las.
Os criminosos não se limitam a publicar imagens de câmeras espiãs. Também fazem transmissões ao vivo. O acesso a vídeos íntimos, naturalmente, não é gratuito. Em algumas regiões, criminosos montaram uma infraestrutura em torno das câmeras espiãs: uns instalam os dispositivos, outros processam as imagens e outros vendem o acesso pela dark web ou por aplicativos de mensagens. Em geral, as vítimas descobrem que havia uma câmera oculta no quarto do hotel por acaso, depois de se depararem com vídeos de si mesmas em sites pornográficos.
Caça a motoristas
Outro vetor de ataque comum é a invasão de câmeras veiculares conectadas à Internet. Esses dispositivos são alvos atraentes para invasores: a segurança é fraca, e as imagens mostram claramente placas de veículos, sinalização viária e endereços em prédios. As gravações também contêm metadados detalhados, incluindo datas exatas, coordenadas de GPS e outras informações.
Isso pode permitir que criminosos identifiquem as rotas habituais da vítima, descubram onde o carro fica estacionado ou até escutem conversas com passageiros. As informações podem ser suficientes para uma vigilância completa, o roubo do veículo ou até chantagem, caso a câmera grave conversas e imagens dentro do carro.
Stalking
Nem todas as imagens roubadas de câmeras resultam de ataques de cibercriminosos profissionais em busca de lucro. Às vezes, stalkers invadem webcams para espionar pessoas específicas, muitas vezes alguém que conhecem. Por exemplo, em 2025 veio à tona um caso em que um homem vinha espionando colegas de trabalho havia anos por meio das câmeras IP instaladas nas casas delas. Todas as vítimas eram mulheres, e não faziam ideia de que estavam sendo observadas.
Em outro caso, um homem monitorava a ex-esposa e a filha por meio de um sistema de interfone e câmeras IP. Ele nem tentava esconder que espionava a própria família e chegou a enviar à filha capturas de tela da webcam. Como consequência, ela acabou tendo que se mudar.
Por que isso acontece?
Negligância com regras básicas de cibersegurança
Esse é provavelmente o principal motivo pelo qual câmeras IP são invadidas. A maioria dos usuários não altera senhas padrão de roteadores, dispositivos inteligentes e aplicativos conectados a eles. Essas senhas são praticamente de conhecimento público. Muitas vezes, são usadas combinações simples, como “admin/admin” ou “root/1234”, que todos conhecem ou que podem ser adivinhadas em segundos sem um algoritmo sofisticado. Foi exatamente isso que permitiu aos invasores comprometer 120.000 câmeras na Coreia do Sul.
Fabricantes de câmeras irresponsáveis
Embora os fabricantes garantam que os dados das câmeras sejam armazenados apenas localmente, na prática, costuma ser bem diferente. Por exemplo, em 2022, pesquisadores descobriram que uma linha popular de câmeras de vídeo enviava capturas de imagem ao servidor do fabricante sempre que uma pessoa aparecia no quadro. E mais: o acesso remoto às gravações de todas as câmeras ficava disponível por URLs previsíveis, o que tornava essas URLs relativamente fáceis de reproduzir ou adivinhar.
Ao mesmo tempo, a empresa afirmava que suas câmeras usavam criptografia de ponta a ponta, armazenavam gravações apenas no dispositivo e não enviavam dados a servidores externos. Por sinal, a suposta “criptografia segura” era implementada com uma chave fixa idêntica para todos os usuários. E a própria chave podia ser facilmente encontrada no código-fonte publicado pelo fabricante.
Em resumo, se um dispositivo tem lente e Wi-Fi, considere a possibilidade de que, mais cedo ou mais tarde, uma falha grave de segurança seja descoberta nele.
Mecanismos de busca para dispositivos vulneráveis estão se tornando cada vez mais populares
Para acessar uma câmera, muitas vezes o invasor só precisa saber o endereço IP dela e testar algumas senhas comuns. Existem mecanismos de busca que indexam dispositivos e suas portas abertas, em vez de sites: webcams, roteadores, controladores industriais, equipamentos médicos e muito mais.
Se uma câmera IP não exigir nome de usuário e senha ou estiver “protegida” pelas credenciais padrão “admin/admin”, ela pode ser facilmente descoberta e adicionada ao banco de dados de um serviço de OSINT. Jornalistas e pesquisadores já usaram esses serviços para encontrar câmeras acessíveis ao público em quartos de crianças, escritórios, salas cirúrgicas de hospitais, bancos e lojas.
Então, o que fazer?
O que é possível fazer em casa ou em um pequeno escritório sem uma equipe dedicada à segurança? Estas cinco recomendações simples podem ajudar.
1. Pesquise sobre o fabricante
Ao escolher um modelo de câmera IP, verifique se câmeras daquele fabricante já foram invadidas. Por exemplo, pesquise por “invasão de câmera IP nome do fabricante“. Depois, acesse a seção de Suporte do fabricante e confira a data da atualização de firmware mais recente para o modelo considerado e para modelos mais antigos.
Se o firmware não tiver sido atualizado nos últimos seis meses ou se as atualizações forem lançadas de forma irregular, considere escolher outro modelo. A maioria das câmeras usa versões embarcadas especializadas do Linux, e mais de 2.300 vulnerabilidades foram registradas no kernel do Linux nos primeiros seis meses de 2026. Sem atualizações regulares de firmware, é quase certo que, mais cedo ou mais tarde, as câmeras de um fabricante apresentarão uma falha de segurança.
Considere modelos de grandes fabricantes para evitar uma coleção inteira de vulnerabilidades com praticamente nenhuma chance de que elas sejam corrigidas. Câmeras baratas de empresas pouco conhecidas, com recursos limitados e proteção fraca, podem acabar saindo caras.
2. Desative recursos desnecessários
Quanto menos serviços de armazenamento em nuvem de terceiros estiverem envolvidos no sistema de vigilância, melhor. Ao escolher uma câmera, procure um slot para cartão microSD ou compatibilidade com dispositivo de armazenamento conectado à rede (NAS), para que todas as gravações possam ser armazenadas localmente.
O ideal é que a câmera consiga funcionar na rede local, sem transmitir dados para a nuvem ou para os servidores do fabricante, com visualização pela LAN ou por meio de uma conexão segura com a rede doméstica ou do escritório.
Depois de comprar uma câmera IP, revise as configurações, geralmente disponíveis no aplicativo do fabricante ou pela interface Web da câmera, e desative tudo o que não for necessário.
Preste atenção aos recursos relacionados ao reconhecimento de pessoas, inteligência artificial, permissões do sistema, descoberta de outros dispositivos na rede e armazenamento em nuvem. Se você não usa um recurso, pode desativá-lo.
Nas configurações de rede, confirme que o UPnP (Universal Plug and Play) está desativado ou sequer disponível como opção. O UPnP pode permitir que a câmera se torne acessível a outros dispositivos pela Internet.
Verifique se o acesso P2P à webcam está desativado ou indisponível, para que a câmera não se conecte a servidores externos nem possa ser acessada pela Internet sem seu controle direto.
Crie o hábito de verificar quem está conectado à sua conta e quem ainda tem acesso às suas gravações. Se você concedeu acesso à webcam a um amigo para ficar de olho no seu cachorro durante uma viagem, lembre-se de revogar depois os acessos ou encerrar as sessões desnecessárias. E, se você terminou um relacionamento recentemente, verifique com atenção especial se a pessoa com quem se relacionava ainda tem acesso. Para saber mais, consulte Higiene digital após uma separação: o que verificar e desativar.
3. Altere as configurações padrão
As senhas padrão de fábrica são conhecidas pelos invasores há anos. Se você ainda não alterou o nome de usuário e a senha do roteador ou da câmera IP, um invasor pode conseguir acesso em questão de segundos.
Substitua o nome de usuário e a senha padrão de fábrica do roteador por credenciais exclusivas e longas. Isso pode ser feito pela interface Web do roteador. Explicamos abaixo como acessá-la. Para gerar e armazenar senhas fortes e exclusivas, recomendamos usar Kaspersky Password Manager.
Atualize o firmware do roteador e da câmera IP para as versões mais recentes, mesmo que você tenha acabado de comprar os dispositivos, e crie o hábito de fazer atualizações regularmente. Campanhas de invasão de câmeras IP em grande escala muitas vezes exploram vulnerabilidades conhecidas há muito tempo, que só podem ser corrigidas com a instalação de atualizações.
4. Coloque todas as câmeras e dispositivos inteligentes em uma rede Wi-Fi separada
Recomendamos segmentar o Wi-Fi doméstico em sub-redes separadas. Você provavelmente já viu essa configuração em cafés, que costumam ter uma rede Wi-Fi para a equipe e outra para visitantes.
O ideal é colocar todas as câmeras IP e outros dispositivos de casa inteligente em uma rede Wi-Fi separada e totalmente isolada de notebooks, celulares e outros dispositivos de trabalho. Melhor ainda, as câmeras IP devem ficar isoladas de todos os demais dispositivos em uma rede Wi-Fi dedicada exclusivamente a elas.
A maioria dos roteadores modernos permite criar pelo menos duas redes Wi-Fi, uma rede principal e uma rede para visitantes. Modelos mais avançados podem oferecer ainda mais opções. Assim, mesmo que a câmera seja invadida, o invasor não conseguirá chegar aos outros dispositivos nem acessar arquivos confidenciais.
Como abrir a interface Web do roteador
Digite o endereço IP do roteador na barra de endereços do navegador. Normalmente, ele está impresso em uma etiqueta na parte inferior do roteador. Entre os endereços IP comuns para roteadores domésticos estão 168.0.1, 192.168.1.1 e 10.0.0.1.
Na página que abrir, faça login. A maioria dos roteadores tem um nome de usuário e uma senha padrão, que normalmente também estão impressos na mesma etiqueta. Alguns roteadores podem solicitar a criação de um nome de usuário e de uma senha. Recomendamos escolher uma senha forte e armazená-la no Kaspersky Password Manager. As senhas padrão de fábrica são conhecidas pelos invasores há muito tempo e, se você não alterar a senha do roteador, eles podem entrar facilmente na sua rede doméstica.
Abra as configurações e procure seções relacionadas à segmentação da rede Wi-Fi ou à criação de sub-redes ou redes para visitantes.
Para obter instruções detalhadas de configuração, consulte o manual do roteador ou a seção de suporte do site do fabricante. Para mais dicas sobre como proteger sua casa inteligente, consulte nossa postagem Como proteger sua casa smart.
5. Aprenda a detectar câmeras ocultas, em casa e durante uma viagem
Nosso último conjunto de recomendações não trata da configuração da câmera em si, mas de boas práticas de segurança.
Crie o hábito de verificar a lista de clientes do roteador. Se você vir um dispositivo desconhecido com um nome estranho ou endereço MAC, investigue o que é e por que está conectado à sua rede doméstica. Nossa solução de segurança inclui um componente dedicado do Smart Home Monitor. Esse recurso pode alertar quando um novo dispositivo se conecta à rede doméstica com ou sem fio, fornecer recomendações simples para melhorar a segurança da rede e identificar senhas fracas do roteador e criptografia insegura.
Durante viagens, recomendamos verificar se há dispositivos de gravação ocultos em quartos de hotel e imóveis alugados:
inspecione locais que ofereçam um bom campo de visão do ambiente, como grades de ventilação, detectores de fumaça, tomadas e objetos decorativos;
no escuro, use o smartphone como detector óptico improvisado: ligue a lanterna e a câmera, examine lentamente o ambiente e procure reflexos característicos produzidos por lentes de câmeras;
use a câmera frontal para procurar fontes de luz infravermelha invisíveis ao olho humano. Isso pode ajudar a identificar a iluminação IR usada para “visão noturna”.
Discover how Microsoft expands its enterprise AI branding by renaming the Microsoft 365 Roadmap to the AI at Work Roadmap to track Copilot and AI agents.
Evooo1Bot is a Mirai-based Linux botnet that hijacks routers and IoT devices for DDoS attacks, credential theft and criminal proxy services.
Fortinet’s FortiGuard Labs disclosed Evooo1Bot in mid-August, a previously undocumented Linux botnet that’s been active since July 2026. The bot borrows Mirai‘s DDoS engine but adds encrypted command-and-control communications, an SSH brute-force scanner, a credential sniffer, and a SOCKS5 proxy module on top.
“FortiGuard Labs has been tracking a previously undocumented Linux botnet family, which we have named Evooo1Bot. The name derives from the hardcoded string “evooo1” found in every binary.” reads the report published by Fortinet. “While the malware reuses the DDoS engine from the publicly leaked Mirai source code, it extends the original framework with numerous capabilities, including encrypted C2 communications, an SSH brute-force scanner, a SOCKS relay module, a credential sniffer, and an integrated exploit arsenal targeting multiple known vulnerabilities.”
The botnet targets 18 known CVEs, some of them dating back to 2007, including:
The bot communicates exclusively over port 443, which is intentional: the traffic blends into expected HTTPS flows at the network perimeter. After gaining initial access through one of its exploit modules or via brute-forced SSH credentials, the bot runs a loader script that clears Bash history to erase evidence of the intrusion before pulling the architecture-appropriate binary from an external server.
The breadth suggests the operators are scanning opportunistically for anything unpatched rather than targeting specific organizations.
“This capability significantly increases the value of an infected host to attackers. The victim’s IP address can be used to disguise malicious traffic, bypass geographic restrictions, or provide access to internal networks through an already compromised machine.” continues the report. “In larger botnets, the same functionality could also be used to build a distributed proxy infrastructure, enabling anonymous traffic forwarding or monetization through residential and enterprise proxy services.”
Evooo1Bot stands out because of its proxy module. A network of compromised routers, cameras, and firewalls acting as SOCKS5 relays is a valuable commodity; operators can use it themselves to obscure attack traffic, or sell access to other criminals looking for residential or enterprise IP addresses that don’t trigger geographic blocks.
“Unlike typical botnet commands that focus on downloading payloads or launching attacks, the !socks module turns an infected host into a SOCKS5 proxy that the operator can use as a network relay. It supports two operating modes. In direct mode, it opens a SOCKS5 listener on the infected host on the default TCP port 1080 and waits for incoming client connections. The implementation first attempts to create a dual-stack IPv6 listener and falls back to IPv4 if that fails. Each accepted client is then passed to the session handler for proxying.” continues the report. “The botnet also implements a reverse relay mode. Instead of exposing a listening port, the bot establishes an outbound encrypted connection to an operator-specified relay server. This persistent control channel listens for commands such as RELAY_NEW:<session_id>, which indicate that a new proxy session should be created.”
After establishing C2 contact, the bot accepts commands covering the full post-compromise toolkit: file upload and download, interactive shell access, persistence installation, binary updates, HTTP Basic Auth and Cookie header interception, DDoS over DNS, TCP, and UDP, and the HTTP exploit dispatcher.
The credential sniffer intercepts authentication headers in transit, so any HTTP Basic Auth credentials passing through an infected device can be captured without any additional effort from the operator. If you’re still running devices with unpatched firmware from the CVE list above, or if any of your edge hardware is using default SSH credentials, Evooo1Bot is already scanning for you.
“Beyond traditional botnet functionality, it features encrypted C2 communications, multiple layers of string obfuscation using AES-256-CTR, ChaCha20, and XOR-based key derivation, as well as a 28-command remote administration interface.” concludes the report. “These capabilities place Evooo1Bot well beyond the technical baseline of conventional Mirai-derived malware.”
The Dysphoria botnet has expanded into a major Internet of Things threat, with a new Shadowserver Special Report identifying approximately 296,000 compromised devices. The campaign targets exposed routers, gateways, IP cameras and other embedded Linux systems, converting poorly secured equipment into a distributed platform for DDoS attacks and increasingly, residential proxy and relay operations. Dysphoria’s […]
Attackers breached a Polish CHP plant through a Fortinet device and private APN, reaching PLCs and disrupting turbine and water treatment systems.
Poland’s CERT has described a second attack on the country’s energy sector, and this one matters for a simple reason: it shows how an ordinary-looking network design can turn into a route into OT. The target was a smaller combined heat and power plant feeding heat to around 50,000 residents, and the attackers used a private APN as the path in, something CERT says it saw for the first time in this incident.
The report says the intrusion began at a wind farm, where the attackers hit a Fortinet VPN and firewall device exposed to the internet.
From there they found a Teltonika cellular router, used SSH to build a tunnel, reached the private APN managed by the distribution system operator, and then moved toward the plant’s OT network.
“On 29 December 2025, coordinated attacks targeted the energy sector in Poland, including 30 renewable energy facilities and a large combined heat and power (CHP) plant. These attacks were described in detail in the report published on 30 January 2026*. At the same time, another incident occurred at a smaller CHP plant supplying heat to 50,000 residents.” reads the report published by Poland’s CERT. “The analysis of this incident took more than three months to complete, which is why it was not included in the initial report. To the best of our knowledge, the attack vector used in this case has not previously been observed in any known incidents.”
Once inside, the attackers found a Wago PLC at the CHP plant and used SSH access on that controller to reach the operational network. After roughly a week of reconnaissance, they connected to Siemens PLCs, switched them to stop mode, and set a password that blocked operators from changing the controllers’ state and control logic.
That is where the physical impact started. The steam turbine and water treatment system shut down, the cogeneration process broke, and the plant lost service continuity for a while, though staff restored the affected systems quickly enough to avoid a heat or electricity outage.
“The attacker then damaged the WAGO controller that had been used as a gateway into the network by corrupting its partition table, preventing it from being read by the device. In an attempt to restore the controller, the affected entity performed a factory reset; however, this did not repair the partition table and the device remained unable to boot.” continues the report. “No valuable logs could be recovered from the device during the investigation.”
The report also shows how messy real intrusions get once the attacker is inside the control environment. Moxa serial device servers and Moxa network switches were reconfigured to block legitimate access, ABB and Schneider Electric variable frequency drives were touched as well, and some connection attempts failed or were only partially successful.
“An important aspect of this architecture is that DSOs require all communication between the DSO’s ICT network and the RTU to take place over a serial protocol, in this case DNP3.0. At the compromised facility, a Teltonika RUTX50 router was used, and the DSO’s requirements were met. However, no requirements had been defined regarding the handling of the cellular router’s administrative interface.” continues the report. “As a result, the router was configured with two physical interfaces: a serial link connected to the RTU and a second interface, Ethernet, connected to a VLAN managed by the central firewall that had been compromised by the attacker.”
That is the uncomfortable part. The attackers did not need some exotic zero-day chain to do damage. They used a reachable edge device, a private APN that was already in the path, weak or exposed access points, and enough patience to move from reconnaissance to disruption.
CERT notes that the attackers damaged some devices while trying to cover their tracks, and in the WAGO case the controller could not be brought back by a simple reset. The agency also says this kind of private APN setup is not rare, which is exactly why the finding matters beyond Poland.
“As maintenance work was being carried out at the facility, the entity initially assumed that the process interruption had been caused by an error made by the contractor’s engineers and reported the event for informational purposes only.” continues the report. “However, due to its awareness of other similar events, CERT Polska initiated incident handling under the assumption that the event may have resulted from a cyberattack. Further analysis confirmed this hypothesis.”
The practical lesson is not subtle. Private APNs, edge routers and OT gateways need the same discipline as any other exposed infrastructure, because once an attacker can pivot from a field device into control systems, the difference between “maintenance” and “incident” gets very thin.
“Based on our analysis of the malware and associated TTPs, we attribute the attack to the Russia-aligned Sandworm APT with medium confidence due to a strong overlap with numerous previous Sandworm wiper activity we analyzed,” said ESET researchers. “We’re not aware of any successful disruption occurring as a result of this attack,” ESET researchers said.
ESET researchers uncovered DynoWiper, a destructive wiper malware used in an attempted cyberattack against Poland’s energy sector on December 29, 2025. While no successful disruption has been confirmed, the malware’s architecture shows clear destructive intent. ESET attributes the operation with medium confidence to the Russia-aligned Sandworm APT group, citing strong overlaps in tactics, techniques, and behavior with previous Sandworm-linked wiper attacks analyzed by the team.
The attempted attack occurred during peak winter demand and coincided with the 10-year anniversary of Sandworm’s 2015 cyberattack on Ukraine’s power grid, the first malware-induced blackout that left around 230,000 people without electricity. ESET tracks the DynoWiper malware as Win32/KillFiles.NMO. Subscribers to ESET’s private Threat Intelligence APT reports have already received further technical details and indicators of compromise to aid rapid detection and incident response. The cybersecurity firm also shared an associated IoC hash for defensive use.
Cisco Talos found hackers using simple authorization claims to bypass AI guardrails, build DDoS attack tools, steal credentials and access live camera services.
Microsoft’s Project Perception brings coordinated AI agents into security operations, raising new questions about permissions, oversight, accuracy, and deployment risk.
After attacks hit 30+ Minnesota water systems, CISA urged utilities to remove internet-exposed PLCs and strengthen OT security.
Between Sunday and Monday, July 26 and 27, a coordinated cyberattack hit operational technology (OT) systems at more than 30 community water utilities across the state, according to Minnesota IT Services (MNIT).
“A coordinated cyberattack targeted operational technology at more than 30 Minnesota community water systems on July 26 and 27. Minnesota IT Services (MNIT) immediately activated the state’s cybersecurity incident response capabilities.” reads the statement published by MNIT. “MNIT continues to collaborate with federal, state, local, Tribal, and private-sector partners to investigate the attack, support affected communities, and strengthen the security of Minnesota’s critical infrastructure.”
The agency activated its statewide incident response the moment it learned of the attack, and it’s still active as of this week.
Four cities went public with details: Braham, Maple Plain, Plymouth, and South St. Paul. Braham took the hardest hit of the group; the town of about 1,700 people had its water plant knocked offline entirely after attackers disabled the computerized controls running its well and treatment systems.
State and federal investigators are working to determine attribution, but the timing is hard to ignore: the attacks came four days after CISA updated its advisory on Iranian-affiliated actors targeting programmable logic controllers across US critical infrastructure. No formal attribution has been made, but Tenable researchers assess the operational pattern is consistent with CyberAv3ngers, an Iran-linked group formally tied to the IRGC.
“Federal and state officials have not publicly attributed the Minnesota attacks to any specific actor. However, the operational pattern is consistent with the CyberAv3ngers threat ecosystem, a state-directed group the U.S. government has formally attributed to Iran’s Islamic Revolutionary Guard Corps Cyber-Electronic Command.” reported Tenable.
CISA now warns of a surge in attacks targeting internet-exposed PLCs at water utilities. Attackers have changed passwords and IP addresses to lock out operators, causing boil water notices and forcing some facilities to switch to manual operations. The US agency urges organizations to remove publicly accessible PLCs and other OT systems from the internet immediately.
“CISA is currently observing a significant increase in cyber threat actors targeting programmable logic controllers (PLCs) in the Water and Wastewater Systems (WWS) Sector. CISA urges critical infrastructure owners, operators, and integrators to remove publicly exposed PLCs and other operational technology (OT) from the internet as soon as possible.” reads CISA’s alert. “Threat actors targeting exposed PLCs have modified passwords to lock out operators and disconnected the PLCs by changing their IP addresses. This activity has resulted in boil water notices and sustained manual operations.”
The FBI confirmed that utility companies in at least seven states have reported PLC-related incidents. The attacks aren’t sophisticated in the traditional sense, after remotely accessing internet-facing devices, the actors changed IP addresses and passwords, resulting in loss of monitoring and control functionality. That’s it. Default or weak credentials on internet-exposed hardware, and suddenly operators are locked out of their own systems.
CVE-2021-22681 is a critical Rockwell Automation vulnerability (CVSS 9.8) that remained unexploited for years because industrial control systems are difficult to patch without disrupting essential services. Since March 2026, however, Iranian-affiliated threat actors have actively exploited the flaw, prompting CISA to add it to its Known Exploited Vulnerabilities catalog. Rockwell has confirmed that no security patch is available, making network isolation and other compensating controls essential.
That last sentence is worth sitting with. A CVSS 9.8 vulnerability in controllers that run public water infrastructure, no patch, actively exploited. The compensating control is network isolation, which is exactly what CISA is now urgently requesting.
“These threat actors are targeting water entities of all sizes. Even water organizations with mature cybersecurity processes should validate their external connections, as this targeting activity includes cellular modems installed by operators, vendors, or system integrators that may not be documented or included in routine attack surface scans.” continues the alert. “OT assets exposed to the internet have an increased risk of defacement, configuration changes, operational disruptions, and, in severe cases, physical damage.”
A July 2026 update to CISA’s advisory found that attacks exploiting internet-exposed PLCs have expanded beyond Rockwell Automation to include Schneider Electric and Siemens devices. The advisory also documents attackers stealing PLC project files for the first time and adds new guidance to detect tampering with reusable code modules embedded in industrial control programs.
Exfiltrating project files means the attacker is taking the engineering logic of the plant, the actual programmed behavior of the industrial process, and studying it offline. That’s reconnaissance for a more targeted future attack, not just disruption for its own sake.
The Minnesota attacks resulted in boil water notices and sustained manual operations at affected utilities. Drinking water remained safe in most cases, and contingency procedures held. But the affected cities include Maple Plain, Braham, South St. Paul, and Plymouthm not isolated rural facilities, but communities of real scale. CyberAv3ngers is known for targeting small water and municipal facilities, which experts believe are among the lowest-hanging fruit in US critical infrastructure. Many small and rural facilities lack dedicated cybersecurity resources. That’s the point. These attacks aren’t about technical sophistication. They’re about finding the organizations with the least capacity to defend themselves and demonstrating that the capability to disrupt public services exists and can be exercised.
CISA’s alert specifically notes that even mature organizations should validate their external connections, because the targeting includes cellular modems installed by operators, vendors, or system integrators that may not appear in routine network scans. A modem installed by a contractor for remote access and never documented in the asset inventory is still an attack surface. The practical checklist is short: get PLCs off the internet, segment OT networks from IT networks, change default credentials, and audit every remote access path, including the ones you didn’t authorize.
“CISA recommends organizations implement the following mitigations:
Disconnect the PLC from the internet. Remote access for operational purposes should go through a VPN or gateway device, not directly to the PLC.
Enable password protection and change default passwords.
Allowlist IPs to only allow remote access from known engineering laptops or other critical OT assets.
After disconnecting PLCs from the internet, operators should ensure they have a known clean backup of the PLC image in case they are locked out by a modified password.” concludes CISA. Note: Owners, operators, and integrators of Rockwell Automation MicroLogix 1400 PLCs should see Rockwell Automation’s IMPORTANT NOTICE: Restoring Access to a MicroLogix 1400 Controller When the Password Is Unknown for guidance addressing this activity.”
Coordinated OT cyberattacks hit 30+ Minnesota water utilities, briefly disrupting one plant. Backup procedures prevented major water service impacts.
Minnesota just had its own live-fire lesson in what happens when someone targets water utilities at scale. Between Sunday and Monday, July 26 and 27, a coordinated cyberattack hit operational technology (OT) systems at more than 30 community water utilities across the state, according to Minnesota IT Services (MNIT).
“A coordinated cyberattack targeted operational technology at more than 30 Minnesota community water systems on July 26 and 27. Minnesota IT Services (MNIT) immediately activated the state’s cybersecurity incident response capabilities.” reads the statement published by MNIT. “MNIT continues to collaborate with federal, state, local, Tribal, and private-sector partners to investigate the attack, support affected communities, and strengthen the security of Minnesota’s critical infrastructure.”
The agency activated its statewide incident response the moment it learned of the attack, and it’s still active as of this week.
Four cities went public with details: Braham, Maple Plain, Plymouth, and South St. Paul. Braham took the hardest hit of the group; the town of about 1,700 people had its water plant knocked offline entirely after attackers disabled the computerized controls running its well and treatment systems.
Crews had the plant back up within roughly two hours, filtering and treating water normally again.
Plymouth got off comparatively easy. The city’s IT team disconnected the cellular-connected equipment at two of its water towers as a precaution, and the issue stayed contained to that cellular-connected equipment, according to the city’s own statement. Most of the affected utilities across the state kept running through backup procedures without ever going offline.
Minnesota IT Services is continuing to investigate the coordinated cyberattack against the state’s water utilities while helping affected operators contain the incident, assess the damage, and restore impacted systems. The agency is sharing threat intelligence and response guidance in coordination with state and federal partners, including the FBI, CISA, the EPA, the Minnesota Department of Health, and local utilities. Authorities are still analyzing the scope of the attack, but there is currently no indication that drinking water safety has been compromised, and no Minnesota community has been advised to change its water use.
MNIT’s chief information security officer, John Israel, put out a statement framing the response as proof the state’s investment in cybersecurity partnerships actually paid off.
“Cyberattacks against critical infrastructure require a coordinated, whole-of-government response,” said Israel. “MNIT is working side by side with our partners to share intelligence, support affected communities, and help utilities restore operations safely while strengthening defenses against future attacks. This incident demonstrates why Minnesota has invested in strong cybersecurity capabilities and partnerships. Our response worked as intended, enabling agencies at every level of government to rapidly coordinate, contain the incident, and help prevent more serious impacts to critical services.”
Partners include a mix of state, local, federal, and Tribal entities now working the case together. That list includes Minnesota’s Department of Health, its Bureau of Criminal Apprehension fusion center, CISA, the EPA, and the FBI, all working alongside the affected utilities directly.
The attack has yet to be attributed, and the investigation is still ongoing. The timing lines up close enough with something else to raise an eyebrow, though: four days earlier, CISA and six other federal agencies had updated a warning about Iranian-affiliated hackers exploiting internet-facing programmable logic controllers made by Rockwell Automation, Schneider Electric, and Siemens, across US water and energy infrastructure broadly. Nobody’s confirmed a link between that advisory and what happened in Minnesota, and it would be premature to draw a straight line between the two just because they landed in the same week.
Minnesota’s health department says it hasn’t seen any city ask residents to change how they use their tap water, which is the detail worth holding onto here. Contingency plans, backup procedures, and manual overrides did what they’re supposed to do at a majority of the affected utilities: nothing dramatic happened, because the boring stuff worked. Sometimes the best cybersecurity story is the one where nobody outside the IT department even noticed.
Ruflo fixed a CVSS 10.0 flaw that exposed its MCP bridge without any authentication, putting AI provider keys, stored chats and persistent agent memory at risk.
Fortinet has found a new TrickBot variant hiding commands in DNS traffic and using scheduled tasks and added modules to maintain access on infected Windows PCs.
TuxBot v3, an AI-built IoT botnet for 17 architectures, shipped with LLM bugs and safety disclaimers the developer never removed.
Palo Alto Networks’ Unit 42 identified a previously undocumented modular IoT botnet framework called TuxBot v3 Evolution, and it comes with an unusual detail: the developer used a large language model to write significant portions of the code, and the LLM’s safety disclaimer ended up in every compiled binary. Sixty-one C source files each carry an identical header warning that “this code is for educational and authorized security research only.” The developer shipped it without removing a single line.
“The malware authors leveraged an LLM to assist in their code development, yielding mixed results. While the AI complied with their request to generate botnet code, it included a safety disclaimer that the developer failed to remove before shipping.” reads the Unit 42’s report. “Although the LLM clearly aided in constructing the botnet, several functions in the analyzed samples failed to work correctly. While a manual code review could have easily resolved these errors, the authors neglected this step. “
The LLM’s raw chain-of-thought reasoning was also left verbatim in source file comments throughout the codebase, including gems like “// I created them so I should know?” and “// Wait, where is the command?”, an LLM narrating its own confusion to itself, preserved for posterity in a working botnet.
The framework is substantial. It cross-compiles a C-based bot agent for 17 architectures, including ARM, MIPS, PowerPC, RISC-V, and x86_64. It includes a Go-based command-and-control server with a DDoS-for-hire panel, a custom exploit virtual machine, Docker-based test infrastructure, and an automated build system.
The bot brute-forces Telnet access with 1,496 credential pairs and contains exploit code targeting more than 30 IoT device families.
“The TuxBot framework we recovered and analyzed is approximately 70% functional. The core infection flow (scanning, credential brute-forcing, persistence, primary C2 setup and DDoS execution) works.” continues the report. “The Telnet, SSH, HTTP and Android Debug Bridge (ADB) scanners all operate correctly. Furthermore, with its 1,496 credential pairs, the Telnet scanner remains a viable infection vector.”
The parts that don’t work trace almost entirely to bugs introduced by the LLM.
The most consequential LLM failure is in the C2 authentication module. The developer asked for Argon2id password hashing. The LLM couldn’t import the right library, fell back to SHA256 loops, but kept the Argon2id comments, constants, and output format, including a return value formatted as “$argon2id$v=19$…” that contains nothing of the sort.
“Despite its use of PKBDF2 for password hashing, the LLM formats the output to look like Argon2id anyway:
The LLM hallucinated that it implemented Argon2id but actually fell back to SHA256 loops while keeping the Argon2id comments, constants and output format.” states the report.
There’s also an XOR key mismatch that breaks the IRC fallback channel, four exploit payloads, and HTTP polling. The custom exploit VM never fires because the Go compiler writes the file magic as “TUXE” while the C runtime expects “EXPL.” Sixteen exploit functions are compiled as dead code that never get called. Seventy-eight attack vectors mapped to six handlers, all HTTP application-layer methods silently redirected to TCP SYN floods.
“During our research, we were able to fix these issues with a handful of LLM-assisted prompts. We reconstructed the correct table entries and fixed the IRC C2 channel with a few targeted prompts.” states Palo Alto Networks. “Given that the operator already has the source code and has been actively deploying binaries (six new samples in April 2026), we can reasonably assume that a version with some or all of these fixes already exists in the wild.”
Unit 42 found six new samples in internal telemetry in April 2026, compiled with GCC 14.2.0 production builds across multiple architectures. The C2 infrastructure at 209.182.237[.]133 has been active since at least March 2026.
The developer’s Git log leaked their workstation hostname pointing to an Iranian-hosted machine, and the parent domain digikalas[.]online resolves to Iran’s Arvan Cloud CDN. Shared dropper infrastructure at 185.10.68[.]127 on FlokiNET links TuxBot to Kaitori v3.9 and AISURU tooling, separate codebases that all converge on the same bulletproof host, placing the operator within the Keksec ecosystem.
The development timeline starts in January 2025 with the developer cloning the open-source MHDDoS DDoS toolkit from GitHub, with 254 automated benchmark reports generated in early January 2026 and the first VirusTotal submission appearing January 20. Somebody spent a year building this. The AI helped with most of it, introduced most of the bugs, and nobody caught them because the generated code reads cleanly on the surface.
“Shared infrastructure with Kaitori v3.9 and AISURU tooling places the TuxBot operator within the Keksec ecosystem. This group is known for running multiple IoT botnet variants in parallel. TuxBot appears to be another variant in that portfolio. It’s one that aims to go beyond the usual Mirai fork with its encrypted C2, its DGA and a modular exploit system, even though that system does not work yet in the version we recovered.” continues the report. “The broken features can be fixed. We demonstrated this during our analysis by reconstructing the IRC C2 channel and decrypting the mismatched table entries with a few targeted LLM prompts. “
Binarly found six U-Boot flaws, including two that enable code execution during boot image verification, impacting 50+ releases.
Binarly’s research team has found six vulnerabilities in U-Boot, the open-source bootloader that runs on home routers, smart cameras, server management controllers, and a large portion of the embedded hardware that powers the internet.
All six are triggered during the verification of a FIT image, which is the format U-Boot uses to package and validate the software it loads. Two of the vulnerabilities can lead to arbitrary code execution. Four can trigger a denial-of-service condition. The affected code has been present in U-Boot since version v2013.07, meaning over 50 stable releases are potentially impacted.
U-Boot matters because it runs before the operating system, before any security software, before almost everything.
“Because U-Boot is one of the first components to run during the boot process, it is highly security-sensitive: severe flaws at this stage can be used by a potential attacker to compromise everything that is loaded and executed afterwards.” reads the report published by Binarly. “Recognising the critical nature of this component, the Binarly Research team decided to examine the core functionality of the U-Boot project more closely. This research revealed six distinct vulnerabilities, ranging in impact from denial of service (DoS) to arbitrary code execution during the verification of an untrusted image.”
Malicious code planted at this stage is extremely difficult to detect and nearly impossible to remove without physically reflashing the device’s storage chip.
FIT stands for Flattened Image Tree. It’s the standard format U-Boot uses to bundle kernels, device trees, ramdisks, and firmware into a single package that also contains cryptographic hashes and signatures. FIT Signature Verification is the step that checks those signatures before deciding whether the image is trusted enough to execute.
Binarly focused on this component specifically because breaking it would undermine the entire concept of verified boot, which is the mechanism meant to ensure only trusted code runs at each stage of startup. Several vulnerabilities in this same code path have been disclosed before, including CVE-2020-10648 and CVE-2021-27097, and Binarly found reason to believe there were more.
BRLY-2026-037 stems from a function called fdt_find_regions, which walks the device tree structure inside a FIT image and builds a list of regions to hash. It calls fdt_get_name to retrieve node names during this walk. The problem is that fdt_get_name can return NULL in certain cases, specifically when processing an old-format FIT image whose version is below 0x10 and the node name contains no slash character. The code never checks for this and proceeds to use the NULL return value directly.
For the root node, this causes an immediate crash. For child nodes, execution reaches a strcpy call that copies from the NULL pointer into a stack buffer allocated in the parent function. On most modern systems the zero page is unmapped and this also crashes. But on embedded devices it’s common for the zero page to be mapped, which means an attacker who can also control what sits at memory address 0x0 can turn this NULL dereference into a stack-based buffer overflow and from there into code execution. Binarly confirmed the vulnerability triggers in U-Boot’s sandbox build.
BRLY-2026-038 builds on the same root cause but exploits a different consequence. When fdt_get_name fails, it writes a negative error code into the len argument. The surrounding code then uses len to advance a pointer through a stack buffer, but it never checks whether len is negative. A negative value moves the pointer backwards instead of forwards, producing a stack buffer underflow.
“This underflow primitive enables us to move the end pointer backwards by 10 bytes (FDT_ERR_BADSTRUCTURE error code is -11, and *end++ = ‘/’ is executed on each iteration) for each malformed FDT entry until it reaches the return address of fdt_find_regions, which is possible because the target buffer lives in the stack frame of the parent fit_config_check_sig function.” continues the report. “From there, carefully chosen valid nodes supply the names that overwrite the return address of fdt_find_regions, along with the payload bytes.”
Binarly demonstrated this working on a QEMU ARM build, printing a custom message to the console during U-Boot execution. The fix for both vulnerabilities is a single null check on the return value of fdt_get_name.
BRLY-2026-039 involves the size of the strings region in a FIT image. During signature verification, the code reads this size from a property in the image called “hashed-strings” without checking whether the declared size actually fits within the image boundaries. An attacker sets this value to 0xFFFFFFFF and the hashing routine attempts to read nearly four gigabytes of data, quickly running past the end of the image into unmapped memory and crashing the bootloader.
BRLY-2026-040 is another null pointer dereference in fdt_find_regions, this time from a different code path. When the function encounters a property tag in the device tree, it calls fdt_get_property_by_offset to read the property header.
For FIT images with a version below 0x10, this function returns NULL without attempting to parse the property. The code immediately dereferences the returned pointer without checking it, crashing U-Boot on any platform where the zero page is unmapped.
BRLY-2026-041 involves FIT images that store payload data externally, referenced by position and size values embedded in the image.
“All three properties – data-position, data-offset and data-size – are fully controlled by the attacker, and none of them are checked against the actual size of the FIT image. The data pointer and size produced here then travel through the same hashing path as it was described for BRLY-2026-039 above.” continues the report. “This provides attackers with two straightforward methods of crashing the bootloader: pointing the data region outside the mapped memory through data-position/data-offset, or requesting an enormous data-size. For example, with a provided size of 0xFFFFFFFF the hashing routine reads far beyond the image bounds.”
An attacker can crash the bootloader either by pointing the data region outside mapped memory or by declaring a data size of 0xFFFFFFFF.
BRLY-2026-042 is triggered even earlier than the others, before signature verification starts, during FIT format validation. A function called fdt_check_no_at walks the entire FIT image tree recursively to look for node names containing an @ symbol, a character that can cause logical problems in libfdt’s node matching. The recursion stops only when it runs out of subnodes, and the depth limit inherited from the preceding check allows trees nested up to INT_MAX levels deep. Adding one more nesting level to a FIT image costs 12 bytes. Each recursive call consumes at least 16 bytes of stack space. The math isn’t complicated.
“This ensures that the stack will be exhausted regardless of the size of the device’s RAM.” states Binarly.
The fix adds a depth counter that rejects images once nesting exceeds 32 levels.
A reasonable assumption is that exploiting a bootloader vulnerability requires physical access to the hardware. Binarly pushes back on this directly, pointing to earlier research on Supermicro BMC firmware as a counter-example. Server BMCs expose remote administration interfaces, and Binarly has previously shown that an attacker with access to those interfaces can bypass firmware update validation and force the legitimate update mechanism to flash a malicious image. The same principle applies broadly: any device that accepts firmware updates over a network, even one that performs validation, may be reachable without anyone touching the hardware.
All six patches have been accepted upstream and are available in U-Boot’s master branch. Binarly prepared the patches themselves after the initial disclosure encountered some friction with the project’s maintainers. Organizations running devices built on U-Boot, particularly server hardware with BMC controllers, should apply the patches through their vendor’s firmware update process as soon as updates become available. Proof-of-concept FIT images and reproduction steps for all six vulnerabilities are included in Binarly’s individual advisories.
“The PoC FIT image generation script and the steps required to reproduce the issue are fully detailed in the advisory for this vulnerability.” concludes the report. “The fix adds a depth counter to fdt_check_no_at, rejecting the image once the nesting reaches FDT_MAX_DEPTH, which is defined in boot/fdt_region.c and is equal to 32.”
Google announced that it helped take down NetNut, a 2 million strong malicious residential proxy network. The incident highlights the growing risks posed by residential proxy networks that quietly conscript consumer devices into services used by cybercriminals and nation-state actors alike.
runZero found 7 flaws in FatFs, a filesystem used in IoT and embedded devices. Bugs can cause memory corruption, crashes, or data leaks via crafted storage.
Cybersecurity firm runZero has disclosed seven vulnerabilities in FatFs, a compact open-source library that lets embedded devices read and write FAT and exFAT formatted storage, the same formats used on USB drives and SD cards. The severity ratings run from CVSS Medium to High.
This project revisited a 2017 security audit of the FatFs driver, where manual testing and fuzzing had only found minor issues. In March 2026, the team repeated the analysis using Visual Studio Code and GitHub Copilot in auto mode with simple prompts and no custom tooling. The results were unexpected: issues previously missed became easy to find. The AI helped generate fuzzing inputs automatically and even validated exploitability across different embedded environments, turning what was once a manual, time-consuming process into something far more automated and effective.
The flaws impact multiple platforms, including Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr RTOS, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and SWUpdate. Downstream from those platforms sit consumer IoT devices, industrial controllers, drones, hardware crypto wallets, and more.
Most of the devices that bundle FatFs don’t have the memory protections that phones and desktops take for granted, such as ASLR.
“For the vendors who build on these platforms it’s simple: any physical access leads to a jailbreak, especially given the lack of address space layout randomization (ASLR) and memory protection. For everyone else, there are numerous devices where brief physical access by the general public should not lead to a full compromise.” states the report. “For example, security cameras with SDCard storage, voting machines with USB file readers, ATMs, and pretty much anything else that has a screen that you expect people to touch.”
A security camera with an SD card slot, a voting machine with a USB reader, an ATM, a public kiosk: none of these should hand over full control to whoever plugs in a drive, but on unpatched hardware running vulnerable FatFs code, that’s the exposure.
All seven bugs share the same trigger: a device reads a crafted storage volume or firmware image, FatFs mishandles the malformed data, and bad things follow. Two of the CVEs, CVE-2026-6682 and CVE-2026-6683, are also implicated in over-the-air firmware update processes, which extends the attack surface beyond physical media entirely.
Below are the details of the seven flaws:
CVE-2026-6682 (CVSS 7.6, High) – FAT32 integer overflow in mount_volume() can produce attacker-controlled file-size metadata. This may be trusted as a read length by downstream code, leading to heap or stack corruption and possible code execution.
CVE-2026-6687 (CVSS 7.6, High) – exFAT label-length stack overflow in f_getlabel() allows oversized writes into label buffers when the label field is not properly capped. This can lead to straightforward memory corruption in embedded firmware.
CVE-2026-6688 (CVSS 7.6, High) – long filename overflow in downstream callers where fno.fname exceeds fixed-size buffers. This often breaks in wrapper code using strcpy or sprintf and depends heavily on how firmware handles filenames.
CVE-2026-6685 (CVSS 6.1, Medium) – unsigned subtraction wrap in dirty-cache handling on fragmented volumes can corrupt memory or cause silent data corruption, which is especially dangerous in logging and control systems.
CVE-2026-6683 (CVSS 4.6, Medium) – exFAT divide-by-zero in sync/write paths triggered by crafted media leads to reliable crashes and potential device bricking in firmware update scenarios.
CVE-2026-6686 (CVSS 4.6, Medium) – uninitialized cluster exposure when extending files past EOF can leak stale data from previously deleted files, creating an information disclosure risk.
CVE-2026-6684 (CVSS 4.6, Medium) – GPT partition scan loop in pre-R0.16 versions can trigger unbounded scanning, causing boot-time denial of service. It is fixed upstream, but still present in older embedded deployments.
FatFs is maintained by one developer. runZero made repeated attempts to reach the maintainer and involved JPCERT/CC in the coordination process. Neither effort produced a response. For six of the seven CVEs, there is no upstream patch. The only fix available is the GPT scan issue addressed in R0.16, and even that requires downstream vendors to update their vendored copies.
That last detail is the crux of the problem.
“FatFs is one of those components. It’s compact, useful, and copied everywhere. That’s great for shipping products quickly, but less great when memory-safety issues show up in parser-adjacent code that happily ingests untrusted media.” continues the report. “This kind of component is even more challenging to deal with, from a disclosure-and-fix perspective, in that nearly everyone ends up making local, vendored modifications. So, an upstream patch must be validated pretty carefully before incorporating.”
Even when a fix does eventually appear, every vendor that’s diverged from upstream has to validate it against their own modifications before shipping it. The precedent from PixieFail, nine vulnerabilities in EDK II network boot code disclosed in 2024, is that this process takes years, not weeks, and FatFs has a weaker fix pipeline because there’s no responsive upstream at all.
runZero published proof-of-concept disk images, a test harness, and a working QEMU-based exploit demonstration in a companion repository at github.com/runZeroInc/vulns-2026-fatfs-chance. No attacks using these bugs had been reported as of the July 1 disclosure date.
What to do if you ship or run affected products?
If you build firmware that touches FAT or exFAT storage, the immediate work is: find your vendored copy of FatFs, audit the wrapper code around it, examine how your code handles filenames and file sizes, and plan for patching. Pay particular attention to any code that copies fno.fname into a fixed-size buffer. If you run affected devices rather than build them, treat physical ports and firmware update channels as attack surface: restrict who can plug in media, monitor for vendor security advisories, and apply firmware updates when vendors release them.
The broader point runZero makes is worth sitting with. Keeping these bugs quiet in 2026 would accomplish nothing, because the tooling that found them is now widely available. The right response to that reality is disclosure, coordination where possible, and publication to give defenders a head start.
Five Eyes agencies warned that AI could speed cyberattacks within months, raising new risks around prompt injection, phishing, and enterprise AI tools.
Researchers at the University of Toronto have built a worm that thinks for itself. Using free off-the-shelf AI models it works out how to break into each new computer it encounters, and hijacks the powerful ones to host its own AI brain. And then the researchers discovered their creation had quietly removed the list of machines it wasn't supposed to attack.
Meanwhile, Meta's shiny new AI customer support agent has been cheerfully helping hackers help themselves to other people's Instagram accounts. Just keep asking, politely but firmly, to have a password reset sent to a different email address - and the AI will eventually agree.
All this and more in episode 471 of the "Smashing Security" podcast with cybersecurity expert and keynote speaker Graham Cluley, and special guest James Ball.
Entrar
1400 Controller When the Password Is Unknown
