A Critical JCE Vulnerability (CVE-2026-48907), and 30 Days of Attacks in My Own Logs

A maximum-severity vulnerability has been found in JCE (Joomla Content Editor), Joomla's editor extension. It is tracked as CVE-2026-48907, and its CVSS score is 10.0 -- the top of the scale. It is a remote code execution (RCE) flaw that lets an attacker run arbitrary PHP code on the server, unauthenticated, in a single step.

A fixed version is already available. But "just update" is not the whole story, and that is why I am writing this. First, this is a real, actively exploited incident that regulators treated as an emergency -- yet there is almost no Japanese-language guidance explaining how to respond to it concretely. Second, applying the patch does not remove anything an attacker may have left behind if your site was breached before you updated. And third, 30 days of my own access logs contain this exact attack, recorded persistently, aimed straight at this vulnerability. Even a small personal site gets targeted. I am leaving the raw data here as a lead for operators in the same position.

As a preface: I am not a security professional. What follows is my attempt to line up the public vulnerability information against the primary data in my own logs. Where I have avoided asserting something as fact, please read it with that caution intact.

Why this vulnerability is dangerous

JCE is one of the most widely installed editor extensions for Joomla. That reach is exactly what makes the blast radius so large.

The technical core is a missing authorization check in the profile import feature. Before the patch, JCE only performed a CSRF token check on profile import. But Joomla embeds that token in public pages, including the homepage, so an attacker can simply harvest it. There was no authentication check -- no verification of whether the caller was a logged-in user -- so anyone holding a valid token could invoke the import routine.

The attack has two stages. First, it creates a fake editor profile that permits file uploads without authentication. Then it uses that profile to write an executable file, such as a .php or .phtml, onto the server. After that, requesting the file executes the PHP. No authentication, no user interaction, no prior privileges. That is what a CVSS 10.0 looks like in practice.

Affected versions and the fix

Affected versions run from JCE 1.0.0 through 2.9.99.4. The remediation timeline was:

• 2.9.99.5 (June 3): fixed the vulnerability itself
• 2.9.99.6 (June 8): added hardening
• 2.9.99.8 (June 18): further security features and bug fixes. This is the recommended version for every site.

One caveat. Version 2.9.99.6 caused some sites to have legitimate image and file uploads blocked (a false-positive PHP-tag detection). That was fixed in 2.9.99.8. If you have had upload trouble recently, this may be why. Either way, if you are going to update, go all the way to 2.9.99.8.

The three-day deadline regulators imposed

What tells you this is not just "another CVE" is the response from the U.S. Cybersecurity and Infrastructure Security Agency (CISA). On June 16, CISA added this flaw to its Known Exploited Vulnerabilities (KEV) catalog and gave federal agencies until June 19 to remediate -- one of the shortest windows in CISA's history. The reason: working exploit code is public, and the attacks are automated.

"We have no user registration, so we are safe" does not hold

This is the most commonly misunderstood point. The JCE developer has stated it plainly: the attacks are automated, and a site with no public registration is not safe. As noted above, the CSRF token this attack needs can be lifted from the homepage. Neither a login mechanism nor user registration is a precondition for the attack.

And my own logs bear that out.

30 days recorded in my logs

My site is a small Joomla setup that only went fully live in late June, spanning three properties (commercial and non-commercial combined). I analyzed 30 days of its access logs -- roughly 680,000 lines. Here is what was observed, to the extent I can share it. I am withholding the source IP addresses: most are likely compromised third-party servers, and there is nothing to gain by exposing them.

The attacks came every day, at a mechanical pace. Attack POSTs targeting JCE were recorded every single day across the observation window. What stood out was that several sources operated on a rigid, fixed quota of roughly 1,181 to 1,182 requests per day -- as if stamped out by a machine. They shared the same fingerprint (a burst of profile-import attempts followed by webshell-placement probes) and rotated source addresses over roughly two weeks. This is the behavior of an automated botnet campaign, not manual work by a person.

The method matched the CVE analysis exactly. The flow was a POST to the `profiles.import` task (an attempt to create a fake profile), followed by attempts to place and access webshell-like `.php` and `.phtml` files in various locations. The filenames included patterns that circulate in known attacks, such as names beginning with `nx` or containing `nxploited`. This is precisely the "create profile, then plant an executable" two-stage sequence described above.

Registration made no difference. The fact that my site was targeted confirms the developer's warning. No special condition was needed to be a target.

In my case, I found no sign that any of these attacks succeeded. In the logs, the attack POSTs all landed on error pages after redirects, every webshell-placement attempt was blocked, and there was no record of a successful probe for sensitive files. On top of that, I inspected the files on the server directly and found nothing suspicious that an attacker might have left behind.

Let me be precise about the language here. What log analysis and file inspection can establish is that no trace of a successful breach was found. That is not the same as proving that no breach ever occurred. Which is exactly why the following steps matter.

What to check and do right now

The following steps are based on public information (from CISA, the JCE developer, and others).

1. Upgrade first. Update JCE to 2.9.99.8. If you are not using it, disable and remove it from the Joomla administrator console. JCE is sometimes bundled with templates and distribution packages, so it may be running even if you do not remember installing it. Audit your extensions to confirm whether JCE is present on your site, and if so, which version.

2. Check whether you have been breached. The developer's recommended checkpoints are:

• In "Components -> JCE Editor -> Editor Profiles," look for any editor profile you do not remember creating.
• In upload directories such as `images/` and `media/`, look for unfamiliar `.php` / `.phtml` / `.phar` files.
• In your access logs, look for unauthenticated requests to `index.php?option=com_jce&task=profiles.import`.

If you can reach the server over SSH, the most reliable approach is to search the upload directories directly for recently written executable files. Be careful, though: legitimate files (such as PHP shipped with a component) will also turn up, so distinguish carefully between what is legitimate and what is suspicious. For any file you are unsure about, always take a backup before deleting it.

3. Harden at the server level too. Applying the patch is the baseline, but these additional mitigations are recommended:

• Restrict web access to `/tmp/`, and prevent PHP execution in temporary directories.
• Use a WAF (web application firewall) to filter requests to `com_jce&task=profiles.import`.

The single most important point: the update closes the door, it does not clean the house

The developer stresses this directly. Applying the fix closes the entry point. But if you were already breached before that, the update does not remove what the attacker left behind.

So doing it in the wrong order cuts the value in half. Not "I updated, so I am safe," but "I updated, and then I checked whether I was already inside before that." Both stages are needed. If a breach is possible, it is also recommended that you rotate all administrator passwords, database credentials, and hosting control-panel credentials as a precaution.

Closing

Even a small, just-launched site like mine gets tailed by a botnet for two weeks. Attackers are remarkably fast at turning a newly disclosed flaw into an automated attack. I saw that firsthand, in my own logs, this time.

Fortunately, within the range I could verify, my site showed no trace of harm. But part of that is simply that the flaw being targeted did not happen to line up with my site's configuration. The only way not to leave it to luck is to fix what needs fixing, when it needs fixing. If this article becomes that lead for even one person who has not yet reached the English-language information, it will have done its job.

*This article is based on public vulnerability information and on the primary data of my own site's access logs. I am not a security professional, and parts of this account involve inference. When addressing your own site, always consult the official information from the developer and from CISA as well.*

*Main references: JCE official (joomlacontenteditor.net), the CISA KEV catalog, and the vulnerability databases for CVE-2026-48907.*