Balbooa released Gridbox 2.20.4.2 today, fixing two SQL injection flaws in the page builder that need no login. The Joomla CNA scored both CVE-2026-102788 and CVE-2026-102789 at CVSS 4.0 9.3 Critical, with releases 1.0.0 to 2.20.4.1 affected.

The first is in the sort order of store and category post lists: the value from the page URL went straight into the ORDER BY of the query. 2.20.4.2 now checks it against a whitelist. The second is a page editor task that loads blog posts and had no permission check at all, so any visitor could call it and reach the same query.

Both let an anonymous visitor read the database, and on Joomla that means the user table and its password hashes. No public exploitation has been reported yet.

What to do: update every Gridbox site to 2.20.4.2, including ones you moved to 2.20.4.1 last week. If a site sat on an affected version, check for admin accounts you didn't create and consider resetting admin passwords. Sites still on Joomla 3 top out at Gridbox 2.17.0.2 with no fix.

The full post has the version table, why ORDER BY injection keeps showing up in Joomla extensions this year, and how mySites.guru flags affected sites.

Quix Page Builder 6.4.0 is out for Joomla, and it's a security release, even though the changelog only says the Joomla Article elements now respect article access levels.

Before 6.4.0, the Joomla Article element had a front-end AJAX handler that anyone could call without logging in. It took an article id from the request and told Joomla the access check had already been done. So a guest could ask for any published article on the site by its id and get the full text back, including articles set to Registered, Special or a custom access level, whether or not that article was ever placed on a Quix page.

The same release fixes two related leaks. The Joomla Articles list element sent the full text of articles the visitor wasn't allowed to read when com_content's "show unauthorised links" option was on, and a page that showed a restricted article to a logged-in member could be cached and served to the next anonymous visitor.

There's no CVE or advisory for it. If you use access levels to keep member content private and you run Quix, update to 6.4.0. The full post covers how the handler worked, which versions are affected and how mySites.guru flags sites still on an older Quix.

DJ-Extensions released DJ-HelpfulArticles 1.3 today, a security release for their free article rating extension. In 1.2 the rating widget sent the visitor's IP address from the browser, and the component stored whatever it was given without checking it was an IP. The admin "Helpful articles" overview then printed it without escaping, so anyone, with no account, could submit a rating with script in the IP field and it would run in an administrator's browser when they opened the overview. The vendor rates it High.

1.3 takes the IP from REMOTE_ADDR and validates it, and escapes the stored values in the overview. One catch from the vendor's own FAQ: updating does not delete anything already planted. After updating, open the overview and look for IP entries that are not IP addresses, and if an admin opened that page while on 1.2, check for admin accounts you did not create.

Versions 1.0.0 to 1.1.0 have a separate XSS (CVE-2024-27183), so anything below 1.3 should be updated. There is no CVE for this one yet.

The full post covers how the flaw worked, what to check after updating, and how mySites.guru flags it across sites.

If you run Joomla on a cPanel server and saving an article, or Global Configuration > Permissions, in the administrator started failing after 21 October, check whether the PHP2Shell ModSecurity mitigation went onto that server.

The mitigation adds SecRequestBodyAccess On to /etc/apache2/conf.d/modsec/modsec2.user.conf so its new rule can see the PHP_SESSION_UPLOAD_PROGRESS field. That setting is server-wide, and ModSecurity 2 defaults it to Off. With it on, cPanel's OWASP Core Rule Set 3.0.2 reads every POST body for the first time, and old XSS and injection rules start denying admin saves to /administrator/index.php.

CSF makes it worse: five ModSecurity denies in an hour and lfd bans the editor's IP, so the whole site looks down from their house while everyone else can still see it.

We hit this on two servers running a mix of Joomla and WordPress sites. The full post on the mySites.guru blog covers which rules fired, how to check your own server, and the narrow exclusions on the admin save paths we used so the front end stays protected.

Four days after the PHP2Shell fixes (PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35), a researcher has published a repository claiming six more unpatched flaws in fully patched PHP, with exploit scripts, and RedEye Security wrote it up as "PHP2Shell, Part Two". The PHP project has confirmed none of it yet. The exploit code went public about 16 hours before anyone emailed [sec@php.net](mailto:sec@php.net), so no one who could verify the claims has had the chance. Treat them as claims for now.

What is confirmed: CVE-2026-115560 (session upload progress) gets its fix in the next regular PHP release, with session.upload_progress.enabled=0 as the stopgap until then, and a use-after-free in unserialize() on PHP's own bug tracker reproduces on the patched builds but is still untriaged. Stock Joomla is not exposed to the first, and only meets the second if an extension unserializes data an attacker controls.

Nothing to do today if your host applied the 21 October release. The useful work this week is preparation: know the PHP version of every site, know who applies PHP updates at each host and how to reach them, and restore a backup to prove it works. The full post has the claim-by-claim breakdown against what is on record, the disclosure timeline from the repository's own commit history, where to watch for the next PHP release, and how mySites.guru keeps that inventory for you.

Current have this message "Fatal error: Class 'Joomla\Utilities\IpHelper' not found in .... administrator\includes\framework.php.

Tried installing old Joomla 4.6.5 to 4.10. Received message about could not open ....sessiongc.php for writing and then I got out of the install and now I cannot get back into the administrator.

Phoca released Phoca Gallery 6.1.6 on 19 October as a security release, and the Joomla CNA has now published it as CVE-2026-102786, CVSS 8.6 High. It is a stored XSS in the front-end photo info view: the view prints an image's EXIF metadata into the page without escaping it, so a crafted image can break out of an HTML attribute and run script when someone opens that photo's info page. EXIF is written by whoever made the file, so any account that can upload an image to a gallery can plant it, and it fires on whoever views it later, an admin included.

The awkward part is distribution. Phoca ships one release line per Joomla generation, and the fix is on the Joomla 6 line only. Joomla 5 sites are offered 5.1.3 and Joomla 4 sites 4.5.5, both still inside the affected range with no backport, so Joomla's update screen will not deliver the fix. Those sites need the 6.x package installed by hand, or the gallery removed.

The full post has the diff, the steps for each Joomla version, and how we flag affected sites.

YOOtheme has released YOOtheme Pro 5.0.53, and the changelog lists it as the fix for CVE-2026-102785, an unauthenticated remote code execution in the image handler. Every Pro 5 build from 5.0.0 to 5.0.52 is affected, on Joomla and WordPress alike. YOOtheme says Pro 4 and earlier are not affected.

The image handler is the public route the template uses to resize, crop and cache images, so anyone can reach it without logging in. Comparing 5.0.52 with 5.0.53, the fix limits which image operations a request can ask for and checks that the cache file name matches the signed image URL before anything is written.

There is no interim workaround, so the update is the fix. Back up, update every Pro 5 site, then check for files you did not add (PHP files in images, cache or media folders are the obvious place to look) and admin accounts you do not recognise. The CVE record is not published yet, so there is no official CVSS score.

The full post covers the fix in more detail, what to check after updating, and how mySites.guru flags affected Joomla sites.

YOOtheme has given a day's advance notice of a critical security update for YOOtheme Pro 5, the Joomla page-builder template. It is due on Wednesday 21 October at 16:00 CEST (14:00 UTC), and the vendor says every site running Pro 5 must update the moment the new version is available. YOOtheme Pro 4 and earlier are not affected, so if your sites are still on the Pro 4 line there is nothing to do here.

No technical details and no CVE are public yet. We did not find or investigate this one ourselves; it was reported to YOOtheme by a third party, so this is a heads-up rather than a write-up. There is no interim mitigation, so the useful thing to do tonight is take a fresh backup of each Pro 5 site and list which sites are on Pro 5, so you can move quickly tomorrow afternoon.

The full post has the vendor's exact wording, a short FAQ, and what we will publish once the fixed version is out.

Hey guys ? Using MCP in joomla right now ?
We're working on a visual builder for joomla for joomla 6, still alpha,
looking for feedbacks, before releasing.
Our goal is to release it full GPL.

Would love to hear your thoughts about it.

So a few questions for you ?
- which tools / builders / editors / cck are you using ?
- do you care about MCP ?

-- did you migrate everything to j6 ? or you still have very old joomla ?

Hi all, I'm part of the JoomlArt team (mods, thanks for letting me post this).

Over the years a lot of the support requests we get aren't about templates at all. They're small edits on live sites: a module that looks wrong on mobile, the site name overlapping the menu button, a page that needs a German version, an image that needs swapping. Simple to describe, annoying to track down in overrides and module positions.

We've been building Tracy for that. You import a copy of your Joomla site, describe the change (or click the element and comment), and it makes the edit. It stays Joomla, your admin and extensions are still there. Every change is logged with undo, and you can save Releases to roll back to.

It's beta and I'm sure it'll trip on some setups. That's honestly why I'm posting here: you know weird Joomla configurations better than anyone.

If you're an active JoomlArt subscriber you get a month free during beta. Sign in with your subscription email.

Two questions for the sub:
1. What's the Joomla task you'd most want to hand off?
2. What would make you NOT trust an AI touching your site?

Someone is emailing Joomla site owners pretending to be Fotis Evangelou of K2. The email says Joomla support phoned him about your site and that updates have to be done before 25 October. Joomla has no support desk that phones anyone, so it's false from the first line.

I replied and played along for an evening. Within a couple of hours they'd offered three plans ($350, $450, $550), asked me to create a Super User account in his name with a Gmail address, and sent a $550 invoice billed from a completely different name. They also told me, in bold, not to pay through the invoicing platform's escrow option.

The emails pass SPF, DKIM and DMARC because they really do come from that Gmail account. That says nothing about who's typing. If you get one, don't create the account and don't pay. If you already made the account, block it, change your admin passwords and check for any other Super Users or extensions you don't recognise. Fotis didn't send these, and other well-known Joomla names are being used the same way.

The full write-up on the mySites.guru blog has every email, the headers, and what the invoice platform's open API gave away about who's really behind it.

Hey, Robert from MariaDB Foundation here. We run a yearly survey on how MariaDB is used, or cases where you are using MySQL, PostgreSQL, or something else. (mod approved)

https://mariadb.typeform.com/to/tS69UzVo?utm_source=reddit_joomla

I'm curious if you are running Joomla on MariaDB, or another database, and why? Any problems or wishes on the database side?

Vectors are available in MariaDB since 11.8. Has anyone done anything with vectors in databases in or outside Joomla?

Under 10 minutes, anonymous, results published at mariadb.org/survey.

Thanks for taking the time!
Robert, MariaDB Foundation

I wanted to know how you fellt about the different builders and different frameworks existing in joomla ?

I introduce myself first, I've been using joomla for many many years, I did try with all these years qui a few builders and associated frameworks. I tried CCK for a while. I purchased many licences through the years Quix, SPBuilder. Try asteroid framework, helix.
But my main goal was to keep websites easily editable for our customers.

Of course, I had look at what was happening elsewhere—Elementor and Divi on WordPress, Webflow, and others… Where do you stand on all this?

What do you think about page builders? Do you still see them as relevant in 2026 for the kind of web design work you do? The same question could be asked about CMSs, for that matter.

I find it hard to believe that CMSs will disappear because of AI, despite what we sometimes read or hear. We’ll still need to keep information organized and visually editable—or maybe I’m just stuck in the 20th century.

So how do you guys work with Joomla ?