Joomla: 4 Extensions Added to KEV in 4 Days — Unauthenticated Upload to RCE

Between July 7 and 10, 2026, CISA added four Joomla extensions to its Known Exploited Vulnerabilities catalog. Four entries in four days, on the same CMS, with exactly the same vulnerability class: unauthenticated arbitrary file upload leading to PHP code execution.

This isn't a series of independent discoveries. It's the signature of a systematic campaign against the Joomla extension ecosystem — likely an actor who industrialised the hunt for one weakness across the most widely deployed extensions, then exploited the results at scale.

If you operate Joomla sites, or host them for clients, this article is an audit to run today.

The 4 CVEs

Only one of these has complete NVD data at the time of writing — CVE-2026-56291 (Balbooa Forms), rated CVSS 9.8. For the other three, NVD has not yet published a score, vector, or version list. I'm therefore relying solely on the CISA descriptions, which are explicit about the nature of the flaw. I won't invent scores or version numbers.

Technical Details

The common pattern

The four CISA descriptions paraphrase one another:

• SP Page Builder: unrestricted upload of file with dangerous type vulnerability that allows unauthenticated users to upload arbitrary files, ultimately resulting in the upload and execution of PHP code
• Joomlack Page Builder: improper access control vulnerability that could allow for remote code execution via unauthenticated arbitrary file upload
• iCagenda: unrestricted upload of file with dangerous type vulnerability that allows the upload of arbitrary files in the file attachment feature, ultimately resulting in PHP code upload and execution
• Balbooa Forms: unauthenticated arbitrary file upload that allows uploading executable files and leads to full RCE

The mechanism is always the same, and it's the oldest web bug in the book:

1. The extension exposes an upload endpoint (form attachment, page-builder media, event attachment)
2. That endpoint is reachable without authentication — either by design (public form) or through an access-control oversight
3. File type is not validated, or validation relies on the declared extension / client-supplied Content-Type, both attacker-controlled
4. The file lands in a directory served by the web server and where PHP is executable
5. The attacker requests their file → webshell

CVE-2026-56291 (Balbooa Forms) — the only documented one

NVD description:

Joomla Extension - balbooa.com - Unauthenticated file upload in Balbooa Forms extension < 2.4.1 - The Joomla extension Balbooa Forms is vulnerable to an unauthenticated arbitrary file upload that allows uploading executable files and leads to full RCE.

Why page builders are especially exposed

Two of the four extensions are page builders. That's no accident: a page builder needs, by nature, to handle media uploads, and its upload code is often the oldest and broadest in the extension. They're also the most-installed extensions — a page builder is typically one of the first things added to a Joomla site.

Wide deployment + broad upload surface = an obvious target for anyone chasing volume.

Exploitation and Impact

Why these CVEs are mass-exploited

This vulnerability class is the opportunistic attacker's dream:

• Trivial exploitation: one multipart POST, no memory exploit, no race condition
• No authentication: no credentials to obtain first
• Immediate, reliable result: a webshell that works on the first try
• Remotely fingerprintable target: a Joomla extension's presence shows in URL structure and asset paths, so detection automates at scale

That's why these flaws are scanned by bots within hours of disclosure, not weeks.

After the webshell

• Defacement or SEO spam injection (hidden links, parasite pages) — the most common, because it monetises directly
• Conditional malicious redirects: a normal visitor sees the site, a visitor arriving from Google is redirected to phishing
• Data theft: the Joomla database holds user accounts and their hashes
• Server abuse: spam sending, phishing hosting, mining, C2 relay
• Pivot on shared hosting to other sites under the same account

An often-overlooked point: these compromises durably damage SEO. Google detects the spam injection or the redirect, and the site can be demoted or blacklisted — damage that long outlives the technical cleanup.

Audit to Run Today

1. Inventory your extensions and their versions

In Joomla admin: System → Manage → Extensions. Cross-reference against the four extensions listed.

From the command line, with server access:

grep -rl "iCagenda\|balbooa\|sppagebuilder\|joomlack" /var/www/*/administrator/components/ 2>/dev/null

2. Hunt for PHP files in upload directories

This is the most important check. No .php file should exist in an upload directory:

find /var/www/*/images /var/www/*/tmp -type f \
  \( -name "*.php" -o -name "*.phtml" -o -name "*.php5" -o -name "*.phar" \) -ls 2>/dev/null

Treat any result as a webshell until proven otherwise.

3. Hunt for recent, suspicious files

# Files modified in the last 60 days outside legitimate updates
find /var/www/mysite -type f -name "*.php" -mtime -60 -ls | head -50

4. Hunt for webshell patterns

grep -rlE "eval\(|base64_decode\(|shell_exec\(|passthru\(|\\\$_POST\[.{1,10}\]\s*\)" \
  /var/www/mysite --include="*.php" 2>/dev/null

Watch for false positives: some legitimate libraries use base64_decode. Review each hit.

5. Verify administrator accounts

SELECT id, username, email, registerDate, lastvisitDate
FROM #__users u
JOIN #__user_usergroup_map m ON u.id = m.user_id
WHERE m.group_id = 8;  -- Super Users

Any unrecognised account, especially a recently created one, is a strong signal.

Mitigation

1. Update the extensions

For Balbooa Forms the target is clear: 2.4.1 or later. For the other three, check the vendor's site — NVD doesn't yet expose the fixed versions. If a vendor has published no fix, uninstall the extension: a KEV-listed vulnerable extension with no patch has no place on a production site.

2. Forbid PHP execution in upload directories

This is the structural mitigation that neutralises this entire vulnerability class, including future instances. It's worth applying regardless of these four CVEs.

On Apache, in images/.htaccess:

<FilesMatch "\.(php|phtml|php3|php4|php5|php7|php8|phar|pl|py|cgi|sh)$">
    Require all denied
</FilesMatch>
php_flag engine off

On Nginx:

location ~* ^/(images|tmp)/.*\.(php|phtml|phar)$ {
    deny all;
    return 403;
}

An attacker can still drop their file, but the server won't execute it — the upload becomes harmless.

3. Shrink your extension surface

Every installed extension is third-party code running with your site's privileges. Uninstall — not merely disable — anything not actively used. A disabled extension often remains reachable by direct URL.

4. If you find a compromise

1. Isolate the site (maintenance mode) before cleaning, to avoid reinfection mid-cleanup
2. Preserve a forensic copy before modifying anything
3. Restore from a backup predating the compromise if you have a clean one — more reliable than manual cleanup
4. Rotate every secret: admin passwords, database credentials, API keys
5. Check Google Search Console's Security Issues section, and request a review after cleanup

Why Continuous Monitoring of CMS Extensions Matters

Joomla is the world's second most-deployed CMS, and as with WordPress, nearly all compromises come through a third-party extension rather than the core. Those extensions are maintained by vendors of wildly varying size, ship fixes with no centralised channel, and the discovery rate runs at several per week across the ecosystem. No team tracks that manually.

With cveo.tech, inventory your Joomla and WordPress sites along with their deployed extensions and get automatic alerts whenever a critical CVE targets one of your exact versions — so you patch in the window before automated scanning bots find your site.