DJ-Classifieds 3.11.3 Fixes SQL Injection, Upload and Ownership Flaws

DJ-Extensions released DJ-Classifieds 3.11.3 on 2 November 2026. The changelog that went out with the vendor’s update notification lists security fixes for unrestricted uploads, SQL injection and missing ownership checks. The package appeared on the mySites.guru release feed that morning as “DJ-Classifieds Package 3.11.3”, and the download sits in the DJ-Extensions customer account area.

If a Joomla site you manage runs DJ-Classifieds, update it to 3.11.3 today. The changelog names the classes of flaw and nothing more, so we compared the 3.11.2 and 3.11.3 code to see what changed. All three classes check out, two of the SQL injections are reachable without a login under common settings, and the comparison also turned up a fix the changelog does not mention: an eval() in the bundled PayPal payment plugin that ran on attacker-supplied input before PayPal verification. That is the most serious thing in the release, and it is the one we are least certain about, for reasons set out below.

What DJ-Classifieds 3.11.3 fixes

Here is the release in order of severity, worst first. The scores are our own CVSS 4.0 assessment, derived from the code, not from a published advisory. There is no CVE for any of these yet.

Everything below comes from comparing the released code of both versions side by side.

The bundled PayPal plugin ran eval() on request input

DJ-Classifieds ships its own PayPal payment plugin. Its job is to receive PayPal’s Instant Payment Notification, a server-to-server POST that confirms a payment, and the correct design verifies that notification with PayPal before trusting a word of it.

In 3.11.2 the handler did something else first. It looped over the POST fields and, for each one, ran eval() on a string built from the field’s name. The field names come straight from the request, so an attacker who could shape them could get their own PHP to run. This happened before the plugin asked PayPal whether the notification was genuine, so the PayPal check that is meant to be the gate never stood between the attacker and the eval().

The payment view reaches this handler with no login and no CSRF token, so on a site that has the PayPal plugin enabled the path is anonymous.

3.11.3 deletes the loop entirely, so no request input reaches eval().

Two things to note. The changelog does not mention this fix, so we are describing a change we found by reading the diff, not a flaw the vendor disclosed. And it only matters on sites that use the bundled PayPal plugin. We think that combination still makes it the most serious item in the release, which is why it leads.

A location cookie reached the listing queries unescaped

DJ-Classifieds can sort and filter listings by distance from the visitor, and it keeps the visitor’s coordinates in a cookie called djcf_latlon. On the public advert and profile listings, that cookie value was split on an underscore and dropped straight into the distance calculation in the SQL, with no escaping and no numeric cast.

A cookie is entirely under the visitor’s control, so a value shaped as SQL was read as SQL. The listings are public, so no login is involved. The path runs when a distance column or a geolocation search is enabled, which is a common setup for a classifieds site that groups adverts by location. A SELECT-based injection like this reads data, so the realistic outcome is reading the database, including the user table, which is why the confidentiality impact is High.

3.11.3 casts the coordinates to numbers before they reach the query, in the listings and in the maps module, the search module, the Leaflet plugin and the Google Maps layout that shared the same pattern.

The advert id was bound from the form into a query

When an advert is saved, the save handler bound the entire submitted form onto the advert record and then used the record’s id in a query. The id was cast to an integer for the ownership check, but the raw submitted value was what reached the query, so a value such as 0 UNION SELECT ... passed the integer check as a harmless 0 while the full string was concatenated into the SQL.

The save needs a form token, which any visitor can read from the public add-advert page, so the token is not a barrier. Whether a login is needed depends on one setting: when guest advert posting is enabled, the save is reachable without an account, and many classifieds sites run that way. With guest posting off, it needs any registered user, which lowers the score to 7.1. Like the cookie injection, this is a SELECT path, so the realistic impact is reading the database.

3.11.3 stops the save binding server-controlled columns such as the id from the form, and resets the id to the loaded, ownership-checked record before any query uses it.

The image rotate action accepted any path

The front-end image rotate action took a file path from the request, joined it to the site root, and rotated the image at that path in place. It did not check that the path stayed inside the upload folder and did not reject .. segments, so an anonymous request could point it at an image anywhere the path could reach and have the component re-encode it.

This one does not read data or run code. It can only rotate or corrupt image files the web server can write, so the impact is limited tampering and the loss of those image assets, which is why it scores Medium rather than higher. It is still reachable with no login and no token.

3.11.3 confines the action to the temporary upload folder, resolves the real path and rejects anything that climbs out of it.

Payment and advert-copy actions did not check ownership

Several actions checked that a user was logged in but not that the record they were acting on belonged to them. In 3.11.2 a logged-in user could reach another user’s payment, order or offer, and could copy another user’s advert and its images. This is the “missing ownership checks” line in the changelog, and it is the one class here that needs a login, so it is a logged-in user reaching another user’s data rather than an anonymous one.

3.11.3 adds an owner check to the payment, order, offer and advert-copy paths, and to the advert-copy images, allowing a configured administrator through but no one else.

How mySites.guru flags DJ-Classifieds below 3.11.3

mySites.guru records every installed extension and its version on every connected site twice a day, and flags any site running a version listed in its Joomla vulnerability database on the site’s own card and in its audit. The Joomla element for this component is com_djclassifieds.

Connected sites running DJ-Classifieds below 3.11.3 are flagged, with 3.11.3 shown as the version that resolves it. Sites still below 3.11.2 were already flagged for the July upload flaw, so for them this release changes the target version as well.

How this relates to the July DJ-Classifieds upload fix

DJ-Classifieds 3.11.2, released on 20 July 2026, fixed an unauthenticated file upload in the front-end imageupload task. mySites.guru found that one in a customer’s server logs and reported it privately, and DJ-Extensions released the fix three days later. It is tracked as CVE-2026-61424, scored CVSS 4.0 10.0 by the Joomla CNA. Separately, CVE-2025-54474 was an authenticated SQL injection in 3.9.2 to 3.10.1, fixed in 3.10.2.

That makes 3.11.3 at least the third DJ-Classifieds security release in recent months. The 3.11.3 upload fix is a different path from the July one: 3.11.2 fixed the imageupload task, while 3.11.3 changes how profile, category and custom-field image uploads decide a file is an image, replacing a check on the browser-sent type with a check on the real file content. A site owner does not need to tell the two apart. Update to 3.11.3 and both are closed.

Not a mySites.guru finding, and no CVE yet

These are not flaws we reported to DJ-Extensions. We found the July upload flaw and reported it privately, but for 3.11.3 we did what any site owner’s security team could do: we compared the released code against the previous version to see what the vendor changed. Everything above comes from that comparison and from the changelog a DJ-Classifieds user forwarded to us.

No CVE has been published for any of these fixes. Whoever reported the vendor-listed flaws, or the Joomla CNA, may assign numbers later, as happened with the July flaw. A missing CVE is paperwork that has not caught up, not a verdict on severity, so do not wait for one before updating. We have covered DJ-Extensions before, on DJ-HelpfulArticles 1.3, and this release sits in a longer run of Joomla extension disclosures where the fix often arrives before the paperwork does.

What to do today on every Joomla site running DJ-Classifieds

1. Update every DJ-Classifieds site to 3.11.3. The download is in the DJ-Extensions customer account area and needs an active subscription.
2. If any site is still below 3.11.2, do that one first. It is also exposed to the July unauthenticated upload, CVE-2026-61424, and that one was being probed in the wild before its fix was released.
3. After updating, look in the component upload folder, tmp/djupload under the web root by default, for files you did not put there.
4. Check the Joomla Super User and Administrator groups for accounts you did not create.
5. Look for recently modified PHP files across the whole site, not just the upload folder.

Flag every Joomla site the day a fix is released

A release like this one is a list-building problem before it is an update problem: which of your sites run DJ-Classifieds, on which version, and which of those are still below 3.11.2. By hand that is a login per site. On mySites.guru the subscription answers it from the twice-daily snapshot, and every connected site running an affected version is flagged the day a fix is released, with the version that resolves it.

The follow-up checks run as part of the same subscription. The rogue admin check above lists Super Users added outside the normal flow, and the Joomla malware scanner looks for code dropped on the server once someone has a way in. If a site already shows signs of compromise, start with the Joomla hacked-site guide, or have us clean it for you.

If you manage Joomla sites for clients, see what the subscription costs, or run the free audit to see what it finds on your own sites first.