Affiliate Disclosure: This site contains affiliate links. We earn a commission when you purchase through our links at no additional cost to you.

Page Builder CK is a free drag-and-drop layout extension for Joomla, the kind of thing thousands of small business sites use to build landing pages without touching code. On June 27, 2026, its developer pushed version 3.6.0 with a changelog that read, in full: “IMPORTANT : Fix security issue.” No detail. That one line was covering for a bug that lets a complete stranger take over your site.

Every version up to 3.5.10 has an unauthenticated file upload flaw. No login, no session, nothing, just a request. The attacker picks the file, picks the folder it lands in, and then loads it in a browser to run it. That’s remote code execution, and it doesn’t take any skill to reach it.

TL;DR

FieldDetail
CVECVE-2026-56290
CVSS10.0 (CVSS 4.0) / 9.8 (CVSS 3.1)
Published2026-06-29
AffectedPage Builder CK for Joomla, versions up to 3.5.10
Auth requiredNone
Attack vectorNetwork
ImpactUnauthenticated arbitrary file upload → full remote code execution
StatusActively exploited in the wild
Fix3.6.0 (Joomla 5), 3.4.10 (Joomla 4), 3.1.1 (Joomla 3)

Why this one is worse than the usual upload bug

Most file upload vulnerabilities at least confine the attacker to one folder. Lock down /images or wherever uploads land, block PHP execution there, and you’ve cut off the easiest path to code execution. That trick doesn’t work here.

The vulnerable endpoint is one of Page Builder CK’s front-end AJAX handlers, the kind that fires while you’re dragging elements around in the page editor and saving your layout. It’s meant to accept image uploads. Before doing anything sensitive, an endpoint should check two things: who is this, and are they allowed to do this. This one checked neither. The only gate was a Joomla anti-CSRF token, a value meant to prove a request came from a real page on the site, not that the requester is logged in or authorized. Joomla prints that token on its own public pages, so any visitor can grab one with a single request and hand it straight back.

Past that gate, the endpoint trusted the caller’s input for both the filename (extension included) and the destination folder. No allow-list, no restriction to a media directory, nothing stopping a .php file from landing wherever the request told it to land. Upload the file, request it, and the server executes it. That’s full RCE, reachable by anyone on the internet, no account required.

Security firm mySites.guru found and reported the bug, and confirmed it by source-diffing 3.5.10 against the 3.6.0 patch and reproducing the chain on a clean install. They’re not publishing the exact endpoint or a working request. The fix is public, and handing out a recipe on top of that doesn’t help anyone.

It’s already being exploited

Within hours of the patch landing, mySites.guru’s automated scanning caught a live web shell planted through this exact flaw on a real site. It sat at:

/media/com_pagebuilderck/gfonts/bhup.php

That’s a self-contained uploader shell. Load it in a browser and it hands the attacker a form to write whatever they want, wherever they want, from then on. The first exploit through this bug wasn’t the payload, it was the foothold. Once that shell is in place, the attacker doesn’t need the original Page Builder CK bug anymore.

Two details matter for anyone checking their own sites. The shell wasn’t in /images, where people typically watch for this kind of thing. It was under /media, because the flaw lets the attacker choose the destination. And it hid inside a folder called gfonts, a name that blends in with legitimate font assets. Checking only the obvious upload paths, or trusting a folder because its name sounds harmless, won’t catch this.

If you manage a Joomla site running Page Builder CK below 3.6.0, don’t stop at updating. Search /media/com_pagebuilderck/ and its subfolders for stray PHP files, and more broadly for anything containing an upload handler pattern like $_POST['_upl']. If you find one, the site is already compromised. Patching closes the hole, but it doesn’t remove a door that’s already open. Check the Joomla Users list for Super User accounts you don’t recognize, rotate credentials and secrets, and treat the whole site as untrusted until you’ve cleaned it properly.

Bug bounty relevance

CVE-2026-56290 didn’t turn up in this week’s CVE-to-bounty-program cross-reference because the automated matching relies on tech-stack keywords, and “Joomla page builder extension” is a narrower target than the enterprise software those matches usually catch. That doesn’t make it irrelevant. It makes it a manual-recon opportunity instead of an automated one.

Joomla still runs a meaningful share of small business and nonprofit sites, and some of those run bug bounty or vulnerability disclosure programs, particularly through managed hosting providers or agencies that operate VDPs across their client base. If a program’s scope includes Joomla-based properties, checking the installed extension list is worth five minutes. Page Builder CK versions are visible to any user with backend access, and version disclosure alone (pre-3.6.0, or the older backported lines below 3.4.10/3.1.1) is often enough to justify a report once you’ve confirmed the version through legitimate access.

The pattern here also isn’t new. mySites.guru points to a run of near-identical Joomla extension bugs this year: SP Page Builder, iCagenda, the Novarain/Tassos framework, the JCE editor. All were unauthenticated uploads or code execution through front-end AJAX endpoints that check a CSRF token and stop there. If you’re hunting against any Joomla-based target, that’s the exact pattern worth testing for: an AJAX handler that verifies a token but never verifies identity or permission.

How to check if you’re affected

1. Confirm the version

In the Joomla admin, go to System → Manage → Extensions, search for Page Builder CK, and check the installed version. Anything at 3.5.10 or below (on Joomla 5) is vulnerable. The vendor also backported fixes to older Joomla lines: 3.4.10 for Joomla 4, 3.1.1 for Joomla 3. Match the patched version to the Joomla major version in use.

2. Update immediately

Update through the Joomla admin update manager, or download the current build directly from joomlack.fr if it doesn’t appear there. There’s no partial mitigation here worth relying on. Unpublishing the component in the admin doesn’t stop the underlying endpoint from being reachable.

3. Check for compromise before assuming you’re clean

Search the whole site, not just /images, for PHP files that shouldn’t be there:

find . -name "*.php" -newer <known-clean-reference-file>
grep -r "_upl" --include="*.php" .

Look specifically under /media/com_pagebuilderck/ and its subfolders, since that’s where the confirmed exploitation was found. Check the Users list in Joomla admin for any Super User account you don’t recognize.

4. If you find anything, clean the whole site

A single found file means the attacker had write access to the server, not just to Page Builder CK’s upload folder. Treat the discovery as a starting point for a full audit, not the end of one. Rotate Joomla passwords, database credentials, and any API keys or secrets accessible from the compromised environment.

Testing on your own or a program’s Joomla install

If you’re testing this on an in-scope program’s Joomla site with permission, or on your own test install, the useful signal is version evidence rather than a working exploit chain. Grab the extension version from the frontend where possible (some Joomla configurations expose it in page source or manifest files), or from backend access if you have a legitimate account. Version below 3.6.0 (or the equivalent backported version) combined with the component being active is generally sufficient to file a report. You don’t need to demonstrate the upload chain against a live production instance, and most programs would rather you didn’t.

The takeaway for anyone running Joomla extensions

This bug exists because the extension’s developer, like a lot of third-party Joomla extension authors, built authorization checks into individual AJAX handlers rather than relying on a framework-level guarantee. Joomla’s core team is closing part of that gap. Recent core releases hardened the built-in com_ajax component so AJAX handlers require an authenticated session by default, a deliberate breaking change because the old default was worse. That fix doesn’t retroactively cover extensions like Page Builder CK that route around core AJAX and handle their own requests, which is exactly why the manual update is still necessary here.

If you’re running Joomla with any third-party extensions, and almost everyone is, the practical habit worth building is checking extension versions against vendor changelogs regularly, not just when a CVE makes headlines. The changelog for this one said nothing. The exploit was live within hours of the patch.