Hi Jan,
Follow-up on this: it's not a size or php.ini issue, and not Admin Tools either. I traced it to Joomla core's own file upload safety check.
Error shown with debugging on:
Code: Select all
Joomla\Filesystem\File::upload: File not uploaded for security reasons!
libraries/vendor/joomla/filesystem/src/File.php:328
called from administrator/components/com_phocadownload/libraries/phocadownload/file/fileupload.php:314 (PhocaDownloadFileUpload::realMultipleUpload)
This check scans the raw bytes of the uploaded file for forbidden extension strings (
.php, .py, .pl, etc.), and it's enough for those strings to appear
anywhere in the file, including inside a zip's file listing. Any zip that contains .php files (any Joomla package or extension, including a plain 2MB update zip I tested) will always trigger this, since filenames inside a zip are stored uncompressed.
This started for us right after updating to Joomla
5.4.8 on 18 August. The 5.4.8 changelog includes PR
#48080 "Update joomla/filesystem from 3.2.0 to 3.3.0 and partly backport PR 48038 from 6.1-dev" — PR
#48038 originally fixed a different upload-breaking regression in the 6.1 line caused by joomla/filesystem 4.2.0. It looks like backporting that fix into the 5.4 filesystem package changed how/when this content safety check applies, and now it's also triggering during the backend "multiple upload" in Phoca Download, even though our "Activate XSS Check" setting is set to "Yes (Frontend only)".
Uploads worked fine on 5.4.7 (also from 8 July), broke after updating to 5.4.8. Not size, PHP limits, permissions, or WAF related — confirmed via error log, browser network tab, and manual byte-scanning of the zip.
Could this be reported upstream to the Joomla core team, and/or could Phoca Download pass allowUnsafe (or otherwise bypass this specific check) for its own trusted backend uploads?
Reproduce:
https://joomlanl.nl/images/phocadownload/pd_own.jpg
Github:
https://github.com/joomla/joomla-cms/pull/48080
Thanks,
Astrid