Someone left the loading-dock door unlocked, the alarm off, and a forklift key in the ignition
CVE-2026-57827 is an unauthenticated arbitrary file upload in RSFiles! (com_rsfiles), a file-manager and download component for Joomla CMS. Versions prior to 1.17.12 contain a split-controller design flaw: the upload workflow is separated into a *pre-flight check* (which validates permissions and file extensions) and a *write method* (which actually saves the file). The write method can be invoked directly via task=rsfiles.upload, bypassing all security controls — no session, no CSRF token, no file-type check. Because the default installation leaves .htaccess PHP-execution protection disabled in the /downloads/ folder, an attacker drops a PHP webshell in one POST and executes it immediately. The result is full remote code execution as the web-server user. Affected: all RSFiles! releases ≤ 1.17.11. Fixed in 1.17.12, released 2026-07-10.
The vendor's CVSS 3.1 score of 9.8 is accurate and, if anything, conservative — the CVSS 4.0 score from some databases is 10.0. This is a single-request, zero-prerequisite, unauthenticated RCE against an internet-facing application with a publicly weaponized exploit and a Nuclei scanning template. There are no configuration prerequisites that narrow the vulnerable population; the default install is exploitable. The only reason this isn't dominating CISA KEV is likely the relatively niche install base (~38k lifetime downloads). For any organization that *does* run RSFiles!, the vendor severity is dead-on.
4 steps from start to impact.
Discover target
/index.php?option=com_rsfiles or the presence of /components/com_rsfiles/ in page source is a reliable indicator. Bulk discovery is trivial via search-engine dorking (inurl:com_rsfiles) or Nuclei's template scan. Mass-scanning PoC tooling (shinthink/CVE-2026-57827) supports threaded target lists out of the box.- Target runs Joomla with RSFiles! < 1.17.12 and is internet-accessible
- RSFiles! has a relatively small install base (~38k lifetime downloads); most Joomla sites do not have it
com_rsfiles identify exposed instances.Craft and send unauthenticated upload
POST to /index.php?option=com_rsfiles&task=rsfiles.upload with a PHP webshell payload (e.g., <?php system($_GET['cmd']); ?>), specifying folder= (root downloads dir) and overwrite=1. No authentication cookie, no CSRF token, no session of any kind is required. The write method accepts the file without checking extension, MIME type, or file signature.- HTTP(S) connectivity to the Joomla site
- None — endpoint is reachable by any anonymous visitor
Execute webshell
/downloads/ directory. Because the default RSFiles! installation does not enable .htaccess PHP-execution denial in that folder, the attacker simply requests /downloads/shell.php?cmd=id to execute arbitrary OS commands as the web-server user (typically www-data or apache). From here, the attacker has full RCE on the host.- Default RSFiles! configuration (no custom .htaccess blocking PHP in /downloads/)
- A hardened host with a restrictive
.htaccessorphp_admin_value engine offin the vhost config would block execution — but this is non-default and rare
.php files under /downloads/. Endpoint detection of unexpected child processes spawned by the web server process.Post-exploitation: pivot or persist
configuration.php to extract database credentials, dumps user tables (including admin password hashes), installs persistent backdoors (cron jobs, SSH keys), and scans the internal network for lateral movement targets. If the Joomla host sits in a flat network or DMZ with internal access, this is a beachhead for further compromise.- Web server user has file-read access to Joomla config (standard)
- Network segmentation and EDR on the host may limit lateral movement
- Containerized or read-only filesystem deployments limit persistence
com_rsfiles entirely eliminates the attack surface with zero side effects to the rest of Joomla. This is the fastest mitigation and should be deployed within the noisgate mitigation SLA of ≤ 3 days for CRITICAL findings. Use Joomla's Extension Manager → Manage → select RSFiles! → Unpublish (to disable) or Uninstall (to remove)./index.php where the query string matches option=com_rsfiles&task=rsfiles.upload (or any task=rsfiles.* pattern). This stops the exploit at the network edge before it reaches PHP. Deploy within ≤ 3 days. Example nginx: location / { if ($args ~* "option=com_rsfiles.*task=rsfiles.upload") { return 403; } }. Test that legitimate admin uploads still work via a different path or are handled post-patch..htaccess file (Apache) or location block (nginx) to the RSFiles! downloads directory that prevents PHP execution: php_flag engine off or location ~* /downloads/.*\.php$ { deny all; }. This breaks the final step of the chain — even if a file is uploaded, it cannot execute. Deploy within ≤ 3 days. Note: this does NOT prevent the upload itself, so uploaded malware persists on disk..htaccess protection by default. Apply within the noisgate remediation SLA of ≤ 90 days for CRITICAL findings — though given the trivial exploitability, patching within days is strongly recommended..php, .phtml, .phar, or .shtml files created in the RSFiles! downloads directory or its subdirectories. This is a detective control — it won't prevent exploitation but ensures you detect it within minutes. Deploy alongside any other compensating control.- Joomla's built-in ACL / user permissions — the vulnerability bypasses Joomla's permission system entirely by calling the write method directly; no Joomla-level permission setting will help.
- CSRF token configuration in Joomla global settings — the vulnerable endpoint ignores tokens regardless of global Joomla CSRF settings; only the patched version enforces token checks on this specific task.
- Upload file-size limits — a PHP webshell can be as small as 30 bytes (
<?php system($_GET['c']);); file-size restrictions provide no meaningful barrier. - IP-based rate limiting alone — the exploit requires only a single request; rate limiting will not prevent a determined attacker from landing the initial shell.
The supporting signals.
| In-the-Wild Exploitation | No confirmed campaigns. Not listed in CISA KEV. No GreyNoise tags observed as of 2026-10-06. However, the availability of mass-scanning PoC tooling makes opportunistic exploitation highly likely against exposed instances. |
|---|---|
| Proof-of-Concept | Two public GitHub repos: shinthink/CVE-2026-57827 (Python 3.8+, 16 stars, 1 fork — includes threaded mass-scanning, shell cleanup) and Candisexterior171/CVE-2026-57827 (Python, 0 stars). Nuclei template available in the ProjectDiscovery templates repository. Exploit is single-request, trivially reproducible. |
| EPSS | 0.02328 (2.33%) — places this in approximately the top 5% of all scored CVEs. For a niche Joomla extension, this is a notably elevated probability of exploitation in the next 30 days. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — 9.8 Critical. Network-attackable, low complexity, no privileges, no user interaction. Full CIA impact. CVSS 4.0 scores at 10.0 due to downstream scope impact. Every metric is worst-case. |
| Affected Versions | RSFiles! for Joomla ≤ 1.17.11 (all versions). The flawed split-controller upload design has been present for years. |
| Fixed Version | RSFiles! 1.17.12 (released 2026-07-10). Fix adds CSRF token enforcement, permission checks in the write method, extension allow-list validation, and enables .htaccess PHP-execution denial in /downloads/ by default. |
| Install Base / Exposure | RSFiles! has ~38,709 lifetime downloads per rsjoomla.com. Joomla powers ~1.2% of CMS-driven sites (~111k active business domains per W3Techs). RSFiles! is a fraction of that. Niche but entirely internet-facing — every instance is reachable. |
| Disclosure Timeline | 2026-07-09: Phil Taylor (mySites.guru) discovers flaw during source-code audit. 2026-07-10: Private disclosure to RSJoomla; vendor ships 1.17.12 same day. 2026-07-11: CVE-2026-57827 assigned. |
| Researcher | Phil Taylor of mySites.guru. Identified via source-code audit of commonly installed Joomla extensions. Part of a broader Joomla security disclosure series. |
| Scanner Coverage | Nuclei template available (CVE-2026-57827). SentinelOne, BitNinja, and OpenCVE track this CVE. No Qualys/Tenable QID confirmed in search, but generic CWE-434 upload checks in web application scanners should flag the endpoint. |
Sources.
- mySites.guru — RSFiles! 1.17.12 RCE Fix (Original Disclosure)
- GitHub — shinthink/CVE-2026-57827 PoC (16 stars)
- BitNinja — Critical Joomla Extension Threat: CVE-2026-57827
- SentinelOne Vulnerability Database — CVE-2026-57827
- OpenCVE — CVE-2026-57827 Details
- RSJoomla — RSFiles! Official Product Page
- GitHub — Candisexterior171/CVE-2026-57827 PoC
Why this verdict
- Zero-friction attack chain: The exploit is a single unauthenticated HTTP POST with no prerequisites — no credentials, no CSRF token, no user interaction, no special configuration. The default install is vulnerable. This is the lowest possible attacker cost for RCE.
- Public weaponization: Two GitHub PoC repos exist, one with mass-scanning and threading support. A Nuclei detection template exists. The exploit is copy-paste simple — a
curlone-liner can pop a shell. This lowers the attacker skill requirement to near-zero. - Internet-facing by definition: RSFiles! is a Joomla front-end component. Every instance is reachable from the internet. There is no 'internal-only deployment' scenario that narrows the exposed population.
- Role multiplier: Joomla web servers are not in the high-value-role catalog (not DCs, hypervisors, CI/CD, PKI, backup, or edge appliances). Typical deployment is a public-facing website or download portal. However, compromise of the web server yields: database credentials (Joomla
configuration.php→ MySQL/PostgreSQL), all CMS user credentials, potential PII in the database, and a network beachhead. In flat-network environments, this is a pivot to internal infrastructure. The blast radius is host → database → potential lateral movement — not fleet-scale, but a full site compromise with data-exfiltration and beachhead value. - No friction points to downgrade: Unlike many CVEs where authentication, network position, or non-default configuration requirements introduce compounding downward pressure, this CVE has *none*. Every metric in the CVSS vector is worst-case. The vendor's 9.8 is accurate.
Why not higher?
The CVSS 3.1 ceiling is 10.0 (Scope Changed), and this scores 9.8 (Scope Unchanged) because compromise of the Joomla host does not automatically cascade into other security domains without additional attacker effort. The CVSS 4.0 score of 10.0 accounts for downstream impact, but under CVSS 3.1 the 9.8 is the correct maximum for this attack profile. There is no technical basis to score higher.
Why not lower?
There is no friction in this attack chain that would justify a downgrade. The exploit requires zero authentication, zero user interaction, works against the default configuration, and public weaponized tooling exists with mass-scanning support. The only argument for lower severity — the niche install base — is an *exposure* metric, not a *severity* metric; it tells you how many hosts to search your inventory for, not how urgently to patch the ones you find. For any organization running RSFiles!, this is unambiguously critical.
Crowdsourced verification payload.
Run this script on each Joomla host (or from an auditor workstation with HTTP access to the target). Invoke as: bash check_cve_2026_57827.sh https://example.com. No special privileges required — it performs read-only HTTP checks and local file inspection if run on the host. Returns exit code 0 for PATCHED, 1 for VULNERABLE, 2 for UNKNOWN.
#!/usr/bin/env bash
# check_cve_2026_57827.sh — Detect RSFiles! < 1.17.12 (CVE-2026-57827)
# Usage: bash check_cve_2026_57827.sh <JOOMLA_BASE_URL>
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -euo pipefail
URL="${1:-}"
if [[ -z "$URL" ]]; then
echo "Usage: $0 <JOOMLA_BASE_URL>"
exit 2
fi
# Strip trailing slash
URL="${URL%/}"
echo "[*] Checking $URL for CVE-2026-57827 (RSFiles! < 1.17.12)"
# Method 1: Check if com_rsfiles is reachable
HTTP_CODE=$(curl -sk -o /dev/null -w '%{http_code}' "${URL}/index.php?option=com_rsfiles" 2>/dev/null || echo "000")
if [[ "$HTTP_CODE" == "000" ]]; then
echo "[!] Cannot reach target. Check URL and connectivity."
echo "UNKNOWN"
exit 2
fi
if [[ "$HTTP_CODE" == "404" ]] || [[ "$HTTP_CODE" == "500" ]]; then
echo "[+] com_rsfiles not found (HTTP $HTTP_CODE). Component likely not installed."
echo "PATCHED"
exit 0
fi
echo "[*] com_rsfiles responded with HTTP $HTTP_CODE — component is present."
# Method 2: Try to read the manifest version from the filesystem (local only)
MANIFEST="/administrator/components/com_rsfiles/rsfiles.xml"
if [[ -f "$MANIFEST" ]]; then
VERSION=$(grep -oP '<version>\K[^<]+' "$MANIFEST" 2>/dev/null || echo "")
if [[ -n "$VERSION" ]]; then
echo "[*] Local manifest version: $VERSION"
# Compare version — vulnerable if < 1.17.12
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
PATCH=$(echo "$VERSION" | cut -d. -f3)
if [[ "$MAJOR" -lt 1 ]] || \
[[ "$MAJOR" -eq 1 && "$MINOR" -lt 17 ]] || \
[[ "$MAJOR" -eq 1 && "$MINOR" -eq 17 && "$PATCH" -lt 12 ]]; then
echo "[!] RSFiles! $VERSION is VULNERABLE (< 1.17.12)"
echo "VULNERABLE"
exit 1
else
echo "[+] RSFiles! $VERSION is PATCHED (>= 1.17.12)"
echo "PATCHED"
exit 0
fi
fi
fi
# Method 3: Remote version check via manifest XML (often accessible)
REMOTE_XML=$(curl -sk "${URL}/administrator/components/com_rsfiles/rsfiles.xml" 2>/dev/null || echo "")
if echo "$REMOTE_XML" | grep -q '<version>'; then
VERSION=$(echo "$REMOTE_XML" | grep -oP '<version>\K[^<]+' || echo "")
if [[ -n "$VERSION" ]]; then
echo "[*] Remote manifest version: $VERSION"
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
PATCH=$(echo "$VERSION" | cut -d. -f3)
if [[ "$MAJOR" -lt 1 ]] || \
[[ "$MAJOR" -eq 1 && "$MINOR" -lt 17 ]] || \
[[ "$MAJOR" -eq 1 && "$MINOR" -eq 17 && "$PATCH" -lt 12 ]]; then
echo "[!] RSFiles! $VERSION is VULNERABLE (< 1.17.12)"
echo "VULNERABLE"
exit 1
else
echo "[+] RSFiles! $VERSION is PATCHED (>= 1.17.12)"
echo "PATCHED"
exit 0
fi
fi
fi
# Method 4: Probe the vulnerable endpoint (safe — no actual upload)
# A HEAD/OPTIONS to the upload task; patched versions return 403 or require token
PROBE_CODE=$(curl -sk -o /dev/null -w '%{http_code}' -X OPTIONS "${URL}/index.php?option=com_rsfiles&task=rsfiles.upload" 2>/dev/null || echo "000")
echo "[*] Upload endpoint probe returned HTTP $PROBE_CODE"
if [[ "$PROBE_CODE" == "200" ]]; then
echo "[!] Upload endpoint is accessible without authentication — likely VULNERABLE"
echo "VULNERABLE"
exit 1
elif [[ "$PROBE_CODE" == "403" ]] || [[ "$PROBE_CODE" == "302" ]]; then
echo "[+] Upload endpoint returned $PROBE_CODE — likely PATCHED or protected"
echo "PATCHED"
exit 0
fi
echo "[?] Could not definitively determine RSFiles! version or patch status."
echo "UNKNOWN"
exit 2