An exposed operator directory reveals how one actor compromised 14,000+ Dahua cameras across Ukraine and Russia, no password needed for most.

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

Pierluigi Paganini

(SecurityAffairs – hacking, newsletter)

A hidden backdoor in 20 router models lets remote servers execute commands as root, putting affected devices at risk of takeover.

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:

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

Pierluigi Paganini

(SecurityAffairs – hacking, Backdoor)

US agencies warn Iran-linked actors are targeting internet-exposed water and energy control systems, risking disruption.

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

Pierluigi Paganini

(SecurityAffairs – hacking, Iran-Linked Actors)

Dutch intelligence says Russia hacks IP cameras to monitor NATO military logistics and weapons shipments to Ukraine.

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

Pierluigi Paganini

(SecurityAffairs – hacking, IP cameras)

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)

US and allies warn of Russian APT groups targeting routers and network devices to compromise critical infrastructure worldwide.

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

Pierluigi Paganini

(SecurityAffairs – hacking, newsletter)

Binarly found six U-Boot flaws, including two that enable code execution during boot image verification, impacting 50+ releases.

Binarly’s research team has found six vulnerabilities in U-Boot, the open-source bootloader that runs on home routers, smart cameras, server management controllers, and a large portion of the embedded hardware that powers the internet.

All six are triggered during the verification of a FIT image, which is the format U-Boot uses to package and validate the software it loads. Two of the vulnerabilities can lead to arbitrary code execution. Four can trigger a denial-of-service condition. The affected code has been present in U-Boot since version v2013.07, meaning over 50 stable releases are potentially impacted.

U-Boot matters because it runs before the operating system, before any security software, before almost everything.

“Because U-Boot is one of the first components to run during the boot process, it is highly security-sensitive: severe flaws at this stage can be used by a potential attacker to compromise everything that is loaded and executed afterwards.” reads the report published by Binarly. “Recognising the critical nature of this component, the Binarly Research team decided to examine the core functionality of the U-Boot project more closely. This research revealed six distinct vulnerabilities, ranging in impact from denial of service (DoS) to arbitrary code execution during the verification of an untrusted image.”

Malicious code planted at this stage is extremely difficult to detect and nearly impossible to remove without physically reflashing the device’s storage chip.

FIT stands for Flattened Image Tree. It’s the standard format U-Boot uses to bundle kernels, device trees, ramdisks, and firmware into a single package that also contains cryptographic hashes and signatures. FIT Signature Verification is the step that checks those signatures before deciding whether the image is trusted enough to execute.

Binarly focused on this component specifically because breaking it would undermine the entire concept of verified boot, which is the mechanism meant to ensure only trusted code runs at each stage of startup. Several vulnerabilities in this same code path have been disclosed before, including CVE-2020-10648 and CVE-2021-27097, and Binarly found reason to believe there were more.

BRLY-2026-037 stems from a function called fdt_find_regions, which walks the device tree structure inside a FIT image and builds a list of regions to hash. It calls fdt_get_name to retrieve node names during this walk. The problem is that fdt_get_name can return NULL in certain cases, specifically when processing an old-format FIT image whose version is below 0x10 and the node name contains no slash character. The code never checks for this and proceeds to use the NULL return value directly.

For the root node, this causes an immediate crash. For child nodes, execution reaches a strcpy call that copies from the NULL pointer into a stack buffer allocated in the parent function. On most modern systems the zero page is unmapped and this also crashes. But on embedded devices it’s common for the zero page to be mapped, which means an attacker who can also control what sits at memory address 0x0 can turn this NULL dereference into a stack-based buffer overflow and from there into code execution. Binarly confirmed the vulnerability triggers in U-Boot’s sandbox build.

BRLY-2026-038 builds on the same root cause but exploits a different consequence. When fdt_get_name fails, it writes a negative error code into the len argument. The surrounding code then uses len to advance a pointer through a stack buffer, but it never checks whether len is negative. A negative value moves the pointer backwards instead of forwards, producing a stack buffer underflow.

“This underflow primitive enables us to move the end pointer backwards by 10 bytes (FDT_ERR_BADSTRUCTURE error code is -11, and *end++ = ‘/’ is executed on each iteration) for each malformed FDT entry until it reaches the return address of fdt_find_regions, which is possible because the target buffer lives in the stack frame of the parent fit_config_check_sig function.” continues the report. “From there, carefully chosen valid nodes supply the names that overwrite the return address of fdt_find_regions, along with the payload bytes.”

Binarly demonstrated this working on a QEMU ARM build, printing a custom message to the console during U-Boot execution. The fix for both vulnerabilities is a single null check on the return value of fdt_get_name.

BRLY-2026-039 involves the size of the strings region in a FIT image. During signature verification, the code reads this size from a property in the image called “hashed-strings” without checking whether the declared size actually fits within the image boundaries. An attacker sets this value to 0xFFFFFFFF and the hashing routine attempts to read nearly four gigabytes of data, quickly running past the end of the image into unmapped memory and crashing the bootloader.

BRLY-2026-040 is another null pointer dereference in fdt_find_regions, this time from a different code path. When the function encounters a property tag in the device tree, it calls fdt_get_property_by_offset to read the property header.

For FIT images with a version below 0x10, this function returns NULL without attempting to parse the property. The code immediately dereferences the returned pointer without checking it, crashing U-Boot on any platform where the zero page is unmapped.

BRLY-2026-041 involves FIT images that store payload data externally, referenced by position and size values embedded in the image.

“All three properties – data-position, data-offset and data-size – are fully controlled by the attacker, and none of them are checked against the actual size of the FIT image. The data pointer and size produced here then travel through the same hashing path as it was described for BRLY-2026-039 above.” continues the report. “This provides attackers with two straightforward methods of crashing the bootloader: pointing the data region outside the mapped memory through data-position/data-offset, or requesting an enormous data-size. For example, with a provided size of 0xFFFFFFFF the hashing routine reads far beyond the image bounds.”

An attacker can crash the bootloader either by pointing the data region outside mapped memory or by declaring a data size of 0xFFFFFFFF.

BRLY-2026-042 is triggered even earlier than the others, before signature verification starts, during FIT format validation. A function called fdt_check_no_at walks the entire FIT image tree recursively to look for node names containing an @ symbol, a character that can cause logical problems in libfdt’s node matching. The recursion stops only when it runs out of subnodes, and the depth limit inherited from the preceding check allows trees nested up to INT_MAX levels deep. Adding one more nesting level to a FIT image costs 12 bytes. Each recursive call consumes at least 16 bytes of stack space. The math isn’t complicated.

“This ensures that the stack will be exhausted regardless of the size of the device’s RAM.” states Binarly.

The fix adds a depth counter that rejects images once nesting exceeds 32 levels.

A reasonable assumption is that exploiting a bootloader vulnerability requires physical access to the hardware. Binarly pushes back on this directly, pointing to earlier research on Supermicro BMC firmware as a counter-example. Server BMCs expose remote administration interfaces, and Binarly has previously shown that an attacker with access to those interfaces can bypass firmware update validation and force the legitimate update mechanism to flash a malicious image. The same principle applies broadly: any device that accepts firmware updates over a network, even one that performs validation, may be reachable without anyone touching the hardware.

All six patches have been accepted upstream and are available in U-Boot’s master branch. Binarly prepared the patches themselves after the initial disclosure encountered some friction with the project’s maintainers. Organizations running devices built on U-Boot, particularly server hardware with BMC controllers, should apply the patches through their vendor’s firmware update process as soon as updates become available. Proof-of-concept FIT images and reproduction steps for all six vulnerabilities are included in Binarly’s individual advisories.

“The PoC FIT image generation script and the steps required to reproduce the issue are fully detailed in the advisory for this vulnerability.” concludes the report. “The fix adds a depth counter to fdt_check_no_at, rejecting the image once the nesting reaches FDT_MAX_DEPTH, which is defined in boot/fdt_region.c and is equal to 32.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, U-Boot)

CERT/CC warns an unpatched backdoor in several Tenda routers lets attackers bypass login and gain full admin access with a hidden password.

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

Pierluigi Paganini

(SecurityAffairs – hacking, Tenda)

runZero found 7 flaws in FatFs, a filesystem used in IoT and embedded devices. Bugs can cause memory corruption, crashes, or data leaks via crafted storage.

Cybersecurity firm runZero has disclosed seven vulnerabilities in FatFs, a compact open-source library that lets embedded devices read and write FAT and exFAT formatted storage, the same formats used on USB drives and SD cards. The severity ratings run from CVSS Medium to High.

This project revisited a 2017 security audit of the FatFs driver, where manual testing and fuzzing had only found minor issues. In March 2026, the team repeated the analysis using Visual Studio Code and GitHub Copilot in auto mode with simple prompts and no custom tooling. The results were unexpected: issues previously missed became easy to find. The AI helped generate fuzzing inputs automatically and even validated exploitability across different embedded environments, turning what was once a manual, time-consuming process into something far more automated and effective.

The flaws impact multiple platforms, including Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr RTOS, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and SWUpdate. Downstream from those platforms sit consumer IoT devices, industrial controllers, drones, hardware crypto wallets, and more.

Most of the devices that bundle FatFs don’t have the memory protections that phones and desktops take for granted, such as ASLR.

“For the vendors who build on these platforms it’s simple: any physical access leads to a jailbreak, especially given the lack of address space layout randomization (ASLR) and memory protection. For everyone else, there are numerous devices where brief physical access by the general public should not lead to a full compromise.” states the report. “For example, security cameras with SDCard storage, voting machines with USB file readers, ATMs, and pretty much anything else that has a screen that you expect people to touch.”

A security camera with an SD card slot, a voting machine with a USB reader, an ATM, a public kiosk: none of these should hand over full control to whoever plugs in a drive, but on unpatched hardware running vulnerable FatFs code, that’s the exposure.

All seven bugs share the same trigger: a device reads a crafted storage volume or firmware image, FatFs mishandles the malformed data, and bad things follow. Two of the CVEs, CVE-2026-6682 and CVE-2026-6683, are also implicated in over-the-air firmware update processes, which extends the attack surface beyond physical media entirely.

Below are the details of the seven flaws:

• CVE-2026-6682 (CVSS 7.6, High) – FAT32 integer overflow in mount_volume() can produce attacker-controlled file-size metadata. This may be trusted as a read length by downstream code, leading to heap or stack corruption and possible code execution.
• CVE-2026-6687 (CVSS 7.6, High) – exFAT label-length stack overflow in f_getlabel() allows oversized writes into label buffers when the label field is not properly capped. This can lead to straightforward memory corruption in embedded firmware.
• CVE-2026-6688 (CVSS 7.6, High) – long filename overflow in downstream callers where fno.fname exceeds fixed-size buffers. This often breaks in wrapper code using strcpy or sprintf and depends heavily on how firmware handles filenames.
• CVE-2026-6685 (CVSS 6.1, Medium) – unsigned subtraction wrap in dirty-cache handling on fragmented volumes can corrupt memory or cause silent data corruption, which is especially dangerous in logging and control systems.
• CVE-2026-6683 (CVSS 4.6, Medium) – exFAT divide-by-zero in sync/write paths triggered by crafted media leads to reliable crashes and potential device bricking in firmware update scenarios.
• CVE-2026-6686 (CVSS 4.6, Medium) – uninitialized cluster exposure when extending files past EOF can leak stale data from previously deleted files, creating an information disclosure risk.
• CVE-2026-6684 (CVSS 4.6, Medium) – GPT partition scan loop in pre-R0.16 versions can trigger unbounded scanning, causing boot-time denial of service. It is fixed upstream, but still present in older embedded deployments.

FatFs is maintained by one developer. runZero made repeated attempts to reach the maintainer and involved JPCERT/CC in the coordination process. Neither effort produced a response. For six of the seven CVEs, there is no upstream patch. The only fix available is the GPT scan issue addressed in R0.16, and even that requires downstream vendors to update their vendored copies.

That last detail is the crux of the problem.

“FatFs is one of those components. It’s compact, useful, and copied everywhere. That’s great for shipping products quickly, but less great when memory-safety issues show up in parser-adjacent code that happily ingests untrusted media.” continues the report. “This kind of component is even more challenging to deal with, from a disclosure-and-fix perspective, in that nearly everyone ends up making local, vendored modifications. So, an upstream patch must be validated pretty carefully before incorporating.”

Even when a fix does eventually appear, every vendor that’s diverged from upstream has to validate it against their own modifications before shipping it. The precedent from PixieFail, nine vulnerabilities in EDK II network boot code disclosed in 2024, is that this process takes years, not weeks, and FatFs has a weaker fix pipeline because there’s no responsive upstream at all.

runZero published proof-of-concept disk images, a test harness, and a working QEMU-based exploit demonstration in a companion repository at github.com/runZeroInc/vulns-2026-fatfs-chance. No attacks using these bugs had been reported as of the July 1 disclosure date.

What to do if you ship or run affected products?

If you build firmware that touches FAT or exFAT storage, the immediate work is: find your vendored copy of FatFs, audit the wrapper code around it, examine how your code handles filenames and file sizes, and plan for patching. Pay particular attention to any code that copies fno.fname into a fixed-size buffer. If you run affected devices rather than build them, treat physical ports and firmware update channels as attack surface: restrict who can plug in media, monitor for vendor security advisories, and apply firmware updates when vendors release them.

The broader point runZero makes is worth sitting with. Keeping these bugs quiet in 2026 would accomplish nothing, because the tooling that found them is now widely available. The right response to that reality is disclosure, coordination where possible, and publication to give defenders a head start.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, FatFs)