Helix3 security incident

At the end of June 2026, another serious security issue came to light in the Joomla ecosystem — this time not in the JCE editor, but in the JoomShaper Helix3 template framework. The story is also instructive in the way it came to light: whilst investigating a compromised client website, researchers discovered the actual point of entry and then privately notified the developer. The fix was released in version 3.1.1 of Helix3 on 29 June 2026 — but the developer’s own changelog simply stated: “Security Update”, nothing more.

It is important to clarify that Helix3 is an older, but still widely used, JoomShaper template framework, and is not to be confused with the newer Helix Ultimate, which is not relevant in this context.

The root cause of the error

The problem arises via the Joomla com_ajax component, which, by design, forwards requests to the target plugin’s own AJAX handler — in this case, Helix3’s onAjaxHelix3 function — even for visitors who are completely unauthenticated. The Joomla core does not perform any authorisation checks here; this task falls to the plugin. However, several actions in Helix3 were executed without any checks.

What an unauthenticated attacker could do (prior to version 3.1.1)

save – it was possible to write arbitrary content to a file under the active template. The code forced the extension to be .json, but it did not sanitise the path, so the file could end up outside the intended directory via a directory traversal.
remove – file deletion without extension restrictions or path checks, which effectively allowed the deletion of any file to which the web server user had access.
import – overriding the parameters of a template style stored in a database.
Several other, similarly unprotected actions (load, resetLayout, updateFonts, fontVariants) were also accessible without logging in.

Real code execution?

Not automatically on its own — the write operation was restricted to the ..json extension. However, there are two scenarios in which it could still lead to code execution:

On poorly configured Apache servers, where a file name in the format nev.php.json is passed to the PHP interpreter for execution.
In the case of chain exploitation, where arbitrary file deletion is used to remove protective files (e.g. .htaccess) that would otherwise prevent a previously placed file from executing.

Further fixes in version 3.1.1 not documented by the manufacturer

An authenticated image upload path that extracted the file extension directly from the uploaded filename, without a whitelist — this allowed a low-privileged (Author/Editor) account to upload and execute a .php file.
A second path traversal vulnerability in the image deletion function.
Stored XSS due to inadequately escaped output.
A hard-coded, leaked Google Fonts API key.
An unrestricted article voting endpoint.

Scope of application

The patch’s manifest declares compatibility with Joomla versions 4.0 through 6.5, with separate Joomla 5 and 6 branches in the patched code — meaning the issue also affects the versions of Joomla currently in active use.

CVE status

A formal CVE identifier is still being assigned to the vulnerability; credit has been given to the researcher who reported it. In the meantime, the patched version 3.1.1 serves as the authoritative reference.

The change log problem

The article specifically highlights that the manufacturer’s own changelog entry simply stated: “Security Update” — providing no information whatsoever about the affected component, the severity of the issue, or whether the vulnerability had been actively exploited. This kind of vague communication makes it difficult for website operators to assess the urgency of the fix and set the appropriate priority.

Recommended immediate steps

Update to Helix3 3.1.1 or later without delay.
Replace the Google Fonts API key in the Helix3 settings — the old key was leaking, and no server configuration alone can fix this.
Check the writable folders in your template (e.g. css/, layouts/, images/) for unexpected .json, .php or files with double extensions (.php.json).
Check the server logs for requests containing the com_ajax and plugin=helix3 parameters, particularly those from unknown IP addresses.
Implement temporary server-side protection until the patch is installed — see below.

Temporary .htaccess protection

The following set of rules is not a substitute for updating; it merely provides temporary, supplementary protection whilst you update to Helix3 version 3.1.1 (or later). Before installing in a production environment, it is advisable to test this on a test or staging site, as the stricter rules may interfere with logged-in administrators’ ability to edit templates, styles and fonts.

<IfModule mod_rewrite.c>
    RewriteEngine On

    # --------------------------------------------------------------------
    # 1) Block unauthenticated requests to the vulnerable Helix3 ajax
    #    handler (com_ajax -> plugin=helix3 -> onAjaxHelix3). The exploit
    #    chain hits index.php?option=com_ajax&plugin=helix3&... with
    #    actions like save / remove / import / load / resetLayout /
    #    updateFonts / fontVariants, none of which checked auth pre-3.1.1.
    # --------------------------------------------------------------------
    RewriteCond %{QUERY_STRING} option=com_ajax [NC]
    RewriteCond %{QUERY_STRING} plugin=helix ?3? [NC]
    RewriteCond %{HTTP_COOKIE} !joomla_user_state=logged_in [NC]
    RewriteRule ^ - [F,L]

    # --------------------------------------------------------------------
    # 2) Block POST requests to com_ajax targeting helix3 with no referer
    #    from your own admin area - stops most off-site/scripted abuse.
    # --------------------------------------------------------------------
    RewriteCond %{REQUEST_METHOD} POST
    RewriteCond %{QUERY_STRING} option=com_ajax.*plugin=helix3 [NC]
    RewriteCond %{HTTP_REFERER} !^https?://(www\.)?DOMAINNEVED.HU/administrator [NC]
    RewriteRule ^ - [F,L]
</IfModule>

Important: replace the placeholder DOMAINNEVED.HU with your own domain name, and after installation, check that the Helix3-based template editing (styles, layouts, fonts) continues to work correctly for logged-in administrators.

Summary

The Helix3 incident clearly illustrates the extent to which flexible Joomla components, such as com_ajax, place a heavy burden of responsibility on individual plugins when it comes to access control — a single missing check is enough to allow a completely unauthenticated visitor to write to or delete files on the server. Furthermore, the story also highlights the importance of transparent security communication: a vague ‘Security Update’ post on its own does not provide enough information for a website operator to correctly assess the urgency of the update.

If you are using the Helix3 template, the steps to take are clear: update to version 3.1.1 immediately, replace the affected API key, and, until this is done, apply the above .htaccess rules as an additional safeguard.

cybersecurity
website security
release
news