Joomla AJAX handlers remain an overlooked security risk

The issue centers on com_ajax, Joomla’s lightweight router for letting plugins and modules process AJAX requests without creating separate routes. The router does not perform authorization on behalf of the extension, so each handler must enforce its own access rules.

Three checks with different purposes

• Session::checkToken() validates the CSRF token and helps establish that a request originated from the site. It does not identify the sender or confirm permission.
• $user->guest indicates whether the request comes from a logged-in user.
• authorise() and Joomla ACL rules determine whether that user may perform the requested action.

The source post cites missing authorization checks in AJAX handlers for Astroid Framework and Novarian Framework. It also links a wave of Joomla site defacements involving an unauthenticated AJAX endpoint in JoomShaper Helix3, referred to as the “AntonKill” wave. AcyMailing is cited for privilege escalation caused by missing permission checks in its internal router; the listed affected range is Joomla 9.11.0–10.8.1.

A handler that checks only a token can still expose destructive operations:

Session::checkToken() or die('Invalid Token');
$input = Factory::getApplication()->getInput();
$this->deleteItem($input->getInt('id'));

The recommended pattern adds an explicit ACL check before the operation:

Session::checkToken() or die('Invalid Token');

$app  = Factory::getApplication();
$user = $app->getIdentity();

if (!$user->authorise('core.manage', 'com_yourcomponent')) {
    throw new Exception('Access Denied', 403);
}

$this->deleteItem($app-> getInput()->getInt('id'));

Developers should review every com_ajax action for an explicit authorization decision rather than treating token validation as sufficient. Site administrators should keep Astroid, Novarian, Helix and other third-party extensions updated, and audit older handlers where checkToken() is present without an ACL check.