Evooo1Bot is a Mirai-based Linux botnet that hijacks routers and IoT devices for DDoS attacks, credential theft and criminal proxy services.

Fortinet’s FortiGuard Labs disclosed Evooo1Bot in mid-August, a previously undocumented Linux botnet that’s been active since July 2026. The bot borrows Mirai‘s DDoS engine but adds encrypted command-and-control communications, an SSH brute-force scanner, a credential sniffer, and a SOCKS5 proxy module on top.

“FortiGuard Labs has been tracking a previously undocumented Linux botnet family, which we have named Evooo1Bot. The name derives from the hardcoded string “evooo1” found in every binary.” reads the report published by Fortinet. “While the malware reuses the DDoS engine from the publicly leaked Mirai source code, it extends the original framework with numerous capabilities, including encrypted C2 communications, an SSH brute-force scanner, a SOCKS relay module, a credential sniffer, and an integrated exploit arsenal targeting multiple known vulnerabilities.”

The botnet targets 18 known CVEs, some of them dating back to 2007, including:

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

The bot communicates exclusively over port 443, which is intentional: the traffic blends into expected HTTPS flows at the network perimeter. After gaining initial access through one of its exploit modules or via brute-forced SSH credentials, the bot runs a loader script that clears Bash history to erase evidence of the intrusion before pulling the architecture-appropriate binary from an external server.

The breadth suggests the operators are scanning opportunistically for anything unpatched rather than targeting specific organizations.

“This capability significantly increases the value of an infected host to attackers. The victim’s IP address can be used to disguise malicious traffic, bypass geographic restrictions, or provide access to internal networks through an already compromised machine.” continues the report. “In larger botnets, the same functionality could also be used to build a distributed proxy infrastructure, enabling anonymous traffic forwarding or monetization through residential and enterprise proxy services.”

Evooo1Bot stands out because of its proxy module. A network of compromised routers, cameras, and firewalls acting as SOCKS5 relays is a valuable commodity; operators can use it themselves to obscure attack traffic, or sell access to other criminals looking for residential or enterprise IP addresses that don’t trigger geographic blocks.

“Unlike typical botnet commands that focus on downloading payloads or launching attacks, the !socks module turns an infected host into a SOCKS5 proxy that the operator can use as a network relay. It supports two operating modes. In direct mode, it opens a SOCKS5 listener on the infected host on the default TCP port 1080 and waits for incoming client connections. The implementation first attempts to create a dual-stack IPv6 listener and falls back to IPv4 if that fails. Each accepted client is then passed to the session handler for proxying.” continues the report. “The botnet also implements a reverse relay mode. Instead of exposing a listening port, the bot establishes an outbound encrypted connection to an operator-specified relay server. This persistent control channel listens for commands such as RELAY_NEW:<session_id>, which indicate that a new proxy session should be created.”

After establishing C2 contact, the bot accepts commands covering the full post-compromise toolkit: file upload and download, interactive shell access, persistence installation, binary updates, HTTP Basic Auth and Cookie header interception, DDoS over DNS, TCP, and UDP, and the HTTP exploit dispatcher.

The credential sniffer intercepts authentication headers in transit, so any HTTP Basic Auth credentials passing through an infected device can be captured without any additional effort from the operator. If you’re still running devices with unpatched firmware from the CVE list above, or if any of your edge hardware is using default SSH credentials, Evooo1Bot is already scanning for you.

“Beyond traditional botnet functionality, it features encrypted C2 communications, multiple layers of string obfuscation using AES-256-CTR, ChaCha20, and XOR-based key derivation, as well as a 28-command remote administration interface.” concludes the report. “These capabilities place Evooo1Bot well beyond the technical baseline of conventional Mirai-derived malware.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Evooo1Bot botnet)

OVSwrap is a 13-year-old Linux kernel flaw that lets local users gain root privileges on most distributions using Open vSwitch.

Security researcher Asim Manizada disclosed OVSwrap (CVE-2026-64531, CVSS score of 7.8), a local privilege escalation vulnerability in the Linux kernel’s Open vSwitch datapath that lets an ordinary user become root on a wide range of default-configured distributions.

The upstream fix shipped in stable trees on July 24, and a proof-of-concept exploit with pre-built records for roughly 800 kernel builds is now public. If your distribution hasn’t shipped a patched kernel yet, you need to act now.

“Open vSwitch accepts a list of “actions” from userspace and validates/rewrites some of the actions into a larger internal form. These internal actions are stored as Netlink attributes, whose length field is only 16 bits wide. Now, the total internal action stream is allowed to grow past 64 KiB. But an individual nested action attribute (an attribute and all of its recursive children) still needs to fit in that 16-bit length field. Pre-fix, Open vSwitch did not check that second limit.” reads the report published by Manizada. “As a result, an attacker can submit a valid action (e.g., CLONE) containing hundreds of, say, small conntrack actions.”

The unsafe assignment behind this had been in the code for 13 years without being exploitable, held in check by a 32 KiB cap on the total generated action stream. A March 2025 change removed that cap because it was causing unpredictable failures in large OpenStack deployments, and in doing so made the old bug reachable. The enabling commit’s review thread discussed reliability and user-facing failures but never addressed the security consequence of removing the guard.

“The kernel expands those actions until the generated action is larger than 65,535 bytes, then stores that length in the 16-bit nla_len, causing it to wrap to a small value. Later code trusts the wrapped length, advances by it, and resumes parsing from the middle of the generated conntrack data.

“Critically, parts of that conntrack data – labels and timeout names – are controlled by the attacker.” the researcher continues. “Parts of that conntrack data — labels and timeout names — are controlled by the attacker. And because the wraparound redirects parsing to a deterministic offset within the same contiguous buffer, forged action headers can be placed exactly where parsing resumes. No heap grooming needed, which is why Manizada describes it as having “logic-bug-grade reliability.” Memory corruption with the predictability of a logic bug is not something defenders encounter every day.”

The exploit chains three primitives from that wraparound: a kernel pointer leak through a fake OUTPUT action, an arbitrary kernel read through a forged tunnel SET action, and a targeted decrement through teardown of a forged tunnel destination pointer.

The proof-of-concept exploit uses leaked kernel information to locate critical memory structures, bypass kernel protections, and eventually change the attacker’s user and group IDs to zero, effectively granting root privileges.

The PoC corrupts a live kernel credential, modifies /etc/sudoers or /etc/sudoers.d, and opens a root shell, leaving processes and OVS state behind deliberately to avoid unsafe teardown.

The reachability conditions are what make this broadly dangerous.

“Importantly, the attacker does not need much to reach the vulnerable code – no existing OVS bridge, no running ovs-vswitchd, no host-level CAP_NET_ADMIN. All you need is a CAP_NET_ADMIN in the user namespace that owns the network namespace*.” continues the report. “An ordinary user can therefore use an unprivileged user namespace to create a new network namespace, receive CAP_NET_ADMIN over that namespace, and create a private OVS datapath inside it with a plain unshare -Urn. This leaves many distros vulnerable in their default unprivileged-user-namespaces-enabled configuration.”

The tested list of exploitable distributions in default configuration includes AlmaLinux 9 and 10, Alpine 3.22 through 3.24, Amazon Linux 2023, Arch, CentOS Stream 9 and 10, Debian 12 and 13, Fedora 42 through 44, Kali 2026.1, Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS, Rocky Linux 9 and 10, and Ubuntu 22.04. Ubuntu 24.04 blocks direct namespace creation via AppArmor but falls to an aa-exec fallback in the PoC; Ubuntu 26.04 is blocked by default but exploitable after disabling AppArmor’s user-namespace restriction.

Install the patched vendor kernel if one is available. If you can’t patch today and OVS isn’t required on the system, the fastest interim step is to block future module loads with echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf — though a module already loaded in memory still needs to be removed or cleared by rebooting. Disabling unprivileged user namespaces closes the ordinary local-user route but doesn’t protect against a container process that already has CAP_NET_ADMIN over a network namespace it controls. The PoC repository also includes an emergency BPF guard for environments that must keep both OVS and namespaces active.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Linux)

Januscape: A 16-year-old Linux KVM flaw lets cloud VM tenants crash hosts and potentially escape guests. It affects Intel and AMD systems.

Security researcher Hyunwoo Kim has published details of a use-after-free vulnerability in Linux’s KVM hypervisor that allows code running inside a guest virtual machine to corrupt host kernel memory. The bug, tracked as CVE-2026-53359 and named Januscape, has been sitting in the kernel since August 2010. It affects both Intel and AMD processors, which makes it the first publicly documented guest-to-host KVM exploit that works across both architectures.

Kernel-based Virtual Machine (KVM) is a virtualization technology built directly into the Linux kernel that allows one physical computer to run multiple independent virtual machines (VMs).

Introducing "Januscape" (CVE-2026-53359)

A Guest-to-Host Escape in KVM/x86 exploiting a UAF in the shadow MMU. Triggerable on both Intel and AMD hosts. Threatens x86 public clouds (GCP, AWS) that expose nested virtualization.

"16 years" latent. Successfully used as a… pic.twitter.com/UHVC6Tg3Nm

— V4bel (@v4bel) July 6, 2026

Kim used it as a zero-day submission in Google’s kvmCTF program, which offers up to $250,000 for full guest-to-host escapes. The public proof-of-concept reliably panics the host kernel. A separate, complete exploit that achieves code execution on the host exists but hasn’t been released. Kim says that one is planned for the distant future.

KVM maintains its own internal set of page tables to track a guest’s memory layout. When it needs one of these tracking pages, it looks for an existing one to reuse. The problem is that it matched candidates by memory address alone and ignored the type of tracking page it was grabbing.

“Januscape is a use-after-free vulnerability in the shadow MMU emulation of KVM/x86. It can trigger the bug with guest-side actions alone to corrupt the host kernel’s shadow page, and it can threaten the guest-host isolation of KVM/x86 hosts that accept untrusted guests and expose nested virtualization, particularly multi-tenant x86 public clouds (GCP, AWS, etc.).” states Kim. “In fact, Januscape was successfully used as a 0-day exploit in Google kvmCTF.”

This mistake confuses KVM about which memory page it is managing. Once KVM’s internal records become incorrect, the Linux kernel may handle invalid data, causing crashes or potentially allowing an attacker to gain control.

Most of the time, the kernel detects the corruption and shuts itself down immediately to prevent further damage. That’s the crash the public PoC triggers: a guest VM loads a kernel module and races for seconds to minutes until the host panics. Every other tenant VM on the same physical machine goes down with it. The more dangerous outcome happens when the freed tracking page gets allocated for a different use before cleanup runs. The cleanup then writes into memory it no longer owns. The attacker controls where that write lands, not what gets written, but that constrained primitive is enough to develop into full host code execution.

The attack requires root inside the guest VM and nested virtualization exposed by the host. Guest root is a standard condition on cloud instances: when you rent a VM, you get root on your own instance. The nested virtualization requirement is what matters architecturally, because even hosts that use hardware memory management by default have to fall back through the older shadow MMU code path when nested virtualization is active, and that’s exactly where the bug lives.

“Unlike the commonly published QEMU escape vulnerabilities, Januscape occurs in in-kernel KVM, so it is triggered independently of QEMU’s emulation. Because of this, it can also threaten large public clouds that implement and use their own virtualization stack.” continues the researcher.

That’s a meaningful distinction. Custom cloud virtualization stacks that strip out QEMU entirely aren’t protected by that fact.

On distributions like RHEL where /dev/kvm is world-writable with permissions set to 0666, an unprivileged local user could also use this bug to escalate to root without being inside a VM at all. Kim flags this but dismisses it as the lower-value use case. The guest-to-host cloud scenario is the one that matters. (His exact phrasing: doing so would be like paying gold for garbage. Fair enough.)

The fix is a one-line addition to kvm_mmu_get_child_sp(). The reuse condition now checks both the guest frame number and the role type together, so KVM only reuses a shadow page when both values match. Fixed stable kernel versions shipped on July 4, 2026: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, and 5.10.260.

NVD hasn’t assigned a CVSS score yet. If you operate an x86 KVM host that accepts multi-tenant guests with nested virtualization enabled, confirm that commit 81ccda30b4e8 is present in your running kernel. Check the package changelog rather than relying on uname -r, because distribution backports may carry the fix under a different version number. If patching immediately isn’t possible, disabling nested virtualization with kvm_intel.nested=0 or kvm_amd.nested=0 removes the attack path for untrusted guests. ARM64 KVM hosts aren’t affected by Januscape specifically, though Kim’s earlier ITScape disclosure (CVE-2026-46316) covers a separate guest-to-host issue on that architecture.

“Januscape (CVE-2026-53359) covers the range from 2032a93d66fa (2010-08-01) to 81ccda30b4e8 (2026-06-16).” the researcher concludes “In other words, this vulnerability lay dormant for about “16 years”.”

Januscape is Kim’s third significant Linux kernel exploit in roughly two months. In May 2026, he disclosed Dirty Frag (CVE-2026-43284 and CVE-2026-43500), a page-cache write vulnerability chain that delivers reliable root on most major Linux distributions, extending the same vulnerability class as Dirty Pipe and Copy Fail. In June, he published ITScape (CVE-2026-46316), the first publicly demonstrated guest-to-host KVM escape on ARM64, exploiting a race condition in the virtual interrupt controller.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Januscape)

Bad Epoll (CVE-2026-46242) lets local attackers gain root on Linux and Android. The flaw was missed by AI but found by a security researcher.

A newly disclosed Linux kernel vulnerability, named Bad Epoll (CVE-2026-46242), allows a local attacker with no special privileges to gain full root access on affected Linux systems and Android devices. Security updates are already available, and users are urged to install them as soon as possible.

The flaw affects the Linux kernel’s epoll subsystem, a core feature used by servers, browsers, and countless applications to efficiently manage multiple network connections and file events. Because epoll is fundamental to Linux, there is no practical workaround other than patching vulnerable systems.

Bad Epoll is a classic use-after-free vulnerability, which occurs when a program continues to use a piece of memory after it has already been released (“freed”).

Two kernel threads attempt to release the same internal object simultaneously. One frees the memory while the other continues using it, creating a brief opportunity to corrupt kernel memory and escalate privileges to root.

“Two of epoll’s close paths run at the same time and collide. One frees an object while the other is still writing into it, and that is the use-after-free (UAF).” continues the advisory. “The race window, and how the exploit drives it. The exploit uses four epoll objects grouped into two pairs. One pair triggers the race, while the other becomes the victim. From there, the exploit turns the 8-byte UAF write into a UAF on a file object, and uses a cross-cache attack to fully control the file’s contents. Turning the bug into an arbitrary kernel memory read through /proc/self/fdinfo. With that control, the exploit gains an arbitrary read of kernel memory through /proc/self/fdinfo. Finally, it hijacks control flow and executes a ROP chain to gain a root shell.”

Although exploiting the flaw requires hitting a timing window only six CPU instructions wide, researcher Jaeyoung Chung developed a reliable proof-of-concept that reportedly succeeds in about 99% of attempts on tested systems. According to the researcher, the exploit can even be launched from Chrome’s renderer sandbox, making it particularly dangerous, and could also impact Android devices.

“Bad Epoll (CVE-2026-46242) is a race-condition use-after-free in the Linux kernel’s epoll subsystem. This bug lets an unprivileged process become root, not only on Linux desktops and servers but also on Android devices.” reads an advisory published by Chung.

One of the most interesting aspects of the vulnerability is its connection to AI-assisted vulnerability research. Bad Epoll originates from the same section of kernel code where Anthropic’s Mythos model previously identified another privilege escalation flaw, tracked as CVE-2026-43074. The AI detected the first bug, but missed this closely related vulnerability, which was later discovered manually.

“A single commit in 2023 introduced two separate race conditions into the epoll code, only about 2,500 lines in all. Both turned out to be critical bugs that can lead to privilege escalation.

The first was found by Anthropic’s Mythos and reported as CVE-2026-43074. That result is impressive on its own, because kernel race bugs are known to be hard to find. It showed a frontier AI model’s ability to find race bugs. An independent researcher later submitted a 1-day exploit for it to kernelCTF.” continunes the advisory. “The other race is Bad Epoll, which Mythos missed.”

Chung believes the miss is understandable. The race condition is extremely difficult to reason about because the vulnerable execution path exists for only a tiny fraction of a second. In addition, once the first flaw was patched, Bad Epoll no longer generated obvious warnings through KASAN, Linux’s memory error detection system, making it even harder to spot.

The good news is that there is currently no evidence that Bad Epoll has been exploited in the wild. The only public exploit is the proof-of-concept released through Google’s kernelCTF program. An Android exploit is reportedly still under development.

The flaw affects Linux kernels based on version 6.4 and later, unless they already include the upstream fix. Older long-term support kernels based on Linux 6.1, including some Android devices such as the Pixel 8, are not vulnerable because the problematic code was introduced after those versions branched.

Bad Epoll joins a growing list of high-profile Linux privilege escalation vulnerabilities recently disclosed, including Copy Fail, Dirty Frag, Fragnesia, and DirtyClone. While many of these newer vulnerabilities are deterministic and relatively easy to exploit, Bad Epoll belongs to the older class of race-condition bugs, which are significantly harder to discover, exploit, and patch.

The case also highlights both the promise and the current limitations of AI in vulnerability research. Models such as Mythos have already demonstrated they can identify complex kernel flaws and even uncover long-standing vulnerabilities in projects like FreeBSD.

At the same time, Bad Epoll shows that highly subtle race conditions can still escape even state-of-the-art AI systems. For now, human expertise remains essential, particularly when vulnerabilities depend on tiny timing windows and complex concurrent execution paths.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Bad Epoll)

DirtyClone: a Linux kernel privilege escalation that silently rewrites executables in memory, leaving no disk trace. Patch now.

JFrog Security Research published a working exploit walkthrough on June 25 for CVE-2026-43503 (CVSS score of 8.8), a Linux kernel privilege escalation they call DirtyClone. It’s the fourth vulnerability in the DirtyFrag family, all sharing the same root failure: file-backed memory gets treated as packet data, and an in-place network operation writes where it should have copied. CVSSIf your kernel doesn’t have the May 21 mainline patch, update now.

“The severity of this issue is significant because it allows any unprivileged local user to gain root access (LPE) by manipulating the Linux page cache.” reads the report published by JFrog. “The attack is silent, leaves no kernel logs or audit traces, and bypasses common on-disk integrity monitoring tools.”

The attacker loads a privileged binary like /usr/bin/su into memory, wires those pages into a network packet, and forces the kernel to clone it through a loopback IPsec tunnel they control. The decryption step overwrites the binary’s authentication logic with attacker-chosen bytes, and the next run of su hands over root — while the file on disk stays untouched.

The exploit requires CAP_NET_ADMIN to configure the IPsec environment. On Debian and Fedora that capability is reachable by any local user through unprivileged user namespaces, which are enabled by default.

“The attacker begins by creating a fresh network namespace:

unshare -Urn

This provides network administrative capabilities inside the namespace.” continues the report. “While capabilities are namespaced, page cache is shared at the host level, so if file-backed pages are modified through shared mappings, the effects may propagate to other processes using those pages.”

Ubuntu 24.04 and later restrict namespace creation via AppArmor, blocking the default exploit path, but every other distribution with default namespace configurations is exposed.

The DirtyFrag family now has four members. Copy Fail (CVE-2026-31431) arrived in late April. DirtyFrag (CVE-2026-43284 and CVE-2026-43500) followed on May 7. Fragnesia (CVE-2026-46300) appeared on May 13, bypassing the DirtyFrag patch through a flag-dropping bug in skb_try_coalesce().

“DirtyFrag is a family of Linux kernel memory corruption vulnerabilities in the core networking stack affecting how socket buffers (skb) reference shared page-cache memory, which are subsequently weaponized through in-place cryptographic transformations in subsystems like XFRM/IPsec or RxRPC.” continues the report. “Despite targeting different packet cloning or forwarding paths, variants like DirtyFrag, Fragnesia, and DirtyClone all rely on a shared technique: tricking the kernel into treating read-only, file-backed page cache memory as writable network buffers.”

Each patch closed one code path and left others open. The underlying contract, that every function moving socket buffer fragments must preserve the shared-frag flag, every time, was never fully enforced across the codebase.

The original DirtyFrag researcher Hyunwoo Kim submitted a broader multi-site patch on May 16 covering the remaining fragment-transfer helpers. JFrog independently rediscovered one of the affected functions on May 19, built a working exploit, and reported it. The combined fix merged on May 21, CVE-2026-43503 was published on May 23, and Linux v7.1-rc5 shipped on May 24 as the first fixed release. Ubuntu, Debian, and SUSE have published advisories; Red Hat has a Bugzilla tracking entry.

If patching today isn’t an option, two workarounds reduce the attack surface. Setting kernel.unprivileged_userns_clone=0 on Debian and Ubuntu blocks the namespace-based path to CAP_NET_ADMIN. Blacklisting the esp4, esp6, and rxrpc kernel modules removes the in-place decryption primitives the exploit needs, though that breaks IPsec and AFS. Neither is a fix. The DirtyFrag class probably isn’t finished: any fragment-transfer function that drops the shared-frag flag along the way is a potential new variant, and auditing every such path in the kernel networking stack is a large and unfinished job.

JFrog published a Proof Of Concept video for the exploitation of the flaw.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Linux)

AryStinger hijacks outdated routers via old flaws, turning 4,300+ devices into a stealth network for reconnaissance and intrusion support.

On March 12, 2026, QiAnXin’s XLab threat detection system flagged a single IP address, 107.150.106.14, spreading a Linux binary through two vulnerabilities that were disclosed in 2013 and 2016 respectively. The binary had zero detections on VirusTotal. The devices it targeted were routers built on Realtek’s RTL819X chips, hardware that was mainstream between 2012 and 2015 and has received no firmware updates since. XLab named the malware family AryStinger, based on a source code path hint that the project is called Ary-Attack.

The first thing that sets AryStinger apart is what it doesn’t do. It doesn’t encrypt files. It doesn’t mine cryptocurrency.

“Let’s turn the clock back to March 12, 2026, when the XLab Network-wide Threat Awareness System detected IP 107.150.106.14 spreading a VT 0-detection ELF sample implemented in C through the old vulnerabilities CVE-2013-3307 and CVE-2016-5681″ reads the report published by XLab. “Unlike the common practice of exploiting IoT device vulnerabilities to build DDoS or mining botnets, this campaign aims to build an infrastructure cluster for intrusion reconnaissance activities, possessing information-gathering capabilities such as port scanning, service identification, and subdomain enumeration.”

Each infected router becomes what XLab calls an Executor: a node that receives scan tasks, executes them in parallel with other nodes, and ships the results back to the operator, while hiding the attacker’s real location behind a relay layer.

The infection base currently sits at over 4,300 routers worldwide, a figure XLab says is still rising. It covers only RTL819X devices; the NAS infection scale has no measurement yet. The infected pool is dominated by D-Link hardware, with the DIR-850L accounting for roughly 75% of identified devices. By country, South Korea leads at 48%, followed by China at 32%, then Sweden, Malaysia, and Singapore. None of these are countries that stopped manufacturing security tools. They’re just countries with a lot of old routers that nobody replaced.

The researchers found two separate builds of AryStinger. The RTL819X version is written in C and deliberately stripped down, because the old hardware simply can’t run more. It focuses on mass DNS scanning and traffic tunneling, communicates with its C2 over HTTP using Protobuf-encoded traffic obfuscated with XOR encryption using the hardcoded key sh_#@!_2024_secret, and establishes persistence by downloading Dropbear SSH and running it on port 2332.

A second build, written in Go, appeared on April 26 targeting NAS devices through CVE-2025-11837, a code injection vulnerability in QNAP’s Malware Remover that was demonstrated at Pwn2Own Ireland 2025 and patched in November 2025. Whoever is running AryStinger was exploiting it within five months of the patch. That’s a shorter window than most enterprise patch cycles.

The Go build is considerably more capable. It integrates fscan for internal network scanning, ksubdomain and httpx for subdomain and web service reconnaissance, and Tlsx for TLS fingerprinting. Its most flexible feature is ScriptWork, which executes attacker-supplied source code directly on the infected device.

“ScriptWork supports executing Shell commands as well as source-level Payloads in three categories: Go, Java, and Python.” continues the report. “This design greatly enhances the attacker’s operational flexibility: there is no need to compile binary files separately for different platforms, nor to care about the specific architecture of the target device—it only needs to directly issue the source code to dynamically execute it.”

The downside for the attacker is that source code drops to disk in plaintext and interpreter command lines appear in audit logs, making it more detectable than in-memory binary execution.

The distributed task architecture is the operationally clever part.

“The attacker can split a massive scanning task into multiple small chunks and distribute them to different Executors for parallel execution.” continues the report. “With this distributed-like design, the attacker can efficiently complete the early “footprinting” activities, thereby providing strong assurance for the smoothness and success rate of subsequent intrusion operations.”

XLab confirmed this by running a test device and watching the C2 assign a .ba top-level domain brute-force task with an offset value of 11,654,000,000, placing that specific node at roughly 12% into the length-7 subdomain scanning space. The fleet collectively covers the entire space without any single node doing more than its assigned slice.

The hardcoded key sh_#@!_2024_secret contains “2024,” which may indicate the operation started before XLab’s March 2026 detection. That’s a detail that matters: if the infrastructure has been running since 2024, the reconnaissance data it has already collected could be substantial. XLab hasn’t attributed AryStinger to any known threat actor and says the investigation is ongoing.

“Although many mysteries surrounding AryStinger remain to be solved, the mere fact of its targeted attacks against old routers is enough to define it as a real threat not to be underestimated.” continues the report.

“As a key device for daily internet access, once a router is illegally compromised, it will not only threaten personal privacy and property security, but may even endanger national security.” the Ministry of State Security warned. 

The operational pattern, end-of-life routers compromised through n-day vulnerabilities and turned into relay infrastructure for the pre-intrusion phase, matches what Mandiant and others have documented as Operational Relay Box networks, or ORBs, used by state-linked actors.

“Even more concerning is that this malicious sample and its associated C2 servers have an extremely low detection rate in mainstream security engines.” states the report. “It is precisely in view of the compounded risk of this “low detection rate” and “high potential harm” that we decided to write this article and share our research findings with the security community, in the hope of jointly addressing potential risks and safeguarding overall network security.”

Whether AryStinger is state-sponsored or criminal infrastructure being sold as initial access capability, the model is the same: forgotten hardware, ancient CVEs, quiet and hard to detect.

The remediation guidance is straightforward. Check for outbound connections to AryStinger’s C2 and download infrastructure, primarily ajb8.com, dataexplore.cc, and dataexplore.co hostnames. Check /tmp/bin for binaries you didn’t put there. Look for processes named syswapd0h or syswapd0w. The lasting fix is the one that never gets implemented fast enough: retire hardware that stopped receiving firmware updates years ago. A router running code from 2015 is not a network security device. It’s a vulnerability with an ethernet port.

“Once compromised by malware like AryStinger that possesses reconnaissance and covert control capabilities, it is equivalent to a hacker placing a permanent “invisible listening device” and “attack springboard” within your network.” concludes the report. “There is no doubt that when a large number of old devices are gradually compromised and aggregated, ultimately forming a massive covert botnet, this will pose a continuous, covert, and highly destructive real threat to personal privacy, enterprise security, and even national critical network infrastructure.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, malware)