jDownloads 4.1.8 Fixes a Critical File Upload RCE and Eight More Security Issues

TL;DR

Arno Betz released jDownloads 4.1.8 Stable on 12 November 2026 as a security update for Joomla 5 and 6, and the Joomla CNA published five CVE records for it the same day. The worst is CVE-2026-117551, scored 10.0 Critical. Front-end thumbnail uploads were not validated properly, so a user with upload permission could place an executable file on the server and run PHP code. The other four are a server-side request forgery (SSRF) at 8.9 High, a download permission bypass at 8.2 High, a way to publish submissions without approval at 7.1 High, and an authenticated path traversal at 5.1 Medium.

jDownloads is a third-party download manager extension for Joomla, so these are flaws in the extension and Joomla itself is not involved. All five records give the affected range as jDownloads 1.0.0 to 4.1.7, and 4.1.8 is the only fixed release. Sites on 4.1.x can update directly. Sites on 4.0.x, 3.9 and older lines are affected too and have no fixed release on their own line.

The vendor’s release notes list nine security changes, and four of them have no CVE yet. One of those four is a scan page in 4.1.x that ran without a login and showed the scan’s secret key to whoever opened it, which we score 6.9 Medium ourselves. The update does not change that key for you, so rotate it after updating.

What jDownloads 4.1.8 Fixes

The Security section of the 4.1.8 release notes has nine entries. They are in the vendor’s order here, with the vendor’s own wording in the first column:

That list is short on detail, and the vendor says as much: “These release notes are a high-level summary of selected changes, not a complete changelog. A full review of the differences between 4.1.7 and the final 4.1.8 package is still pending.” The CVE records describe five of the nine, and the 4.1.7 package shows what the scan interface did. For the two rename entries and the import and restore entry, the vendor’s line above is all that has been published.

The vendor’s announcement thanks Łukasz Rybak and Fadilulah Ajeigbe for their security reports, and David Jardin and the Joomla! Security Strike Team for coordinating. The CVE records split that credit: Fadilulah Ajeigbe for the thumbnail upload flaw, and Łukasz Rybak for the other four.

The rename fix changes how jDownloads behaves for editors, and the vendor calls it intentional. Renaming an existing main or preview file now has to keep its extension, and changing a file’s type means replacing the file through the normal upload workflow.

PHP Code Execution Through Thumbnail Uploads (CVE-2026-117551)

The record’s title is “RCE through file upload”, and its weakness class is CWE-434, the unrestricted upload of a dangerous file type. jDownloads accepts thumbnail images through its front-end upload form. Before 4.1.8 it did not check those uploads well enough, so a user with upload permission could send a file the server would execute instead of an image. Requesting that file runs PHP code on the server, with everything the website itself can read and change within its reach.

The record’s score and its text describe the attacker differently. The vector scores the flaw as needing no privileges, while the description says the attacker is a user with upload permission. Both can be true of the same site, because who holds that permission is a setting. How far this flaw reaches on your site depends on which user groups you allow to upload from the front end. A site that only lets trusted staff upload is exposed to far fewer people than one that accepts uploads from every registered user or from guests.

The vendor’s fix is the first entry in the list above: “Hardened thumbnail upload validation and image-content checks”. Fadilulah Ajeigbe is credited with the report.

This is a different flaw from CVE-2026-61900, the unauthenticated upload endpoint that 4.1.6 removed in July. A site that updated for that one is still affected by this one until it runs 4.1.8.

SSRF Through the External Download URL (CVE-2026-117543)

A download in jDownloads can point at a file on another server, and jDownloads fetches that URL from the web server. It validated the destination it was given, then followed HTTP redirects without applying the same validation to where they led. A URL that passed the check could therefore redirect the server to an internal address or another destination it should never request, and the response came back to the person who set it up.

The vector scores it as hard to exploit: a high-privilege account, high attack complexity and conditions that have to be present on the target. The impact is rated high all the same, because what an internal service returns to its own web server can be far more sensitive than anything on the public site. Łukasz Rybak is credited with the report.

The fix has a side effect that the vendor calls intentional. External downloads that need an HTTP redirect during server-side retrieval may now be rejected, so the vendor recommends using a direct file URL where possible.

Files Delivered Without the Target Download’s Permissions (CVE-2026-117544)

One download can reference the file of another through the other_file_id parameter. jDownloads did not fully enforce the access restrictions of the download that owns the file, so a request could name a restricted download’s file and receive it. The record classes this as an insecure direct object reference (CWE-639) leading to information exposure (CWE-200).

Many sites use jDownloads to keep files behind a login or a user group: member documents, paid files, client deliverables. This flaw let a request bypass those restrictions, and the vector scores it as needing no account. Version 4.1.8 applies the target download’s permissions when a referenced file is delivered. Łukasz Rybak is credited with the report.

Publishing Without Approval (CVE-2026-117550)

Sites that accept downloads from the front end can hold each submission until it has been approved. The front-end form trusted values it should have ignored. By adding or changing submission parameters, a logged-in user could publish their own submission while automatic publication was switched off, and could set who the download belonged to against the site’s ownership rules.

On a site that reviews submissions before they go live, that removes the review. Whatever the user uploaded appears on the public site under the site’s name. Version 4.1.8 protects the publication state and ownership against submitted values. Łukasz Rybak is credited with the report.

The Scan Page That Needed No Login

The sixth entry in the vendor’s list, “Restricted the scan interface to authenticated, authorized backend users”, has no CVE record, so the score above is our own. In jDownloads 4.1.7 the file administrator/components/com_jdownloads/helpers/scan-interface.php is a standalone script. It boots Joomla itself and then runs, with no check that the visitor is logged in and no permission check. It also writes the monitoring scan’s secret key into the page’s JavaScript, so anyone who loads that URL can read the key from the page source.

The file next to it uses that key. scan.php, in the same folder, is the URL-based scan that sites use for scheduled scan jobs, and the key is the only thing it checks before running a scan. A scheduled job has no browser session, so the key works as its password, and in 4.1.7 that password was printed on a page anyone could open.

A scan run compares the jDownloads upload folders with the database and changes the database to match. In the 4.1.7 code it does the following:

• Creates categories and downloads for new folders and files it finds, published or unpublished according to the site’s auto-publish setting.
• Unpublishes published downloads whose files are missing, or deletes the database record if the site is configured to delete.
• Unpublishes categories whose folder is missing.
• Prints a log of what it found.

So an anonymous visitor who had read the key could run that job whenever they liked and read the log it printed. That is why our assessment is 6.9 Medium under CVSS 4.0: no account is needed, and the effect is a limited loss of confidentiality (the key and the scan log) and a limited loss of integrity (records created, unpublished or deleted by somebody with no right to trigger it).

jDownloads 4.1.8 adds the missing check. The scan interface now confirms that the visitor is logged in and has the core.manage permission on jDownloads before the page runs.

The fix stops the page showing the key, and it leaves the key itself as it was. The vendor’s advice is: “If your scan key may have been exposed, rotate it and update any scheduled URL-based scan jobs accordingly. The update does not automatically rotate existing keys.” A key that somebody copied from a 4.1.7 site is still the key after the update, until you change it. Since nothing records who opened that page, treat the key on any site that ran 4.1.7 as exposed.

Path Traversal in Server-File Selection (CVE-2026-117542)

jDownloads lets an editor attach a file that is already on the server to a download, chosen from one permitted directory. The update_file form parameter was not held to that directory. A manipulated value could name a file elsewhere on the server, and jDownloads would move it or assign it to a download. That exposes the file’s contents through the download, and a moved file is gone from where it used to be, which can break whatever depended on it.

The vector requires a high-privilege account, which is why this scores lowest of the five. Version 4.1.8 restricts server-file selection to its authorised workflow and the allowed file location. Łukasz Rybak is credited with the report.

Which jDownloads Versions Are Affected?

All five CVE records give the same affected range: jDownloads 1.0.0 to 4.1.7. That covers every release line, including 4.0.x, the Joomla 3 era lines 3.9 and 3.2, and the older 2.5 and 1.9 builds. jDownloads 4.1.8 is the only release with the fixes, and it is for Joomla 5 and 6. No 4.0.x or 3.9.x release has been published with any of them.

The scan page issue is narrower. The open scan page is in the 4.1 line, and the 4.0.52 package, the last 4.0.x release, has no scan-interface.php file at all.

The two-step route for 4.0 sites is the vendor’s own upgrade path: from 4.0.x, update to 4.0.52, then move to the 4.1 series. Sites on any 4.1.x build can go straight to 4.1.8.

This is how the jDownloads sites in the mySites.guru database were spread across those lines on release day. Going by the CVE records, every one of these groups is affected:

Nearly all of that 39% are on 4.1.7, so sites on the 4.1 line do follow its releases and are one update away from 4.1.8. The larger group, more than half of the jDownloads sites we see, is on the Joomla 3 era lines. The records say those sites are affected, and the only fix is in a version they cannot install until Joomla itself has been migrated.

What To Do on Each jDownloads Site Now

1. Take a full backup of the site before you start. The vendor asks for this first.
2. Update to jDownloads 4.1.8. A 4.1.x site updates directly. A 4.0.x site updates to 4.0.52 first and then to the 4.1 series.
3. Clear the Joomla cache, your browser cache and PHP OPcache after the install, as the vendor advises.
4. Check which user groups are allowed to upload and submit downloads from the front end, and remove any group that does not need it. That permission decides who could reach the thumbnail upload flaw.
5. Rotate the scan key, then update every scheduled URL-based scan job to use the new one. A cron job still calling the scan with the old key will stop working, which is the point of changing it.
6. Check the upload, editing and download workflows. Look in particular at any routine that renames a file to a different extension, and at external downloads that reach their file through a redirect, because 4.1.8 restricts both on purpose.
7. For sites on jDownloads 3.x or 4.0.x, put the move to the 4.1 series on the plan. On Joomla 3 that depends on the Joomla migration itself. Until then, the front-end upload permission in step 4 is the setting to tighten.

How mySites.guru Flags jDownloads

mySites.guru flags every connected Joomla site running the jDownloads component below 4.1.8, on every release line, which is the range the CVE records give. The rule matches the component only, so companion plugins that reuse the com_jdownloads name, such as an Xmap integration plugin, are not flagged.

Flagged sites appear in the vulnerable extension list with their installed version, so one screen shows which sites still need jDownloads 4.1.8. The mass updater then pushes extension updates across Joomla sites in one run. Every jDownloads rule we hold is on the jDownloads vulnerabilities page.

This is the second jDownloads security release in four months. Versions 4.1.0 to 4.1.5 had an unauthenticated upload endpoint, CVE-2026-61900, fixed in 4.1.6 on 18 July 2026. It is a separate issue from anything in 4.1.8, and a site that updated for it in July still needs this update:

jDownloads 4.1 Shipped an Unauthenticated Upload Endpoint, Now Fixed in 4.1.6jDownloads 4.1.0 to 4.1.5 shipped a leftover test script that let anyone upload files to your Joomla site with no login. Update to 4.1.6, which removes it.Read the full post

For a site that has already been hacked, fix.mySites.guru patches it, audits it for backdoors and hands it back secure for a single fixed fee, usually the same day.