Joomla JCE CVE-2026-48907: CVSS 10.0 Web Shell, No Login Required

CISA added CVE-2026-48907 to its Known Exploited Vulnerabilities catalog on June 16, 2026 — the day after a public GitHub exploit started driving automated scanning at scale. The vulnerability lives in the Joomla Content Editor (JCE), the most widely installed third-party extension in the Joomla ecosystem, affecting every version from 1.0.0 through 2.9.99.4. It carries a CVSS v4 score of 10.0 — the maximum — and requires no authentication, no prior account, no special configuration. An attacker on the open internet can achieve PHP code execution on your server in three HTTP requests. Federal agencies have until June 19, 2026 to remediate; if you run Joomla with JCE, your deadline is now.

Why JCE Is Everywhere — and Why That Matters Here

The Joomla Content Editor is effectively the default rich-text editor for the Joomla ecosystem. Developers routinely install it as a first step after standing up a new Joomla site, and it has been the most-downloaded editor extension for years. Hundreds of thousands of production sites run it. That reach is precisely why a CVSS 10.0 in JCE is not just a bad plugin bug: it is a mass-exploitation event. Within 24 hours of a public exploit appearing on June 9, attackers compromised official Joomla infrastructure itself — extensions.joomla.org, community.joomla.org, and certification.joomla.org were all taken offline — and researchers estimated hundreds of sites compromised, with thousands expected to follow in the days that came next.

Three Design Failures That Combine Into One Shell

The vulnerability lives in the JCE profile import feature. When anyone submits a profile import request to /index.php?option=com_jce&task=profiles.import, three independent security controls all failed simultaneously:

• No authentication check. The import endpoint validated only a CSRF token, not user authorization. Because CSRF tokens appear on public-facing pages, an unauthenticated attacker can trivially retrieve one and replay it without holding any account.
• No file extension restriction. The code ran uploaded filenames through Joomla's File::makeSafe(), which strips special characters — but does nothing about extensions. A file named shell.xml.php passes the sanitizer intact, double extension and all.
• Explicitly disabled upload safety. The upload call passed $allow_unsafe = true to File::upload() — Joomla's own flag for bypassing its built-in blacklist of dangerous extensions, including .php. Whoever wrote this code deliberately turned off the guardrail, apparently believing the other validation was enough.

The result is a three-request attack chain: fetch the CSRF token from the homepage, POST the malicious .xml.php file to the import endpoint, then GET the uploaded file path to trigger execution. Researchers who disclosed the flaw demonstrated it with a payload as simple as <?= 45*69 ?> — confirming RCE when the server returned 3105. The attack is fully automatable, and based on observed exploitation patterns, it has been running on automation since the public proof-of-concept dropped.

The Patch and What It Actually Fixed

Widget Factory released JCE 2.9.99.5 on June 3, 2026 with an initial fix, then followed with 2.9.99.6 containing six additional hardening layers: explicit authorization checks on all administrative actions; a strict .xml-only whitelist using pathinfo(); $allow_unsafe = false restoring the extension blacklist; a 512 KB upload size cap; XXE protection during XML parsing; and a field allowlist restricting what gets processed from the XML payload. The right target is 2.9.99.6 or later. If you patched to .5 already, update again.

The critical caveat: patching closes the entry point but does not clean a site that was already compromised. Two weeks elapsed between the patch release (June 3) and CISA's KEV listing (June 16), and the public exploit has been live since June 9. Any site running JCE below 2.9.99.5 during that window should be treated as potentially compromised — not merely vulnerable.

How to Tell If You Were Already Hit

Several reliable indicators let you audit whether exploitation succeeded before you patched:

• Web server logs: Search for a profiles.import POST immediately followed — within the same second — by a plugin.rpc&...&method=upload POST, both returning HTTP 200. That two-step sequence is the upload chain in action.
• Database check: Run SELECT id, name FROM #__wf_profiles WHERE name REGEXP '^J[0-9]{6}$' against your Joomla database. Attackers created throwaway editor profiles with auto-generated six-digit names matching that pattern.
• Filesystem scan: Look for .xml.php files in writable directories — particularly under media/system/js/ and libraries/joomla/. The most commonly observed webshell obfuscation uses eval(gzinflate(base64_decode(...))). Also check for plain text files named Nxploited, a marker some attackers leave for re-targeting.
• JCE admin panel: Review Editor Profiles for entries you did not create, especially any with upload permissions allowing PHP files or descriptive names like "RCE via JCE."

If any of these fire, treat the server as compromised. Patching over a running web shell closes one door while the attacker holds the keys to others. A restore from a known-good backup predating June 3 is the only clean path back.

What to Do Right Now

• Update JCE to 2.9.99.6 or later immediately. Version 2.9.99.5 is better than unpatched but does not include the full hardening suite.
• Run the log and database checks above even if you have already patched — especially if the site was unpatched at any point between June 3 and today.
• If you find evidence of compromise, restore from a clean backup and treat the current filesystem as untrusted. Attempting to scrub a live web shell infection is unreliable.
• If your Joomla site is not actively maintained, this is the moment to put it on a formal update schedule or take it offline until that can happen. An unmaintained CMS installation running popular plugins is a reliable exploitation target, not a question of if but when.

The window between a June 3 patch release and a June 9 public exploit is six days. At Falcon Internet, our 24x7x365 NOC monitoring flags unpatched plugin versions on managed sites, but the urgency here applies regardless of who manages your infrastructure — six days is not a comfortable margin, and this week proved it.