CVE-2026-57331: Critical File Deletion in Videochat Plugin
| Field | Value |
|---|---|
| CVE ID | CVE-2026-57331 |
| CVSS score | 9.9 (NVD) |
| Attack vector | Unknown from available source data |
| Authentication required | Not fully confirmed; NVD wording suggests performer-level privileges |
| Patch status | Update available; current public plugin version observed is 7.5.6 |
TL;DR - CVE-2026-57331 is a critical arbitrary file deletion flaw in the WordPress plugin Paid Videochat Turnkey Site. - Affects versions up to and including 7.4.8; upgrade immediately to a version newer than 7.4.8, ideally current 7.5.6. - No confirmed in-the-wild exploitation or public PoC is currently documented.
Vulnerability at a glance
CVE-2026-57331 is a critical vulnerability in the WordPress plugin Paid Videochat Turnkey Site – HTML5 PPV Live Webcams by videowhisper, plugin slug ppv-live-webcams. The National Vulnerability Database describes the issue as “Performer Arbitrary File Deletion in Paid Videochat Turnkey Site <= 7.4.8 versions.” NVD assigns a CVSS 9.9 severity rating, which makes this an urgent remediation item for any site running the plugin.
The confirmed affected range is “versions up to and including 7.4.8.” The official WordPress.org plugin page showed 7.5.6 as the current public version at the time of research. That means defenders have a newer release available, but the exact first fixed version number was not explicitly confirmed in the source material reviewed. In practice, administrators should treat all installations on 7.4.8 or earlier as vulnerable and move directly to the latest available release rather than trying to pinpoint an intermediate safe version.
What is still unknown
Several important technical details remain unconfirmed from the source material reviewed. Those include the exact CVSS vector string, the exact vulnerable endpoint or function, the precise root cause mechanics, and the exact first fixed version number. The Patchstack advisory existence was confirmed, but the detailed body was not fully extractable from the retrieved content used for this article.
When details are unknown, defenders should avoid filling gaps with assumptions. The right operational assumption here is conservative: the vulnerability is real, serious, affects all versions through 7.4.8, and warrants immediate upgrade to the latest available release. If and when vendor changelogs, patch diffs, or additional researcher analysis become available, use them to refine detections and verify whether any compensating controls can reduce residual risk.
What the bug means in practice
An arbitrary file deletion vulnerability allows an attacker to cause the application to delete files that should not be deletable. In a WordPress deployment, that can have effects ranging from nuisance to major outage. Possible outcomes include removal of media assets, plugin files, temporary files, generated content, or in worse cases application files whose absence breaks the site or related workflows.
Even when a file deletion flaw does not immediately translate to remote code execution, it is still operationally serious. Deleting the wrong file can disable authentication flows, break payment or streaming features, interrupt content delivery, or create recovery windows during which an attacker tries a second stage. For SMBs running revenue-generating live chat or webcam services, the business impact can be immediate: downtime, lost transactions, support load, and time spent restoring files from backup.
Affected products and versions
The affected software is the WordPress plugin Paid Videochat Turnkey Site – HTML5 PPV Live Webcams by videowhisper. The plugin slug is ppv-live-webcams, which is the easiest identifier to use for asset inventory, plugin file path checks, or WP-CLI validation. The official plugin listing confirms the product identity and current distribution channel.
The vulnerable version range is clearly stated as “<= 7.4.8”, meaning all versions up to and including 7.4.8 should be considered exposed. The currently observed public plugin version is 7.5.6. Because the exact first fixed version is unknown from the available advisory text, defenders should not assume that every version above 7.4.8 is necessarily identical from a fix perspective. The safest operational guidance is: upgrade to the latest available version from WordPress.org, currently 7.5.6, and verify the upgrade completed successfully.
Exploitation status and what defenders should assume
At the time of writing, there is no confirmed evidence of exploitation in the wild for CVE-2026-57331 from the sources reviewed. The CVE is not listed in CISA KEV, so there is no authoritative CISA confirmation of active exploitation. There is also no confirmed public proof of concept identified in the gathered source material.
That absence of public exploitation data should not be treated as reassurance. In WordPress ecosystems, vulnerable plugins are often scanned and tested quickly once CVE metadata becomes public, especially when the issue involves file handling and the severity is critical. Since the root cause details were not fully available in the retrieved advisory text, defenders should assume that weaponization could happen rapidly after disclosure. If you operate a publicly exposed site with this plugin, treat this as a patch-now issue rather than a monitor-and-wait case.
Authentication and attack surface
The NVD description uses the term “Performer Arbitrary File Deletion.” That wording suggests the bug may require a performer-level account or role within the plugin’s own access model. However, this requirement was not fully confirmed with complete technical detail in the available source set. Specifically, the exact endpoint, parameter, nonce handling, and authorization checks were not exposed in the retrieved advisory content.
Because of that uncertainty, defenders should take a conservative stance. Assume that any user role mapped to performer functionality in the plugin could be a potential abuse path until the vendor or a fuller advisory confirms otherwise. If your deployment uses delegated performer, host, talent, or content-creator accounts, review those assignments immediately. Also consider the common real-world scenario where lower-privilege accounts are easier to compromise through password reuse, phishing, or credential stuffing than administrator accounts.
Technical Notes
Use WP-CLI to identify installed version and plugin state:
wp plugin list --format=table | grep ppv-live-webcams
wp plugin get ppv-live-webcams --fields=name,status,version,update_version
Manually verify plugin files on disk:
ls -ld wp-content/plugins/ppv-live-webcams
grep "Version:" wp-content/plugins/ppv-live-webcams/*.php
If you manage multiple sites, a simple shell loop can help find affected versions:
for site in /var/www/*; do
if [ -d "$site/public_html/wp-content/plugins/ppv-live-webcams" ]; then
echo "[*] Found plugin in $site"
grep "Version:" "$site"/public_html/wp-content/plugins/ppv-live-webcams/*.php 2>/dev/null
fi
done
Risk prioritization for practitioners
Despite limited public technical detail, the risk is high for three reasons. First, the CVSS 9.9 score from NVD puts this in the critical band. Second, file deletion issues in WordPress often produce immediate operational harm even before a more complex attacker objective is achieved. Third, the plugin appears to be actively distributed and used in internet-facing use cases, which raises the chance of rapid opportunistic scanning once the CVE is indexed by defenders and attackers alike.
For security teams triaging patch queues, this should sit near the top for any environment where the plugin is installed. For SMB owners without a dedicated SOC, the practical order of operations is straightforward: identify whether the plugin exists, confirm whether the version is 7.4.8 or earlier, back up the site, update to the latest release, and then review logs for signs of prior abuse. If your site experienced unexplained missing files recently, investigate as a potential security incident rather than only a stability problem.
Additional Resources
For further reading on securing your WordPress site, check out our articles on how to choose endpoint protection for a small business and the best password managers for teams.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection and hunting guidance
Detection is difficult here because the exact vulnerable function and request shape are not yet confirmed from primary-source advisory text. That means defenders cannot rely on a single canonical IOC such as a fixed URI, parameter name, or known exploit payload. Instead, detection should focus on unexpected file deletion activity, plugin role actions, and administrative changes or errors around the plugin path.
Start by reviewing web server logs and WordPress logs around any period of unexplained media loss, plugin breakage, or site errors after performer activity. Because the issue likely involves file operations, host-level telemetry can be more valuable than application telemetry. File integrity monitoring, auditd, EDR file delete events, and abrupt changes under wp-content/ should all be part of the hunt. If logs are sparse, compare current filesystem state against backup inventories or deployment manifests to identify missing files.
Technical Notes
Look for suspicious requests referencing the plugin slug in Apache or Nginx logs:
grep -R "ppv-live-webcams" /var/log/apache2/* /var/log/nginx/* 2>/dev/null
Example generic access-log pattern to investigate:
POST /wp-admin/admin-ajax.php HTTP/1.1
POST /?action=... HTTP/1.1
GET /wp-content/plugins/ppv-live-webcams/...
If you have Linux auditd enabled, hunt for file deletions under WordPress paths:
ausearch -k wordpress-delete -ts recent
ausearch -f /var/www/html/wp-content/ -m PATH,SYSCALL -ts recent
Example auditd rule to add for ongoing monitoring:
auditctl -w /var/www/html/wp-content/ -p wa -k wordpress-delete
A simple Sigma-style idea for web logs is to flag requests to admin-ajax.php or plugin-specific endpoints followed closely by file-not-found spikes:
title: Possible WordPress plugin abuse followed by file deletion symptoms
logsource:
product: webserver
detection:
selection1:
cs-uri-stem|contains:
- "/wp-admin/admin-ajax.php"
- "ppv-live-webcams"
selection2:
sc-status:
- 404
- 500
timeframe: 10m
condition: selection1 followed_by selection2
In WordPress environments with debug logging enabled, also inspect for sudden warnings tied to missing files after plugin actions:
grep -E "No such file|failed to open stream|include\(|require\(" wp-content/debug.log 2>/dev/null
Mitigation and patching
The primary mitigation is to upgrade immediately. The confirmed vulnerable range is “<= 7.4.8”. The official plugin directory showed 7.5.6 as the current public version, and that is the safest target based on available evidence. Since the exact first fixed version is not confirmed, do not stop at “any version above 7.4.8” unless you have independently verified the vendor changelog or patch notes.
If you cannot patch immediately, reduce exposure by limiting who can access the plugin’s performer-related features, disabling the plugin temporarily if business operations allow, and increasing monitoring on WordPress filesystem paths. Because the likely abuse path involves authenticated or semi-authenticated plugin actions, compensating controls around account security matter: enforce password resets for performer accounts, require MFA where possible at the WordPress or SSO layer, and remove stale accounts.
Technical Notes
Upgrade with WP-CLI:
wp plugin update ppv-live-webcams
wp plugin get ppv-live-webcams --fields=name,status,version
If you need to pin to the latest available package from WordPress.org and verify afterward:
wp plugin install ppv-live-webcams --force
wp plugin activate ppv-live-webcams
wp plugin list --format=table | grep ppv-live-webcams
Temporary containment if patching must wait:
wp plugin deactivate ppv-live-webcams
Basic backup before change:
tar -czf /root/wp-content-backup-$(date +%F).tar.gz /var/www/html/wp-content
mysqldump -u root -p wordpress > /root/wordpress-$(date +%F).sql
Example file-permission hardening is environment-specific, but at minimum verify the web server user cannot delete beyond intended writable directories. If you use immutable infrastructure or read-only deployments for plugin code, confirm those controls actually prevent runtime deletion attempts.