User tests: Successful: Unsuccessful:
extract.php read ZIP entry filenames directly from the archive's local file headers and used them unvalidated in mkdir() and fopen() calls during extraction. A crafted entry name containing ".." segments or an absolute path (e.g. "../../../../etc/cron.d/x" or "/var/www/other-site/shell.php") could therefore write files outside the intended destination directory, commonly known as a Zip Slip vulnerability.
This adds isPathTraversalAttempt(), which rejects entry names that are absolute (Unix root, Windows drive letter, or UNC path) or contain a ".." path segment. The check runs on the raw entry name before addPath is prepended, and reuses the existing $isBannedFile / skip-and-seek mechanism already used for "." and ".." basenames and the skipFiles list, so rejected entries are safely skipped without disrupting the ZIP read pointer.
No behavior change for well-formed archives.
Pull Request resolves # .
Added a new private method isPathTraversalAttempt() to ZIPExtraction in administrator/components/com_joomlaupdate/extract.php, and one additional check in readFileHeader() that marks entries as banned (using the existing $isBannedFile skip logic) when the raw entry filename is an absolute path or contains a .. path segment.
../../../evil.php, an absolute path /tmp/evil.php, or a Windows-style C:\evil.php.administrator/components/com_example/example.php, in the same archive.extract.php against this archive (e.g. via the update flow, or by calling it directly with the required password/task parameters).A ZIP entry with a ..-containing or absolute path name is extracted using its literal, unvalidated path, allowing mkdir()/fopen() calls to create directories and write files outside the intended extraction root.
Entries with .. segments or absolute paths are detected before extraction and skipped, consistent with how other banned entries (e.g. ./.. basenames, skipFiles list) are already handled. Well-formed archives extract unchanged.
Please select:
| Status | New | ⇒ | Pending |
| Category | ⇒ | Administration com_joomlaupdate |
Hi @brianteeman, thanks for flagging — this was already reported through the
official channel and reviewed by the Security Strike Team. Harald assessed it as not meeting the security-issue bar, since exploitation requires Super User access, which already implies full code execution via the standard extension/update upload flow. He suggested I open this as a normal hardening PR on the public tracker, which is what this is.
Strange, because yes it is correct that you would need to be a Super User and a super user can knowingly do all sorts of things in this case you are describing the potential of a super user being tricked into unkowingly uploading a zipslipped joomla update
| Title |
|
||||||
@brianteeman Thanks for reviewing this.
If this gets merged, I'd appreciate it if the Security Strike Team could revisit whether it qualifies for a CVE. If not, I'd be grateful for an acknowledgment of the security hardening contribution.
| Labels |
Added:
PR-5.4-dev
|
||
@brianteeman @richard67 any update?
https://drive.google.com/drive/folders/1DzfyuLlqyLQ2_3fzIcRXIz0vOcUYUPon
ig this should help
I can confirm that before applying the pr then performing an update with the supplied zipslip wrote a php file to the root of the web space
I can confirm that after applying pr then the php file was not written
As I stated before you would need to be a super user but I can see a scenario where a super user was tricked into downloading and then uploading a malicious joomla update zip
Not marking it as a success or failure as Idont know enough about this to know if the PR is sufficient
@brianteeman Agreed, and that's the distinction worth flagging back to the JSST. "Requires Super User" conflates the privilege needed to trigger extraction with the intent needed to cause the traversal. A Super User running the normal update flow isn't consenting to writes outside administrator/ they're consenting to a scoped install. If the ZIP source is attacker-influenced (compromised update stream, malicious package, social-engineered install), their legitimate action becomes the delivery mechanism for an out-of-scope write, e.g. a web shell in a sibling site or a cron job. That's privilege escalation from "site admin" to "host compromise," not a no-op.
Either way, functionally this is the same bug class as every other Zip Slip CVE assigned in extraction libraries, none of those needed a malicious caller, only a malicious archive.
thanks, done
Hello @richard67 Richard,
This issue is fixed in 9678a17 can you please merge this pull request?
Hello @richard67 Richard, This issue is fixed in 9678a17 can you please merge this pull request?
@kdalal-vulncheck Each pull request needs 2 successful human test before it can be considered to be merged.
https://github.com/joomla/joomla-cms/security