P7zip and possible RCEs

I had a quick look at the p7zip package on broken.sh and noticed that it contains two possible RCE vulnerabilities: CVE-2018-5996 and CVE-2018-10115, the latter being unlisted on broken.sh but mentioned in p7zip forums and basically confirmed on the german IT news site heise.de. The last upstream update is from 2016, version 16.02 while their upstream (it’s just a port of 7zip) is at version 19.00.

The forum is somewhat silent and one of the last discussions is from 2019 and is about the development model of 7zip and p7zip, where the developer of 7zip chimed in and said that the developer for p7zip appears to be missing: https://sourceforge.net/p/p7zip/discussion/383043/thread/fa143cf2/
In my opinion this means the project is effectively dead and we will essentially have to support it ourselves.

I would suggest to mark it as insecure and try to get rid of it… but it’s used by a bunch lot of other packages. While some are probably not a real issue (like rarcrack), others like unetbootin and kde/ark or playonlinux and wine will probably hurt persons that e.g. are using desktops on NixOS.

nixpkgs/pkgs]$ fgrep -cr p7zip | awk -F: '$NF > 0 {print $1}' | sort -u | fgrep -v tools/archivers/p7zip | wc -l

Even debian seems to be just carrying unofficial patches found on the forums or on random internet pages. Their security tracker claims that they are not vulnerable, though I cannot find any patch for that, but it could just mean that the vulnerable part is not included in their package due to unfree licensing of the affected RAR support? I’m not sure about that.

So what do we do about this issue? Ignoring it sounds like a bad plan. Do we try to get rid of p7zip? Try to track Debian? Or do we hope to keep up with that ourselves?

1 Like

I’d suggest to mark it as insecure for the reasons above, at least until there’s a somewhat canonical place to obtain patches from.

Probably some of the packages referring to p7zip can fall back to use other decompression tools - I’d expect people to step up and fix things if they care about it - this is similar to how we did with unsupported SSL versions.

I already have a patch to use dd and mtools for memtest86-efi, instead of 7z. I can open a PR, if you plan on marking 7z as insecure.

Here’s the PR: https://github.com/NixOS/nixpkgs/pull/86417

https://github.com/NixOS/nixpkgs/pull/86417 was merged, feel free to highlight me on PRs fixing now broken packages.

Thank you for noticing this. I just got notified of p7zips insecurity when updating. Do you happen to know any alternatives for direct command line usage? My use-case is mostly “aint nobody got time to remember tar flags” and the nice thing about p7zip is that it can unpack just about everything without any arcane flags.

1 Like

On the command line I personally use bsdtar from libarchive. bsdtar xf <file> will extract all sorts of formats and it detects them based on file content so it still works when using - for piping, no extra z or J or something.

I’ve also heard good compliments of unar.

I recommend arc(1), in the archiver package, for general use; it’s written in a memory safe language and supports a wide variety of formats, but unfortunately not .7z. unar supports .7z; I think it might be the only non-deprecated free software package in nixpkgs that does, though I haven’t performed an exhaustive search.

I think it would be a good idea to recommend alternatives in the nixpkgs warning.


There is now a recent and updated unar in nixpkgs: https://github.com/NixOS/nixpkgs/pull/86628


It seems unar only support decompression. Any alternative to create 7zip files?

libarchive should work, e.g. bsdtar -cf archive.7z --format=7zip ....


Thank you very much.

https://github.com/szcnick/p7zip/releases seems to be an updated fork

1 Like

Oh, nice! Maybe the 7zip devs will have a look at it and give it their “blessing”.

This fork has been discussed here: