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 < [email protected]> 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 >
