/pcq/media/media_files/2025/11/17/rondodox-rises-as-xwiki-flaw-fuels-a-new-wave-of-internet-attacks-2025-11-17-16-12-55.jpg)
A major vulnerability in XWiki has created a serious opportunity for attackers. The vulnerability, identified as CVE-2025-24893, permits even guest users to execute remote code on a server through the /bin/get/Main/SolrSearch endpoint. With the vulnerability, anyone that finds the weakness will be able to execute commands on the system as if they were a member of the system. The XWiki team triaged and fixed the bug in February 2025 with updates to versions 15.10.11, 16.4.1, and 16.5.0RC1. However, many users were never updated, which would leave their servers vulnerable long after the bug was fixed.
Early signs of trouble
In March, attackers began attempting to exploit the bug in a quiet manner. These early attempts were small and easy to overlook. The real trouble began in late October when VulnCheck revealed coordinated activity exploiting the bug. Attackers began to utilize the bug to load cryptocurrency miners. A miner utilizes the victim's CPU for profit for the attacker while slowing down the server's performance. The issue escalated quickly and prompted CISA to add the bug to its list of Known Exploited Vulnerabilities and mandate federal agencies to patch the bug before November 20.
RondoDox Enters the Scene
How the Botnet Gets Going
While some miners were cashing in on the vulnerability, another group swooped in—a more aggressive bunch. They're the ones behind RondoDox, a botnet that lures in vulnerable devices and uses them to launch distributed denial of service attacks. These attacks just swamp a target with loads of traffic across all the usual protocols like HTTP, UDP & TCP. When they spotted unpatched XWiki servers going live, RondoDox pounced.
A Big Jump in Attacks
The first RondoDox exploit attempt linked to that vulnerability showed up on November 3, 2025. Within days VulnCheck saw a major spike in activity. Attempt after attempt just poured in with a peak on November 7, then a second surge on November 11. These attacks weren't coming from one source; they were happening all over the place. Multiple actors were all scrambling to find that one weakness & take control of as many systems as they could.
Some folks were trying to build these botnets, others were deploying mining rigs, and there were even some going for reverse shells to get in long-term. With automated scanning tools like Nuclei templates, even the not-so-skilled can just jump in with minimal fuss once a template is out there.
/filters:format(webp)/pcq/media/media_files/2025/11/17/hot-to-botnet-operates-2025-11-17-13-07-24.jpg)
This Affects Small Teams & Young Pros Too
The Risk You Might Be Overlooking
Young developers, students, small startups, and anyone using open-source tools like XWiki for projects, clubs, or side gigs are often running on cloud servers that they forget about once they're up & running. Attackers don't care who owns the machine; they just want to know if it responds. An unpatched service is all they need to take control.
What Happens After the Breach
Once the bad guys get in, the server can become a botnet node, a mining rig, or a backdoor for a deeper intrusion. Even more, it can be used to stash some nasty files or be a launchpad for other attacks. Often the owner doesn't even notice anything's wrong till the server starts slowing down or a cloud provider starts poking around.
Staying safe in a fast-moving threat environment
The message from XWiki is simple. When a vulnerability is made publicly known, the internet moves at high speed. An attacker finds an opportunity. Other attackers replicate the same tactic. Soon enough, thousands of systems will face the same threat. The only way to defend against this is to patch quickly and configure appropriately. Users should patch XWiki to a version that contains the patches, examine logs to see if there has been unauthorized access, disable guest accounts that are not needed, and avoid exposing administrative interfaces to the internet. If users regularly maintained the systems and patched quickly, compromising XWiki would not have made a difference, as botnets such as RondoDox could have been avoided.
Furthermore, the XWiki incident is simply another reminder of how a day or two delay in patching can lead to larger problems that could have been avoided. Such a simple patch could have determined the difference between compromising a user's system and having a secure system that was not being used as a host for an attacker evading detection.
More For You
GootLoader Returns with Sneaky Font Trick to Spread Malware Again
WhatsApp image hack Samsung Galaxy phones: Landfall spyware is secretly watching you
Google Warns of PromptFlux a New AI Threat Built on ChatGPT APIs
The Herodotus Trojan: How a new Android threat is outsmarting users and defenses
ChatGPT Atlas Browser Exploit: A New Pipeline for AI Data Theft
/pcq/media/agency_attachments/2025/02/06/2025-02-06t100846387z-pcquest-new-logo-png.png)
Follow Us