SP Page Builder 4.0.1 – Unauthenticated Custom Icon Upload Leading to PHP Payload Extraction

Hi Toufiqur,

Thank you for confirming that this security issue was addressed in SP Page Builder 6.6.2.

SP Page Builder 4.0.1 → 4.x → 5.x → 6.0.x → 6.5.x → 6.6.1 → FIXED IN 6.6.2?!

If version 6.6.2 contains the security fix, customers need a clear explanation of exactly which earlier versions were affected. There are several major product generations and many releases between 4.0.1 and 6.6.2. This is therefore not something that can simply be answered by testing the latest patched version and confirming that it now returns HTTP 403.

However, my report concerns SP Page Builder 4.0.1, not 6.6.2. Therefore, receiving HTTP 403 in a current patched environment is expected and does not contradict the findings documented above.

On the affected 4.0.1 installation, unauthenticated POST requests to:

/index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon

were accepted, archives were extracted into tmp/builderCustomIcon_*, and the same source immediately attempted to access PHP payloads under newly generated iconfont/ico... paths. The behaviour was also reproduced using a harmless marker archive.

The purpose of this post is not to claim that SP Page Builder 6.6.2 remains vulnerable. The purpose is to document the behaviour of the affected legacy version and to raise the question of how customers are expected to receive timely information about serious security issues.

Could you please clarify:

Which SP Page Builder versions were affected?
In which exact version was the issue first fixed?
Was a direct security advisory sent to all customers when the issue was confirmed?

The website will be rebuilt and migrated next week. Until then, a local temporary block is preventing the endpoint from accepting or extracting uploaded archives.

Thank you for your response and for offering assistance.

“I have checked Page Builder 4 authentication about custom icon and no problem found.”

To remove any possible ambiguity regarding the version, installation state, source file, or local modifications, I am now providing the exact original SP Page Builder Pro 4.0.1 installation package, together with the controller extracted directly from that package.

Original vendor files

Complete original SP Page Builder Pro 4.0.1 package:

[https://cloud.8core.eu/index.php/s/9HXiBeB9Qgr7Rsx](http://)

SHA-256:

3d853960a93a763c270e191c512f5383d8bfab877e9d0384df8807e582b36160

Original controller extracted from the package:

https://cloud.8core.eu/index.php/s/7NQPGsKeZZ57Hnn

SHA-256:

ad82fdc4bb03fc8e40d1e5cac1d8e34067bf16142a1e6d08cd02b0637326450f

The SHA-256 hash of the separately provided controller is identical to the hash of:

site/controllers/asset.php

inside the original 4.0.1 installation ZIP.

The package manifest identifies the version as:

<version>4.0.1</version>

Therefore, this is not a controller reconstructed from an infected website, modified by a customer, or taken from an unknown source. It is the controller distributed inside the original JoomShaper SP Page Builder Pro 4.0.1 package.

After installation, its Joomla path is:

/components/com_sppagebuilder/controllers/asset.php

Customer download availability

At the time of writing, this exact SP Page Builder 4.0.1 package remains available in my JoomShaper customer download area without a visible security warning beside the download.

Screenshot of the customer download area:

If this package is considered secure, please identify the authentication protection in the original controller.

If it is not considered secure, please explain why it remains downloadable without a prominent warning, a replacement patch, or clear information about the affected endpoint.

Relevant original code

The original uploadCustomIcon() method begins as follows:

public function uploadCustomIcon()
{
$model = $this->getModel();

// Get file form input
$input = Factory::getApplication()->input;
$user = Factory::getUser();

$customIcon = $input->files->get('custom_icon', null);

// Tmp path
$tmp_path = Factory::getConfig()->get('tmp_path');

// Root path
$rootPath = JPATH_ROOT . '/media/com_sppagebuilder/assets/iconfont/';
$rootUrl = 'media/com_sppagebuilder/assets/iconfont/';
$report = array();

The current Joomla user is loaded:

$user = Factory::getUser();

However, the $user variable is not subsequently used to reject a guest, verify an authenticated session, or check whether the user is authorised to upload custom icons.

Before the uploaded archive is accepted, I cannot find checks equivalent to:

$user->guest
$user->authorise(...)
Factory::getApplication()->getIdentity()->authorise(...)
Session::checkToken(...)

The method instead obtains the uploaded file directly:

$customIcon = $input->files->get('custom_icon', null);

It then writes the uploaded archive into the Joomla temporary directory:

$zip_file = $tmp_path . '/builderCustomIcon.zip';

if (File::upload($tmp_src, $zip_file, false, true))
{
$extract = $this->unpack($zip_file);

The unpack() function creates an automatically generated extraction directory:

$tmpdir = uniqid('builderCustomIcon_');

$extractdir = Path::clean(
dirname($packageFilename) . '/' . $tmpdir
);

$archive = new Archive([
'tmp_path' => Factory::getConfig()->get('tmp_path')
]);

$extract = $archive->extract(
$archivename,
$extractdir
);

This produces directories in the form:

builderCustomIcon_*

For a custom font package, the code then recursively copies the extracted font directory into a publicly accessible location:

Folder::copy(
$extract_path . '/' . $font_path,
$rootPath . '/' . $fontFamily . '/' . $font_path
);

The resulting destination is:

/media/com_sppagebuilder/assets/iconfont/<fontFamily>/<font_path>/

I cannot find any filtering in this method that rejects PHP files, mixed-case PHP extensions, .phtml, .pht, .htaccess, or other potentially executable files before the complete extracted font directory is recursively copied.

The specific question

Please identify the exact line in the original SP Page Builder Pro 4.0.1 controller that prevents an unauthenticated visitor from reaching this archive-upload and extraction process.

Loading the user object is not an authentication check:

$user = Factory::getUser();

The code must actually evaluate the user, session, permission, or authorised action and reject the request before processing the uploaded file.

Please quote the exact code responsible for that rejection.

Reproduced behaviour

On the affected installation, an unauthenticated multipart request to:

/index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon

using the field:

custom_icon

was accepted.

The archive was written and extracted into:

/tmp/builderCustomIcon_*

The behaviour was separately reproduced with a harmless ZIP package containing only valid custom-icon metadata and a plain text marker.

No PHP code, shell, command-execution payload, or destructive content was used in the verification archive.

The harmless archive was accepted and processed through the same endpoint.

Temporary local mitigation

Because this legacy website is scheduled for migration, we temporarily hard-disabled the endpoint before any uploaded file could be accepted, written, extracted, or copied.

Locally modified controller:

SHA-256:

f0d3aefea2de379148be1f437a618e9f99cd56082ecbc73994cbafc1f98c61bf

The only functional addition is at the beginning of uploadCustomIcon():

public function uploadCustomIcon()
{
/*

• 8Core controlled lab response:
• reject every custom icon upload before any file is accepted,
• written to tmp, unpacked or copied to iconfont.
  */
  http_response_code(403);
  header('Content-Type: application/json; charset=utf-8');

echo json_encode([
    'status' => false,
    'output' => "Sorry, honey, I'm not into intimate relationships with you."
], JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE);

die();

$model = $this->getModel();

After applying this local hard block, the same harmless request returned:

HTTP 403 Forbidden

and no new archive, extraction directory, or copied iconfont file was created.

This is not presented as an official patch or complete production solution. It is simply a temporary endpoint disablement demonstrating that the request reaches uploadCustomIcon() and that rejecting it before the upload-processing code prevents the observed filesystem activity.

Conflicting version information

Your support thread states that the issue was fixed in SP Page Builder 6.6.2.

The same discussion later states that the shared replacement file applies only to:

SP Page Builder 5.x – 6.6.1

and explicitly says it is not intended for:

SP Page Builder 4.x or 3.x

This leaves a very direct question:

SP Page Builder 4.0.1 → 4.x → 5.x → 6.0.x → 6.5.x → 6.6.1 → FIXED IN 6.6.2?!

Which exact versions were vulnerable, and what specifically protects the original unmodified SP Page Builder 4.0.1 controller?

Requested clarification

Please provide precise answers to the following:

Which exact SP Page Builder 4 version and build did you test?
Was your test performed on a pristine original package or on an installation containing a later security modification?
Which exact line in the original 4.0.1 uploadCustomIcon() method rejects an unauthenticated visitor?
Which SP Page Builder versions are affected by this upload issue?
In which exact version was the authentication or authorisation check first introduced?
Is SP Page Builder Pro 4.0.1 considered affected or unaffected?
If it is affected, why is the package still available in the customer download archive without a visible security warning?
Will JoomShaper add an explicit warning or remove the unsafe package from customer downloads?
Is there an official patch specifically tested and supported for SP Page Builder 4.0.1?

I am not requesting another general link to a blog post.

I am requesting a code-level explanation concerning the exact original vendor package, exact version, exact controller file, and exact method being discussed.

The complete package and both controller versions are available above so that your development or security team can reproduce the comparison directly.

Best regards,

Tomislav Galić

Instead of thanking us for reporting a serious security issue, you are denying the problem without addressing the evidence.

By doing so, you are not making the issue disappear — you are making it bigger, because the original vulnerable package is still available for download without a clear warning.

Your Security Communication and Customer Support Are Completely Unacceptable

Gentlemen,

Instead of simply saying, “Thank you, Tomislav, for reporting a serious security problem,” you chose to respond with pathetic, irrelevant and demonstrably misleading excuses that nobody asked for.

This is completely unacceptable and, from a marketing perspective, embarrassingly poor.

I did not ask you for generic statements about using the latest Joomla version. I did not ask for promotional material, vague patches, contradictory version information or unsupported claims that the problem does not exist.

I provided you with:

• the exact affected product version;
• the original installation package;
• the exact vulnerable controller and method;
• the file hash;
• the request path;
• the missing authentication and authorization checks;
• reproducible evidence showing that an unauthenticated request could write arbitrary content into publicly accessible directories.

I asked you one very simple technical question:

Show me the exact line in the original affected code that prevents an unauthenticated visitor from calling this function.

You never answered it.

Instead, you repeatedly avoided the question, referred me to unrelated pages, provided contradictory information about affected versions and finally offered another generic patch without clearly explaining what it fixes, which versions are vulnerable or which product and Joomla combinations it officially supports.

And then you sent this newsletter:

https://preview.mailerlite.io/emails/webview/78670/193149941198096327

The email, sent on 16 July 2026, is titled:

“Helix Ultimate v2.2.9 and Helix 3 v3.1.3 are Now LIVE!”

It opens with pathetic fear-based marketing about customers waking up one morning and discovering that all their work has disappeared because they used outdated software.

You warn customers about “security vulnerabilities,” but then describe the new Helix Ultimate release as fixing:

• unexpectedly deleted blog images;
• Mega Menu saving;
• stripped copyright text;
• a modal interface.

For Helix 3, you mention a missing language string.

You do not mention:

• the unauthorized AJAX actions;
• the missing permission validation;
• the ability to write files into public directories;
• the affected versions;
• the actual security severity;
• indicators of compromise;
• the need to inspect access logs and the filesystem;
• the fact that updating does not remove files that may already have been planted;
• any clear security advisory or CVE reference.

This newsletter is a perfect example of the exact problem I described.

You use security risks as a marketing tool to frighten customers into updating, while refusing to clearly disclose the serious security problems that existed in your own products.

That is not responsible security communication.

That is damage control disguised as marketing.

Had you behaved professionally—acknowledged the report, thanked the person who provided the evidence, apologized to your customers, published a clear security advisory and offered timely technical assistance and cooperation—this matter could have ended properly and respectfully.

Instead, you chose denial, avoidance, contradictory statements and cheerful marketing emails filled with emojis while your customers were given no useful information about whether their websites may already have been compromised.

Because of the way you handled this matter, I will publish the entire documented case across local and European web-design forums and social media.

This will include:

• the vulnerable code;
• the original package and hashes;
• reproducible technical evidence;
• server and access-log evidence;
• the files successfully written through the affected endpoints;
• your forum responses;
• your contradictory claims;
• your patches;
• your security announcements;
• and this marketing newsletter.

This will not be presented as gossip, speculation or a personal attack.

It will be presented as a detailed, evidence-based and extremely critical review of JoomShaper, its products and, in particular, the completely unacceptable quality of its customer support and security communication.

You had every opportunity to handle this correctly.

You chose not to.

Hi Paul,

First of all, thank you for taking the time to write such an honest and direct reply. I genuinely appreciate it. I also appreciate that you acknowledged the newsletter title and the lack of technical details in the blog post, and that you are willing to discuss improvements internally.

Please don't misunderstand my intentions.

I am not moving away from Joomla, and I am not replacing Helix or SP Page Builder because of this incident. Every CMS, framework or page builder will eventually have security issues. Yesterday, for example, we spent only a few hours testing Gridbox by Balbooa and found a serious security issue there as well. We are following responsible disclosure and have contacted the vendor privately because our goal is to help them fix it, not to compromise them publicly.

What concerns me is something different.

A web developer is not necessarily the system administrator, nor the person who decides when a website is upgraded. In many projects—especially public institutions and government organizations—the developer can recommend an upgrade, but the final decision belongs to the client. In reality, perhaps one out of ten customers will approve a major migration, such as Joomla 3 to Joomla 4, because it involves additional cost and they often don't have internal technical staff.

From the customer's perspective, none of the discussions about versions, upgrades or end-of-support really matter. They simply see it as:

"I paid for a product, and now it has security problems."

That is why I believe that software which is still available for download and actively used in production should be accompanied by very clear security communication whenever a serious issue is discovered. Many administrators are not security specialists, and clear warnings can make the difference between a protected website and a compromised one.

I don't intend to leave Joomla, and I don't intend to leave JoomShaper either. We've been working with your products for many years. My criticism comes from someone who wants to continue using them and wants the Joomla ecosystem to remain trusted and competitive.

If improving the communication around security advisories is something that comes out of this discussion, then I believe the entire Joomla community will benefit.

Thank you again for your honest response and for listening. I truly appreciate it.

I set the /media/com_sppagebuilder/assets/iconfont/ folder permissions to 000 until a verified patch is installed.