Helix3 Custom Code Hack

What this check and mySites.guru tool looks at on your site

Helix3 is one of the older, widely used Joomla template frameworks, and it is a separate codebase from Helix Ultimate with its own version numbers. This check reads every template style on the site from the Joomla database and inspects the four Custom Code params the exploit overwrites: Before </head>, Before </body>, Custom CSS and Custom Javascript. It scans every style, not just ones named “helix” - Helix3-based commercial templates carry many different names, and the same payload written into any template’s params is equally a compromise.

A style is only flagged on unmistakable defacement tells: the boast phrase defacements sign themselves with, in any of the four fields; script that replaces the entire page body, a wholesale takeover in the custom Javascript; script that rewrites the browser page title; or a hard-coded page-title tag injected into the head markup fields (Joomla renders the page title itself, so a literal one pasted into these fields is an injection tell). Legitimate use of these fields, analytics snippets, verification meta tags, custom CSS, matches none of these and is never flagged.

How one overwritten row reaches the entire site

Versions of Helix3 before 3.1.1 registered an ajax handler, onAjaxHelix3, reached anonymously through Joomla’s com_ajax dispatcher, that processed its actions before checking who was asking. One of those actions imports template settings, letting an anonymous attacker overwrite a style’s parameters in #__template_styles, including the Custom Code fields the template echoes into every page it renders. The flaw is tracked as CVE-2026-49049, found while investigating a hacked customer site and reported to JoomShaper under responsible disclosure.

The four fields exist so a site owner can add a snippet without editing template files: an analytics tag before </head>, a chat widget script before </body>, a CSS override, a small piece of custom Javascript. That is exactly why they are such an effective target. Joomla trusts whatever is in them and prints it into every single page the template serves, so one overwritten row reaches the entire site in one step rather than one page at a time.

The campaign observed in the wild writes a full-page defacement, the defacement wave this check exists to catch: markup injected before the closing head tag, takeover CSS, and a script that rewrites the page title and replaces the whole document body, usually signed with a boast phrase naming the attacker or crew. A more dangerous variant skips the visible defacement entirely and instead loads a Web3 wallet drainer while the page looks completely normal, so a site that looks fine proves nothing and a visual check alone is not a clean bill of health. Because the payload lives in a database column rather than a file, the site’s files all hash clean, which is exactly why a database-side check exists to catch it. The same vulnerable handler also allowed an unauthenticated file write and an arbitrary file delete, so a flagged site should always get a full file audit too, not just a database clean-up: the injected Custom Code is the visible symptom, and the entry point behind it can just as easily have dropped something on disk that a database check alone will never see.

Four fields, nothing but your own code

Every template style’s four Custom Code fields contain only content your team put there: real analytics snippets, verification tags, or genuine custom CSS. Nothing in any of the four fields rewrites the page title, replaces the document body, or carries a hard-coded title tag.

How to fix it

1. Update Helix3 to the current version first. Cleaning without patching invites an immediate re-defacement, since older versions accept the same write from any anonymous visitor. In the administrator, go to System, then Update, then Extensions, and update both the “System - Helix3 Framework” plugin and the “Helix3 - Ajax” plugin. They are separate plugins, and the vulnerable code is in the Ajax one, so updating only the framework leaves the site exposed.
2. Preserve anything you need before cleaning. If you kept legitimate custom code in any of the four fields, copy it out first.
3. Inspect and clean every template style. In the administrator, go to System, then Templates, then Styles, open each style, and check its Before </head>, Before </body>, Custom CSS and Custom Javascript fields against the tells above. Blank only the fields that match; leave every other template setting untouched.
4. Clear the Joomla cache so no cached page keeps serving the defacement after the clean-up.
5. Run a full file audit. The same vulnerable handler also allowed an unauthenticated file write and delete, so confirm nothing else was dropped on the site.
6. Check the rest of your portfolio. This is automated, sprayed tooling; every site running a Helix3-based template below the current version is a target. If a Joomla 3 site cannot run the fixed mainline version, see Unpatched JoomShaper Security Holes for JoomShaper’s separate Joomla 3 patch.

What mySites.guru does about it

On every snapshot, twice a day, mySites.guru reads every template style on the site and checks its four Custom Code fields against the tells above. Where a style matches, we show you exactly which field triggered the flag and an excerpt of what is in it, so you can verify it before anything changes.