The crux of the problem is that when provided a zip archive with a file
with a path pointing outside of the archive, mat2 would include the file
present on the filesystem in the resulting archive. For example, a file named
../../../var/www/mat2-web/requirements.txt in a zip archive would result in
requirements.txt file from a mat2-web server being put into the cleaned
On the bright side, this arbitrary file read should mostly impact administrators
of mat2-web instances, since while mat2 does its very best to handle
malicious/malformed files, it is primarily designed to clean files from trusted
sources. Unfortunately, this arbitrary file read might result in a remote code
execution depending on mat2-web setups, since leaking the
a Flask application yields arbitrary python code execution. A mitigation would
be to pass the
app.secret_key via an environment variable instead of
hardcoding it, which is a good practise anyway.
Case where an attacker is sending a malicious zip file to a regular mat2 user to process, and is then able to get it back should hopefully be pretty rare.
The vulnerability was fixed in the following Debian versions:
- oldstable (buster) in
- stable (bullseye) in
- unstable and testing in
Nevertheless, nice bug, now fixed, you should upgrade, kudos to jfriedli for finding it and sending a comprehensive report and reproducer my way!