If your organization runs a Joomla website, there is a good chance it uses JCE, the Joomla Content Editor. It is, by a wide margin, the most installed editor extension in the Joomla ecosystem, used in place of Joomla's default editor on sites ranging from small business brochure sites to large institutional and government portals. That popularity is exactly why the vulnerability disclosed in early June 2026 deserves immediate attention from anyone responsible for a Joomla site, technical or not.
The short version is that an attacker who has never logged in, never created an account, and never interacted with your site before can send a handful of web requests to a vulnerable Joomla installation and end up with a working backdoor on your server. No password to guess, no phishing email to send, no employee to trick. If your site runs an outdated version of JCE and is reachable on the internet, it is a target right now, whether or not it allows public visitor registration.
This is tracked as CVE-2026-48907, and it carries a CVSS score of 10.0, the maximum possible severity. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities catalog on June 16, 2026, based on confirmed evidence of active, automated exploitation in the wild. Even Joomla's own official project infrastructure, including its extensions directory, was knocked offline as a result.
How this came to light
The flaw was identified in the JCE editor extension's profile import functionality and disclosed by the Joomla! Project, which serves as the CVE Numbering Authority (CNA) for this record. A patched release, JCE version 2.9.99.5, was published on June 3, 2026, closing the core vulnerability. A follow-up hardening release, 2.9.99.6, arrived on June 8 after a fuller security audit of the surrounding code, and a further release, 2.9.99.7, followed on June 18 to fix an upload regression introduced in 2.9.99.6 and to add an additional permitted-user-groups safeguard.
The NVD record for CVE-2026-48907 was published on June 5, 2026, describing the issue plainly: the JCE editor extension allows the creation of new editor profiles by unauthenticated users, ultimately resulting in PHP code upload and execution.
The timeline moved quickly and did not stay quiet for long. Working exploit code was published publicly on GitHub on June 9, 2026, just days after the first patch. From that point, exploitation shifted from a theoretical risk to an active, automated campaign scanning the internet for reachable, unpatched JCE installations.
What is CVE-2026-48907?
CVE-2026-48907 is an improper access control vulnerability in JCE's editor profile system. Editor profiles are a legitimate and useful JCE feature: they let administrators define which toolbar options, plugins, file types, and upload permissions are available to different groups of users. Administrators can export a profile as an XML file and re-import it, for example when moving configuration between installations.
The problem is that, prior to the patch, the endpoint responsible for importing a profile (index.php?option=com_jce&task=profiles.import) did not actually check who was making the request. An unauthenticated visitor, someone with no account and no session on the site at all, could reach this endpoint directly and use it to import a profile of their own choosing.
The three weaknesses that made this exploitable
Security researchers at YesWeHack, who published an independent patch analysis and proof-of-concept, found that the vulnerability was really a chain of three separate weaknesses, each of which needed to be present for the exploit to work. Removing any one of the three would have broken the chain.
First, the import endpoint had no real authorization check. The only protection in place was a CSRF token check, a control designed to stop a malicious website from tricking someone else's browser into submitting a form on their behalf. That is a different problem from the one at hand. Joomla embeds this same CSRF token in the HTML of every public page on the site, including the homepage, so an attacker can simply visit the site, read the token out of the page source, and use it in a scripted request of their own. There was no check that the requester was actually a logged-in, authorized user.
Second, the file upload handling did not validate the file extension. Once past the CSRF check, the code responsible for saving the uploaded profile file only sanitized the filename for characters that are illegal on most filesystems. It never confirmed the file actually had a .xml extension, the format profiles are supposed to use. A file named something like payload.xml.php passed through untouched.
Third, and most decisively, the underlying Joomla file upload function was called with its safety check deliberately disabled. Joomla's core File::upload() function normally blocks a list of dangerous extensions, including .php and its variants, unless it is explicitly told not to. The vulnerable JCE code passed the flag that disables this protection, so even a filename ending in .php was written to disk exactly as submitted.
What an attacker can actually do
Put together, the three weaknesses allow an attack that takes only three HTTP requests and needs no credentials at all. In broad terms: the attacker first visits the site to harvest a CSRF token from the page source, then sends a crafted request to the profile import endpoint containing a PHP file disguised with an .xml.php name, which the vulnerable code writes into the site's temporary upload directory. Because that directory is typically reachable over the web and the server will execute PHP files placed there, a final request to the uploaded file's path runs the attacker's code directly on the server.
The result is full, unauthenticated remote code execution: the attacker can read and write files, browse the entire server filesystem, install a persistent web shell, create rogue administrator accounts, pivot to other applications on the same host, or exfiltrate the site's database.
Who is affected?
The vulnerability affects JCE (both the free and Pro editions) from version 1.0.0 through 2.9.99.4, which in practice covers every JCE 2.7.x, 2.8.x, and 2.9.x release still in common use. JCE 2.6.x is a notable exception; the developer has confirmed that its default configuration does not expose the vulnerable profile import path, though that branch is no longer supported and should still be scheduled for migration regardless.
| JCE Version | Status |
|---|---|
| 1.0.0 – 2.9.99.4 | Vulnerable; public exploit exists |
| 2.9.99.5 | Patches the core CVE-2026-48907 flaw |
| 2.9.99.6 | Adds further hardening after a full audit; introduced an upload regression for some sites |
| 2.9.99.7 | Fixes the 2.9.99.6 regression and adds a permitted user groups whitelist; current recommended release |
There is no separate WordPress build of JCE and no shared codebase with WordPress plugins, so this issue is specific to Joomla sites. It does not require any particular Joomla configuration beyond having the JCE extension installed and reachable, and it does not require public user registration to be enabled; the entry point needs no account of any kind.
Active exploitation: what we know
This is not a theoretical risk. Independent researchers and Joomla site management platforms have documented live compromises since shortly after the public proof-of-concept was released.
According to the Joomla-focused monitoring firm mySites.guru, what began as three compromised sites in a single client portfolio grew to hundreds within days, and the firm expects the number to reach into the thousands as automated scanning tools continue to weaponize the public exploit. The attack has no discernible targeting logic: it is a botnet-style sweep that tries the exploit against every reachable JCE install it finds.
Perhaps the clearest illustration of how indiscriminate the campaign is: the official Joomla project's own infrastructure was hit. The Joomla Extensions Directory (extensions.joomla.org), along with community.joomla.org and certification.joomla.org, were all taken offline and replaced with maintenance pages as a result of this attack. If sites run by the people who maintain Joomla's own security practices were affected, organizations with less dedicated Joomla oversight should not assume they are safe by default.
The compromise pattern is consistent across affected sites. Attackers import a rogue editor profile, typically given a machine-generated or blunt name, configured to permit PHP or plain-text file uploads with file-type validation disabled, and forced to the top of the profile list using an unusually large negative ordering value (commonly -99999) so that it takes effect immediately. That profile is then used to drop a web shell, most often as a hidden file with a double extension such as .xml.php, into a writable, web-accessible directory such as tmp/, media/, images/, or somewhere in the libraries/ tree.
Joomla's own advisory for this issue is direct about the risk: exploitation is active, working exploit code is public, the attacks are automated, and a site with no public visitor registration is not protected, since the vulnerable path requires no account of any kind. The advisory also makes an important point for incident response: patching closes the entry point going forward, but it does not remove anything an attacker may have already left behind on a site that was compromised before the update was applied.
CISA's Known Exploited Vulnerabilities listing
On June 16, 2026, CISA added CVE-2026-48907 to its Known Exploited Vulnerabilities (KEV) catalog under the name "Widget Factory Joomla Content Editor Improper Access Control Vulnerability." CISA only adds an entry to the KEV catalog when there is confirmed evidence of active exploitation, so this listing functions as independent, government-level confirmation of what researchers and site monitoring firms were already observing directly.
The KEV listing carries a binding remediation deadline of June 19, 2026, for U.S. Federal Civilian Executive Branch (FCEB) agencies. That directive legally applies only to those federal agencies, but CISA's general guidance is that any KEV-listed vulnerability should be treated as a patch-now priority by every organization, not only those the directive formally covers. A flaw serious enough to warrant an emergency federal deadline is a reasonable bar for prioritizing your own patch cycle above routine maintenance scheduling.
Detection
Because this vulnerability leaves both database and filesystem traces, detection is more tractable than it is for some of the memory-resident kernel flaws we have covered recently. There are three places worth checking.
Editor profiles. Review the JCE profiles list (stored in the #__wf_profiles table or equivalent) for entries you did not create. Warning signs include machine-generated or generic names, no corresponding administrator action in your logs, and an unusually large negative ordering value that would force the profile to take priority over legitimate ones.
The filesystem. Look for unexpected PHP files in tmp/, media/, images/, and the libraries/ tree, particularly files with double extensions such as .xml.php, and for obfuscated code patterns such as eval(gzinflate(base64_decode(...))) or direct shell_exec calls.
# Search common JCE-writable directories for suspicious double-extension files
find /var/www -path "*/tmp/*.xml.php" -o -path "*/media/*.xml.php" -o -path "*/images/*.xml.php" 2>/dev/null
Access logs. The exploit produces a recognizable two-request signature: an unauthenticated POST to index.php?option=com_jce&task=profiles.import, followed shortly afterward by a request to the uploaded file's location.
# Check web server access logs for the profile import endpoint
grep "task=profiles.import" /var/log/apache2/access.log /var/log/nginx/access.log 2>/dev/null
Repeated or unauthenticated hits to that endpoint, especially from IP ranges with no legitimate reason to reach your Joomla administrator functionality, warrant closer investigation regardless of whether you have already patched.
What should you do?
1. Determine your JCE version
Check the installed JCE version from the Joomla administrator panel under Extensions, or by inspecting the extension's manifest file directly on the server.
2. Patch immediately
Update JCE to version 2.9.99.7, the current recommended release, which includes the core fix along with the subsequent hardening and regression fixes. This can be done through the Joomla administrator's extension update interface, or by downloading the package directly from the vendor.
3. If you cannot update right away, apply the free patch package
JCE 2.9.99.7 requires PHP 7.4 and Joomla 3.9 or later. For sites that cannot meet that baseline immediately, the JCE developer has published a free patch package that closes the core vulnerability in the 2.7.x, 2.8.x, and 2.9.x branches without requiring a full version upgrade. Treat this as a stopgap; it does not include the broader hardening added in 2.9.99.6 and 2.9.99.7, and it will not clean up a site that has already been compromised. Back up and test on a copy of the site before applying it, and continue planning a path to a fully supported Joomla and PHP version.
4. Audit for signs of prior compromise
Before assuming a patch alone has resolved the issue, check whether the site was compromised before you updated:
- Review the JCE profiles list for rogue entries as described in the Detection section above.
- Search writable directories for unexpected PHP files, particularly ones with double extensions.
- Check the Joomla administrator users list for any accounts you do not recognize; attackers who gain a foothold frequently create additional super administrator accounts to preserve access after the entry point is closed.
- Review access logs for unauthenticated requests to the profile import endpoint predating your patch date.
5. If compromise is confirmed, remediate fully before considering the site clean
Removing a rogue profile and an obvious web shell is not sufficient on its own. If an attacker had unauthenticated remote code execution on your server, treat the entire site, and potentially the hosting account or server if shared, as compromised until proven otherwise:
- Preserve copies of the rogue profile and any suspicious files as evidence before deleting them.
- Remove the rogue profile and every dropped web shell.
- Update JCE to a patched version so the entry point cannot be reused.
- Rotate Joomla secrets, administrator passwords, database credentials, and any credentials that may have been reused elsewhere.
- Run a full file-level malware scan of the site rather than relying on removal of the specific files already identified, since a web shell is typically the beginning of an intrusion rather than the entirety of it.
6. Restrict PHP execution in upload directories as defense in depth
Whether or not you have patched, configuring your web server to refuse to execute PHP in directories JCE writes to (such as tmp/) removes the second half of the attack chain even if a future flaw reintroduces the first half.
# Example Apache configuration to block PHP execution in JCE-writable paths
<Directory "/var/www/joomla/tmp">
php_admin_flag engine off
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
7. Apply WAF or request filtering as an additional layer
If your Joomla deployment sits behind a WAF or reverse proxy, add rules to flag or block unauthenticated requests to com_jce&task=profiles.import. This will not replace patching, but it raises the cost of continued scanning against your site and gives you an additional alerting signal while you complete remediation.
Summary
| CVE | CVE-2026-48907 |
| Component | JCE (Joomla Content Editor) extension |
| CVSS Score | 10.0 (Critical, v4) |
| Type | Improper Access Control (CWE-284), leading to unauthenticated PHP upload and RCE |
| Attack vector | Network, no authentication or user interaction required |
| Affected versions | JCE 1.0.0 – 2.9.99.4 (2.6.x not affected by default) |
| Disclosed | June 5, 2026 (NVD published) |
| Public PoC? | Yes, published on GitHub June 9, 2026 |
| Active exploitation? | Yes, confirmed by multiple independent sources |
| Added to CISA KEV | June 16, 2026 |
| FCEB remediation deadline | June 19, 2026 |
| Full fix | Update JCE to 2.9.99.7 |
| Interim mitigation | Free patch package for JCE 2.7.x/2.8.x/2.9.x sites that cannot yet upgrade; block PHP execution in upload directories |
| Notable impact | Joomla's own extensions directory, community, and certification sites were taken offline |
An unauthenticated, maximum-severity RCE in the most widely deployed editor extension in the Joomla ecosystem, with active, automated exploitation already underway and a federal remediation deadline attached, is about as clear a "patch today" signal as this kind of disclosure gets. If you need help identifying every Joomla site in your environment running a vulnerable JCE version, auditing for signs of prior compromise, or standing up detection coverage for the exploitation pattern, get in touch. This is exactly the kind of fast-moving, widely exploited disclosure that CrowdSOC exists to help organizations respond to.