Unauthenticated SQL Injection in SP Property Finder found by mySites.guru

SP Property Finder 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. 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 (SQL injection, credited to Phil Taylor by the Joomla CNA) and 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

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 = <value>, 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. 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.

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.

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.

Two of those five CVEs are the issues we reported. CVE-2026-78082 is the SQL injection, which the Joomla CNA published at 9.3 Critical and credited to us. 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 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 and EasyStore 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.

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 or a full backup 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.
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.

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.

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 in the same vendor’s flagship builder, to Quix and DPCalendar, and the wider month of Joomla 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.

Want the alerts and the tooling to act on them? Start with a free audit on one site and see your full extension inventory, or sign up for mySites.guru 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 for the SQL injection, credited to Phil Taylor of mySites.guru, and 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.

Each finding, scored under CVSS 4.0:

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.