# mySites.guru > Manage, monitor, and secure all your WordPress and Joomla sites from one dashboard. Security audits, bulk updates, backups, uptime monitoring, and 280+ tools. Trusted by 90,000+ sites since 2012. ## About mySites.guru mySites.guru is a SaaS platform for agencies and freelancers who manage multiple WordPress and Joomla websites. It provides a single dashboard with 280+ tools including security audits, malware detection, bulk updates, automated backups, uptime monitoring, one-click admin login, and whitelabel client reports. Founded in 2012 as myJoomla.com (the original Joomla health checker), it expanded to support WordPress and rebranded to mySites.guru. Built and maintained by Phil Taylor. - Website: https://mysites.guru - Pricing: £19.99/month unlimited sites, £5/month single site, £199.99/year - Free audit: https://mysites.guru/free-audit/ - Features: https://mysites.guru/features/ - Expert help: https://fix.mysites.guru/ (£120 flat rate) ## Solutions - WordPress Hacked?: https://mysites.guru/wordpress-hacked/ — Free security scan for compromised WordPress sites. - Joomla Hacked?: https://mysites.guru/joomla-hacked/ - Triage a hacked Joomla site, clean it yourself, or hand it over for a flat fee. - Joomla Malware Scanner: https://mysites.guru/joomla-malware-scanner/ - Free file-level malware and backdoor scanning for Joomla. - JCE Hack Tool: https://mysites.guru/jce-hack/ - Find and remove the JCE Profiles hack and the webshells dropped through it. - WordPress Malware Scanner: https://mysites.guru/wordpress-malware-scanner/ — Deep file-level malware scanning. - WordPress Vulnerability Scanner: https://mysites.guru/wordpress-vulnerability-scanner/ — Automatic CVE alerts for plugins and themes. - Bulk Update WordPress: https://mysites.guru/bulk-update-wordpress/ — Update all plugins across every site at once. - Manage Multiple WordPress Sites: https://mysites.guru/manage-multiple-wordpress-sites/ - One dashboard for all your sites. ## Guides - WordPress & Joomla Security Guide: https://mysites.guru/guides/wordpress-joomla-security-guide/ - Malware scanning, vulnerability management, hardening, and incident response. - Managing CMS Updates at Scale: https://mysites.guru/guides/managing-cms-updates-at-scale/ - Handling WordPress and Joomla updates across dozens or hundreds of sites safely. - Agency Multi-Site Management: https://mysites.guru/guides/agency-multi-site-management/ - Team workflows, client reporting, bulk operations, and scaling agency operations. - Site Monitoring & Alerting Guide: https://mysites.guru/guides/site-monitoring-alerting-guide/ - Uptime monitoring, SSL tracking, disk space alerts, and file change detection. - The Joomla Agency Handbook: https://mysites.guru/guides/joomla-agency-handbook/ - Managing Joomla sites at agency scale. ## Tool Reference - Every check we run: https://mysites.guru/tools/ - The full reference for every automated check we run on a WordPress or Joomla site. - Hacked site detection: https://mysites.guru/tools/hacked-site-detection/ - Signatures and behaviours that only appear on a compromised site: rogue admin accounts, planted editor profiles, malicious cron jobs and injected template code. - Joomla configuration: https://mysites.guru/tools/joomla-configuration/ - Settings in Joomla Global Configuration that decide how much a mistake or a break-in can cost you. - WordPress configuration: https://mysites.guru/tools/wordpress-configuration/ - The wp-config.php constants and admin settings that harden a WordPress install, and the ones that quietly leave it open. - Security headers: https://mysites.guru/tools/security-headers/ - The HTTP response headers a browser uses to decide what your pages are allowed to do. - Database integrity: https://mysites.guru/tools/database-integrity/ - How the database is named, who connects to it, and what else it can reach. - User accounts and access: https://mysites.guru/tools/user-accounts/ - Who can log in, how they prove it, and how many accounts nobody has used in years. - Hosting environment: https://mysites.guru/tools/hosting-environment/ - What the server underneath the site is actually running. - Files: https://mysites.guru/tools/file-information/ - Files that should not be there, files that changed, and files that are missing. - Folders: https://mysites.guru/tools/folder-information/ - Folder permissions, writable paths, and directories left behind by an install. - Extensions and plugins: https://mysites.guru/tools/extensions-and-plugins/ - The third-party code with the same privileges as the CMS itself. - Discussion settings: https://mysites.guru/tools/discussion-settings/ - Comment handling, and the settings that decide how much spam you moderate. - Writing settings: https://mysites.guru/tools/writing-settings/ - Post revisions, autosaves and the content the database keeps forever by default. - Appearance: https://mysites.guru/tools/appearance/ - The active theme, and whether it is the one you think it is. - Search engine visibility: https://mysites.guru/tools/search-engine-visibility/ - What your robots.txt allows search engines and AI answer engines to fetch, and the single stray line that can take a site out of Google altogether. - Your Database User Should Not Be root: https://mysites.guru/tools/database-integrity/database-user-is-root/ - Only 0.1% of sites get this wrong, but the failure is total. A root database user means one SQL injection reaches every database on the server. - One Site, One Database User: https://mysites.guru/tools/database-integrity/database-user-sees-other-databases/ - If your Joomla database user can see other databases on the server, one compromised site's credentials can expose every site that shares that hosting account. - The Default Database Prefix: https://mysites.guru/tools/database-integrity/default-database-prefix/ - A jos_ Joomla database prefix isn't a vulnerability by itself. It's a force multiplier for one, and a sign the site started life on a much older Joomla version. - Backup Tables Left In The Database: https://mysites.guru/tools/database-integrity/leftover-backup-tables/ - Joomla's installer renames old tables to bak_ instead of deleting them. They sit in your live database, readable by anything that reaches your data. - Disable Joomla Guided Tours In Production: https://mysites.guru/tools/extensions-and-plugins/guided-tours-plugin/ - Joomla ships Guided Tours as three extensions, not one. Disable all three on a live site, and avoid the one combination that breaks tour dismissal. - Remove Sample Data From A Production Site: https://mysites.guru/tools/extensions-and-plugins/sample-data-in-production/ - Unpublishing the Sample Data module on your dashboard does not disable Sample Data. The install button stays live until you disable the plugins behind it. - Check Files That Are Not Core Files: https://mysites.guru/tools/file-information/files-that-are-not-core-files/ - Every file on your site that Joomla or WordPress did not ship in its own release. On a typical site that is thousands of files, most of them entirely normal. - Files That Can Send Mass Email: https://mysites.guru/tools/file-information/files-that-can-send-email/ - Every file on your Joomla site containing the word mail, the starting point for finding a hidden spam relay or mailing backdoor an attacker planted. - Files That Can Upload Other Files: https://mysites.guru/tools/file-information/files-that-can-upload/ - Every file on your Joomla site that calls PHP's move_uploaded_file, the function behind both ordinary upload forms and the classic file-upload backdoor. - Hacked Files (100% Certain): https://mysites.guru/tools/file-information/hacked-files/ - A file appears here only when its hash matches a known hack, its name is unique to attacker uploads, or a live compromise was found on your site. - Check Core Folders For Impostor Files: https://mysites.guru/tools/file-information/impostor-files-in-core-folders/ - Joomla ships a known, fixed set of files in every folder it owns. This check lists anything sitting in one of those folders that the CMS itself never put there. - Suspect Content In Files: https://mysites.guru/tools/file-information/suspect-content/ - This check reads the content of every file on your site against roughly 1,500 hack patterns and lists matches for you to read and judge, not confirmed hacks. - Helix Ultimate Mega Menu Hack: https://mysites.guru/tools/hacked-site-detection/helix-ultimate-mega-menu-hack/ - A Helix Ultimate Joomla extension mega-menu setting can carry a stored XSS payload that never touches a file, so scanners miss it. How to check and clean it. - Helix3 Custom Code Hack: https://mysites.guru/tools/hacked-site-detection/helix3-custom-code-hack/ - The Helix3 Joomla extension Custom Code template fields can carry a database-only defacement payload that file scanners never see. How to check and clean it. - Check for JCE Rogue Profiles & Backdoors: https://mysites.guru/tools/hacked-site-detection/jce-rogue-profiles/ - A rogue JCE editor profile lets an attacker re-upload a webshell after every clean-up. How to spot the fake profile and the files it plants on a Joomla site. - Check For Malicious Cron Jobs: https://mysites.guru/tools/hacked-site-detection/malicious-cron-jobs/ - A cron job that quietly re-downloads malware after every clean-up is why a hacked Joomla site keeps reinfecting itself. How to find one and remove it safely. - Rogue Super Admin Accounts: https://mysites.guru/tools/hacked-site-detection/rogue-super-admin-accounts/ - A planted Super Administrator account is how an attacker keeps access to a hacked Joomla site after the entry point is closed. How to spot and remove one. - SP Page Builder Rogue Icon-Font Assets: https://mysites.guru/tools/hacked-site-detection/sp-page-builder-rogue-assets/ - SP Page Builder Joomla extension can carry thousands of rogue icon-font rows planted by an old exploit, hiding a webshell in plain sight. How to check for them. - Unpatched JoomShaper Security Holes: https://mysites.guru/tools/hacked-site-detection/unpatched-joomshaper-holes/ - Helix Ultimate, Helix3 and SP Page Builder dropped Joomla 3 support, but JoomShaper still ships free security patches for it. How to apply them, and why. - Debug Mode Left On In Production: https://mysites.guru/tools/joomla-configuration/debug-mode-enabled/ - Joomla's debug mode prints file paths, SQL and stack traces to anyone who loads the page. Why that is dangerous on a live site, and how to switch it off. - Force Multi-Factor Authentication For Super Users: https://mysites.guru/tools/joomla-configuration/force-mfa-for-super-users/ - Joomla can force Multi-Factor Authentication on Super Users, but does not by default. Why leaving it optional protects almost nobody, and how to enforce it. - FTP Credentials In Global Configuration: https://mysites.guru/tools/joomla-configuration/ftp-layer-credentials/ - Joomla's FTP Layer went in Joomla 4, but old configuration.php files still hold plain text FTP credentials. Why that is a legacy risk worth checking for. - Joomla 3 Is End Of Life: https://mysites.guru/tools/joomla-configuration/joomla-3-end-of-life/ - Joomla 3 reached end of life in August 2023, no new security fixes are coming from the Joomla project. Here's what that means and what to do about it. - Scheduled Tasks Stuck Locked: https://mysites.guru/tools/joomla-configuration/locked-scheduled-tasks/ - A Joomla scheduled task stuck in a locked state won't run again until it's manually unlocked, silently stopping backups, update checks and cleanup jobs. - Plain Text Passwords In Email: https://mysites.guru/tools/joomla-configuration/plain-text-password-emails/ - Joomla can still email a user's actual password in plain text on account creation. Joomla itself recommends against it. Here's how to switch it off. - Search Engine Friendly URLs: https://mysites.guru/tools/joomla-configuration/sef-urls-disabled/ - Search Engine Friendly URLs turn Joomla's query-string links into readable, keyword-rich URLs. It's an SEO setting, not a security one, and it's easy to enable. - Shared Site And Administrator Sessions: https://mysites.guru/tools/joomla-configuration/shared-site-and-admin-sessions/ - Shared Sessions lets one cookie log you into both your Joomla site and /administrator, so a front-end XSS bug can reach an authenticated admin session. - Content-Security-Policy: https://mysites.guru/tools/security-headers/content-security-policy/ - Content-Security-Policy is a response header that tells the browser which sources of scripts and content it may load, closing off most XSS attacks. - Strict-Transport-Security (HSTS): https://mysites.guru/tools/security-headers/strict-transport-security/ - Strict-Transport-Security tells the browser to only ever use HTTPS for your site, closing the gap an attacker can exploit during that first request. - X-Content-Type-Options: https://mysites.guru/tools/security-headers/x-content-type-options/ - X-Content-Type-Options stops browsers guessing a file's type from its content, closing a route attackers use to smuggle scripts past file uploads. - X-Frame-Options: https://mysites.guru/tools/security-headers/x-frame-options/ - X-Frame-Options controls whether other sites can load your pages in an iframe, which is what stops a clickjacking attack from working against your site. - Accounts Nobody Has Used In Six Months: https://mysites.guru/tools/user-accounts/inactive-user-accounts/ - A Joomla account nobody has logged into for six months is not being watched by anyone, including you. That makes it an easy target for credential stuffing. - The joomla.user.helper Username Signature: https://mysites.guru/tools/user-accounts/joomla-user-helper-usernames/ - A Joomla username matching joomla.user.helper.XXXX is not a setting to fix. It is a forensic indicator that an attacker already created an account on your site. - Do Not Use admin As A Super User Username: https://mysites.guru/tools/user-accounts/super-admin-username/ - A login is only two things, a username and a password. If your Super User account is named admin, an attacker already has half of it before they start guessing. - Turn Off User Registration If You Do Not Use It: https://mysites.guru/tools/user-accounts/user-registration-enabled/ - Open registration on a site you do not need it on is a magnet for spam bots, and a free foothold the moment an authenticated-only flaw appears in an extension. - Disable XML-RPC In WordPress: https://mysites.guru/tools/wordpress-configuration/disable-xmlrpc/ - XML-RPC lets remote apps log in and publish to WordPress over one endpoint, which also makes it a brute-force and pingback-amplification target. - Disable File Editing With DISALLOW_FILE_EDIT: https://mysites.guru/tools/wordpress-configuration/disallow-file-edit/ - DISALLOW_FILE_EDIT removes the plugin and theme editor from wp-config.php, closing the fastest route an attacker with admin access has to run code. - Block Plugin Installs With DISALLOW_FILE_MODS: https://mysites.guru/tools/wordpress-configuration/disallow-file-mods/ - DISALLOW_FILE_MODS blocks every plugin and theme install, update and delete from wp-admin, including WordPress's own automatic security updates. - Let Search Engines Index The Site: https://mysites.guru/tools/wordpress-configuration/search-engine-visibility/ - The Discourage search engines from indexing this site setting tells every crawler to stay away, and it's most often found switched on by accident after launch. ## Blog Posts ## Regular Labs Publishes 24 Joomla Extension Updates Including 10 Security Fixes URL: https://mysites.guru/blog/regular-labs-september-2026-security-updates/ Date: 2026-09-13 Tags: security, joomla, regular labs, joomla extensions, vulnerability, updates Category: Manage Multiple Joomla Sites Regular Labs shipped 24 Joomla extension updates on 13 September 2026. Ten fix security issues across nine CVEs, and four change behaviour on update. [Regular Labs](https://regularlabs.com/latest-releases), Peter van Westen’s Joomla extension house, published 24 extension updates on 13 September 2026. Every one of them shipped the same day. Ten have a `[SECURITY FIX]` entry in the changelog, covering nine CVE identifiers between them, and four of those ten are flagged by the vendor as `BC BREAK`. This is the second catalogue-wide release in eight weeks. The [22 July round](https://mysites.guru/blog/regular-labs-joomla-extension-security-release/) patched around thirty extensions with no CVE numbers attached at the time. Every version this batch marks as affected is a build from that July release or later, so the sites that did the right thing in July are precisely the sites with something to do again now. Do Conditional Content first [CVE-2026-85192](https://mysites.guru/vulnerabilities/CVE-2026-85192/), fixed in Conditional Content 8.0.0, let an untrusted article author run PHP through an inline Condition Rule. That is code execution reachable by the lowest content-authoring role on a Joomla site. Everything else in this batch is cross-site scripting or information disclosure. If you triage nothing else, triage this one. It affects the Pro edition. ## TL;DR - **24 extensions updated**, all dated 13 September 2026. Ten have security fixes, fourteen are ordinary maintenance. - **Nine CVE identifiers**, all still RESERVED and unpublished on release day, so no vulnerability database or scanner can show them yet. - **Two CVEs span multiple extensions** because the code is shared. [CVE-2026-85188](https://mysites.guru/vulnerabilities/CVE-2026-85188/) covers four extensions, [CVE-2026-85196](https://mysites.guru/vulnerabilities/CVE-2026-85196/) covers two. - **[CVE-2026-85192](https://mysites.guru/vulnerabilities/CVE-2026-85192/) is the outlier**: PHP execution by an article author, in Conditional Content. The rest are XSS and information disclosure. - **Four releases are flagged `BC BREAK`** and will stop working features until an administrator re-authorises them. This is a release to stage, not to push. - **Every rule is already live in our [vulnerability database](https://mysites.guru/vulnerabilities/)**, so connected Joomla sites running an affected build are flagged now rather than whenever the CVE records publish. ## What Regular Labs shipped on 13 September All 24 releases, with the ten security ones marked. Version numbers link to the vendor’s changelog entry. Extension Version Security fix [Advanced Module Manager](https://regularlabs.com/advancedmodulemanager/download#v12.1.0) 12.1.0 Yes [Articles Anywhere](https://regularlabs.com/articlesanywhere/download#v20.0.0) 20.0.0 Yes, BC BREAK [Articles Field](https://regularlabs.com/articlesfield/download#v5.0.5) 5.0.5 [Better Frontend Link](https://regularlabs.com/betterfrontendlink/download#v2.2.11) 2.2.11 [Cache Cleaner](https://regularlabs.com/cachecleaner/download#v10.0.7) 10.0.7 [CDN for Joomla!](https://regularlabs.com/cdnforjoomla/download#v8.0.4) 8.0.4 [Conditional Content](https://regularlabs.com/conditionalcontent/download#v8.0.0) 8.0.0 Yes, BC BREAK [Content Templater](https://regularlabs.com/contenttemplater/download#v14.2.0) 14.2.0 Yes [DB Replacer](https://regularlabs.com/dbreplacer/download#v9.1.0) 9.1.0 [Email Protector](https://regularlabs.com/emailprotector/download#v6.3.12) 6.3.12 [Extension Manager](https://regularlabs.com/extensionmanager/download#v9.3.5) 9.3.5 [GeoIP](https://regularlabs.com/geoip/download#v7.0.4) 7.0.4 [IP Login](https://regularlabs.com/iplogin/download#v7.0.4) 7.0.4 [Keyboard Shortcuts](https://regularlabs.com/keyboardshortcuts/download#v4.0.4) 4.0.4 [Modals](https://regularlabs.com/modals/download#v17.0.0) 17.0.0 Yes, BC BREAK [Modules Anywhere](https://regularlabs.com/modulesanywhere/download#v9.0.5) 9.0.5 [Quick Index](https://regularlabs.com/quickindex/download#v5.0.5) 5.0.5 Yes [ReReplacer](https://regularlabs.com/rereplacer/download#v16.2.0) 16.2.0 Yes [Snippets](https://regularlabs.com/snippets/download#v11.0.0) 11.0.0 Yes, BC BREAK [Sourcerer](https://regularlabs.com/sourcerer/download#v16.0.2) 16.0.2 [Tabs & Accordions](https://regularlabs.com/tabsaccordions/download#v3.1.0) 3.1.0 Yes [Tooltips](https://regularlabs.com/tooltips/download#v10.1.0) 10.1.0 [Users Anywhere](https://regularlabs.com/usersanywhere/download#v2.1.0) 2.1.0 Yes [What? Nothing!](https://regularlabs.com/whatnothing/download#v19.79.4) 19.79.4 Two of the fourteen non-security releases still change security-relevant behaviour without the vendor labelling them as fixes. Cache Cleaner 10.0.7 “tightens destination checks for URLs requested after cache cleaning”, and Tooltips 10.1.0 adds the same author-group gate on JavaScript Events that earned Modals and Articles Anywhere a CVE. Neither is tagged, so neither gets a rule from us, but both are worth knowing about. ## The ten security fixes Nine CVEs, ten extensions. The affected range in every case starts at the July 2026 build and ends at the version below. CVE Extension Fixed in Issue [CVE-2026-85192](https://mysites.guru/vulnerabilities/CVE-2026-85192/) Conditional Content 8.0.0 Untrusted article authors could run PHP through inline Condition Rules [CVE-2026-85195](https://mysites.guru/vulnerabilities/CVE-2026-85195/) Articles Anywhere 20.0.0 JavaScript Events attachable by any content author [CVE-2026-85196](https://mysites.guru/vulnerabilities/CVE-2026-85196/) Articles Anywhere, Users Anywhere 20.0.0, 2.1.0 Request input unescaped, raw output open to any author [CVE-2026-85189](https://mysites.guru/vulnerabilities/CVE-2026-85189/) Modals 17.0.0 Modal links accepted `javascript:` URLs [CVE-2026-88853](https://mysites.guru/vulnerabilities/CVE-2026-88853/) Modals 17.0.0 JavaScript Events attachable by any content author [CVE-2026-88852](https://mysites.guru/vulnerabilities/CVE-2026-88852/) Snippets 11.0.0 Snippet variable overrides settable by any author [CVE-2026-85190](https://mysites.guru/vulnerabilities/CVE-2026-85190/) Quick Index 5.0.5 Crafted index class options allowed JavaScript injection [CVE-2026-85191](https://mysites.guru/vulnerabilities/CVE-2026-85191/) Tabs & Accordions 3.1.0 Crafted `data-rlta-alias` attributes ran JavaScript on click [CVE-2026-85188](https://mysites.guru/vulnerabilities/CVE-2026-85188/) Advanced Module Manager, Conditional Content, Content Templater, ReReplacer 12.1.0, 8.0.0, 14.2.0, 16.2.0 Condition Set labels could reference unrelated database fields The shared-code pattern is the thing to take away. [CVE-2026-85188](https://mysites.guru/vulnerabilities/CVE-2026-85188/) is one defect in one Condition Set implementation that ships inside four separate products, so patching Content Templater and stopping there leaves the same bug live in three other places. Regular Labs has always built this way, and it is why a catalogue-wide release is the normal shape of a fix here rather than an overreaction. Every one of these needs an authenticated account with content rights. None is reachable by an anonymous visitor. That is the honest framing, and it is also why Conditional Content stands out: on a Joomla site the Author role is the lowest content role there is, and plenty of sites hand it out freely or allow self-registration into it. ## Four of these releases will change how your site behaves This is the part that matters operationally, and it is the part a CVE list will not tell you. Articles Anywhere 20.0.0, Conditional Content 8.0.0, Modals 17.0.0 and Snippets 11.0.0 are all flagged `BC BREAK` by the vendor. In each case the fix was not to sanitise a value but to withdraw a capability that had been open to any content author and put it behind an author-group setting that starts switched off. - **Articles Anywhere and Modals** now restrict JavaScript Events to selected article author groups by default. - **Snippets** now restricts Snippet variable overrides the same way. - **Conditional Content** now prevents untrusted article authors running PHP in inline Condition Rules. In each case the new setting defaults to **Super Users only**. We confirmed that in the shipped packages rather than inferring it: the `javascript_events_usergroups` field in Articles Anywhere 20.0.0’s plugin manifest sets `default="Super Users"`, and the code default matches. Articles Anywhere 19.0.6 has no such field and no gate at all, so this arrived whole in 20.0.0. That default is the right one for a security fix, and it is also why sites will change behaviour. If a site legitimately uses any of those features from a non-Super-User account, and many do, the feature stops working the moment the update is applied, and keeps not working until an administrator re-authorises the groups that should have it. Nothing warns you. The page just renders without the behaviour it had yesterday. The gate is also narrower than a group check alone. Regular Labs’ shared security code only allows executable attributes through when the content is being rendered as a Joomla article, category or featured view, when the tag is actually present in the stored article row, and when the article’s last editor is in an allowed group. Modules, templates and third-party components never qualify, whatever the group setting says. Anyone using these tags inside a module should expect them to stop working regardless of how the permission is configured. Conditional Content is the gentlest of the four, and its own field description says so: existing saved Condition Sets keep working, and only the restriction on _saving_ new PHP is enforced. The other three take effect on render. Stage this batch before rolling it out A security release that removes a working capability on purpose is a different risk profile from one that patches a string behind the scenes. Update a representative site first, check any page using JavaScript Events, Snippet variables or PHP Condition Rules, re-authorise the author groups you actually trust, and only then push the wave. For what it is worth, the restriction is the correct call. Joomla’s own default text filters put Author, Editor and Publisher on the Default Forbidden List, which strips `script` along with `iframe`, `object` and `embed`. Only Super Users get unfiltered HTML, and core tightened this on purpose in 3.8.8 so that even Administrators no longer get unfiltered content by default. An extension that let an Author put executable script in a page was not offering an expected capability. It was routing around a filter Joomla puts in front of that group on purpose. ## Why no vulnerability scanner can see these yet All nine CVE identifiers were still in RESERVED state on the day of release. The numbers are allocated, and Regular Labs has printed them in its own changelogs, but the records are not live at cve.org or in NVD. We checked the MITRE record endpoint, the NVD API and the CVE Project’s own git mirror, and all three come back empty. Everything downstream mirrors published records. That means the aggregators, the feeds, and most commercial scanners cannot show you a single one of these today. If your tooling is quiet on Regular Labs this week, that silence is a gap in the data rather than a clean bill of health. This is the same gap the [July round](https://mysites.guru/blog/regular-labs-joomla-extension-security-release/) sat in for weeks, and those numbers did eventually arrive. One of them, the Sourcerer issue, [turned out to need a second fix release](https://mysites.guru/blog/sourcerer-14-unverified-content-php-execution/) once it was properly scored. We do not wait for publication. All 34 matching rules for this batch went into our [Joomla vulnerability database](https://mysites.guru/vulnerabilities/) on release day, so every connected site running an affected build is already flagged with the version that resolves it. Regular Labs did announce the release publicly and did so promptly, posting eleven times on Mastodon within twelve minutes of the packages going live, each post linking its own changelog. The problem is reach rather than intent. That account had around 70 followers when we checked, the vendor’s RSS feed has not had an item since 2019, there is no security page and no mailing list signup anywhere on the site. The summary post announcing all 24 updates does not use the word security at all, and the Modals post hit Mastodon’s character limit mid-sentence, so one of the two CVE numbers for that extension is simply not in it. None of that is concealment. It is a release that was announced into a room with almost no one in it, while the CVE records that would have spread it further sat unpublished. If you maintain Joomla sites and you learned about this from us rather than from the vendor, that is why. ## What the sites we monitor actually look like We can see the installed version of every Regular Labs extension across the Joomla sites connected to mySites.guru. Measured on release day, across the ten affected extensions, the picture splits in a way that is worth sitting with. - **62.8%** - on the July build - current until this morning, newly affected today - **36.7%** - already behind - running a version with a published CVE before today - **0.5%** - already patched - as expected on release day Share of installs across the ten affected extensions, on Joomla sites snapshotted in the last 30 days. The 62.8% is unremarkable. Those sites were fully current when they went to bed and are affected because a new release exists, which is how patching works. The 36.7% is the number worth acting on, and when we broke it down by the age of the installed build it turned out not to mean what we first assumed. Around 32% of all installs we monitor sit on a build dated 4 September 2023 or earlier, with almost nothing in between that and the current release. The obvious reading is a large group of abandoned sites. The obvious reading is wrong. ## The 2023 cluster is Joomla 3, and it is stranded rather than neglected 4 September 2023 is the date Regular Labs last shipped a build for Joomla 3. Pull the vendor’s own update feed and every Joomla 3 branch is frozen on that day: Articles Anywhere at 14.2.0, Modals at 12.6.1, Snippets at 8.7.0, Quick Index at 3.6.0, Content Templater at 11.5.0, ReReplacer at 13.2.0. The Joomla 4, 5 and 6 branch is versioned separately and is the only one receiving this batch. Those terminal version numbers are exactly the versions clustering in our data. Measured across the seven affected extensions with a Joomla 3 branch, 19.1% of installs are sitting on precisely the last build Regular Labs ever released for their platform, and a further 11.8% are older still. That reframes the number. A fifth of these installs belong to sites that applied every update offered to them and then ran out of updates. Joomla’s own update check tells them they are current, because as far as their branch is concerned they are. None of these nine fixes will reach a Joomla 3 site There is no Joomla 3 backport in this batch and there will not be one. For a site in that group the remediation is a migration rather than an update. Applying the fix means moving the site to Joomla 4 or later first, which is work of a completely different size, and worth scoping now rather than at the next release. So the useful question after this release goes past whether you applied it: which sites in your portfolio could not receive it, and did you know which ones those were before today? The oldest Articles Anywhere install still connected to us is version 1.9.3, released in January 2011. ## The vendor’s own update feed is still behind its own release One practical wrinkle, checked at 16:17 UTC on release day, roughly three hours after the packages went live. Joomla sites do not poll the changelog page. They poll `download.regularlabs.com/updates.xml`, and that feed was still offering the previous version for three of the ten affected extensions: Quick Index at 5.0.4, Content Templater at 14.1.0 and Users Anywhere at 2.0.6. Articles Anywhere and Snippets had already rolled over, and Snippets flipped while we were watching, so this is staggered propagation rather than a broken feed. The feed sets a six hour cache lifetime, which fits. It still means a site checking for updates this afternoon may be told it is current on three extensions that are not. If you are working through this batch today and an extension reports nothing available, check the version against the table above rather than trusting the prompt. ## How do you update 24 extensions safely? 1. **Take a backup first.** Four of these releases change behaviour on purpose, so a rollback path is not optional this time. 2. **Do Conditional Content first** if you run it. [CVE-2026-85192](https://mysites.guru/vulnerabilities/CVE-2026-85192/) is the only code execution issue in the batch. 3. **Update one representative site**, then open a page that uses JavaScript Events, Snippet variables or PHP Condition Rules and confirm it still does what it should. 4. **Re-authorise the author groups** you actually trust in each of the four BC BREAK extensions, rather than disabling the new restriction wholesale. The restriction is the fix. 5. **Check your template overrides.** Articles Anywhere 20.0.0 also changes full article layouts in feeds, which is exactly where a stale override bites. 6. **Do not trust an empty update prompt today.** The vendor’s update feed was still serving the previous version for three of the ten extensions three hours after release. Check the installed version against the table above. 7. **Separate out your Joomla 3 sites.** They cannot receive any of this. Put them on a migration list rather than an update list. 8. **Then roll the wave**, and [turn on automatic updates](https://mysites.guru/blog/automatic-updates-for-any-joomla-extension/) for the extensions where you are comfortable with it, so the next catalogue-wide release is not another manual afternoon. ## How do I find every site running a Regular Labs extension? Checking 24 extensions by hand across a portfolio is the kind of job that gets postponed, which is how a site ends up on a 2023 build. mySites.guru keeps an extension inventory for every connected Joomla site. Searching the [extension inventory](https://manage.mysites.guru/en/extensions) for any of these names returns every install and its version on one screen, and anything below the fixed version is flagged automatically against the rules we added on release day. You get a list of sites to fix rather than a list of sites to check. The official Joomla [Vulnerable Extensions List](https://mysites.guru/blog/vulnerable-extension-list-joomla-wordpress/) will almost certainly not record this release, and the public CVE databases cannot yet. That gap between what a vendor has fixed and what the world can see is the whole reason we keep [our own vulnerability database](https://mysites.guru/vulnerabilities/) rather than mirroring someone else’s. ## Timeline - **4 September 2023** The last Joomla 3 build Regular Labs shipped its final Joomla 3 release across the range on this date. Every Joomla 3 branch in the vendor's update feed is still frozen here, which is why a fifth of the installs we monitor sit on exactly these version numbers. - **22 July 2026** The catalogue-wide security release Around thirty extensions patched at once, with no CVE identifiers assigned at the time. Every version marked affected in today's batch is a build from that release or later. - **17 August 2026** Sourcerer 16.0.0 closes CVE-2026-74253 The July round's Sourcerer fix turned out to be incomplete, and the issue was assigned a CVE retroactively. Evidence that a Regular Labs fix release can itself need re-scoping. - **13 September 2026** Twenty four updates, ten with security fixes Nine CVE identifiers across ten extensions, four of them flagged BC BREAK. All nine CVE records were still RESERVED and unpublished on the day of release. ## Further Reading - [Regular Labs Patched Its Whole Joomla Extension Catalogue at Once](https://mysites.guru/blog/regular-labs-joomla-extension-security-release/) - the 22 July 2026 round, and the source of every version number now marked affected - [Sourcerer 14 and 15 did not fix CVE-2026-74253. 16.0.0 does.](https://mysites.guru/blog/sourcerer-14-unverified-content-php-execution/) - what happens when a Regular Labs fix release needs re-scoping - [Twenty Rules for Joomla Extension Developers Handling a Security Report](https://mysites.guru/blog/joomla-extension-security-disclosure-standard/) - the yardstick we measure vendor handling against - [One VEL for Every Joomla and WordPress Site](https://mysites.guru/blog/vulnerable-extension-list-joomla-wordpress/) - why the official Vulnerable Extensions List will not record this release - [Automatic Updates for Any Joomla Extension](https://mysites.guru/blog/automatic-updates-for-any-joomla-extension/) - how to stop a twenty four extension wave being a manual job - [Regular Labs latest releases](https://regularlabs.com/latest-releases) - the vendor's own changelog index, the only published source for this batch - [CWE-79: Improper Neutralization of Input During Web Page Generation](https://cwe.mitre.org/data/definitions/79.html) - the class covering most of this batch ## Unauthenticated SQL Injection in SP Property Finder found by mySites.guru URL: https://mysites.guru/blog/sp-property-finder-sql-injection-disclosure/ Date: 2026-09-10 Tags: security, joomla, sp property finder, sql injection, vulnerability, responsible disclosure Category: Manage Multiple Joomla Sites mySites.guru found an unauthenticated blind SQL injection in JoomShaper's SP Property Finder. Any visitor could read the database. Fixed in 4.1.4. [SP Property Finder](https://www.joomshaper.com/joomla-extensions/sp-property) is JoomShaper’s real-estate listings component for Joomla, used to run property search sites: agents, listings, maps, enquiry forms. During a security audit of SP Property Finder 4.1.3, **mySites.guru found an unauthenticated SQL injection in the public property search, and reported it to JoomShaper before disclosing anything publicly.** JoomShaper closed it in SP Property Finder **4.1.4**. If you run SP Property Finder on any Joomla site, update to 4.1.4 now. If you manage more than a handful of sites, read on for how to find every affected one at once. ## TL;DR - mySites.guru found an **unauthenticated blind SQL injection** in SP Property Finder 4.1.3 and reported it to JoomShaper - **Unauthenticated SQL injection, [CVE-2026-78082](https://mysites.guru/vulnerabilities/CVE-2026-78082/).** The Joomla CNA rates it 9.3 Critical and credits it to us; we assess the read-only injection at 8.7 High. Either way, with no login and no token an anonymous visitor could **read the entire database**, password hashes and the site secret included - **Unauthenticated mail relay (CVSS 4.0 6.9, Medium).** The property contact and enquiry forms took the recipient address straight from the request, so an attacker could send email to any address with a spoofed sender, from your domain and mail server, an open spam and phishing relay - **Update to SP Property Finder 4.1.4 immediately** - Reported privately, fixed in **4.1.4**. Our two findings are **[CVE-2026-78082](https://mysites.guru/vulnerabilities/CVE-2026-78082/)** (SQL injection, credited to Phil Taylor by the Joomla CNA) and **[CVE-2026-78303](https://mysites.guru/vulnerabilities/CVE-2026-78303/)** (mail relay); the release fixed three more that we did not report - **A month from report to release, 27 days of it silence.** Acknowledged 11 August, then quiet until we chased on 7 September with the Joomla Security Strike Team copied in; a fixed build followed within 20 hours - mySites.guru already flags every connected Joomla site still running a vulnerable version How we handle what we find mySites.guru discovered this issue and reported it to JoomShaper before publishing details. We withheld the exact requests and any proof of concept until a fix was available and site owners had a reasonable window to update. Fix first, publish second, every time. ## The worst one: an anonymous request that reads the database SP Property Finder’s whole reason to exist is a public property search. A visitor filters listings by city, price, size, number of bedrooms, postcode, and the component turns those filters into a database query. Most of those filters were handled correctly. A few were not. The postcode filter is the clearest example. The search model took the `zip` value from the request and pasted it straight onto the end of the query as `a.zip = `, with none of the quoting that the neighbouring `city` and `keyword` filters use (`components/com_spproperty/models/properties.php:166`, with the same pattern in the map view at `models/maps.php:153`). The sort control had the same flaw in its `ORDER BY` clause, where the sort direction was appended raw (`properties.php:190`), and so did the price and size range dropdowns (`properties.php:131` and `:136`). A postcode and a sort direction are ordinary-looking fields, which is exactly why the missing quoting is easy to overlook. There is no login, no token and no CSRF check in front of any of it. The property search is meant to be used by anonymous visitors, so the endpoint is open by design, and the missing input handling turns that open endpoint into an unauthenticated [SQL injection](https://owasp.github.io/www-community/attacks/SQL_Injection). An anonymous attacker could read any table in the Joomla database, from user accounts and password hashes to the site secret and every stored enquiry. We confirmed it on our own SP Property Finder test install, two ways. A boolean proof: a crafted postcode that asked the database a true-or-false question about another table (does a user with this ID exist, does this character of the admin password hash match) changed which listings came back, letting an answer be read out one bit at a time. And a time-based proof: a value that made the database pause for a measurable few seconds against an instant baseline, which shows the injected code ran inside a real query even when nothing is visible on the page. We did not extract any real data beyond confirming the admin username and the first byte of its hash on our own lab box. This one leaves no trace A database read leaves your site looking untouched: no file changes, no new admin user, nothing for an integrity scanner to catch. If a vulnerable version was ever live, treat the database as potentially copied, rotate the Joomla secret and any stored API keys, and assume password hashes are known. ## Read-only, but not harmless It is worth being precise about what this injection can and cannot do, because the honest answer is more useful than the scary one. It is a read-only injection. It sits inside a `SELECT` that fetches property listings, and Joomla’s database driver does not run stacked queries, so there is no way to turn it into an `INSERT`, `UPDATE` or `DELETE`. An attacker cannot use this bug on its own to add an administrator, change a price, or write a file. The Joomla CNA published it as 9.3 Critical, on a vector that assumes integrity and availability impact. We score the injection itself High rather than Critical, because it is read-only: a total loss of confidentiality, with integrity and availability untouched. On a read-only bug that distinction is worth keeping, and it changes nothing about how fast you should update. Read-only does not mean small. The injection reads the whole database, not just SP Property Finder’s own tables, so “confidentiality” here means every row on the site is exposed to an anonymous request. On a property site that includes the personal data the component holds, the enquirer names, email addresses and phone numbers submitted through contact and booking forms, the agent records, and the booking and enquiry history. It includes unpublished and draft listings and any prices not yet meant to be public. It includes the Joomla `#__users` table, with usernames, email addresses and password hashes, the session table, and the site secret. There is no table the query cannot reach: if it is in the database, an anonymous visitor can read it. The catch is that a full database read is a short step from full compromise. The Joomla session table lives in the same database, so an attacker who can read arbitrary tables can read a logged-in administrator’s session token and step straight into the admin panel with it, no password required. From there, installing a malicious extension is a normal administrator action. Reading the password hashes offers a slower second route through offline cracking. “Read-only” describes the bug, not how far the damage reaches. ## The second finding: an open mail relay The property pages have contact and enquiry forms, so a visitor can ask an agent about a listing. To send that email, the form told the server who to send it to, and the server believed it. The recipient address was taken straight from the submitted request and used as-is, with no server-side lookup of the real agent and nothing to stop a visitor changing it (`controllers/agents.php` and `controllers/properties.php`, neither of which has a CSRF token on the send). Because the recipient comes from the request, an attacker could point it at any address they liked, set the sender to anything they liked, and make the site send arbitrary email. The result is an unauthenticated open mail relay: any SP Property Finder site with a contact form on a published listing could be made to send email to any recipient, with a spoofed sender, **from the site’s own domain and mail server**. That is a spam and phishing platform running on your domain’s reputation, and the fastest way to get your legitimate mail blacklisted. The correct fix, which the update makes, is for the server to look up the real recipient from the property or agent record it already holds, rather than trusting one supplied by the browser. ## Does 4.1.4 actually fix it? We tested it rather than reading the changelog, because a fix release and a fixed bug are not always the same thing. With this same vendor in August we reported a SQL injection, watched the patch harden the exact method we named, and [found the identical flaw still reachable through the function directly below it](https://mysites.guru/blog/sp-page-builder-pre-auth-rce-file-inclusion-disclosure/). The check worth doing is a before and after on one install. We ran our original attack requests against 4.1.3, confirmed every one of them still worked, then sent the identical requests to 4.1.4. That order matters more than it sounds: a patched site returning no results looks exactly like a site where the filter stopped being applied at all, and only the control run separates the two. On 4.1.4 the postcode filter still filters and no longer injects. A value crafted to break out of the query comes back treated as ordinary text, and the database reports no error behind it. The sort control is checked against a fixed list of permitted columns and directions, so anything else falls back to the default ordering instead of reaching the query at all. The price and size ranges are validated as numbers before use. The map view got the same treatment as the property list, closing the second route to the same flaw. The contact forms were rebuilt rather than patched around. The recipient is looked up in the database from the property or agent being enquired about, so the browser cannot influence who receives the mail, and both endpoints require a valid session token before they will send anything. ## Fixed properly, shipped by JoomShaper with no announcement or credit The fix itself is good work, and we say so above. What surrounds it is the pattern we have written about before with this vendor. It also took a month, and most of that month was waiting. We reported the flaw on 10 August and 4.1.4 shipped on 10 September. JoomShaper acknowledged the report on 11 August, naming the affected parameters back to us, then went silent for 27 days. The build only appeared after we chased on 7 September and copied the Joomla Security Strike Team on the thread, at which point a fixed package reached us within 20 hours. The engineering, once it started, was quick and correct. What it took to start was a chase, with the Joomla Security Strike Team copied in to see the response time for themselves. JoomShaper released SP Property Finder 4.1.4 on 10 September 2026 with no security announcement and no advisory. It exists as a changelog on the download page, the security entries sitting above routine map and asset-loading tidy-ups with nothing to mark them apart. ![The SP Property 4.1.4 changelog on JoomShaper's download page, dated 10 September 2026. A Security section lists five entries, each with a shield icon: an unauthenticated SQL injection in property search and map filter parameters (CVE-2026-78082), CSRF token verification on property booking and agent contact forms (CVE-2026-78083), a JavaScript-context XSS issue in property and agent view script blocks (CVE-2026-78302), authorization checks and upload validation for gallery images (CVE-2026-78084), and contextual output escaping across agent and property templates (CVE-2026-78303). A Fixes section below lists ordinary bug fixes for OpenStreetMap display, Mapbox tiles and asset loading. Nowhere does the page say vulnerability or advisory, or name a reporter.](https://mysites.guru/_astro/sp-property-4-1-4-changelog.vBtIudw2_ZLzVOV.webp) Two of those five CVEs are the issues we reported. [CVE-2026-78082](https://mysites.guru/vulnerabilities/CVE-2026-78082/) is the SQL injection, which the Joomla CNA published at 9.3 Critical and credited to us. [CVE-2026-78303](https://mysites.guru/vulnerabilities/CVE-2026-78303/) is the mail relay, which the CNA records as an unvalidated email destination in booking requests. The changelog’s own wording does not line up with those records: it labels [CVE-2026-78303](https://mysites.guru/vulnerabilities/CVE-2026-78303/) as “contextual output escaping” rather than the mail relay it closes, and never uses the word relay anywhere. The other three CVEs cover a missing CSRF check, a gallery access-control flaw and a cross-site scripting bug, and are not our findings. JoomShaper’s changelog credits no one; the Joomla CNA credits us on the SQL injection alone. The changelog names no reporter. We had asked JoomShaper to tell us when 4.1.4 went public and were not told; we found the release through our own version tracking. It is the same shape we described with [SP Page Builder](https://mysites.guru/blog/sp-page-builder-sql-injection-mail-relay-disclosure/) and [EasyStore](https://mysites.guru/blog/easystore-security-disclosure/) earlier in the year: a complete, well-built fix, shipped without a word to the person who reported it. We have no complaint about the engineering, only about being left to find the release ourselves and about a changelog whose descriptions do not even match the CVE records it cites. ## Which versions are affected? SP Property Finder **4.1.3**, the version we audited, and **every earlier version** that shares the same front-end search models are affected. JoomShaper fixed the issue in SP Property Finder **4.1.4**. If you run any earlier version, assume your site is affected and update now: the search endpoint needs no login, so if the site is online, it is reachable. If you are on 4.1.3 or earlier Assume your site is affected and update now. The SQL injection needs no login and no token, so a public property search page is all an attacker needs to reach it. ## How do you update SP Property Finder safely? 1. **Take a backup first.** Before any extension update on a production Joomla site, back up the database and files. If you use mySites.guru, [trigger a snapshot](https://mysites.guru/blog/get-a-quick-snapshot-of-your-joomla-and-wordpress-sites-with-mysites-guru/) or a [full backup](https://mysites.guru/blog/backup-all-your-joomla-wp-sites-easily-with-one-button-in-mysites-guru/) first. 2. **Update through Joomla’s Extensions manager, or in bulk from mySites.guru.** On a single site, open the Joomla administrator, go to System, then Update, then Extensions, and let Joomla pull SP Property Finder 4.1.4. If you manage more than one site, use the mySites.guru [mass update feature to upgrade SP Property Finder across every affected site from one dashboard](https://mysites.guru/blog/how-to-mass-upgrade-joomla-and-wordpress-sites-from-one-dashboard/). 3. **Confirm the version.** After updating, check SP Property Finder reports 4.1.4 or later. 4. **Clear caches.** Clear Joomla’s cache and any CDN or page cache. Property search pages are often cached, which is worth knowing here: page caching hid the flaw from casual testing during our audit, because identical requests returned an identical cached page. 5. **Rotate secrets if you were exposed.** If a vulnerable version was live and public for any length of time, rotate the Joomla secret and any stored API keys, and treat password hashes as potentially known. Updating closes the door. It does not undo any data an attacker may already have read through the SQL injection, so if you handle sensitive data and were on a vulnerable version for a while, treat credentials and exposed data as potentially known. ## What the sites we monitor look like today We keep a live inventory of every extension on every connected Joomla site, so we can see how SP Property Finder is versioned across the ones we monitor. Here is the spread on the day 4.1.4 shipped. - **94%** - still on a version below 4.1.4 - on the day the fix shipped - **52%** - on 4.1.3, the version we audited - the build the injection was proved against - **15%** - on a release older than the 4.1 line - some on the 1.x and 3.x branches, years behind - **6%** - already updated to 4.1.4 - within hours of release Measured 10 September 2026 across connected Joomla sites running com\_spproperty with a snapshot in the previous 30 days. Percentages of that group, a small population, not of all managed sites. Release day is too early to judge an update rate, so the 94% is expected rather than damning. The figures that matter are the half still on 4.1.3, the exact build we proved the injection against, and the sites several releases behind on the 1.x and 3.x branches, where a security release is easy to miss entirely. On the day a fix ships for a public, unauthenticated, whole-database read, almost every affected site is still running the code that leaks. Closing that gap is deliberate work, and it is the work the next section is about. ## How do I find every SP Property Finder site I manage? Up to about ten sites, you can log in to each Joomla admin and check. Past that, you need a single view. mySites.guru keeps a live inventory of every extension, template and framework on every Joomla and WordPress site in your account. You search for SP Property Finder once and get back every connected site running it, the version each one is on, and whether an update is available. View every SP Property Finder install across your sites [Open your Extension Inventory](https://manage.mysites.guru/en/extensions) Search for SP Property Finder across every connected Joomla site and filter for anything earlier than 4.1.4. Not a subscriber? [Sign up free](https://manage.mysites.guru/en/register) and connect your sites. ## Why search and listing components keep producing this A property search is attack surface for the same reason it is useful: it takes input from anonymous visitors and turns it into a database query. A filter for postcode, price or bedroom count cannot require a login, because the whole point is that visitors use it. Every one of those public filters is a place where request input meets the database, and when the code behind them concatenates that input into the SQL instead of quoting it, an anonymous visitor becomes an anonymous attacker. We have seen the same shape across the Joomla ecosystem this year, from the [SP Page Builder pre-auth SQL injection](https://mysites.guru/blog/sp-page-builder-sql-injection-mail-relay-disclosure/) in the same vendor’s flagship builder, to [Quix](https://mysites.guru/blog/quix-sql-injection-disclosure/) and [DPCalendar](https://mysites.guru/blog/dpcalendar-sql-injection-disclosure/), and the wider [month of Joomla disclosures](https://mysites.guru/blog/a-month-of-joomla-security-disclosures/). The lesson is the same each time: the components that accept input from anonymous visitors need updating the moment a fix exists, which makes these updates security-critical rather than routine maintenance. ## Stay ahead of the next one There will be another, because Joomla runs on thousands of third-party extensions and the ones that accept input from anonymous visitors keep producing bugs like these. The hard part is never the update itself. It is knowing a fix exists, knowing which of your sites are affected, and getting to them before an attacker does. That is the job mySites.guru does for you. It keeps a live inventory of every extension on every Joomla and WordPress site in your account, flags the ones with a known vulnerability, and lets you push the update to all of them from one screen. Get free email alerts when a Joomla vulnerability breaks We email a plain-English alert the moment a serious flaw like this one is disclosed, with the affected versions and what to do. No charge, unsubscribe any time. [Subscribe to security alerts](https://list.mysites.guru/subscribe) Want the alerts and the tooling to act on them? Start with a [free audit](https://mysites.guru/free-audit/) on one site and see your full extension inventory, or [sign up for mySites.guru](https://mysites.guru/pricing/) to get vulnerability alerts and one-click updates across every site you manage. ## Disclosure and severity The main finding is a SQL injection (CWE-89) reachable by an anonymous visitor over the network, with no login and no token. It is read-only, which caps the direct impact at a total loss of confidentiality: full read access to the database, integrity and availability untouched. The secondary finding is an unauthenticated mail relay: the property contact forms trust a request-supplied recipient, yielding arbitrary mail sending with sender spoofing. SP Property Finder 4.1.4 shipped on 10 September 2026. The Joomla CNA published [CVE-2026-78082](https://mysites.guru/vulnerabilities/CVE-2026-78082/) for the SQL injection, credited to Phil Taylor of mySites.guru, and [CVE-2026-78303](https://mysites.guru/vulnerabilities/CVE-2026-78303/) for the mail relay, with no reporter named. Three further CVEs in the same release, for a CSRF gap, a gallery access-control flaw and an XSS issue, are not our findings. The Joomla CNA published the SQL injection at **9.3 Critical**, on a vector (`VC:H/VI:H/VA:H`) that assumes integrity and availability impact. We assess the injection itself at **8.7 High**: it is read-only, so the honest vector is `VC:H` alone, a total loss of confidentiality with integrity and availability untouched. It sits at the top of the High band either way, and a full-database read is serious regardless of where the number falls. 8.7CVSS 4.0 HighmySites.guru read-only assessment (Joomla CNA published 9.3 Critical) Reachable over the internet through the public property search, with no login and no token. Ends in full read access to the site database, password hashes and the site secret included. The Joomla CNA scored it 9.3 Critical on a vector that also assumes write and availability impact; we keep the read-only vector we proved. `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N` No login neededExploitable over the internetFull database readPassword hashes exposed 6.9CVSS 4.0 MediummySites.guru assessment CVE-2026-78303. The property contact and booking forms trusted a recipient address supplied by the browser, so the site could be made to send mail to anyone with a spoofed sender. Scored Medium because nothing on the Joomla site itself changes, which understates the real cost: phishing sent from your own domain and mail server. `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N` No login neededSender spoofingMail sent from your domain Each finding, scored under CVSS 4.0: Finding Vector (`CVSS:4.0/...`) Score Severity Unauthenticated SQL injection (full DB read) `AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N` 8.7 High Unauthenticated mail relay (sender spoofing) `AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N` 6.9 Medium CVSS 4.0 scores the mail relay **6.9, Medium**, because the direct impact on the Joomla system is low: it reads and changes nothing on the site itself. That number understates the practical risk, which is phishing sent from your own domain and mail server, and the mail-reputation damage that follows. We treat it as a priority fix regardless. Field Detail Component SP Property Finder for Joomla (`com_spproperty`) Vendor JoomShaper ([joomshaper.com](https://www.joomshaper.com/)) Type Unauthenticated SQL injection (CWE-89); unauthenticated mail relay (CWE-640 / CWE-79-adjacent) CVSS 4.0 SQL injection 9.3 Critical (Joomla CNA), 8.7 High (our read-only assessment); mail relay 6.9 Medium CVE [CVE-2026-78082](https://mysites.guru/vulnerabilities/CVE-2026-78082/) (SQL injection, credited to Phil Taylor by the Joomla CNA) and [CVE-2026-78303](https://mysites.guru/vulnerabilities/CVE-2026-78303/) (mail relay); both published 10 September 2026 Impact Anonymous read of the whole database including password hashes and the site secret; unauthenticated arbitrary mail sending with sender spoofing Finder Phil Taylor, mySites.guru Affected versions 4.1.3 and all earlier versions sharing the front-end search models Fixed in SP Property Finder 4.1.4 Reported 10 August 2026 (privately to JoomShaper) Acknowledged 11 August 2026 (JoomShaper confirmed receipt) Fixed 10 September 2026 (SP Property Finder 4.1.4) CVE published [CVE-2026-78082](https://mysites.guru/vulnerabilities/CVE-2026-78082/) and [CVE-2026-78303](https://mysites.guru/vulnerabilities/CVE-2026-78303/), both 10 September 2026 ## Timeline - **2026-08-10** Reported privately to JoomShaper An unauthenticated SQL injection reading the whole database including password hashes and the site secret, plus an unauthenticated mail relay, both in SP Property Finder. All public detail withheld. - **2026-08-11** JoomShaper acknowledges the report The vendor confirmed receipt within a day and named the affected parameters back to us, so the report had reached someone technical rather than a support queue. - **2026-09-07** We chase, 27 days after the acknowledgement, copying the Strike Team Nothing had been heard since 11 August. The chase copied the Joomla Security Strike Team, and a fixed build followed within 20 hours. - **2026-09-08** JoomShaper sends a fixed build for checking We retested it against our original attack requests, with a control run on the vulnerable version first, and confirmed every reported flaw was closed. Nothing changed for site owners at this point, because the build was not public yet. - **2026-09-10** JoomShaper ships 4.1.4 with no announcement Released with no security announcement and no advisory, as a changelog on the download page. We had asked to be told when it went out and were not; we found the release ourselves. It is the same build JoomShaper sent for sign-off, so our verification stands. - **2026-09-10** The release cites five CVEs, two of them ours CVE-2026-78082 for the SQL injection and CVE-2026-78303 for the mail relay are the two we reported; three more cover issues we did not. The Joomla CNA credits Phil Taylor as finder on the SQL injection record and no one on the rest; JoomShaper's own changelog credits no one at all. All five published at MITRE the same day. ## Further Reading - [Our SP Page Builder SQL injection and mail relay disclosure](https://mysites.guru/blog/sp-page-builder-sql-injection-mail-relay-disclosure/) - the same vendor, the same pairing of a database read and a mail relay, in a different component. - [Our DPCalendar](https://mysites.guru/blog/dpcalendar-sql-injection-disclosure/) and [Quix Page Builder](https://mysites.guru/blog/quix-sql-injection-disclosure/) SQL injection disclosures, and the [month of Joomla security disclosures](https://mysites.guru/blog/a-month-of-joomla-security-disclosures/) - the same class of bug across the ecosystem. - [Why AJAX endpoints are a CMS security blind spot](https://mysites.guru/blog/ajax-endpoints-cms-security-blind-spot/) - the recurring public-endpoint pattern behind flaws like this one. - [CWE-89: SQL Injection](https://cwe.mitre.org/data/definitions/89.html) - the canonical reference for this weakness class. - [JoomShaper downloads](https://www.joomshaper.com/downloads/extension) - the vendor's download page, where 4.1.4 appears. ## Digital Peak patches four Joomla extensions after a Claude audit URL: https://mysites.guru/blog/digital-peak-claude-security-audit-release/ Date: 2026-09-10 Tags: security, joomla, dpcalendar, dpattachments, vulnerability, ai Category: Manage Multiple Joomla Sites Digital Peak shipped out-of-band fixes for DPCalendar, DPMedia, DPAttachments and DPCases on 10 September. DPAttachments is the one to do first. [Digital Peak](https://joomla.digital-peak.com/) shipped five releases across four Joomla extensions today, all rated High and all out of band. The vendor puts eleven of the twelve fixes down to a security analysis run with Claude over the last few days. The twelfth is the DPCalendar location title, which we reported on 27 August and which the announcement now credits to us. That is the third DPCalendar security release in nine weeks, and the first one that reaches past the calendar into the rest of the catalogue. The code is public for three of the four extensions, so we read the actual changes rather than working from the severity ratings. Do DPAttachments first, then the rest DPAttachments 5.8.1 is the only one the vendor asks you to prioritise, and the code shows why: the attachment download route checked that an attachment record existed and never checked whether the person asking was allowed to have it. The other three generally need an account, or content arriving from a source you already trust. ## TL;DR - Five releases: **DPCalendar 10.12.1** and **8.19.6**, **DPMedia 1.21.1**, **DPAttachments 5.8.1** and **DPCases 3.8.1**. Every one of them is tagged Security: High on its download page - **DPAttachments is the priority.** Unpublished attachments, attachments on a restricted view level, and attachments outside their publish window could all be downloaded by someone with no entitlement to them - The releases are **out of band**. Digital Peak normally ships on the fourth Thursday of the month, and today is the second Thursday - **The Joomla 3 branch got one fix, not three.** DPCalendar 8.19.6 is security only and its release notes list the unescaped location title alone - **The DPCalendar fix is one we reported.** We sent it to Digital Peak and the Joomla Security Strike Team on 27 August, and the vendor’s announcement now credits it - **Eleven of the twelve have no CVE yet.** The DPCalendar location title is the exception, under [CVE-2026-78071](https://mysites.guru/vulnerabilities/CVE-2026-78071/), whose affected range was widened on release day to take in 10.12.0 and 8.19.5 - Two of the fixes share a shape worth recognising: in both DPAttachments and DPCalendar, the escaping was already present on the field next door and simply missing on one - **DPCalendar is not one update.** On release day our [Release Radar](https://releases.mysites.guru/joomla?q=DP) recorded 59 distinct DPCalendar items moving to the new versions ## What did Digital Peak fix on 10 September? Twelve issues across four extensions, four of them rated High and eight Medium. The vendor’s [announcement](https://joomla.digital-peak.com/blog/claude-security-audit-results) lists them by severity, and each release page lists the internal tracker numbers. Extension Fixed in High-severity issue Also fixed [DPCalendar](https://joomla.digital-peak.com/products/dpcalendar) [10.12.1](https://joomla.digital-peak.com/download/dpcalendar/dpcalendar-10.12.1), [8.19.6](https://joomla.digital-peak.com/download/dpcalendar/dpcalendar-8.19.6) Location title not escaped in the map view and upcoming module Microsoft and Exchange attachment filename hardening, CSRF state parameter on calendar imports [DPMedia](https://joomla.digital-peak.com/products/dpmedia) [1.21.1](https://joomla.digital-peak.com/download/dpmedia/dpmedia-1.21.1) DPReferences shows references to users without media manager access Path traversal on external file names, Google Drive search injection, OAuth state parameter, two permission plugin fixes [DPAttachments](https://joomla.digital-peak.com/products/dpattachments) [5.8.1](https://joomla.digital-peak.com/download/dpattachments/dpattachments-5.8.1) Unauthorised access to direct downloads Stored XSS in the CSV preview, upload context validation [DPCases](https://joomla.digital-peak.com/products/dpcases) [3.8.1](https://joomla.digital-peak.com/download/dpcases/dpcases-3.8.1) User information not escaped in views Path traversal for icons outside the root The DPCalendar row is the one with a history. That flaw is the tail of an incomplete fix from the previous release, and we are the ones who reported it, which is covered [further down](#where-the-dpcalendar-fix-came-from). Digital Peak states that none of the twelve allows a file to be placed on the server, and that there is no evidence of exploitation in the wild. We found nothing to contradict that. There is no public proof-of-concept and no exploit code for any of them. Two items in the DPMedia release notes are worth flagging because they do not appear in the announcement’s security list at all: a permission plugin that should check delete and save, and a restricted adapter that should consider permissions from the category and the article. Both read as access-control work. Neither is described as a security fix. ## DPAttachments 5.8.1 is the update to do first DPAttachments is developed in a [fully public repository](https://github.com/Digital-Peak/DPAttachments), so this one can be read rather than inferred. The fix for the High-severity issue is a single commit, `Case 12252: Check access if an attachment can be downloaded`. Before the fix, the download controller looked up the attachment by the ID in the request and made one check: ```diff public function download(): void { $attachment = $this->getModel()->getItem($this->input->get('id')); - if (!\is_object($attachment)) { + if (!$attachment instanceof \stdClass || !$this->app->bootComponent('dpattachments')->canView($attachment)) { header('HTTP/1.0 404 Not Found'); exit(0); } ``` The original test asks whether the attachment exists. It does not ask whether the requester is entitled to it. Those are different questions, and only one of them was being asked. The fix adds a `canView()` method to the component and calls it from both the download controller and the front-end attachment view, which had the same gap: ```php public function canView(\stdClass $attachment): bool { if ($this->canDo('core.edit', $attachment->context, $attachment->item_id)) { return true; } $user = $this->app->getIdentity(); if ($user === null || (int)$attachment->state !== 1) { return false; } if (!\in_array((int)$attachment->access, $user->getAuthorisedViewLevels(), true)) { return false; } $now = (new Date())->toSql(); if (!empty($attachment->publish_up) && $attachment->publish_up > $now) { return false; } return empty($attachment->publish_down) || $attachment->publish_down >= $now; } ``` Read that as a list of the things that were not being enforced, because that is what it is. Publication state, view access level, publish-up date and publish-down date were all recorded on the attachment and none of them governed who could download it. The acceptance tests added alongside the fix say the same thing more bluntly. One is titled `canNotOpenUnpublishedAttachmentDetailsPage`, and its stated intent is “that an unpublished attachment cannot be viewed by a guest”. A test written to assert that a guest cannot do something is a test written because a guest could. This is the classic missing-authorisation shape, [CWE-862](https://cwe.mitre.org/data/definitions/862.html), and it is the same pattern we wrote up when [Events Booking exposed invoices](https://mysites.guru/blog/events-booking-invoice-idor/) and when [Cotton Cloud patched the login and left the data](https://mysites.guru/blog/cotton-cloud-incomplete-security-fix/). Attachment IDs are sequential integers, which is the part that turns a missing check into a practical problem. We are describing the mechanism at the level the vendor did, and not publishing a request template, because most sites running this extension have not updated yet. ## The escaping was already there, one field along The second DPAttachments fix, `Case 12253`, is in the CSV preview template. It escaped the body of the table and not the header row. ```diff titles as $title) { ?> - + escape((string)$title); ?> data as $row) { ?> - + escape((string)$value)); ?> ``` The data cells were already running through `htmlentities()`. The header cells, four lines above them in the same file, were not. Digital Peak committed a test fixture, `test-xss.csv`, whose first column heading is a working `