Check for JCE Rogue Profiles & Backdoors

What this check and mySites.guru tool looks at on your site

JCE (com_jce) is installed as the content editor on more Joomla sites than any other, which makes it a standing target, and finding every site running a vulnerable version is how this check started. This check reads the JCE profiles table (#__wf_profiles) for editor profiles carrying the attacker’s signature: a machine-generated name matching J followed by six digits (J938560, J991471, J940401), a label such as Pwned with a description of RCE via JCE, a large negative ordering value that forces the profile to the top of the list, or upload filetypes that include php, phtml or txt. It also checks the known JCE drop locations, tmp, images, media/system/js and libraries/joomla, for the malicious profile-import file the attack uploads, and for dropped webshells matching known signatures: hidden files named like .xml.php, so they read as a harmless config file at a glance; eval(gzinflate(base64_decode(...))) droppers, which decompress and run a payload that never touches disk in readable form; filter_input(INPUT_POST, ...) and shell_exec($_GET/$_POST) backdoors, which take a command straight out of the request and run it; and Nxploited marker files, a calling-card left by the specific toolkit behind this campaign.

A profile that simply has allow_php enabled is not flagged. That setting controls whether PHP code survives inside article content, not whether files can be uploaded, and legitimate developer-built profiles often have it switched on. The signal this check acts on is a profile that permits uploading a script extension through the file browser, whatever its allow_php setting says.

How an anonymous upload becomes a working webshell

The vulnerability behind this attack is an unauthenticated editor-profile upload: insufficient access controls let an anonymous visitor, with no Joomla account at all, upload an editor profile. Because a profile defines exactly what filesystem and upload actions JCE permits, the compromise runs in a short, predictable chain. First, a request to JCE’s profile-import function, with no valid Joomla session, is accepted and saved as a new row in #__wf_profiles. That new profile carries an upload filetype allowlist the attacker controls, one that includes php or phtml where a legitimate profile never would. Next, the same visitor opens JCE’s own file browser, now permitted by the fake profile’s ID, and uploads a PHP file the site would ordinarily reject. That file is the webshell, and from there the attacker can read, write and run anything the web server’s user account can reach, including planting further backdoors, creating rogue admin accounts, or reaching other sites on the same hosting account.

It affects every Joomla site running a vulnerable JCE version, not just sites that allow public registration, because the whole point of the flaw is that no account is needed at any step.

Telling a malicious profile from a merely permissive one is the crux of getting this right:

Judge a profile by what it lets you upload, and by whether anyone on your team actually created it. allow_php is a red herring either way.

Every profile traceable to someone on your team

Every editor profile on the site was created deliberately, by someone you can name, with an upload filetype list limited to images and documents. Nothing in #__wf_profiles carries the machine-generated naming pattern, a forced top-of-list ordering, or an upload allowlist that includes a script extension.

How to fix it

1. Preserve evidence first. List every profile in #__wf_profiles and note anything you plan to remove before you remove it, in case you need it later.
2. Delete the rogue profile. Remove the matching row from #__wf_profiles through phpMyAdmin or your database tool, and delete any dropped webshells you found in tmp, images, media/system/js or libraries/joomla.
3. Update JCE to the current version. The upload flaw was fixed in 2.9.99.5, with further hardening since, so update straight to whatever JCE currently ships rather than stopping at the first patched release. Until it is updated, the site can be re-breached within hours.
4. Rotate secrets. Change the Joomla administrator password, any FTP or SSH credentials, and the Joomla secret in configuration.php, since a webshell running as the web user could have read all of them.
5. Check the rest of your sites. This is automated, sprayed tooling. When one site running JCE is hit, others running the same vulnerable version usually are too.

What mySites.guru does about it

On every snapshot, twice a day, mySites.guru reads the JCE profiles table and the known drop locations against the signatures above, and flags any site carrying a rogue profile or a matching webshell. We show you exactly which row and which file triggered the flag, so you can verify it before you touch anything.