Hello Balbooa team,
I maintain around 30 Joomla sites built with Gridbox. On one of them I traced a persistent flood of automated account creations to the store registration endpoint. I would like to report three related issues.
Environment: Joomla 5.4.6 · Gridbox 2.20.2.1 · PHP 8.3
Important: this is not leftover damage from a compromised site
I want to rule out the obvious explanation up front, because I checked it carefully.
Earlier in July the site had been compromised through a known extension vulnerability. In response I rebuilt it completely:
All files replaced from a verified-clean backup dated 14 July 2026, scanned beforehand for injected code (no findings in the code directories).
All rogue accounts removed from the database.
Everything updated: Gridbox to 2.20.2.1, BaForms to 2.4.3.1, Joomla to 5.4.7. Site secret and all passwords rotated.
New accounts started appearing again on 31 July — on the rebuilt, fully patched installation, and they are still arriving as I write this (most recently today, 3 August). They are created in the Guest group, are marked active immediately, and have never logged in.
So this is not residual compromise and not an unpatched version. It is the current release behaving as designed, on a clean site.
1. The endpoint ignores Joomla's global user settings
StoreController::register() is publicly reachable at
index.php?option=com_gridbox&task=store.register
and calls $user->bind($data) followed by $user->save() directly. As a result:
"User Registration = No" in Joomla's Users options has no effect. Accounts are created regardless.
"New User Account Activation = Administrator" has no effect either. The account is saved as active, skipping the activation workflow entirely.
Site owners reasonably assume that disabling registration in Joomla disables it site-wide. Right now it does not, and there is no indication anywhere that a second, independent registration path exists.
2. The only control is hidden when "Login" is disabled
The behaviour is governed solely by checkout->registration in the store settings (#__gridbox_api, row service = 'store').
In the backend the toggle is hidden whenever Login is disabled. In administrator/components/com_gridbox/tmpl/storesettings/default.php, line 180:
$style = $store->checkout->login ? '' : ' style="display: none;"';
$style is then applied to the container holding the USER_REGISTRATION checkbox (lines 204–214). On my site Login is off — so the toggle is invisible, while the stored value remains "registration":true and stays fully effective, because StoreController::register() checks checkout->registration alone and never looks at checkout->login.
There is no way to turn this off through the interface. I had to change it directly in the database:
UPDATE #__gridbox_api
SET `key` = REPLACE(`key`, '"registration":true', '"registration":false')
WHERE service = 'store';
This is the part I would consider a real bug: a setting that is active but unreachable.
3. No captcha, no rate limiting
The endpoint accepts unlimited POST requests. Over five days it produced one new account roughly every one to two hours, around the clock, all from addresses of the form xtw18387+@outlook.com — a known subscription-bombing pattern where a third party's mailbox is the actual target.
The checkout settings do contain a recaptcha field, but it does not appear to be applied to this endpoint.
This is a known campaign, not a one-off
The address pattern is documented by CleanTalk's public spam database. Variants of xtw18387+@outlook.com are recorded there with spam activity across several unrelated websites, the earliest entries dating back to 19 May 2026 — well before my site was affected. Any Gridbox shop with checkout->registration left at its default is a usable target for it.
You already solve this elsewhere in Gridbox
Your own documentation describes reCAPTCHA-based spam protection for the Reviews app and for the Comments app. The same protection is missing on the store registration endpoint, even though a recaptcha key already exists in the checkout settings. Applying the existing mechanism here would be consistent with the rest of the product.
Suggested fixes
Honour Joomla's allowUserRegistration and the account activation setting, or document clearly that Gridbox deliberately overrides them.
Render the Registration toggle independently of Login, so it can be switched off. Alternatively, treat login = false as implying registration = false.
Apply the existing captcha setting to store.register, and add basic rate limiting per IP.
I am happy to provide log excerpts or test further on request.
Best regards Tina
