Critical Vulnerability in Helix Ultimate 2.2.6 and Older Versions: Malicious JavaScript Can Take Over Joomla Administration

A serious security vulnerability has been discovered in the popular Helix Ultimate framework for Joomla. The flaw allows an unauthenticated attacker to write data into menu item parameters and inject malicious JavaScript into a website.

The vulnerability affects Helix Ultimate 2.2.6 and all older versions. The security fix was released in version 2.2.7. However, we recommend always installing the latest available version of Helix Ultimate.

MyDreams innovations s.r.o. has checked and secured all Joomla websites using Helix Ultimate that are under our management. Vulnerable installations were updated, and the databases of individual websites were inspected for injected malware, unauthorized menu changes, and unknown administrator accounts.

Who is affected by the vulnerability

Websites using the following versions are at risk:

Helix Ultimate 2.2.6 and older

The security fix was released in:

Helix Ultimate 2.2.7

However, we recommend always installing the latest available version of Helix Ultimate.

The vulnerability may also affect very old websites using Helix Ultimate 2.0.x or 2.1.x. On websites running unsupported versions of Joomla, a standard automatic update may not be possible, and security measures must be handled individually.

How the security flaw works

Helix Ultimate used publicly accessible AJAX actions processed through the Joomla component:

index.php?option=com_ajax

Some of these actions did not sufficiently verify:

whether the user was logged in,
whether the user had permission to change the settings,
whether the request contained a valid CSRF security token,
whether the submitted values contained malicious code.

An attacker could therefore modify selected Joomla menu parameters used by the Mega Menu feature without being authenticated.

The attacker could then store malicious JavaScript in the menu item parameters. Because the content was not sufficiently filtered when the menu was rendered, the script was loaded directly into the website page.

This is known as a stored XSS vulnerability, meaning that the malicious code remains permanently stored on the website.

How an attacker can gain administrator access

Injecting JavaScript into the menu does not necessarily provide the attacker with immediate access to the administration area. The most dangerous moment occurs when the infected website is opened by an administrator who is also logged in to the Joomla administration.

The observed malware worked as follows:

The attacker injected malicious JavaScript into the Mega Menu parameters.
The JavaScript was displayed on the frontend of the website.
The script regularly checked whether the visitor had an active Joomla administrator session.
If the visitor was logged in as an administrator, the malware loaded the form for creating a new user.
It extracted a valid Joomla CSRF token from the form.
It created a new user on behalf of the logged-in administrator.
The new user was added to the Super Users group.
The website address and login credentials were sent to the attacker’s server.

The attacker did not need to know the original administrator password. Instead, the attacker abused the administrator’s privileges through malicious code running in the administrator’s browser.

How the compromise appears

The most common symptom is a long block of JavaScript displayed directly on the page or in the website source code.

The code may begin, for example, as follows:

(function () {
    'use strict';

    if (window.joomlacreater_inline_run) return;

Other possible signs of compromise include:

a long JavaScript block visible on the page,
unknown code in the HTML source,
a broken or incorrectly rendered main menu,
unusually long parameters in a menu item,
redirects to external domains,
an unknown account in the Super Users group,
administration changes made without the administrator’s knowledge,
malware reappearing after the cache has been cleared,
suspicious requests to com_ajax in access logs.

One analyzed malware variant used the following credentials:

Username: admin_mori
Email: This email address is being protected from spambots. You need JavaScript enabled to view it.

However, the malware was also able to download different login credentials from a remote command-and-control server. It is therefore not sufficient to search only for the admin_mori account. All administrator accounts created around the time of the attack must be checked.

Where the malware is stored

When the Helix Ultimate vulnerability is exploited, the malicious code is usually stored directly in the Joomla database.

The most common location is:

#__menu

Specifically, the following column:

params

The #__ value represents the database table prefix. In an actual database, the table may be named, for example:

abc_menu

The attacker inserts JavaScript into one of the Mega Menu parameters. This may include:

a custom CSS class,
a menu item icon,
a badge,
custom text,
an additional attribute,
Mega Menu content or configuration.

Create a backup first

Before making any database changes, create a complete backup:

mysqldump -u DB_USER -p DATABASE_NAME > backup-before-cleanup.sql

You should also save a copy of the access logs. They may contain the IP address, timestamp, and exact request used during the attack.

How to find the known malware variant in the database

The following SQL query searches for known indicators of compromise:

SELECT
    id,
    menutype,
    title,
    alias,
    link,
    parent_id,
    published,
    params
FROM `#__menu`
WHERE params LIKE '%olybrdbtrknks%'
   OR params LIKE '%joomlacreater%'
   OR params LIKE '%admin_mori%'
   OR params LIKE '%mori_pro3344%'
   OR params LIKE '%memetkaan43%'
   OR params LIKE '%sendBeacon%'
   OR params LIKE '%public_config%'
   OR params LIKE '%jc_router_iframe%';

Replace the #__ prefix with the actual database table prefix.

For example:

SELECT id, title, params
FROM `abc_menu`
WHERE params LIKE '%joomlacreater%';

General check for malicious JavaScript

The attacker’s domain, login details, and malware code may change. We therefore recommend performing a broader check as well:

SELECT
    id,
    menutype,
    title,
    alias,
    link,
    params
FROM `#__menu`
WHERE params REGEXP
'<script|</script|javascript:|onerror[[:space:]]*=|onload[[:space:]]*=|onclick[[:space:]]*=|fetch\\(|sendBeacon|XMLHttpRequest|document\\.cookie|navigator\\.|credentials.{0,30}include';

This query may also return legitimate values, so the results must be reviewed manually.

Finding unusually long menu parameters

Malicious JavaScript may contain several thousand characters. Suspicious menu items can be identified by the length of the params column:

SELECT
    id,
    menutype,
    title,
    alias,
    CHAR_LENGTH(params) AS params_length
FROM `#__menu`
ORDER BY CHAR_LENGTH(params) DESC
LIMIT 50;

If ordinary menu items contain only a few hundred characters, while one item contains tens of thousands of characters, it is very likely that the item has been modified.

How to remove the malicious code from the database

First, identify the ID of the infected menu item:

SELECT
    id,
    title,
    params
FROM `#__menu`
WHERE params LIKE '%joomlacreater%'
   OR params LIKE '%olybrdbtrknks%';

Before editing the row, export it separately:

mysqldump -u DB_USER -p DATABASE_NAME PREFIX_menu \
  --where="id=MENU_ITEM_ID" \
  > infected-menu-item.sql

You must then edit the JSON stored in the params column.

Recommended procedure:

Copy the complete contents of the params column.
Format it as JSON.
Find the value containing the malicious JavaScript.
Remove only the infected value.
Preserve all legitimate Mega Menu settings.
Save the repaired JSON back into the database.
Clear the Joomla cache and any server-side cache.
Check the resulting page source code.

If the database supports the JSON_PRETTY function, the content can be displayed in a more readable form:

SELECT
    id,
    title,
    JSON_PRETTY(params)
FROM `#__menu`
WHERE id = MENU_ITEM_ID;

Why you should not automatically clear all parameters

The following command will remove the malware:

UPDATE `#__menu`
SET params = '{}'
WHERE id = MENU_ITEM_ID;

However, it will also delete all legitimate settings for that menu item.

This may remove:

Mega Menu configuration,
the number of columns,
the icon,
the CSS class,
the dropdown width,
title visibility settings,
other display parameters.

Using an empty JSON value is appropriate only if you are prepared to recreate all settings for the menu item.

If it is not possible to determine which part of the parameters is infected, it may be safer to delete the menu item and recreate it.

Checking the template settings

SELECT
    id,
    template,
    title,
    home,
    params
FROM `#__template_styles`
WHERE params LIKE '%olybrdbtrknks%'
   OR params LIKE '%joomlacreater%'
   OR params LIKE '%admin_mori%'
   OR params LIKE '%sendBeacon%'
   OR params REGEXP
      '<script|javascript:|onerror[[:space:]]*=|onload[[:space:]]*=';

Pay particular attention to the following fields:

Custom JavaScript,
Before Head,
Before Body,
After Body,
custom template code.

Checking custom HTML modules

SELECT
    id,
    title,
    module,
    position,
    published,
    content,
    params
FROM `#__modules`
WHERE content LIKE '%olybrdbtrknks%'
   OR content LIKE '%joomlacreater%'
   OR content LIKE '%admin_mori%'
   OR params LIKE '%olybrdbtrknks%'
   OR params LIKE '%joomlacreater%';

Checking articles

SELECT
    id,
    title,
    state
FROM `#__content`
WHERE introtext LIKE '%olybrdbtrknks%'
   OR fulltext LIKE '%olybrdbtrknks%'
   OR introtext LIKE '%joomlacreater%'
   OR fulltext LIKE '%joomlacreater%'
   OR introtext LIKE '%admin_mori%'
   OR fulltext LIKE '%admin_mori%';

Checking administrator accounts

In a standard Joomla installation, the Super Users group usually has the ID 8.

All users in this group can be listed with the following query:

SELECT
    u.id,
    u.name,
    u.username,
    u.email,
    u.registerDate,
    u.lastvisitDate,
    u.block,
    m.group_id
FROM `#__users` AS u
INNER JOIN `#__user_usergroup_map` AS m
    ON m.user_id = u.id
WHERE m.group_id = 8
ORDER BY u.registerDate DESC;

Check in particular for:

unknown usernames,
unknown email addresses,
accounts created shortly after the attack,
accounts without a normal login history,
accounts with names similar to an existing administrator.

The known malware variant can be found with:

SELECT
    id,
    name,
    username,
    email,
    registerDate,
    lastvisitDate,
    block
FROM `#__users`
WHERE username = 'admin_mori'
   OR email = This email address is being protected from spambots. You need JavaScript enabled to view it.';

Blocking the malicious user

UPDATE `#__users`
SET block = 1
WHERE username = 'admin_mori'
   OR email = This email address is being protected from spambots. You need JavaScript enabled to view it.';

Before deleting the account, record its ID, registration date, and last login time.

Removing the attacker’s account

First remove the user’s group assignments:

DELETE m
FROM `#__user_usergroup_map` AS m
INNER JOIN `#__users` AS u
    ON u.id = m.user_id
WHERE u.username = 'admin_mori'
   OR u.email = This email address is being protected from spambots. You need JavaScript enabled to view it.';

Then remove the user account:

DELETE FROM `#__users`
WHERE username = 'admin_mori'
   OR email = This email address is being protected from spambots. You need JavaScript enabled to view it.';

If the account uses a different username, work with the exact user ID instead:

DELETE FROM `#__user_usergroup_map`
WHERE user_id = USER_ID;

DELETE FROM `#__users`
WHERE id = USER_ID;

Invalidating all active sessions

If the malware was active on the website, you must assume that it may have abused an active administrator session.

All sessions stored in the database can be invalidated with:

TRUNCATE TABLE `#__session`;

This will log out all currently authenticated users.

After the website has been cleaned, change the passwords for:

all Super Users,
the database user,
FTP and SFTP accounts,
SSH accounts,
the hosting control panel or ISPconfig,
SMTP accounts,
API keys stored in Joomla.

Checking website files

Although the original JavaScript was stored in the database, the attacker may also have uploaded a PHP backdoor after gaining administrator access.

Known indicators can be searched for in files with:

grep -RIn \
  --exclude-dir=cache \
  --exclude-dir=tmp \
  --exclude-dir=logs \
  -E 'olybrdbtrknks|joomlacreater|admin_mori|mori_pro3344|memetkaan43|jc_router_iframe' .

Check for PHP files in directories where they would not normally be expected:

find images media tmp cache \
  -type f \
  \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' -o -iname '*.php5' \) \
  -ls 2>/dev/null

Also check recently modified files:

find . -type f \
  \( -name '*.php' -o -name '*.js' -o -name '*.html' \) \
  -mtime -30 \
  -printf '%TY-%Tm-%Td %TH:%TM %p\n' |
sort

An update alone will not remove the malware

Updating Helix Ultimate closes the original security vulnerability, but it does not automatically remove:

JavaScript already stored in the database,
unauthorized user accounts,
modified menu items,
uploaded PHP backdoors,
changes to the template,
compromised passwords,
active administrator sessions.

Every website that used Helix Ultimate 2.2.6 or older must therefore be updated and thoroughly inspected.

Recommended security procedure

Temporarily restrict public access to the infected website.
Create backups of the files, database, and logs.
Update Helix Ultimate to a secure version.
Check #__menu.params.
Remove the malicious JavaScript.
Check template settings, modules, and articles.
Review all Super Users.
Remove unauthorized administrator accounts.
Invalidate all active sessions.
Change all important passwords.
Check files for PHP backdoors.
Clear Joomla, server, and CDN caches.
Review access logs and block attacking IP addresses.

How MyDreams responded

After information about the vulnerability became available, the MyDreams team began checking Joomla websites using Helix Ultimate.

For all websites under our management, we performed the following actions:

checked the installed Helix Ultimate version,
updated vulnerable installations,
inspected Mega Menu parameters,
searched the database for malicious JavaScript,
reviewed administrator accounts,
checked recently modified files,
removed any detected malware,
invalidated suspicious sessions,
applied additional administration security measures.

All websites managed by MyDreams have been checked and secured.

For older websites where the current version of Helix Ultimate or Joomla could not be installed in the standard way, we applied individual security measures according to the technical condition of each website.

Conclusion

The vulnerability in Helix Ultimate 2.2.6 and older versions is extremely dangerous because it can be exploited by an unauthenticated attacker.

A typical attack chain looks like this:

Helix Ultimate 2.2.6 or older
        ↓
publicly accessible AJAX action
        ↓
unauthorized write to Mega Menu parameters
        ↓
stored malicious JavaScript
        ↓
execution in the browser of a logged-in administrator
        ↓
creation of a new Super User account
        ↓
complete takeover of the Joomla website

We recommend that all Joomla website administrators update Helix Ultimate immediately and also inspect the database, user accounts, and website files.

Updating the framework alone is not enough. If malicious JavaScript has already been stored in the database, it will remain there even after a secure version has been installed.

Hosting blog

Critical Vulnerability in Helix Ultimate 2.2.6 and Older Versions: Malicious JavaScript Can Take Over Joomla Administration