Ring’s new TAKE encryption limits video-key retention while keeping cloud AI features, Ring Verify, and optional end-to-end encryption in play.
The post Ring’s New TAKE Encryption Deletes Video Keys Without Giving Up AI Features appeared first on TechRepublic.
Cybercriminals used to hacking home routers and security cameras have found another Internet-connected device to add to their botnets: your car, according to research published by Kaspersky Lab.
The post Malware Takes the Wheel: Kaspersky Finds First Car Head Unit-Specific Attack appeared first on The Security Ledger with Paul F. Roberts.
A researcher discovered an exposed directory containing the tools of an attacker who compromised more than 14,000 Dahua cameras between June 17 and July 22, 2026, mainly in Ukraine and Russia. Hunt.io reconstructed the operation, named Operation CameraSwarm, from the leaked files and telemetry.
The find started with a mistake. On 23 July, Hunt.io’s AttackCapture system crawled a server at 154.86[.]119.60 and pulled down 2,616 files across 234 subdirectories, 407 MB in total, from an HTTP directory the operator had left wide open. That single slip handed researchers the operator’s scanning engine, exploit chains, exfiltration bot, and a Windows stealer staged on the same box.
“This is the second Dahua-related camera compromise operation we’ve traced back to an exposed operator directory in as many weeks. Where last week’s investigation centered on a Russian-speaking operator running a purpose-built platform against 58 cameras, this one is a different scale entirely.” reads the report published by Hunt.io.
The brute-force engine alone reached over 12,300 unique addresses. A separate authentication-bypass chain, built around two 2021 Dahua vulnerabilities, planted a persistent backdoor account on 1,923 cameras, an account stored independently of the admin password that survives both a password change and, on most firmware, a factory reset. A third path skipped IP addresses entirely and reached 283 cameras purely by serial number, through Dahua’s own cloud relay.
That third path is the part worth sitting with. Most of those cameras were exposed online without authentication.
Dahua’s cloud relay lets any app reach a camera sitting behind NAT using nothing but its serial number, and authentication to that relay runs on credentials baked identically into every Dahua client ever shipped. The operator’s own code logs the result of probing this channel at scale: 89.4 percent of live serials returned an open, no-authentication channel. Nine out of ten cameras, reachable by anyone who could guess or harvest a serial number.
“The device never authenticates the connecting party. It authenticates the session, via a token the cloud issued before the device was contacted. Obtaining that token requires only the fixed SDK credentials shared by every legitimate Dahua application.” continues the report. “The only real barrier to reaching any camera through this path is knowing its serial number, precisely what the operator’s harvesting pipeline exists to produce at scale.”
Getting from the tunnel session to full admin access still requires valid credentials or an authentication bypass. However, the attacker’s own logs suggest that most exposed cameras did not need this final step.
There are also two important details about the reported CVEs. The tool links its persistent backdoor technique to CVE-2024-39943, but that CVE actually refers to a different command-injection flaw in Rejetto’s HTTP File Server. The technique is valid, but the CVE reference is wrong. Likewise, the relay abuse is not CVE-2025-31702, which Dahua describes as a narrower authenticated privilege-escalation flaw. Incorrect CVE references can send defenders looking for the wrong fix.
Hunt.io also found something that had nothing to do with cameras: a UPX-packed Windows binary, tagged as SalatStealer, staged on the same server alongside a PowerShell script that disables Windows Defender five different ways, including a Group Policy key built to survive reboots and Defender updates. The researchers treat it as a separate, unrelated capability riding along on shared infrastructure, not part of the camera campaign proper.
What stands out across the whole toolkit is that none of it was built from scratch. The brute-force engine, the bypass chain, the relay tooling, the recovery-code generator: each traces to a different public repository, credited (sometimes accurately) to at least six other developers. The operator assembled, patched, and rewrote, layering Russian comments over Spanish code in one component recovered in three separate stages of the same rewrite.
“The same toolkit also recovers stored device passwords outright, through a routine that derives its decryption key entirely from values the attacker already holds, device class prefix and serial number, so no device secret is needed. A residual Spanish comment in that code confirms it came from the same upstream source as the original brute-forcer.” states the report.a
The offline recovery-code generator is arguably the most consequential piece precisely because it doesn’t need a compromised device at all. Given a live serial number, it derives a code entirely offline that unlocks Dahua’s cloud-level account-recovery flow, no current credentials required. Removing a backdoor account doesn’t touch this. Only Dahua changing how the code is derived would.
For anyone running Dahua gear, or the OEM-rebranded lines built on the same backend (Amcrest, Lorex, Annke, Swann, among others), the practical checklist is short: check for a p2pwn account and remove it, disable P2P on any device where it isn’t actually needed, confirm firmware is patched against the 2021 bypass pair, and rotate every credential that camera ever held, since the exfiltration bot grabbed those too. None of that fixes the recovery-code problem. That one sits with the vendor.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, newsletter)
IT threat evolution in Q2 2026. Non-mobile statistics
IT threat evolution in Q2 2026. Mobile statistics
The statistics in this report are based on detection verdicts returned by Kaspersky products unless otherwise stated. The information was provided by Kaspersky users who consented to sharing statistical data.
In Q2 2026:
Microsoft has dismantled an illicit malware-signing service used by ransomware operators. Microsoft’s Digital Crimes Unit has shut down a malware-signing-as-a-service (MSaaS) operation run by the threat group Fox Tempest. The illicit service abused the Microsoft Artifact Signing platform to generate digital signature certificates for malicious software. Malware signed by these certificates was observed in campaigns conducted by such ransomware groups as Rhysida, Akira, INC, Qilin, and BlackByte. The service was also leveraged by operators of the Oyster loader as well as the Lumma and Vidar infostealers. To disrupt the operation, Microsoft seized the domain used by the MSaaS platform, revoked all associated certificates, and disabled the related accounts. Additionally, the company filed a lawsuit against Fox Tempest.
CISA has confirmed that a Windows vulnerability known as BlueHammer is actively being exploited in ransomware attacks. On April 22, the agency updated its Known Exploited Vulnerabilities (KEV) catalog to note the ongoing ransomware exploitation of CVE-2026-33825. The local privilege escalation flaw in Microsoft Defender was originally disclosed earlier in April. Although Microsoft released a fix on April 14, unpatched systems remain vulnerable. CISA did not disclose further details or attribute the attacks to specific threat groups.
Check Point has linked zero-day exploitation of CVE-2026-50751 to the Qilin ransomware group. The critical vulnerability affects Check Point Remote Access VPN and Mobile Access. Attackers began exploiting the flaw as a zero-day on May 7, with activity spiking sharply in early June. While several dozen organizations have been targeted, at least one incident has been definitively tied to Qilin. Check Point also disclosed a related certificate validation flaw (CVE-2026-50752) that affects site-to-site VPN connections relying on the legacy IKEv1 key exchange protocol.
Researchers assess with high confidence that the PayoutsKing group is leveraging the legitimate QEMU emulator to deploy hidden, Alpine Linux-based virtual machines on compromised hosts. Because security solutions often lack visibility inside virtualized environments, the threat actors use this technique to evade detection. Inside the VM image, the operators deploy various tools — such as credential theft software — and configure the virtual machine as a backdoor managed via a reverse SSH tunnel to their command-and-control infrastructure. While the technique is not new, and we’ve detailed it before, it remains relatively rare in ransomware attacks.
This section highlights the most prolific ransomware gangs by number of victims added to each group’s DLS. Qilin reclaimed the top spot (accounting for 14.57% of total listings) after placing second last quarter. It is followed by the Akira ransomware (7.80%) and the DragonForce RaaS group (6.88%).
Number of each group’s victims according to its DLS as a percentage of all groups’ victims published on all the DLSs under review during the reporting period (download)
In Q2, Kaspersky solutions detected four new ransomware families and 2538 new modifications. This signals a continued stabilization following spikes seen in Q1 and Q4 of last year.
Number of new ransomware modifications, Q2 2025 — Q2 2026 (download)
Our solutions protected a total of 71,860 unique users from ransomware during Q2. Ransomware activity peaked in April, with 31,206 targeted users recorded during that month.
Number of unique users attacked by ransomware Trojans, Q2 2026 (download)
| Country/territory* | %** | |
| 1 | South Korea | 0.87 |
| 2 | Pakistan | 0.76 |
| 3 | China | 0.71 |
| 4 | Libya | 0.49 |
| 5 | Tajikistan | 0.46 |
| 6 | Turkmenistan | 0.38 |
| 7 | Cameroon | 0.38 |
| 8 | Indonesia | 0.36 |
| 9 | Bangladesh | 0.36 |
| 10 | Mozambique | 0.34 |
* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country/territory.
| Name | Verdict | %* | |
| 1 | (generic verdict) | Trojan-Ransom.Win32.Gen | 28.02 |
| 2 | WannaCry | Trojan-Ransom.Win32.Wanna | 7.14 |
| 3 | (generic verdict) | Trojan-Ransom.Win32.Crypren | 6.27 |
| 4 | (generic verdict) | Trojan-Ransom.Win32.Agent | 4.89 |
| 5 | (generic verdict) | Trojan-Ransom.Win32.Encoder | 4.65 |
| 6 | (generic verdict) | Trojan-Ransom.Python.Agent | 3.07 |
| 7 | (generic verdict) | Trojan-Ransom.Win32.Crypmod | 2.70 |
| 8 | (generic verdict) | Trojan-Ransom.MSIL.Agent | 2.45 |
| 9 | PolyRansom/VirLock | Virus.Win32.PolyRansom / Trojan-Ransom.Win32.PolyRansom | 2.31 |
| 10 | (generic verdict) | Trojan-Ransom.Win32.Phny | 2.12 |
* Unique Kaspersky users attacked by the specific ransomware Trojan family as a percentage of all unique users attacked by this type of threat.
In Q2 2026, Kaspersky solutions detected 6067 new miner variants, almost twice the number for the previous reporting period.
Number of new miner modifications, Q2 2026 (download)
In Q2, we detected attacks using miner programs on the computers of 213,003 unique Kaspersky users worldwide.
Number of unique users attacked by miners, Q2 2026 (download)
| Country/territory* | %** | |
| 1 | Mali | 1.56 |
| 2 | Senegal | 1.54 |
| 3 | Tanzania | 1.32 |
| 4 | Panama | 1.04 |
| 5 | Bangladesh | 1.03 |
| 6 | Ethiopia | 0.87 |
| 7 | Costa Rica | 0.67 |
| 8 | Bolivia | 0.67 |
| 9 | Côte d’Ivoire | 0.65 |
| 10 | Kazakhstan | 0.62 |
* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country/territory.
In April, Aikido researchers reported a new attack by the GlassWorm stealer, which was distributed via malicious IDE extensions on the Open VSX Registry. The payload operated by installing a secondary malicious extension across all installed IDE environments on the host machine. Ultimately, this second-stage implant exfiltrated crypto wallet data, environment variables, and other secrets. It also installed a RAT on the infected device.
In May, Socket researchers uncovered a supply chain compromise involving the popular npm package art-template. As a result of the breach, the weaponized package injected the Coruna exploit kit into web applications it was used to build. Coruna targets iOS devices.
In June, Palo Alto Networks’ Unit 42 discovered FlutterShell, a new backdoor family that targets macOS devices. Developed with the Flutter framework, the malware leverages the WebView engine to load web pages that contain malicious JavaScript. On the client side, the backdoor registers bridge functions invoked by the loaded JavaScript that allow threat actors to execute arbitrary payloads on the victim’s device. Notably, the malicious applications successfully passed Apple notarization. Although the specific samples analyzed functioned primarily as adware, the underlying architecture permits the delivery of far more sophisticated malicious payloads.
* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky security solutions for macOS (download)
* Data for the previous quarter may differ slightly from previously published data due to some verdicts being retrospectively revised.
Detections of PasivRobber spyware continued their downward trend. Meanwhile, adware and traffic-routing utilities (categorized as NetTool) rose to the top of the rankings. Additionally, Q2 saw a noticeable spike in detections for the DirtyCow exploit frequently leveraged for iPhone jailbreaking.
| Country/territory | %* Q1 2026 | %* Q2 2026 |
| Brazil | 1.13 | 1.13 |
| China | 1.04 | 1.28 |
| Hong Kong | 0.92 | 0.49 |
| Singapore | 0.85 | 0.19 |
| France | 0.62 | 1.18 |
| Mexico | 0.43 | 0.72 |
| India | 0.41 | 0.42 |
| Thailand | 0.40 | 0.24 |
| Germany | 0.33 | 0.71 |
| The Netherlands | 0.31 | 0.62 |
* Unique users who encountered threats to macOS as a percentage of all unique Kaspersky users in the country/territory.
This section presents statistics on attacks targeting Kaspersky IoT honeypots. The geographic data on attack sources is based on the IP addresses of attacking devices.
In Q2 2026, the breakdown of attacking devices and sessions that targeted Kaspersky honeypots by protocol was as follows:
Distribution of attacked services by number of unique IP addresses of attacking devices (download)
The share of SSH attacks saw a slight uptick compared to the previous quarter.
Distribution of cybercriminal sessions in Kaspersky honeypots (download)
Share of each threat delivered to an infected device as a result of a successful attack, out of the total number of threats delivered (download)
As is typically the case, Mirai botnet variants continue to dominate the IoT threat landscape. Activity of another prominent botnet, Prometei, also saw an increase.
the Netherlands, Germany, and The United States accounted for the highest proportions of SSH-based attacks during this period. While the top three countries remained the same as last quarter, their relative rankings shifted.
| Country/territory | Q1 2026 | Q2 2026 |
| The Netherlands | 17.57% | 21.18% |
| Germany | 10.34% | 16.73% |
| United States | 23.74% | 6.76% |
| Bulgaria | 1.10% | 5.50% |
| Sweden | 2.09% | 4.93% |
| Panama | 6.34% | 4.67% |
| Luxembourg | 0.16% | 4.62% |
| Romania | 5.82% | 4.06% |
| Vietnam | 3.50% | 3.91% |
| India | 6.05% | 2.78% |
The percentage of Telnet-based attacks originating from Pakistan continued to climb, knocking China down to second place.
| Country/territory | Q1 2026 | Q2 2026 |
| Pakistan | 27.31% | 36.60% |
| China | 39.54% | 35.62% |
| Russian Federation | 8.25% | 8.75% |
| India | 4.66% | 4.19% |
| Brazil | 3.30% | 3.34% |
| United States | 0.45% | 3.03% |
| Indonesia | 6.71% | 1.52% |
| Philippines | 0.36% | 0.95% |
| France | 0.17% | 0.84% |
| Thailand | 0.55% | 0.66% |
The statistics in this section are based on detection verdicts by Web Anti-Virus, which protects users when suspicious objects are downloaded from malicious or infected web pages. These malicious pages are purposefully created by cybercriminals. Websites that host user-generated content, such as message boards, as well as compromised legitimate sites, can become infected.
The following statistics show the distribution by country/territory of the sources of internet attacks blocked by Kaspersky products on user computers (web pages redirecting to exploits, sites containing exploits and other malware, botnet C&C centers, and so on). One or more web-based attacks could originate from each unique host.
To determine the geographic source of web attacks, we matched the domain name with the real IP address where the domain is hosted, then identified the geographic location of that IP address (GeoIP).
In Q2 2026, Kaspersky solutions blocked 399,312,961 attacks launched from internet resources worldwide. Web Anti-Virus was triggered by 52,850,592 unique URLs.
Web-based attacks by country/territory, Q1 2026 (download)
To assess the risk of malware infection via the internet for users’ computers in different countries and territories, we calculated the share of Kaspersky users in each location on whose computers Web Anti-Virus was triggered during the reporting period. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries and territories.
This ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out Web Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.
| Country/territory* | %** | |
| 1 | Bangladesh | 11.71 |
| 2 | India | 7.40 |
| 3 | Tajikistan | 7.13 |
| 4 | Venezuela | 7.05 |
| 5 | New Zealand | 6.58 |
| 6 | Vietnam | 6.34 |
| 7 | Taiwan | 6.28 |
| 8 | Belgium | 6.24 |
| 9 | France | 5.97 |
| 10 | Hungary | 5.92 |
| 11 | Nepal | 5.91 |
| 12 | Portugal | 5.86 |
| 13 | Italy | 5.77 |
| 14 | Costa Rica | 5.72 |
| 15 | Canada | 5.65 |
| 16 | Qatar | 5.61 |
| 17 | Dominican Republic | 5.52 |
| 18 | Palestine | 5.48 |
| 19 | Greece | 5.47 |
| 20 | UAE | 5.43 |
* Excluded are countries and territories with relatively few (under 10,000) Kaspersky product users.
** Unique users targeted by web-based Malware attacks as a percentage of all unique users of Kaspersky products in the country/territory.
On average during the quarter, 4.54% of users’ computers worldwide were subjected to at least one Malware web attack.
Statistics on local infections of user computers are an important indicator. They include objects that penetrated the target computer by infecting files or removable media, or initially made their way onto the computer in non-open form. Examples of the latter are programs in complex installers and encrypted files.
Data in this section is based on analyzing statistics produced by anti-virus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media. The statistics are based on detection verdicts from the On-Access Scan (OAS) and On-Demand Scan (ODS) modules of File Anti-Virus and include detections of malicious programs located on user computers or removable media connected to the computers, such as flash drives, camera memory cards, phones, or external hard drives.
In Q2 2026, our File Anti-Virus detected 16,986,351 malicious and potentially unwanted objects.
For each country and territory, we calculated the percentage of Kaspersky users whose computers had the File Anti-Virus triggered at least once during the reporting period. These statistics reflect the level of personal computer infection in different countries.
Note that this ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out File Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.
| Country/territory* | %** | |
| 1 | Turkmenistan | 46.38 |
| 2 | Cuba | 29.70 |
| 3 | Tajikistan | 28.46 |
| 4 | Afghanistan | 28.19 |
| 5 | Yemen | 27.85 |
| 6 | Burundi | 26.82 |
| 7 | Mozambique | 25.01 |
| 8 | Republic of the Congo | 24.88 |
| 9 | Syria | 23.17 |
| 10 | Uzbekistan | 22.49 |
| 11 | China | 21.92 |
| 12 | Nicaragua | 21.60 |
| 13 | Cameroon | 21.47 |
| 14 | Bangladesh | 20.43 |
| 15 | Democratic Republic of the Congo | 20.25 |
| 16 | Algeria | 19.78 |
| 17 | Uganda | 19.48 |
| 18 | Ethiopia | 18.57 |
| 19 | Tanzania | 18.54 |
| 20 | Mali | 18.53 |
* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users on whose computers Malware local threats were blocked, as a percentage of all unique users of Kaspersky products in the country/territory.
On average worldwide, Malware local threats were detected at least once on 10.93% of users’ computers during Q2.
Russia scored 10.78% in these rankings.
A quarter million commercial vehicles in India and sensitive data on tens of thousands of drivers were vulnerable to attacks because of flaws in widely used fleet management software maintained by a VE Commercial Vehicles, a joint venture between the Volvo Group and Eicher Motors, a security researcher has revealed.
The post Researcher: Flaw In Fleet Management Service Exposes 250k Commercial Vehicles To Attack appeared first on The Security Ledger with Paul F. Roberts.
Jacob Baines had a router on his desk that kept trying to call home, and it wasn’t supposed to. VulnCheck researchers found a backdoor baked into Zbtlink routers, and it’s not the kind of flaw you patch with an update. It’s a feature the vendor built in on purpose and shipped anyway.
Zbtlink is a Chinese manufacturer, Shenzhen Zhibotong Electronics, that builds routers and white-labels them under names like Wiflyer, ZBT, and ZBTWiFi, selling the same hardware on Amazon, Alibaba, and Shopify. The researchers bought a Zbtlink AX3000 off Alibaba and found something hiding in the process list disguised as a kernel thread.
Two processes named “kworker” were running as root with real memory footprints, sitting right next to the legitimate kernel threads that share the same name, betting nobody would look twice.
Those two processes are what Baines calls ENDLESSDOORS, built around a tiny open-source tool called rctl that nobody had touched since it was uploaded to GitHub back in 2015.
“A kworker is a Linux kernel thread, and it shows up in a process listing wrapped in brackets. The two unbracketed kworkers in the snippet above, from our AX3000, are not kernel threads.” reads the report published by VulnCheck. “They are ordinary userland processes running as root, with real memory footprints, named to disappear into a crowd of legitimate ones. They are an implant, a phone-home trojan horse. Our zero-day research team named this ENDLESSDOORS.”
The implant phones home to a hardcoded server, and once it connects, there’s essentially no security checking who’s on the other end. As Baines put it, “there is no handshake, no key exchange, no negotiation” before the router hands over control.
“When the implant reaches a server, it sends a fixed 39-byte hello: a 33-byte class label padded with nulls, then its LAN MAC address. That’s the whole registration. There is no client or server verification.
After that, anything the server sends is handed to popen() and executed as uid 0. There is no allow-list and no sandbox. One reserved string, rctlbash, tells the implant to open a second connection to port 7001, allocate a pseudo-terminal, spawn /bin/sh, and bridge it. That is a live interactive root shell.” continues the report. “The vocabulary of this protocol is two phrases: run this as root, and give me a root shell.”
That last part is the whole vulnerability in one sentence. Once connected, anything the command server sends gets executed as root through a basic system call, no allow-list, no sandbox, nothing filtering what commands are acceptable. One specific string even tells the router to open a second connection and hand back a live interactive root shell, essentially a remote login with no password required.
Because the router dials out instead of listening for connections, none of the usual firewall logic helps. A unit sitting behind three layers of corporate firewall is just as exposed as one sitting on the open internet, as long as it can reach the command server somehow. VulnCheck proved this wasn’t theoretical by writing their own tool that impersonated the command server, catching the router’s outbound connection and getting a root shell back in under two seconds.
The researchers pointed out that twenty different router models carry the same backdoor, all of them starting it automatically at boot through an init script named skworker. VulnCheck found the whole fleet dialing out to just four addresses total, hosted across Alibaba Cloud, Vultr, and a Chinese cloud provider, meaning whoever controls those servers controls every affected router in the world simultaneously.
The affected router dials the same tiny set of endpoints. The researchers noted that across all the impacted models it reduces to four primary and secondary endpoints:
| Role | Endpoint | Resolves to | Hosting |
|---|---|---|---|
| Primary | zbtctl.epplink[.]net | 47.100.190[.]96 | Alibaba Cloud, Shanghai |
| Primary | hardcoded IP | 47.107.224[.]89 | Alibaba Cloud, Shenzhen |
| Secondary | online-string.com | 45.32.81[.]152 | Vultr |
| Secondary | rbdg4nzqadui[.]wikaba[.]com | 43.248.136[.]125 | Jiangsu Dongyun Cloud |
VulnCheck skipped the usual courtesy of privately warning the vendor before going public, and explained exactly why. Coordinated disclosure assumes a vendor didn’t mean to ship the flaw, and that assumption didn’t hold here: this was a vendor-built component, started by the vendor’s own boot script, present across two dozen models and years of firmware releases. Warning the company that built it on purpose, in VulnCheck’s view, would only tip off whoever’s running that infrastructure.
Zbtlink said the backdoor was intended only for after-sales maintenance and not present in production devices. However, the company also removed firmware downloads and acknowledged unspecified firmware security vulnerabilities, raising further questions about its explanation.
“This feature is solely intended for after‑sales maintenance and serves no other purposes,” a company spokesman told The Register. “It is generally retained only on sample units to assist customers with software debugging and will not be included in mass‑production shipments.”
There’s no patch coming for any of this, so the fix isn’t waiting around, it’s treating every affected device as compromised by design. Check your model number against the list of twenty, not the brand printed on the case, since the same hardware gets relabeled under multiple names. If you find the backdoor, block the four known command servers at your firewall, and if the router handles anything that actually matters, replace it rather than trust a company that just got caught lying about what it shipped.
“There is no fixed firmware. Treat this as a device-trust problem, not a patching problem.” concludes the report.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Backdoor)
Federal agencies updated their cybersecurity advisory this week: Iran-linked actors are inside American water and energy control systems, and they’re not just looking around. They’re changing things.
The updated advisory from CISA, the FBI, NSA, and the Department of Energy says these actors are getting into programmable logic controllers, the small industrial computers that run pumps, valves, and safety alarms. Once inside, they can mess with what operators see on their screens. That’s how you get outages nobody saw coming.
“The authoring agencies urgently warn U.S. organizations of ongoing Iranian-affiliated cyber targeting of internet-connected operational technology (OT) devices, including programmable logic controllers (PLCs).” reads the advisory. “These actions disrupted PLCs across several U.S. critical infrastructure sectors through malicious project file interactions and manipulation of data on human machine interface (HMI) and supervisory control and data acquisition (SCADA) displays, resulting in operational disruption and financial loss.”
This isn’t new territory. Back in April, the same agencies flagged Iranian hackers going after Rockwell Automation controllers specifically. The updated advisory widens the net. Now Schneider Electric and Siemens equipment is on the list too.
US agencies have expanded guidance on detecting malicious code changes in PLCs after observing attacks targeting Rockwell Automation, Schneider Electric, Siemens, and other internet-exposed industrial controllers.
Attackers access exposed devices via OT ports (44818, 2222, 102, 502) and modems over SSH (port 22), then exfiltrate PLC project files using vendor tools such as Studio 5000, EcoStruxure Control Expert, and TIA Portal. They modify or delete project logic, including Add-On Instructions (AOIs), manipulate HMI and SCADA displays, and disable shutdown and alarm functions, allowing industrial systems to enter unsafe states without alerting operators.
Organizations should follow vendor security best practices, remove PLCs from direct internet access using secure gateways and firewalls, and monitor logs for indicators of compromise and suspicious traffic on OT ports such as 44818, 2222, 102, and 502. Rockwell users should set controllers to Run mode, while suspected victims should contact vendors and federal agencies.
The agencies say potentially any internet-exposed industrial control system could be a target. Here’s the part that should make plant operators lose some sleep. In one case, the hackers didn’t just peek at a system. They rewrote the controller’s programming logic to disable the processes meant to trigger shutdowns and alarms during dangerous conditions.
“At one U.S. victim, the FBI observed the APT actors download a malicious project file to a targeted PLC using configuration software. Analysis indicated the project file retained ladder logic for downstream function but added logic that overrode specific instruction sets responsible for maintaining safe operating parameters in the victim’s environment.
“Since at least March 2026, the authoring agencies identified (through engagements with victim organizations) an Iranian-affiliated APT group disrupted the function of PLCs.” states the advisory. “Organizations across several U.S. critical infrastructure sectors (including Government Services and Facilities, WWS, and Energy Sectors) deployed these PLCs within a wide variety of industrial automation processes. Some of the victims experienced operational disruption and financial loss.”
Systems could then drift into unsafe territory with nobody watching the warning lights, because the warning lights had been switched off from the inside.
“After the actors extracted device project files, the FBI and CISA identified the modification and deletion of project file logic, to include Add-On Instructions (AOIs) and data manipulation on HMI and SCADA displays [T1565].” continues the advisory.” Additionally, the changes disabled critical shutdown and alarm logic, allowing systems to enter unsafe conditions without notifying operators of the anomalies.”
The advisory ties the activity to the ongoing conflict between Iran and the US and Israel, framing it as an effort to cause disruption inside the United States. It fits a pattern going back to February, when the war started and Iranian-linked hacking picked up sharply across the region.
Not all of it looks like this. Some of it has been standard espionage and embarrassment campaigns, like the leak of FBI Director Kash Patel’s personal email account. Some of it has been genuinely destructive. The Iranian group known as Handala remotely wiped tens of thousands of employee devices at medical device maker Stryker, and separately claimed a breach at California’s Cal Water, saying it could disrupt the water supply. Cal Water pushed back, saying it found no sign anyone had touched its operational networks.
That’s the pattern worth watching: espionage on one track, disruption on another, and now a wider set of manufacturers exposed on the operational technology side. If your PLC talks to the internet, it’s not a bystander anymore.
Nobody wants their water plant’s alarm system to be the one thing an adversary quietly switches off. Time to check who can actually reach those controllers from outside.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Iran-Linked Actors)
A security researcher writing under the name tokay0 disclosed a flaw that could allow an attacker to access and control more than 600,000 deployed Shark model robot vacuums.
The post Robot Vacuum Flaw Could Give Hackers Control Over Millions of Home Devices appeared first on The Security Ledger with Paul F. Roberts.
The Netherlands’ AIVD and MIVD, the civilian and military intelligence services, published a joint advisory on July 10 confirming that at least one Russian intelligence service is systematically compromising internet-connected IP cameras across the Netherlands, other EU and NATO member states, and Ukraine to collect military intelligence.
The operation is ongoing. The advisory is based on intelligence gathered by both services and covers a campaign that has escalated since Russia’s full-scale invasion of Ukraine.
The immediate military application in Ukraine is the most direct part of the finding.
“The information obtained by the Russian state actor via digital espionage operations targeting IP cameras provides insight into relevant military data, such as EU and NATO military transport routes and weapon deliveries to Ukraine. The Russian state actor uses image recognition software to conduct targeted searches for military vehicles and the military cargo they are transporting. In some cases, the access to IP cameras gained by the Russian state actor in Ukraine is used to identify the locations of Ukrainian military personnel.” reads the advisory. “Intelligence reveals that this information is subsequently used to neutralise Ukrainian military personnel and military materiel in use by the Ukrainian armed forces. Furthermore, the Dutch services have determined that the Russian service is using the access to IP cameras to acquire relevant military intelligence in EU and NATO member states, including information that is not directly relevant to the war in Ukraine.”
A roadside camera or a business camera overlooking a loading area becomes a targeting asset. That’s the direct line from a default password left unchanged to a strike on Ukrainian forces.
The surveillance operation in EU and NATO member states serves a different but related purpose.
“Furthermore, the Dutch services have determined that the Russian service is using the access to IP cameras to acquire relevant military intelligence in EU and NATO member states, including information that is not directly relevant to the war in Ukraine.” confirms the advisory. “To date, the Dutch services have not observed the Russian state actor using such information for military attacks outside Ukraine.”
The intelligence collected includes EU and NATO military transport routes and weapons deliveries bound for Kyiv. The Dutch services separately confirmed they caught a small number of cameras breached directly on military logistics routes inside the Netherlands, and warned the organizations running them so they could act.
The services are explicit that this isn’t a one-off campaign.
“The Dutch services assess that there has been a systematic increase in the number of digital espionage operations by Russian state actors to support military operations since the start of the war in Ukraine. The digital activities that target IP cameras form only a small part of their operations.” continues the joint advisory. “The Russian authorities derive significant tactical and strategic advantages from the deployment of cyber operations, from both defensive and offensive perspectives. For example, the MIVD has previously issued a warning about exploratory activities by Russian state actors targeting logistical routes, including routes in the Netherlands”
The camera surveillance is described as a small part of a much larger digital intelligence effort.
Getting into a camera isn’t technically sophisticated. The operators scan for internet-connected devices, fingerprint cameras by brand, and walk into those still running default passwords, outdated firmware, or factory settings. Once they’re in, image-recognition software runs automated searches through the video feed looking for military vehicles and the cargo they carry. No zero-days required.
“Once an IP camera has been identified, the malicious actor can attempt to gain access to the IP camera via the internet. This is often a relatively simple process, since many IP cameras that are connected to the internet lack adequate security measures.” states the advisory. “For example, they often have default passwords, obsolete firmware and factory configurations.”
The Dutch services have not observed the same camera-derived intelligence being used for military attacks outside Ukraine. But they say this demonstrates that Russia has the capability to do so, and that the same approach could be applied by Russian military units in a future conflict. That’s not a hypothetical being raised for rhetorical effect. It’s an assessment of demonstrated capability.
The most important variables, according to the advisory, are what the camera can see and whether it’s reachable from the public internet. On the first: cameras should be positioned for their actual purpose and should avoid covering logistics routes, loading docks, ports, or any area where military movements or weapons shipments pass. Sensitive zones within the field of view should be masked or blurred where possible, and GPS location data should be stripped from video streams.
On accessibility: live streams should not be publicly reachable unless there’s an essential reason for it. Port forwarding and UPnP should be disabled. Remote access should go through a VPN rather than direct exposure. Default passwords should be changed immediately on installation, admin accounts should be kept separate from stream-viewing accounts, and MFA should be enabled wherever the device supports it. The advisory also flags the origin of the hardware itself: China, Russia, and Iran are cited as countries actively running offensive cyber programs targeting Dutch and European interests, and buyers should factor that into procurement decisions.
Cybersecurity firm Censys counted more than 87,000 internet-connected cameras across EU and NATO countries and Ukraine running services matching known-exploited vulnerabilities. In the Netherlands alone, more than 45,000 cameras are reachable from the public internet.
The numbers illustrate the scale of the exposed surface the advisory is addressing. Fixing it doesn’t require new technology. It requires treating a camera pointing at a transport route with the same security discipline as any other system connected to the internet.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, IP cameras)
In this episode of the podcast, host Paul Roberts interviews Nishawn Smagh of the firm GreyNoise Intelligence about the findings of their State of the Edge report, an analysis of GreyNoise data on risks stemming from compromised edge devices such as broadband routers, VPN gateways, smart home devices and more. Shawn and Paul talk about how attackers are turning edge devices into their favorite entry point, and strategies for organizations to counter the growing risk of compromised edge devices.
The post Edge Devices Are Your Cyber Underbelly. Here’s Why. appeared first on The Security Ledger with Paul F. Roberts.
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:
Entrar
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
(SecurityAffairs – hacking, TuxBot v3)
The US and allied governments warn that Russian state-sponsored APT groups are scanning and exploiting poorly secured network devices, especially routers, to access critical infrastructure. Groups linked to FSB Center 16, including Berserk Bear, Energetic Bear, Ghost Blizzard, Crouching Yeti, Dragonfly, and Static Tundra, have targeted organizations in communications, defense, energy, finance, government, and healthcare sectors.
“Russian Federal Security Service (FSB) Center 16 cyber actors continue to exploit poorly configured and vulnerable networking devices worldwide, opportunistically compromising multiple critical infrastructure sector networks.” reads the joint advisory.”
Russian FSB Center 16 actors mainly target poorly configured network devices, especially routers, by scanning the internet for exposed SNMP services with weak or default credentials.
They use spoofed requests to steal device configurations and move them to attacker-controlled servers through TFTP or FTP. The group also exploits known Cisco vulnerabilities and management interfaces. These techniques are not unique to Russia and overlap with other nation-state actors, so the recommended protections help defend against multiple threats.
“The Russian FSB Center 16 cyber actors primarily use scanning to identify poorly configured networking devices, primarily routers, for exploitation. The actors scan for Internet IP ranges with active Simple Network Management Protocol (SNMP) agents that accept common or default community strings for authentication” continues the joint advisory.
“While SNMP scanning is the primary method the actors use to discover and exploit poorly configured networking devices, they occasionally exploit common vulnerabilities and exposures (CVEs) in Cisco devices, Cisco’s Smart Install (SMI) functionality, and web portals to manage network devices.”
Russia-linked threat actors have also exploited known vulnerabilities, including CVE-2018-0171 and CVE-2008-4128, to compromise network devices. Their techniques overlap with other threat groups, such as Salt Typhoon.
Network defenders should strengthen router security by disabling Cisco Smart Install, replacing SNMPv1/v2 with SNMPv3 using strong encryption, and enforcing unique passwords with secure storage.
Organizations should monitor SNMP activity, restrict management access through ACLs, block unnecessary ports such as TFTP, SMI and SNMP from external networks, and detect suspicious configuration changes. They should also keep firmware updated, replace unsupported devices, and use attack surface management tools to identify exposed systems and weak configurations.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, newsletter)
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.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, U-Boot)
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.
The post Residential Proxy Risks: Understanding Google’s Latest Action Against 2 Million Strong NetNut appeared first on The Security Ledger with Paul F. Roberts.
CERT/CC published an alert documenting an undocumented authentication backdoor in multiple Tenda firmware versions, tracked as CVE-2026-11405. The flaw gives anyone who knows the right password full administrative access to the device’s web management interface, regardless of whatever password the actual owner has set. The vendor hasn’t responded, and the vulnerability remains unpatched.
“Several versions of Tenda firmware contain an undocumented authentication backdoor that grants administrative access to the devices’ web management interfaces.” reads the advisory published by CERT/CC. “An attacker can expoit this vulnerability, tracked as CVE-2026-11405, to bypass the password verification process and obtain full administrative control without valid credentials.”
The affected firmware versions span several product lines: the FH1201, W15E, AC10, AC5, and AC6. Tenda sells home and business networking gear including routers, switches, wireless access points, and video surveillance equipment. All of these products include a web interface protected by username and password authentication. Or so the documentation says.
The authentication logic sits in the login() function inside the web server binary /bin/httpd. When someone tries to log in, the function first runs through the normal process: MD5-based password hashing, comparison, the usual. If that check fails, instead of stopping there, it does something else entirely.
A matching value grants role=2, which is admin-level access, and creates a valid session with full privileges.
The username field doesn’t matter at all.
“However, if authentication fails, the function invokes GetValue("sys.rzadmin.password") to retrieve an alternate password value from the device configuration. It then performs a direct strcmp() comparison in plaintext between the user-supplied password and the configuration-stored value. A successful match grants role=2 admin-level access and creates a valid session.” continues the advisory. “The associated username is not validated, so any provided username will succeed when paired with the backdoor password.”
An attacker can enter any username and the hidden backdoor password to log in as an administrator. The router’s configured username and password are completely bypassed.
Full admin access to a router’s web interface gives attackers full control of the device. An attacker can redirect traffic by changing DNS settings, disable security features, reconfigure the network, or use the device as a stepping stone into whatever’s connected behind it. The CERT/CC advisory describes the potential outcome as a complete device takeover.
“Successful exploitation grants full administrative access to the device’s web interface, regardless of the configured administrator account credentials.” CERT/CC states. “With administrative control, an attacker can reconfigure the device, alter network settings, and disable security features, enabling broader compromise of the local network.”
The backdoor is baked into the firmware binary, not into any configuration file an admin can edit or reset. The hidden password value lives in the device configuration under sys.rzadmin.password, which means it shipped this way from Tenda intentionally, not as something an owner could accidentally trigger. There’s no way to disable it from the management interface because it isn’t visible there at all.
The vulnerability was reported by an anonymous researcher. Tenda hasn’t acknowledged it or provided any timeline for a fix. CERT/CC’s interim recommendations are to disable remote management on the device, which removes exposure to attackers coming in from the internet, and to change the default LAN IP address to reduce how easily automated scanners can find and probe the device.
No owner-side configuration change removes the code path. Until Tenda ships updated firmware that strips this out entirely, the only meaningful mitigation is making sure the device is unreachable from the internet, and reconsidering whether it should stay in production at all.
If you’re running any of the five affected firmware versions, disable remote management immediately and monitor for a firmware update from Tenda. Given the silence so far, it’s unclear when or whether one will arrive.
“Changing the default LAN IP address may reduce opportunistic discovery by automated scanners that target known default IP ranges. Note that this measure does not prevent deliberate or targeted network scanning.”concludes the advisory.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Tenda)
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:
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.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, FatFs)
IT threat evolution in Q1 2026. Non-mobile statistics
IT threat evolution in Q1 2026. Mobile statistics
The statistics in this report are based on detection verdicts returned by Kaspersky products unless otherwise stated. The information was provided by Kaspersky users who consented to sharing statistical data.
In Q1 2026:
In January 2026, it was reported that the FBI had seized the domains of the RAMP cybercrime forum, a major platform used extensively by ransomware developers to advertise their RaaS programs and to recruit affiliates. There has been no official statement from the FBI, nor is it clear if RAMP servers were seized. In a post on an external website, a RAMP moderator mentioned law enforcement agencies gaining control over the forum. The takedown disrupted a key element of the RaaS ecosystem, creating ripple effects for ransomware operators, affiliates, and initial access brokers.
A man suspected of links to the Phobos group was apprehended in Poland. He was charged with the creation, acquisition, and distribution of software designed for unlawfully obtaining information, including data that facilitates unauthorized access to information stored within a computer system.
In March, a Phobos ransomware administrator pleaded guilty to the creation and distribution of the Trojan, which had been used in international attacks dating back to at least November 2020.
In March, the U.S. Department of Justice charged a man who had acted as a negotiator for ransomware groups. The company he worked for specializes in cyberincident investigations. The prosecution alleges the suspect colluded with the BlackCat threat actor to share privileged insights into the ongoing progress of negotiations. Additionally, the suspect is alleged to have had a prior direct role in BlackCat attacks, serving as an affiliate for the RaaS operation.
In a separate development this March, a U.S. court sentenced an initial access broker associated with the Yanluowang ransomware group to 81 months of imprisonment. According to the U.S. Department of Justice, the convict facilitated dozens of ransomware attacks across the United States, resulting in over $9 million in actual loss and more than $24 million in intended loss.
The Interlock group has been heavily exploiting the CVE-2026-20131 zero-day vulnerability in Cisco Secure FMC firewall management software since at least January 26, 2026. The vulnerability enabled arbitrary Java code execution with root privileges on the affected device. This campaign demonstrates the ongoing reliance on zero-day vulnerabilities for initial access, a focus on network appliances as high-value entry points, and the rapid weaponization of new vulnerabilities within the ransomware ecosystem.
This section highlights the most prolific ransomware gangs by number of victims added to each group’s DLS. This quarter, the Clop ransomware (14.42%) returned to the top of the rankings, displacing Qilin (12.34%), which had held the leading position in the previous reporting period. Following closely is a new threat actor, The Gentlemen (9.25%). Emerging no later than July 2025, the group had already surpassed the activity levels of mainstays such as Akira (7.25%) and INC Ransom (6.13%).
Number of each group’s victims according to its DLS as a percentage of all groups’ victims published on all the DLSs under review during the reporting period (download)
In Q1 2026, Kaspersky solutions detected six new ransomware families and 2938 new modifications. Volumes have returned to Q3 2025 levels following a surge in Q4 2025.
Number of new ransomware modifications, Q1 2025 — Q1 2026 (download)
Throughout Q1, our solutions protected 77,319 unique users from ransomware. Ransomware activity was highest in March, with 35,056 unique users encountering such attacks during the month.
Number of unique users attacked by ransomware Trojans, Q1 2026 (download)
| Country/territory* | %** | |
| 1 | Pakistan | 0.79 |
| 2 | South Korea | 0.64 |
| 3 | China | 0.52 |
| 4 | Tajikistan | 0.40 |
| 5 | Libya | 0.38 |
| 6 | Turkmenistan | 0.36 |
| 7 | Iraq | 0.35 |
| 8 | Bangladesh | 0.33 |
| 9 | Rwanda | 0.30 |
| 10 | Cameroon | 0.28 |
* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country/territory.
| Name | Verdict | %* | |
| 1 | (generic verdict) | Trojan-Ransom.Win32.Gen | 33.90 |
| 2 | (generic verdict) | Trojan-Ransom.Win32.Crypren | 6.38 |
| 3 | WannaCry | Trojan-Ransom.Win32.Wanna | 5.87 |
| 4 | (generic verdict) | Trojan-Ransom.Win32.Encoder | 4.68 |
| 5 | (generic verdict) | Trojan-Ransom.Win32.Agent | 3.80 |
| 6 | LockBit | Trojan-Ransom.Win32.Lockbit | 2.80 |
| 7 | (generic verdict) | Trojan-Ransom.Win32.Phny | 1.99 |
| 8 | (generic verdict) | Trojan-Ransom.MSIL.Agent | 1.96 |
| 9 | (generic verdict) | Trojan-Ransom.Python.Agent | 1.93 |
| 10 | (generic verdict) | Trojan-Ransom.Win32.Crypmod | 1.89 |
* Unique Kaspersky users attacked by the specific ransomware Trojan family as a percentage of all unique users attacked by this type of threat.
In Q1 2026, Kaspersky solutions detected 3485 new modifications of miners.
Number of new miner modifications, Q1 2026 (download)
In Q1, we detected attacks using miner programs on the computers of 260,588 unique Kaspersky users worldwide.
Number of unique users attacked by miners, Q1 2026 (download)
| Country/territory* | %** | |
| 1 | Senegal | 3.19 |
| 2 | Turkmenistan | 3.06 |
| 3 | Mali | 2.63 |
| 4 | Tanzania | 1.62 |
| 5 | Bangladesh | 1.06 |
| 6 | Ethiopia | 0.95 |
| 7 | Panama | 0.88 |
| 8 | Afghanistan | 0.79 |
| 9 | Kazakhstan | 0.77 |
| 10 | Bolivia | 0.75 |
* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country/territory.
In Q1 2026, Google uncovered a new cryptocurrency theft campaign. The scammers directed victims to a fraudulent video call, prompting them to execute malicious scripts under the guise of technical support fixes for connection problems.
In March, researchers with GTIG and iVerify reported the discovery of an in-the-wild exploit chain targeting both iOS and macOS devices. The exploit kit was apparently marketed on the dark web, providing threat actors with a suite of spyware capabilities alongside specialized cryptocurrency exfiltration modules. The exploit was delivered via drive-by downloads when victims visited various compromised websites. Our analysis confirmed that the toolkit included an updated version of a component previously identified in the Operation Triangulation attack chain.
Devices running macOS were similarly impacted by the high-profile supply chain attack targeting the Axios npm package, a widely used HTTP client for JavaScript. The installation of the infected package led to the deployment of a backdoor on macOS devices.
Unique users* who encountered this malware as a percentage of all attacked users of Kaspersky security solutions for macOS (download)
* Data for the previous quarter may differ slightly from previously published data due to some verdicts being retrospectively revised.
The share of PasivRobber spyware attacks is beginning to decline, giving way to more traditional adware and Monitor-class software capable of tracking user activity. The popular Amos stealer also maintains its presence within the TOP 20.
| Country/territory | %* Q4 2025 | %* Q1 2026 |
| China | 1.28 | 1.97 |
| France | 1.18 | 1.07 |
| Brazil | 1.13 | 0.98 |
| Mexico | 0.72 | 0.52 |
| Germany | 0.71 | 0.45 |
| The Netherlands | 0.62 | 0.75 |
| Hong Kong | 0.49 | 0.53 |
| India | 0.42 | 0.48 |
| Russian Federation | 0.34 | 0.37 |
| Thailand | 0.24 | 0.27 |
* Unique users who encountered threats to macOS as a percentage of all unique Kaspersky users in the country/territory.
This section presents statistics on attacks targeting Kaspersky IoT honeypots. The geographic data on attack sources is based on the IP addresses of attacking devices.
In Q1 2026, the share of devices attacking Kaspersky honeypots via the SSH protocol saw a significant increase compared to the previous reporting period.
Distribution of attacked services by number of unique IP addresses of attacking devices (download)
The distribution of attacks between Telnet and SSH maintained the ratio observed in Q4 2025.
Distribution of attackers’ sessions in Kaspersky honeypots (download)
Share of each threat delivered to an infected device as a result of a successful attack, out of the total number of threats delivered (download)
The primary shifts in the IoT threat distribution are linked to the activity of various Mirai botnet variants, although members of this family continue to account for the majority of the list. Furthermore, a new variant, Mirai.kl, surfaced in the rankings. We also observed a significant decline in NyaDrop botnet activity during Q1.
The United States, the Netherlands, and Germany accounted for the highest proportions of SSH-based attacks during this period.
| Country/territory | Q4 2025 | Q1 2026 |
| United States | 16.10% | 23.74% |
| The Netherlands | 15.78% | 17.57% |
| Germany | 12.07% | 10.34% |
| Panama | 7.72% | 6.34% |
| India | 5.32% | 6.05% |
| Romania | 4.05% | 5.82% |
| Australia | 1.62% | 4.61% |
| Vietnam | 4.21% | 3.50% |
| Russian Federation | 3.79% | 2.35% |
| Sweden | 2.25% | 2.09% |
China continues to account for the largest proportion of Telnet attacks, though there was a marked increase in activity originating from Pakistan.
| Country/territory | Q4 2025 | Q1 2026 |
| China | 53.64% | 39.54% |
| Pakistan | 14.27% | 27.31% |
| Russian Federation | 8.20% | 8.25% |
| Indonesia | 8.58% | 6.71% |
| India | 4.85% | 4.66% |
| Brazil | 0.06% | 3.30% |
| Argentina | 0.02% | 2.51% |
| Nigeria | 1.22% | 1.38% |
| Thailand | 0.01% | 0.55% |
| Sweden | 0.54% | 0.55% |
The statistics in this section are based on detection verdicts by Web Anti-Virus, which protects users when suspicious objects are downloaded from malicious or infected web pages. These malicious pages are purposefully created by cybercriminals. Websites that host user-generated content, such as message boards, as well as compromised legitimate sites, can become infected.
The following statistics show the distribution by country/territory of the sources of internet attacks blocked by Kaspersky products on user computers (web pages redirecting to exploits, sites containing exploits and other malicious programs, botnet C&C centers, and so on). One or more web-based attacks could originate from each unique host.
To determine the geographic source of web attacks, we matched the domain name with the real IP address where the domain is hosted, then identified the geographic location of that IP address (GeoIP).
In Q1 2026, Kaspersky solutions blocked 343,823,407 attacks launched from internet resources worldwide. Web Anti-Virus was triggered by 49,983,611 unique URLs.
Web-based attacks by country/territory, Q1 2026 (download)
To assess the risk of malware infection via the internet for users’ computers in different countries and territories, we calculated the share of Kaspersky users in each location on whose computers Web Anti-Virus was triggered during the reporting period. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries and territories.
This ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out Web Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.
| Country/territory* | %** | |
| 1 | Venezuela | 9.33 |
| 2 | Hungary | 8.16 |
| 3 | Italy | 7.58 |
| 4 | Tajikistan | 7.48 |
| 5 | India | 7.21 |
| 6 | Greece | 7.13 |
| 7 | Portugal | 7.10 |
| 8 | France | 7.05 |
| 9 | Belgium | 6.83 |
| 10 | Slovakia | 6.80 |
| 11 | Vietnam | 6.62 |
| 12 | Bosnia and Herzegovina | 6.57 |
| 13 | Canada | 6.56 |
| 14 | Serbia | 6.50 |
| 15 | Tunisia | 6.36 |
| 16 | Qatar | 6.01 |
| 17 | Spain | 5.95 |
| 18 | Germany | 5.95 |
| 19 | Sri Lanka | 5.89 |
| 20 | Brazil | 5.88 |
* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users targeted by web-based Malware attacks as a percentage of all unique users of Kaspersky products in the country/territory.
On average during the quarter, 4.73% of users’ computers worldwide were subjected to at least one Malware web attack.
Statistics on local infections of user computers are an important indicator. They include objects that penetrated the target computer by infecting files or removable media, or initially made their way onto the computer in non-open form. Examples of the latter are programs in complex installers and encrypted files.
Data in this section is based on analyzing statistics produced by anti-virus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media. The statistics are based on detection verdicts from the On-Access Scan (OAS) and On-Demand Scan (ODS) modules of File Anti-Virus and include detections of malicious programs located on user computers or removable media connected to the computers, such as flash drives, camera memory cards, phones, or external hard drives.
In Q1 2026, our File Anti-Virus detected 15,831,319 malicious and potentially unwanted objects.
For each country and territory, we calculated the percentage of Kaspersky users whose computers had the File Anti-Virus triggered at least once during the reporting period. This statistic reflects the level of personal computer infection in different countries and territories around the world.
Note that this ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out File Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.
| Country/territory* | %** | |
| 1 | Turkmenistan | 47.96 |
| 2 | Tajikistan | 31.48 |
| 3 | Cuba | 31.03 |
| 4 | Yemen | 29.59 |
| 5 | Afghanistan | 28.47 |
| 6 | Burundi | 26.93 |
| 7 | Uzbekistan | 24.81 |
| 8 | Syria | 23.08 |
| 9 | Nicaragua | 21.97 |
| 10 | Cameroon | 21.60 |
| 11 | China | 21.09 |
| 12 | Mozambique | 21.02 |
| 13 | Algeria | 20.64 |
| 14 | Democratic Republic of the Congo | 20.63 |
| 15 | Bangladesh | 20.44 |
| 16 | Mali | 20.35 |
| 17 | Republic of the Congo | 20.23 |
| 18 | Madagascar | 20.00 |
| 19 | Belarus | 19.78 |
| 20 | Tanzania | 19.52 |
* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users on whose computers local Malware threats were blocked, as a percentage of all unique users of Kaspersky products in the country/territory.
On average worldwide, Malware local threats were detected at least once on 11.55% of users’ computers during Q1.
Russia scored 11.92% in these rankings.
What happened An internet-connected coffee machine reportedly led to a significant corporate data breach after attackers used the device as an entry point into a secure network. A digital forensics investigator identified only as TR examined the incident after a client suspected a rival had infiltrated its systems. Instead of finding malware, the investigator found […]
The post Internet-Connected Coffee Machine Reportedly Led to Corporate Data Breach appeared first on CISO Whisperer.
The post Internet-Connected Coffee Machine Reportedly Led to Corporate Data Breach appeared first on Security Boulevard.
