RSFiles! 1.17.12 File Upload RCE Fixed

RSFiles! is a widely used file-manager and download component for Joomla, installed as com_rsfiles and used to store, organise and serve downloads on business and membership sites. Up to and including version 1.17.11, its frontend upload had a serious flaw: the task that received an upload could be reached by anyone, with no login and no CSRF token, and the code that actually wrote the file to disk performed no check on its type. An attacker could upload a .php file into the public downloads folder and then run it, which is unauthenticated remote code execution, the worst outcome a web flaw can have.

RSJoomla fixed it in version 1.17.12, released on 10 July 2026. If you run Joomla sites with RSFiles! on them, update every one to 1.17.12 or later right now. This is not a wait-for-a-maintenance-window update. Any site still on 1.17.11 or earlier is reachable by anyone on the internet, so treat it as urgent and check it for tampering the moment it is patched. This post explains what the flaw was, how it surfaced, what the fix does, and how to check whether any of your sites were touched, without publishing anything an attacker could copy.

Unauthenticated and remotely exploitable, update immediately

This flaw needs no account on the site and ends in code running on your server. Update every RSFiles! install to 1.17.12 without waiting for a maintenance window, then check each patched site for stray files in the downloads folder and for unexpected admin accounts, because a site on an old version could already have been hit.

RSJoomla published a clear, unambiguous security advisory alongside the fix, which is exactly what you want a vendor to do. Their post, Unauthenticated File Upload fixed in RSFiles! version 1.17.12 - update NOW! , spells out the risk in plain terms rather than hiding it under a routine “Fixed” line.

TL;DR : The frontend upload in RSFiles! ( com_rsfiles ) up to and including 1.17.11 (fixed in 1.17.12) could be reached by anyone with no authentication and no CSRF token, and the method that actually wrote the file performed no permission check and no file-type check. Because it trusted the caller’s filename and the default downloads folder sits inside the web root with PHP execution on, a .php upload landed in a public directory and could be executed, which is unauthenticated remote code execution (CWE-434). We found it during a source-code audit, reproduced the full chain on a local Joomla install, and disclosed it privately to RSJoomla, who responded the same day, shipped 1.17.12, and published an advisory telling site owners to update now. A CVE has been requested and is pending assignment, crediting Phil Taylor as the reporter. No proof of concept has been made public. Update every RSFiles! install to 1.17.12 or later immediately, then check exposed sites for stray files and unexpected admin accounts. If you manage more than a handful of Joomla sites, mySites.guru lists every RSFiles! install in your account in seconds and pushes the update.

This one did not start with an abuse report or a hacked site. It started with reading the code.

Part of what we do is audit the Joomla extensions that turn up most often across the sites we manage, on a local test install where we can prove a flaw safely and put the box back exactly as it was. RSFiles! came up in that rotation. Reading through the upload path, the security checks were in the wrong place: the method that decides whether you are allowed to upload, and what file types are permitted, is a separate pre-flight step from the method that actually writes the file, and only the first one holds the checks. The second one, the one that writes to disk, could be called directly.

We reproduced the whole chain end to end on a local Joomla install: an anonymous request, no login at any step, uploaded a .php file into the downloads folder, and requesting that file back ran it. From there it was a private email to RSJoomla. They replied the same day, shipped the fix in RSFiles! 1.17.12, and published an advisory the same day telling site owners to update immediately. A CVE has been requested and is pending assignment, crediting Phil Taylor of mySites.guru as the reporter.

This is what responsible disclosure looks like

Found in a code audit, confirmed live on a local install, reported privately, and fixed by the vendor the same day, with a clear public advisory and no technical detail released. No exploit has been published. The reason to write it is to get sites updated, not to show anyone how it worked.

The flaw was an unauthenticated file upload where the security checks and the file write were in two different places, and only one of them was guarded. RSFiles! splits its upload across two separate frontend tasks:

That bundled handler accepts any file type unless the calling code tells it otherwise, and RSFiles! never told it otherwise, so its default was to accept everything, including .php . Because the write task could be called directly, an attacker skipped the pre-flight check entirely and posted to the write task, which never consulted the allow-list or the permission gate. The frontend controller had no site-wide CSRF token and no access check, so the whole thing ran for an anonymous visitor.

The final piece is where the file lands. RSFiles!’s default downloads folder sits inside the web root, and the protective .htaccess that would stop PHP running there is an opt-in admin setting that is off by default. So an anonymous upload of a .php file went into a directory that serves and executes PHP, and requesting it in a browser ran it. No account on the site was needed at any point.

The important detail for site owners is the “no login” part. Plenty of upload bugs need an editor or admin account first, which limits the blast radius to people you already trust. This one did not. Anyone on the internet who could reach the site could reach the upload.

We are deliberately not publishing the exact request an attacker would send. The shape of the bug is enough to understand the risk and to check your own sites; the working details stay private.

An unauthenticated upload that lands executable code is the top of the severity scale, and it is worth being clear why. Once an attacker can run PHP of their choosing on your server, they are no longer limited to your site. They can read your configuration.php and the database credentials in it, create a hidden Joomla Super User, plant a backdoor that survives an extension update, pivot to other sites in the same hosting account, or add the server to a spam or malware network. The uploaded file is rarely the goal in itself; it is the foothold.

This is the same lesson as the AJAX and frontend endpoints blind spot we keep coming back to. An endpoint that Joomla will run for anonymous visitors is exposed to the entire internet, so every input it touches has to be treated as hostile. A single allow-list check on the file that is actually written, “is this one of the types this folder is allowed to hold”, would have stopped this outright.

RSJoomla’s fix closes the anonymous route into the upload. Version 1.17.12 requires a valid CSRF token on the upload task and runs the permission and allow-list checks before the file is written, so a visitor with no account is refused before anything reaches the disk. The changelog records the same release also restoring the missing CSRF token on uploads and blocking file-preview access when permissions are disabled. Their advisory notes it fixes some other, less critical issues that were not separately reported.

The practical takeaway is simple: 1.17.12 shuts the door that let an anonymous visitor upload and run code. Every RSFiles! install on 1.17.11 or earlier is on the wrong side of that door until it is updated. Because the flawed routine had been in the code for years, “my site is old and stable” is a reason to update sooner, not later.

If you already run sites through mySites.guru, this is the part worth knowing. We did not need an RSFiles-specific rule to catch this class of activity. mySites.guru watches for the behaviour, an anonymous visitor uploading an executable file, rather than a fingerprint of one particular extension’s bug.

That generic detection is the same logic that catches Page Builder CK , iCagenda , Balbooa Forms , JCE and Phoca Download upload attempts. An attacker dropping a .php file through a public endpoint looks the same regardless of which extension left the door open, so we can catch new bugs of this shape before anyone has written a rule naming them. Signature-based tools only see an attack once someone has described it. Behaviour-based detection sees it the first time it happens.

If a hostile file does land, the suspect content and hacked-file detection and the backdoor scanning find it across every connected site, matching it against known malware hashes and thousands of code patterns. Anything flagged can be sent for AI-powered malware analysis that explains in plain English what the file does.

The first question after any extension security release is the awkward one: which of my sites actually run this? Up to ten sites, you can log in to each Joomla admin and check the installed extensions list. Past that, you need a single view.

mySites.guru keeps a live inventory of every extension, template, and framework on every Joomla and WordPress site in your account. You for RSFiles! once and get back every connected site running it, the version each one is on, and whether an update is available. No logging into forty admin panels one at a time.

View every RSFiles! install across your sites

Open your Extension Inventory

Once you know which sites need it, the mass updater handles the rollout. Tick the sites on an old version, push the update to all of them from one screen. The same routine covers any Joomla extension, plugin, or core update, so the workflow you set up once works for the security release too. You can also switch on automatic updates for any Joomla extension so future RSFiles! releases land without you lifting a finger.

For agencies managing dozens of Joomla sites

The patch is the easy bit. Knowing which client sites run RSFiles!, and getting the update onto all of them, is the work. See how mySites.guru manages multiple Joomla sites from one screen.

If a particular site cannot be updated right away, unpublishing the RSFiles! frontend and any items that expose its upload takes the vulnerable handler out of reach while you schedule a maintenance window. A web application firewall such as RSFirewall! or Admin Tools can also blunt the attack, but neither is a substitute for the update.

Updating closes the door. It does not tell you whether anyone walked through it first. Because the flaw allowed an anonymous visitor to drop a file and run it, a site that was on 1.17.11 or earlier could already have been touched, and you should check before you assume it is clean.

Three checks, in order of value:

mySites.guru runs all three of these across every connected site at once. The suspect content tool and hacked-file detection surface the stray PHP files, the extension and user inventory sorts every account across every site by registration date, and real-time alerting tells you the moment a new file appears or an unfamiliar admin logs in, rather than at the manual check.

If any of that turns something up, the Joomla hacked recovery guide and the how to fix a hacked site walkthrough cover the cleanup, and fix.mysites.guru is the done-for-you option if you would rather hand it over.

If you manage Joomla sites, treat every extension that accepts or serves files as a piece of your attack surface that deserves regular attention. The exact flaw fixed here, an unauthenticated upload of a file with a dangerous type, is CWE-434 , and it shows up across the whole category rather than in one vendor’s code.

The recent run of Joomla disclosures makes the point. Page Builder CK , iCagenda , Balbooa Forms , and the SP Page Builder zero-day were all the same shape: a frontend endpoint that took a file from an anonymous visitor without a strict check on what was actually written. When a category of extension keeps producing the same kind of bug, the sensible response is not to distrust one vendor, it is to monitor the whole category and to patch fast when a fix lands.

It is worth keeping this in proportion for RSFiles! specifically. Its only previously recorded CVE is a directory traversal from 2007 ( CVE-2007-4504 ) in the 1.0.2 release, nearly two decades ago. This upload flaw is a different and far more serious class of bug, and the response to it, a same-day fix and a clear advisory, is the more relevant signal how the extension is maintained today.

Credit where it is due: RSJoomla did the two things that matter. They fixed it the same day it was reported, and they published a plain-spoken advisory that tells site owners to update now rather than burying it under a routine changelog line. That is not always how these go. We have written before a vendor shipping a security fix under a bland “Security Update” changelog with nothing to tell owners how urgent it was. RSJoomla did the opposite, and it is the right call.

This is one extension on one day. There will be another, because Joomla runs on thousands of third-party extensions and the ones that accept input from anonymous visitors keep producing bugs like this. The hard part is never the update itself. It is knowing a fix exists, knowing which of your sites are affected, and getting to them before an attacker does, across every extension on every site you look after.

That is the job mySites.guru does for you. It keeps a live inventory of every extension on every Joomla and WordPress site in your account, flags the ones with a known vulnerability, and lets you push the update to all of them from one screen. When something like this RSFiles! flaw lands, you see exactly which sites are exposed in seconds instead of logging into forty admin panels to find out. And because the monitoring watches for the behaviour rather than a signature, it catches new upload attacks of this shape before anyone has written a rule naming them.

Get free email alerts when a Joomla vulnerability breaks

This flaw is CWE-434, unrestricted upload of a file with a dangerous type, reached by an anonymous visitor over the network in a single request, with no privileges and no user interaction, and it ends in full remote code execution. That profile is the worst a web flaw can have.

Critical The maximum possible score

It is unauthenticated, remotely exploitable in a single request, needs no user interaction, and ends in full remote code execution, so every metric that makes a flaw dangerous is at its worst here. This is the same profile as the near-identical Page Builder CK and Balbooa Forms flaws, both of which scored 10.0 on CVSS 4.0.

A CVE has been requested for this flaw and is pending assignment, crediting Phil Taylor of mySites.guru as the reporter. We will add the identifier here once it is issued.

The disclosure ran on a single-day cycle from audit to fix: