Skip to main content

Please do not blindly accept Japanese secondary information regarding Joomla vulnerabilities

| Alaudae.JP

In June 2026, a maximum-severity vulnerability, CVE-2026-48907 (CVSS 10.0), was disclosed in JCE (Joomla Content Editor), one of the most widely used editor extensions for Joomla. It allows an unauthenticated third party to execute arbitrary PHP code on the server without logging in, and automated attacks are still ongoing worldwide. On affected systems, this is a critical issue that should be addressed with the highest priority.

At the same time, among the Japanese-language explanations circulating about this incident, I have seen some that contain inaccurate statements or already-outdated information. As someone who also runs a site on Joomla, I would like to share the facts I have been able to confirm and urge some caution.

The correct timeline

  • June 3 JCE 2.9.99.5 released (the fix for CVE-2026-48907). This is effectively where the disclosure begins.
  • June 6-8 2.9.99.6 added (security hardening).
  • June 9 Proof-of-concept (PoC) code was published on GitHub, and automated mass attacks began in earnest from this point.
  • June 16 The U.S. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog. Active exploitation has been confirmed.
  • June 18 2.9.99.7 was released. This is the currently recommended version.

You may also come across expressions about this incident such as "broken by AI for the first time" or "Joomla had not been cracked for many years." To add a little technical context: the core of this issue is a missing authorization check and inadequate upload controls, a type of problem that has been known for a long time. It is closer to reality to understand it as attacks becoming automated and large-scale, triggered by the publication of the PoC.

The most important point: updating alone is not the end of it

As the official guidance also states clearly, an update only closes the "entry point" of the attack; it does not clean a site that has already been compromised. If there are signs of intrusion, you need to act on the assumption that even the contents of the configuration file (configuration.php) may have been read.

At a minimum, replace all of the following credentials.

  • Joomla administrator password
  • Database credentials
  • Hosting / control panel password
  • FTP / SSH credentials
  • Regenerate the secret in configuration.php (the session and token key)
  • Reissue API keys for external services such as Stripe

Simply restoring an old backup brings back the old keys and old passwords, so the leaked information stays alive. Also, rather than picking a restore point that is "roughly a few months ago," the correct approach is to check the access logs for the oldest record of an unauthenticated request (to `task=profiles.import`) and select a backup from before that point. Always run a malware scan on the restored files as well.

Joomla 3 / 4 have already reached end of life (EOL)

This is a more fundamental point, separate from this particular vulnerability.

  • Joomla 3 reached EOL in August 2023. Extended security support (eLTS) also ended in February 2025, and no security updates of any kind are provided anymore.
  • Joomla 4 also reached the end of its active support in October 2024.
  • The current versions are Joomla 5 (supported until October 2027) and Joomla 6.

Among Japanese-language information sites, some still feature "how to set up Joomla 3" and "how to set up Joomla 4" as their main content. While this may be acceptable as a reference for maintaining existing sites, there is no reason for someone building a new site to choose these versions. A CMS that no longer receives updates is, to an attacker, a "target known to be unfixable." Using old procedures as your foundation means choosing a vulnerable starting point from the very beginning.

Do not take it at face value: verify the primary sources

The value of security information varies greatly depending on who wrote it and when. When you see secondary information or summary articles, always verify them against primary sources such as the following.

  • Joomla's official security announcements (developer.joomla.org)
  • Release notes from the JCE developer (joomlacontenteditor.net)
  • The U.S. CISA KEV catalog, and the corresponding CVE/NVD records

An old update date, a version-support status that does not match the current situation, response procedures that do not include credential rotation. Even if such articles look well put together, it is safer not to rely on them as the basis for your decisions.

Joomla is a sufficiently robust CMS when properly maintained. That is precisely why operating it based on accurate, up-to-date information is, in my view, the responsibility of every single user.

*This article is based on publicly available primary sources (Joomla official, the JCE developer, CISA KEV, CVE/NVD) and summarizes information as of June 2026.*

Isamu Hibari / Alaudae.JP

More Stories