Is it possible for you to share the actual file that you are trying to upload.

I suspect that its a false positive similar to #15563 but without the exact file you are trying to upload its hard to be certain.

I think it's quite unimportant which file (stp, step or other files) because I took also a ZIP with some JPEGS inside and it did not work either. And the test throwing the error is looking for if there is a file and not what the file is like (I think the error message is wrong and the error is caused by something else)
Here is a ZIP Package which fails to be uploaded in mediamanager: https://coolcat-creations.com/imagetest.zip

Also failed on another Server and another Website

What settings have you set in the media manager to allow zip files

Upload of Zip Files works without Problems. But not with that one... (When the contents are larger)
Settings are: image/jpeg,image/gif,image/png,image/bmp,application/x-shockwave-flash,application/msword,application/excel,application/pdf,application/powerpoint,text/plain,application/x-zip, application/zip

This is coming from input filter. The linked zip file contains .py in its data which sets off this filter rule:

@zero-24 @SniperSister

@SharkyKZ What is .py? Because I use cleanarchiver - there should be only the jpgs inside? Thank you.

Please read the initial post of #15563 that explains the issue you are experiencing.

confirmed - there are 14 instances of .py and six of .pl in the data when read as a stream

duhhh... thank you both for explaining! So there is no way to fix this issue? maybe something like Apples "upload anyway, I am sure" as a superadmin ?

The equivalent is to use fto

Thats unfortunately not a solution because there is no FTP allowed and most users are not allowed to use the SSH connection... :-(

There is no other option

So there is no way to fix this issue? maybe something like Apples "upload anyway, I am sure" as a superadmin ?

Technically this is possible. Super admins can upload unfiltered files in other places anyways. But I'd wait for security experts to comment on this topic.

@joomla/security any comments?

Sorry for the duplicate report - I didn't get any hits when I searched for the issue originally (would've saved me a lot of time too...) 😩

I'm not intimately familiar with Joomla!, I came across this when troubleshooting a particular ZIP on a client site - I kinda want to ask (excuse me if it's a stupid question) - why exactly is ".py" being searched for via string inside a ZIP file? Seems like a weird way of filtering out dodgy files?

.py indicates a file in the python programming language

Yes, but why check for it in raw data instead of opening the archive and inspecting filenames?

The "file scanner" has several issues and one of them is the (in my opinion) wrong handling of ZIP files. Probably for 4.0 there is an external library somewhere to do the job?

I am more than happy to look into a proper solution to these false-positives, I really would just like to know what the goal of this particular bit of code is, so that we can find a better way of achieving it without this issue.

I understand it is scanning through these particular file extensions (.zip, .bz2 etc.) for instances of other file extensions (.py, php etc.), but what I do not know is why this is done (what is the security vulnerability) nor why in this particular way (as mentioned by @SharkyKZ , surely if it's looking at archive files in particular... it should inspect them like archives and not searching for string-in-string?)

The goal is very easy: prevent the upload of an archive which contains one of the forbitten files in it.

Perhaps the list should be aligned with this list: https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Helper/MediaHelper.php#L178-L181

Sure, but why is that important to do on a ZIP? What is it preventing?

Not sure if it's still possible, but there are self-extracting executable available.

If that's the case then I am not sure that scanning file extensions within the ZIP would be enough solve that problem?

I have the same problem with a ZIP-File containing <?
I don't use the Mediamanager. It is not a Mediamanager only bug/problem.
I disable file checking on ZIP-Files in my component code with

$safeFileOptions['php_ext_content_extensions'] = array('rar', 'tar', 'gz', 'tgz', 'bz2', 'tbz', 'jpa');
if (JFile::upload($src, $dest, false, false, $safeFileOptions))
{
// your code here
}

In this case of false positiv results, the current file checking make no sens.

Yes, but why check for it in raw data instead of opening the archive and inspecting filenames?

Sure, but why is that important to do on a ZIP?

Because - Security.

The institutional memory for the security issue this fixed, seems to have been lost from the project :-(

EDIT: from my very very bad memory I think the security issue was something like, you could upload hack.php by calling it hack.zip on servers where mime type sniffing failed, hack.zip would be a plain text php file just named with zip extension. I forget how you could then go on to exploit the site from that situation... was it not Nicolas that worked on this, I can't remember.

Thank you for raising this issue.

Joomla 3 is now in security only mode with no further bug fixes or new features.

As this issue doesn't relate to Joomla 4 it will now been closed.

If we are mistaken and this does apply to Joomla 4 please open a new issue (and reference this one if you wish) with updated details for testing in Joomla 4.
cc @zero-24