Re: CVE-2025-55188: 7-Zip: Arbitrary file write on extraction, may lead to code execution

[lunbun <lunbun021 () gmail com>]

Hi all,

Does anyone know how might I get the CVSS score of this vulnerability
(CVE-2025-55188) increased?

I recently saw an advisory for CVE-2025-11001, a very similar
arbitrary file write in 7-Zip due to symbolic links
(https://www.zerodayinitiative.com/advisories/ZDI-25-949/).

However, CVE-2025-11001 is clearly different from CVE-2025-55188,
as the advisory states that CVE-2025-11001 was patched in 25.00.
My proof-of-concept symbolic link attack for CVE-2025-55188 works in
version 25.00.

I am concerned that due to the low CVSS score of CVE-2025-55188, most users
do not realize that 25.00 is still vulnerable to symbolic link attacks.

I've already tried contacting MITRE 8 times to update the description
and CVSS score. I've only received one response, and that was that
not enough public information was available.

I then published a proof-of-concept and vulnerability explanation
(https://github.com/lunbun/CVE-2025-55188 and
https://lunbun.dev/blog/cve-2025-55188/), but MITRE is still unresponsive
to my update requests.

I suspect that MITRE is just busy with a huge backlog of CVE requests,
but I am not sure what to do here. If anyone could offer any advice,
I'd greatly appreciate it.

Thanks,
lunbun

On Wed, Aug 13, 2025 at 3:00 AM Jens-Wolfhard Schicke-Uffmann <
drahflow () gmx de> wrote:

> On Sun, Aug 10, 2025 at 05:04:24PM -0700, lunbun wrote:
> > If a symlink targets a nonexistent directory, the write will fail. 7-Zip
> by
> > default will print an error message, like:
> > ```
> > ERROR: Cannot open output file : errno=2 : No such file or directory : ./
> > malicious_link/file.txt
> > ```
> >
> > This applies similarly to other filesystem errors, like insufficient
> > permissions or unwritable directory.
> >
> > However, 7-Zip by default continues with extraction regardless of the
> error,
> > which is why an attacker can use this "shotgun" strategy. These errors,
> though,
> > would hopefully help notify the user that something suspicious is
> happening.
> Never forget terminal escape codes. At least the 7-Zip my debian
> has dumps the raw filename in those error messages. This allows an attacker
> to clean the specific error lines after they have been output (with
> another, later filename containing the required escapes).
>
> With some fantasy, it might also be possible to massage the overwrite
> prompts (they're also unescaped) into suggesting to choose "(A)lways",
> e.g. by good cursor movement and setting a scroll region far above for
> the real prompt.
>
>
> Regards,
>   Drahflow