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.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Robot)

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.

Nem é preciso procurar muito para encontrar exemplos. Coreia do Sul, final de 2025: não foi apenas um dispositivo, mas 120.000 câmeras IP foram invadidas. Os criminosos vendiam, por assinatura em chats privados, imagens íntimas e gravações do cotidiano das pessoas.

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.

Ao comprar outros dispositivos para casa inteligente, avalie se você realmente precisa de uma câmera integrada à smart TV, caixa de som inteligente, robô aspirador ou alimentador automático para animais. Cada um desses dispositivos amplia a superfície de ataque em potencial.

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.
• Se a câmera estiver vinculada a uma conta em um site ou aplicativo, use também uma senha forte e ative a autenticação de dois fatores ou a autenticação por chave de acesso sempre que possível. Os tokens de 2FA e as chaves de acesso também podem ser armazenados no Kaspersky Password Manager e sincronizados em todos os seus dispositivos.
• 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

1. 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.
2. 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.
3. 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”.

Para conhecer outros métodos práticos de encontrar câmeras espiãs, consulte nosso post Quatro maneiras de encontrar câmeras espiãs.

O que mais você deve saber sobre vigilância e câmeras:

• Violação em webcams ao estilo coreano: 120 mil câmeras IP hackeadas
• Perigos na segurança das câmeras IP
• Segurança ao usar o Airbnb: dicas para viagem tranquila
• Lumos: Sistema de detecção de dispositivos IoT
• Como encontrar câmeras escondidas com o seu smartphone

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.

Related Posts:

• uBlock Origin v1.74.0 Is the Final Version for Chrome Before Google's Delisting
• Google Launches Gemini 3.5 Transcribe With Sub-Second Streaming Latency
• NVIDIA Hugging Face Acquisition Rumors Surface

The post Microsoft Unveils the AI at Work Roadmap appeared first on Daily CyberSecurity.

FortiGuard Labs discovered the Evooo1Bot Linux botnet. Read our Evooo1Bot Linux botnet analysis to learn how this malware turns devices into proxy nodes.

Related Posts:

• AmnesiaStealer macOS Infostealer Hacks Apple Devices
• GEEKOM Mini PC Driver Downloads Found Bundled With Backdoor Since 2024
• Abyssos Modular RAT: Zscaler ThreatLabz Analysis

The post Evooo1Bot Linux Botnet Employs SOCKS Relays and DDoS appeared first on Daily CyberSecurity.

GitHub's postmortem reveals a service mesh overload triggered a retry storm across its infrastructure, while a Copilot bug sent authentication traffic to 10x normal levels.

Related Posts:

• Telegram Applies for .gram Domain to Give Every User Their Own TLD
• OpenAI Astra Security Model: Pausing Development for Safety
• GeForce NOW Now Fully Supports Firefox, Delivering 1440p 120fps Streaming

The post GitHub Outage Postmortem: Retry Storm and Copilot Auth Overload Explained appeared first on Daily CyberSecurity.

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:

• CVE-2007-3010: Alcatel OmniPCX Enterprise Remote Code Execution Vulnerability
• CVE-2016-6277: NETGEAR Multiple Routers Remote Code Execution Vulnerability
• CVE-2018-14558: Tenda AC7, AC9, and AC10 Routers Command Injection Vulnerability
• CVE-2019-14931: Mitsubishi Electric Europe B.V. ME-RTU devices and INEA ME-RTU devices remote Command Injection vulnerability
• CVE-2020-10987: Tenda AC1900 Router AC15 Model Remote Code Execution Vulnerability
• CVE-2021-46422: Telesquare SDT-CW3B1 Command Injection vulnerability
• CVE-2022-37055: D-Link Routers Buffer Overflow Vulnerability
• CVE-2024-29269, Telesquare TLR-2005KSH Command Injection Vulnerability
• CVE-2025-10123, D-Link DIR-823X Command Injection Vulnerability
• CVE-2025-55583: D-Link DIR-868L B1 router Command Injection Vulnerability

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.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Evooo1Bot botnet)

Microsoft merges consumer and enterprise Copilot into a unified Super App. Discover the upcoming changes to features, limits, and enterprise security.

Related Posts:

• Apple Proposes New App Store Link-Out Fees of 5% to 15% in Epic Legal Battle
• Mozilla Rotates Firefox and Thunderbird Linux GPG Signing Key After Private Repo Exposure
• Google Gemini Hits 1 Billion Users - Now the Fastest-Growing App in Google History

The post Microsoft Copilot Super App: A Unified Platform Vision appeared first on Daily CyberSecurity.

PoC exploit code is public for CVE-2026-43723, an Apple mediaremoted flaw that lets an app gain root privileges. CVSS 7.8. Patch now.

Related Posts:

• Roundcube Patches RCE and SSRF Flaws in 1.6.18 and 1.7.3
• CVE-2026-15826: User Profile Builder Bug Under Active Attack, Grants Full Admin Takeover (CVSS 9.8)
• CVE-2025-41771: SQL Injection Flaw Hits Phoenix Contact PLCnext

The post CVE-2026-43723: Apple mediaremoted Flaw Lets Apps Gain Root Privileges, PoC Exploit Code Publicly Disclosed appeared first on Daily CyberSecurity.

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 […]

The post Dysphoria Hijacks Routers, Gateways and IP Cameras to Build Massive IoT Botnet appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

PoC exploit code is public for CVE-2026-61515, an unauthenticated command injection in Puwell IP Camera firmware. CVSS 9.3. Details inside.

Related Posts:

• Zero-Click File Drop Hits Xiaomi ShareMe: PoC Public
• CVE-2026-65640: WordPress 7.0.4 Fixes Remote Code Execution
• MariaDB Low-Privilege Remote Code Execution Chain: Full Details and PoC Exploit Code Publicly Disclosed

The post CVE-2026-61515: Unauthenticated Command Injection in Puwell IP Cameras, PoC Exploit Code Publicly Disclosed appeared first on Daily CyberSecurity.

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.

The original report is here: CERT Polska Energy Sector Incident Follow-up Report 2025.

In early 2026, ESET linked a late-2025 cyberattack on Poland’s energy system to the Russia-linked Sandworm APT.

“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.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Poland)

Astaroth's new WhatsApp spambot auto-messages every victim contact in Brazil using a hidden browser, quietly turning each victim into a malware distributor.

Related Posts:

• SMOKE#SCREEN Campaign Abuses ScreenConnect RMM for Stealthy Remote Access
• Canadian Man Pleads Guilty to Cloud Hacking Extortion Scheme That Hit 165 Companies
• DarkSword iOS Exploit Spreads Across 100+ Sites and Drops GHOSTBLADE

The post Astaroth WhatsApp Spambot Turns Brazil Victims Into Unwitting Malware Distributors appeared first on Daily CyberSecurity.

CVE-2026-66747: a Zbtlink router backdoor named ENDLESSDOORS gives unauthenticated remote code execution as root. No fix exists. CVSS 9.8.

Related Posts:

• Metabase SQL Injection Zero-Day (CVSS 10) Exploited
• Multiple ClamAV Flaws Let Remote Attackers Cause DoS
• CryptoJS Randomness Vulnerability Drains Crypto Wallets

The post CVE-2026-66747: Zbtlink Router Backdoor ENDLESSDOORS Enables Unauthenticated Remote Code Execution as Root appeared first on Daily CyberSecurity.

Microsoft’s Project Perception brings coordinated AI agents into security operations, raising new questions about permissions, oversight, accuracy, and deployment risk.

The post Microsoft Project Perception Enters Public Preview: What Security Teams Should Know appeared first on TechRepublic.

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.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, CISA)

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.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, water utilities)

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:

return fmt.Sprintf("$argon2id$v=19$m=%d,t=%d,p=%d$%s$%s", ...)

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. “

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, TuxBot v3)