CVE-2026-48907 in the Widget Factory Joomla Content Editor (JCE) is currently being exploited in automated attacks. The Joomla JCE exploit requires no authentication, works against all JCE versions from 1.0.0 to 2.9.99.4, and gives attackers a persistent web shell on the server. CISA added it to the Known Exploited Vulnerabilities catalog on June 16, 2026, with a CVSS score of 10.0. Here is what the attack looks like, and what you need to do if you run JCE.
How the Joomla JCE Exploit Works
JCE includes a profile import feature that lets administrators create and restore editor configuration profiles. The vulnerability is that the import endpoint does not check whether the user is authenticated before processing the request.
An attacker sends a crafted POST request to index.php?option=com_jce&task=profiles.import with no credentials at all. That request carries a malicious profile definition. If accepted, the server creates a new JCE editor profile that the attacker controls. The attacker then configures that profile to permit arbitrary file uploads, including PHP files. PHP is not filtered because the attacker’s profile has instructed JCE to trust it.
From the upload, the attacker places a PHP web shell. With the web shell in place, they have read and write access to the server’s filesystem, the ability to rename, delete, and modify existing files, directory browsing across the web root and beyond, and permission to upload additional payloads. Widget Factory describes this as “unrestricted file system access.” A web shell at this level is effectively an interactive terminal on the server, running as the web server process user.
Why Automation Makes Every Site a Target
Working exploit code for CVE-2026-48907 is publicly available. Widget Factory confirmed this in its advisory and added that attacks are automated. That changes the threat model considerably. Targeted attacks require someone to decide your site is worth hitting. Automated scans probe every Joomla site that responds to the profile import endpoint, regardless of your traffic, size, or sector.
Widget Factory was direct about one implication: “A site with no public registration is not safe.” Attackers do not need a user account. They are not trying to enumerate credentials. They send one crafted request and either get in or move to the next target.
Checking Whether You Were Hit
If your site ran JCE below version 2.9.99.5 at any point between June 3 and June 16, check for signs of compromise before assuming you are clean. Look in three places:
Access logs. Search for POST requests to index.php?option=com_jce&task=profiles.import that arrived without a valid administrator session cookie. Each such hit is a potential exploitation attempt.
JCE profile manager. Open the JCE settings in the Joomla administrator panel and review the list of editor profiles. Any profile you did not create should be treated as attacker-placed until you can confirm otherwise.
PHP files in upload directories. Scan for PHP files in directories that should hold only user-uploaded media. The directories configured in the attacker’s rogue profile, and Joomla’s standard upload paths, are the first places to check.
How to Respond If You Find Evidence
If you confirm the Joomla JCE exploit reached your server, do not delete suspicious profiles before documenting them. Widget Factory recommends backing them up first for forensic analysis. After that, the remediation steps are:
- Update JCE to version 2.9.99.5 or later
- Remove all malicious editor profiles
- Reset administrator, database, and hosting credentials
- Run a full server-side malware scan to find any web shells or secondary payloads
The update alone does not fix a compromised site. It closes the entry point, but web shells placed before the update are still present and functional. Those need to be found and removed separately.
If You Have Not Yet Patched
Update to JCE 2.9.99.5 immediately. Under Binding Operational Directive 22-01, US federal agencies were required to patch by June 19, 2026. Private organisations face no legal deadline, but automated exploit scanners make no distinction between government portals and small business websites. The urgency is identical.
After patching, run the log and profile checks above regardless of whether you found active signs of compromise. A clean result is still worth confirming rather than assumed. Also verify any WAF is logging requests to the profile import path. That log trail is useful for incident response even after the patch is applied.
Patching a single known flaw is not the same as knowing the rest of your application is sound. Aardwolf Security provides manual web application penetration testing that looks past the obvious, identifying the logic flaws, injection points and access control weaknesses that automated scanners routinely miss. If you run Joomla or any other content management system and want confidence that a recent fix has not left something deeper unaddressed, get in touch with our team to discuss an assessment.
