Attackers Scout Before They Shoot -- JCE Reconnaissance Caught in a Single Day of Access Logs

Recently I analyzed 30 days of my site's access logs and reported that automated attacks targeting CVE-2026-48907, a critical vulnerability in the Joomla editor extension JCE (Joomla Content Editor), were arriving every single day without pause. This is a follow-up. This time I pull out just one day -- July 8 -- and look at it closely. Narrowing to a single day brought into sharp focus something the 30-day totals had buried: the attackers' method.

To state the conclusion first: there was no sign of a breach on this day either. But this day's logs clearly recorded a move I had not been paying attention to -- the reconnaissance that comes before the attack. Why are sites left on old versions singled out? The raw logs let you read the reason.

As a preface: I am not a security professional. What follows is my attempt to line up the primary data of my own access logs against the public vulnerability information.

First, the bare minimum on this vulnerability

CVE-2026-48907 is an unauthenticated remote code execution (RCE) vulnerability in JCE. Its CVSS score is the maximum, 10.0. With no authentication and no user interaction, it lets an attacker write and execute arbitrary PHP code on the server. The attack has two stages: first it creates a fake editor profile that permits unauthenticated file uploads, then it uses that profile to upload a `.php` or `.phtml` webshell to the server and execute it from the web.

Affected versions run from JCE 1.0.0 through 2.9.99.4. Fixed versions have been out since 2.9.99.5, and the version the developer currently recommends for all sites is 2.9.99.9. On June 16, the U.S. CISA designated this flaw as a Known Exploited Vulnerability and imposed an unusually short three-day remediation deadline on federal agencies -- because working exploit code is public and the attacks are automated.

As an aside, that recommended version 2.9.99.9 was released, as it happens, on the very July 8 this article examines. On the exact day attacks were arriving without pause, the developer shipped the latest fix. A quiet chase between the defending side and the hunting side plays out right here.

I will leave the fuller background to the previous article. From here, I turn to the observations of that one day, July 8.

That day's logs, 31,260 lines

On July 8, my site's access logs (across three properties combined) came to 31,260 lines. The vast majority is normal traffic. Successful 200-series responses made up more than 70% of the total, and the records of attacks and probes being turned away (403, 404, 401) were a small fraction. Records of a successful probe for sensitive files were, again, zero on this day.

Within that small fraction were the usual attacks -- and a new discovery.

The usual attacks -- still arriving, unchanged

Exploit POSTs targeting JCE and similar page-builder components arrived again from multiple sources this day. The method is identical to what I observed before: a burst of POSTs trying to abuse the profile import feature, followed by attempts to place webshell-like files. The filenames included patterns that circulate in known attacks, such as names beginning with `nx`.

The result: all misses. The attack POSTs landed on error pages after redirects, and every webshell-placement attempt was blocked. Because the targeted components are not exposed on my site's front end in the first place, there was nothing for the attack to land on.

In other words, as I write this, that campaign is still ongoing in the present tense. This is not a special event on a particular day; it has become the everyday background noise.

The new discovery -- there was a "scouting pass" before the attack

On this day, a behavior I had not been conscious of was clearly recorded. It was not only brute-force POSTs.

Several sources, before launching an attack, were trying to read the manifest files of each component. Specifically, they accessed XML files such as `com_jce/jce.xml`, `com_sppagebuilder/sppagebuilder.xml`, and `com_pagebuilderck/pagebuilderck.xml`.

What is written in these XML files? The version number of that extension. Joomla extensions each record their name and version in an XML called a manifest, and if that can be read, the attacker sees at a glance whether the site has JCE installed and, if so, whether it is a pre-patch, vulnerable version.

What does this mean? The attackers are not firing blindly. They scout first, identify sites that have a vulnerable component -- and an old version of it -- installed, and only then move to mount the real attack. Take aim, then pull the trigger. That day's logs captured the very moment of that aiming.

On my site, access to these manifests was also blocked in every case, and the version was not read. But the mere presence of this reconnaissance carries a heavy meaning. Sites left on old versions are singled out for attack. Putting off an update is not merely "leaving a hole open" -- it is tantamount to telling the attacker that the hole is there.

What this one day tells us

Read a single day's logs carefully and you can see the attack proceeds in stages: reconnaissance, then the real attack. And since the aim of the reconnaissance is to identify the version, the first move of the defense is likewise plain.

Update JCE to 2.9.99.9. If you are not using it, remove it. That is the whole of it. As long as you leave the version old, you get caught by the reconnaissance and stay on the target list. Conversely, once you update all the way to the latest version, even if your manifest is read, the odds are good you will be passed over as "a site not worth targeting." You cannot prevent being scouted, but you can render the result of the scouting harmless.

There is one more thing. Even when attacks end in misses, as on my site, that is not proof that no breach occurred. What log analysis can say reaches only as far as "no trace of a successful breach was found." That is exactly why, alongside updating, I recommend checking with your own eyes once. Here are the concrete markers the developer lists.

Open "Components -> JCE Editor -> Editor Profiles" in the administrator console and look for any profile you do not remember creating. Malicious profiles created by the attack tend to have meaningless auto-generated names and to be ordered so they appear at the top of the list. In addition, check whether the `images`, `media`, and `tmp` folders contain any `.php` file you did not place there (including files with php in the name, such as `foo.php.xml`). These folders should not normally contain PHP files at all. When a profile does not specify an upload destination, the default location is the images folder, so starting there is efficient. As another sign, if the toolbar of the front-end editor has vanished, leaving a single button or nothing at all, that too is a caution flag. On its own it is not proof, but overlapping with an unfamiliar profile, it is a strong indicator.

And what the developer stresses most is the order. The update closes the entry point, but it does not clean a site that has already been breached. If a breach is possible, take a copy of the suspicious profiles and files before deleting them, close the hole with the update first, then remove them, and after that change the administrator, database, and hosting passwords -- in that order.

Closing

A single day's logs show something different from the 30-day totals. An event that, in the aggregate, becomes a quantity -- "attacks arrive every day" -- rises up, when narrowed to a single day, as a quality: "the other side scouts first, checks the version, and then fires."

The fact that the attacking side cares about the version is, turned around, the clearest guidance for the defending side. Raise the version. That is the surest single move to make the scout who came to look around come up empty.

On putting out this information

Let me write this honestly. There is a reason I provide information like this. Should someone at a merely ordinary user level like me be putting this out at all? -- that is what I agonized over at first. Even so, I write only in the hope of delivering what little information I can to as many Joomla site operators in Japan as possible; there is no duty anyone imposed on me.

So let me also be candid about accuracy. In this field, the reliable primary information is at present almost all on overseas sites, and there is no choice but to look at it with your own eyes and judge. This article, too, was written that way -- by lining up the public vulnerability information against my own site's logs. If you find anything outdated or mistaken in what I have written, give priority to the official information from the developer and from CISA. Even so, if this article can be the first lead for even one person who has not yet reached the English-language information, then there was a point to writing it.

*This article is based 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.*