← Back to Feed CACHED · 2026-10-06 13:51:30 · CACHE_KEY CVE-2026-57827
CVE-2026-57827 · CWE-434 · Disclosed 2026-07-11

RSFiles! Joomla Component Unauthenticated Arbitrary File Upload to RCE

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Zero-friction unauthenticated RCE with public exploit tooling. Patch or disable immediately."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Discover target

Attacker fingerprints Joomla sites running the RSFiles! component. The path /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.
Conditions required:
  • Target runs Joomla with RSFiles! < 1.17.12 and is internet-accessible
Where this breaks in practice:
  • RSFiles! has a relatively small install base (~38k lifetime downloads); most Joomla sites do not have it
Detection/coverage: Nuclei template for CVE-2026-57827 available. Shodan/Censys/FOFA queries for com_rsfiles identify exposed instances.
STEP 02

Craft and send unauthenticated upload

Attacker sends a single multipart 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.
Conditions required:
  • HTTP(S) connectivity to the Joomla site
Where this breaks in practice:
  • None — endpoint is reachable by any anonymous visitor
Detection/coverage: WAF rules matching multipart uploads containing PHP tags or executable extensions to Joomla upload endpoints. ModSecurity CRS rules 933100-933210 (PHP injection) may catch basic payloads but are bypassable with encoding.
STEP 03

Execute webshell

The uploaded file lands in the web-accessible /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.
Conditions required:
  • Default RSFiles! configuration (no custom .htaccess blocking PHP in /downloads/)
Where this breaks in practice:
  • A hardened host with a restrictive .htaccess or php_admin_value engine off in the vhost config would block execution — but this is non-default and rare
Detection/coverage: File integrity monitoring (FIM) on the downloads directory. Web server access logs showing GET requests to .php files under /downloads/. Endpoint detection of unexpected child processes spawned by the web server process.
STEP 04

Post-exploitation: pivot or persist

With OS-level command execution, the attacker reads Joomla's 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.
Conditions required:
  • Web server user has file-read access to Joomla config (standard)
Where this breaks in practice:
  • Network segmentation and EDR on the host may limit lateral movement
  • Containerized or read-only filesystem deployments limit persistence
Detection/coverage: EDR alerts on web-server process spawning shells. Database access from unexpected sources. Outbound C2 connections from the web server.
03 · Compensating Control

1
CRITICAL 9.8→IGNORE 0.0
SEVERITY REDUCED
Disable or uninstall RSFiles! immediately — If RSFiles! is not business-critical, removing 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).
2
CRITICAL 9.8→LOW 2.5
SEVERITY REDUCED
Block the upload endpoint at WAF or reverse proxy — Add a WAF rule or nginx/Apache location block denying POST requests to /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.
3
CRITICAL 9.8→MEDIUM 5.0
SEVERITY REDUCED
Deny PHP execution in the /downloads/ directory — Add an .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.
4
CRITICAL 9.8→IGNORE 0.0
SEVERITY REDUCED
Upgrade RSFiles! to 1.17.12+ — The definitive fix. Version 1.17.12 adds CSRF token enforcement, permission checks in the write method, extension allow-list validation, and enables .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.
5
CRITICAL 9.8→HIGH 8.0
SEVERITY REDUCED
Deploy file integrity monitoring on the downloads directory — Configure FIM (OSSEC, Wazuh, Tripwire, or EDR file-monitoring) to alert on any new .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.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNo 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-ConceptTwo 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.
EPSS0.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 VectorCVSS: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 VersionsRSFiles! for Joomla ≤ 1.17.11 (all versions). The flawed split-controller upload design has been present for years.
Fixed VersionRSFiles! 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 / ExposureRSFiles! 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 Timeline2026-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.
ResearcherPhil Taylor of mySites.guru. Identified via source-code audit of commonly installed Joomla extensions. Part of a broader Joomla security disclosure series.
Scanner CoverageNuclei 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.

  1. mySites.guru — RSFiles! 1.17.12 RCE Fix (Original Disclosure)
  2. GitHub — shinthink/CVE-2026-57827 PoC (16 stars)
  3. BitNinja — Critical Joomla Extension Threat: CVE-2026-57827
  4. SentinelOne Vulnerability Database — CVE-2026-57827
  5. OpenCVE — CVE-2026-57827 Details
  6. RSJoomla — RSFiles! Official Product Page
  7. GitHub — Candisexterior171/CVE-2026-57827 PoC
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.8/10)

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 curl one-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.

06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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