Safeguard
Vulnerability Analysis

ThreatSonar, Control Web Panel, and XWiki: When Under-the-Radar Software Gets Popped

An unauthenticated eval injection in XWiki, a known-username command injection in Control Web Panel, and a file-upload RCE in an anti-ransomware tool itself — three vendors, one lesson.

Safeguard Research Team
4 min read

Three vulnerabilities across three unrelated vendors — TeamT5's ThreatSonar Anti-Ransomware, CWP's Control Web Panel, and XWiki Platform — each produced a confirmed-exploited command or code execution finding within the same twelve-month window, and each illustrates the same underlying problem: smaller, less-scrutinized self-hosted software carrying the same severity of vulnerability as any major platform, with far less attention paid to it.

CVECVSSVendorAdded to KEV
CVE-2025-248939.8XWiki Platform30 Oct 2025
CVE-2025-487039.0CWP Control Web Panel4 Nov 2025
CVE-2024-76947.2TeamT5 ThreatSonar17 Feb 2026

Why these three unrelated products belong in the same conversation

None of these vendors share a product category, a customer base, or a codebase — but each produced a vulnerability that lets an attacker execute arbitrary code on a self-hosted server, and each illustrates a different point on the authentication spectrum for how little an attacker needs to reach that outcome. CVE-2025-24893 requires nothing at all: NVD's own reproduction steps show an unauthenticated guest reaching eval injection through a request to XWiki's SolrSearch feature, with the vulnerable code path evaluating attacker-controlled Groovy script content embedded in a URL parameter. CVE-2025-48703 requires only a known, valid non-root username — no password — to achieve OS command injection through shell metacharacters in Control Web Panel's file manager. CVE-2024-7694 requires the attacker to already hold administrator privileges on the ThreatSonar platform itself, at which point they can upload a malicious file that executes arbitrary system commands on the server.

That gradient — zero authentication, a known username with no password, and existing admin privileges — describes three different points on the same underlying failure: each product trusted input (a search parameter, a filemanager request, an uploaded file) that should have been treated as hostile, and none of the three had the kind of dedicated application security review that a mainstream, heavily-scrutinized platform receives as a matter of course. TeamT5 ThreatSonar is a particularly sharp illustration of the point: it's a product marketed specifically as anti-ransomware defense, yet the vulnerability lets an attacker with elevated platform access plant exactly the kind of malicious payload the product exists to stop.

What to check this week

Patch XWiki to 15.10.11, 16.4.1, or 16.5.0RC1 or later immediately given the vulnerability's zero-authentication requirement — any unpatched, internet-reachable instance is exploitable by literally anyone who can reach it.

Patch Control Web Panel to a version beyond 0.9.8.1205, and treat any exposed non-root usernames as sensitive information, since a known username is the only precondition CVE-2025-48703 requires.

Audit administrator account provisioning on any ThreatSonar deployment, since CVE-2024-7694 requires existing admin access — the mitigation here is as much about controlling who holds that access as it is about patching.

Don't deprioritize these three simply because the vendors are less familiar — CVSS scores of 9.8 and 9.0 for two of these three are at the same severity tier as vulnerabilities in far larger, more widely-covered platforms.

Why the security research spotlight doesn't reach every product equally

Widely deployed platforms from major vendors attract continuous, adversarial security research — bug bounty programs, independent researchers, and dedicated internal security teams all probing the same widely-used code. Smaller or more specialized products like a regional wiki platform, a budget-friendly web hosting control panel, or a niche anti-ransomware tool simply don't attract that same density of scrutiny, which doesn't make them inherently less secure in their engineering, but does mean vulnerabilities in them can persist undiscovered and unpatched for longer, and organizations running them often have less community knowledge to draw on when something does surface.

A final consideration on self-hosted software specifically

All three of these products are typically self-hosted rather than delivered as managed SaaS, which means the patching decision rests entirely with each individual deploying organization rather than a vendor pushing updates centrally. That model has real advantages, but it also means the population of vulnerable, unpatched instances for a bug like these three can persist far longer than it would for a cloud service the vendor controls end-to-end — a gap attackers are well aware of and actively scan for.

How Safeguard helps

Safeguard's continuous inventory extends the same rigorous vulnerability tracking to smaller and less-scrutinized self-hosted platforms like ThreatSonar, Control Web Panel, and XWiki that it applies to major vendors, closing the visibility gap that lets under-the-radar software accumulate unpatched, critical-severity exposure.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.