Read more here:
Critical 7 Zip Vulnerability With Public Exploit Requires Manual Update
Follow us on Bluesky, Twitter (X), Mastodon and Facebook at @Hackread
hackread.com
Critical 7 Zip Vulnerability With Public Exploit Requires Manual Update
- Thread starter Brownie2019
- Start date
hackread.com
The core issue is that a serious vulnerability has been found in 7‑Zip, and there is already a public exploit for it – but 7‑Zip does not auto‑update, so a lot of people may stay vulnerable unless they manually upgrade.Read more here:
Critical 7 Zip Vulnerability With Public Exploit Requires Manual Update
Follow us on Bluesky, Twitter (X), Mastodon and Facebook at @Hackread
In plain terms, what’s the problem?
From what’s described:
- There is a vulnerability tracked as CVE-2025-11001 in 7‑Zip.
- A public proof-of-concept (PoC) exploit is available, which means attackers can study it and adapt it for real-world attacks.
- NHS England’s digital security team is flagging it as high risk, even though they say they haven’t seen active exploitation yet.
- Because 7‑Zip is extremely common and doesn’t auto‑update, this creates a large pool of potentially vulnerable systems.
What does the vulnerability likely allow?
Based on how such 7‑Zip bugs usually work (and how it’s being described):
- An attacker could craft a malicious archive (e.g. .7z, .zip, etc.).
- If a user opens or processes that archive with a vulnerable version of 7‑Zip, the attacker may be able to run arbitrary code on the victim’s machine with the user’s permissions.
- This fits typical remote code execution / code execution via malicious file style vulnerabilities.
I don’t have the exact technical root cause (buffer overflow, logic bug, etc.) in my training data, so I can’t reliably say how it’s implemented under the hood – only the practical impact.
Why is NHS calling it high risk?
- 7‑Zip is very widely used on desktops and servers.
- The exploit is public, so anyone (not just advanced actors) can use or adapt it.
- 7‑Zip requires manual updates – no auto‑update – so many systems may stay on a vulnerable version for a long time.
- Malicious archives fit into normal attack chains: phishing emails, “software” archives on shady sites, compromised file shares, etc.
What should you do?
- Update 7‑Zip manually:
- Go to the official 7‑Zip website (7-zip.org) directly – don’t use third‑party download sites.
- Download and install the latest stable version for your OS and architecture (32/64-bit).
- If using it on servers or in scripts, make sure those installations are updated as well.
- Check your version: In 7‑Zip, go to Help → About and compare your version to the latest on the official website. If your version is older, assume it may be vulnerable.
- Be cautious with untrusted archives: Until you’re sure you’re on a fixed version, avoid opening archives from unknown or suspicious sources.
- Enterprise / admins:
- Inventory where 7‑Zip is installed (endpoints, servers, images).
- Plan a mass update via your software deployment tool (SCCM, Intune, etc.).
- Check for any vendor or CERT advisories referencing CVE‑2025‑11001 for more precise technical details and fixed versions.
Bottom line:
The “problem” is a new 7‑Zip vulnerability with a public exploit and no auto‑update mechanism, meaning many users will stay exposed unless they manually install the latest 7‑Zip release. If you’re using 7‑Zip, update from the official site and be careful with archives from untrusted sources.
7zip exploit? Is this a new one? No new release on website so....
Similar situation a few weeks ago with WinRAR, there really are some real gits on this planet!
Right in the article
I tested this POC. The info posted by @Bot is misleading.
The POC works as follows:
- 7-ZIP must be executed with Administrator rights.
- This POC can only copy the payload into a predefined location. It does not execute the embedded payload.
However, the embedded payload will still be blocked when the user attempts to open it directly from the archive.
This POC can be used as part of an attack in Enterprises, when the malware has already gained high privileges. It can be used to hide the copying actions to fool administrators, especially when copying into system folders. The malware can achieve this in many other ways, simply by using standard methods, but doing so with the exploit is more stealthy.
Post edited (changed "exploit" to "POC").
Edit 1.
I only tested the publicly available POC. I did not see the POC that could also automatically execute the embedded payload.
Here is the note from the POC's author:
In the above example, by extracting the content of the archive, the payload (calc.exe) is automatically written to "C:\Users\YOURUSERNAME\Desktop".
Edit 2.
I wrote that "This POC can be used as part of an attack in Enterprises, when the malware has already gained high privileges."
However, in Enterprises, this vulnerability can be more likely exploited when 7-Zip is used by a service account (also noted by the POC's author).
In such a case, a legitimate process that uses 7-Zip can be abused to run the payload with high privileges from an unintended location.
Last edited:
You’re right to correct that – thank you for the detailed test description.
About my earlier post
My previous explanation was too generic and assumed a typical “open archive → instant code execution” scenario. Based on your testing and the more precise info:
- 7‑Zip must be run with Administrator rights for the PoC to work as described.
- The exploit is being used for arbitrary file copy/write into a predefined (and potentially sensitive) location.
- It does not directly execute the embedded payload – execution would still require a separate step or another weakness in the chain.
So, it’s more of an “abuse 7‑Zip to copy files stealthily with high privileges” issue than a classic “instant RCE from opening an archive” (at least in the PoC you tested). That still matters in enterprise/post‑exploitation scenarios, which is why NHS and others are treating it seriously.
Does “Attachments and Archives” stop it?
Based on what you and @Parkinsond described and what that dialog says:
- That feature blocks running EXE/MSI directly from archivers and email clients.
- It does not block copying files from an archive.
So:
- No – it will not stop the file‑copy part of this exploit.
- It does help by preventing the user from directly launching a dropped EXE/MSI from inside 7‑Zip or the mail client.
- If an attacker has another way to execute the copied payload (script, scheduled task, LOLBin, etc.), this feature alone won’t fully mitigate that.
Risk picture
Given what we know right now:
- For home users who rarely/never run 7‑Zip as admin, this specific PoC is much harder to abuse directly.
- For enterprises and already‑compromised systems, it’s a useful stealth tool to copy files into protected locations under the guise of a trusted app.
Best mitigation
- Update 7‑Zip to version 25.00 or later, which the 7‑Zip changelog says fixes CVE‑2025‑11001.
- Avoid running 7‑Zip with elevated/admin rights on untrusted archives.
- Keep “Attachments and Archives” (and similar controls) enabled, but treat them as defense‑in‑depth, not a complete fix.
In short: that restriction feature doesn’t stop the exploit’s copying behavior, but it still adds a layer of protection around execution. The real fix is updating 7‑Zip and limiting when it runs with admin rights.
Yes, your info is most likely current, but I need to add some nuance.
What we know from the article you quoted
The article explicitly says:
"The issue was fixed with version 25.00 in July 2025."
If 7‑Zip 25.01 (03 Aug 2025) is now the current version, then:
- 25.01 is newer than 25.00.
- Vendors virtually always carry security fixes forward, so 25.01 should include the 25.00 fix for CVE‑2025‑11001.
Because my training data stops in 2024, I cannot directly verify the 25.01 changelog, but based on normal software practice and the statement that 25.00 fixed it, running 25.01 should mean you’re not vulnerable to this CVE.
How to double‑check
To be 100% sure, I’d suggest:
- Open the official 7‑Zip changelog: https://www.7-zip.org/history.txt
- Look at entries for versions 25.00 and 25.01 and confirm that 25.00 mentions the fix for CVE‑2025‑11001 (or the related vulnerability description).
Practical takeaway
If you’re on 7‑Zip 25.01, you should be on a version that already includes the CVE‑2025‑11001 fix, assuming the vendor’s statement about 25.00 is accurate. The main risk is for systems still on pre‑25.00 builds.
Ever since Didier Stevens demonstrated the dangers of PDFs and compressed files, it has been good practice to include this softwares in MD Exploit lists.
I have 13 of the same overrides used in Firefox/Chrome in the 3 exe files of 7zip.
And what's more, the news is old:
https://www.zerodayinitiative.com/advisories/ZDI-25-949/
It is the same vulnerability. The above link is included in the article from the OP.
The danger is when an administrator uses a service account. In such an account, all actions are executed with elevated privileges.
For example, when a ZIP archive is unpacked by 7-Zip, the unpacking is done with elevated privileges, and the payload is written anywhere the attacker wants. In this way, the attacker can abuse legitimate applications or system executables (via DLL hijacking, etc.) to run malicious code.
On personal computers, a similar danger is when disabling Admin Approval Mode in UAC (UAC value EnableLUA =0 ) or (in a limited way) when running third-party File Explorer as Administrator.
I don't think 7-zip's benefit claim of higher compression ratio still matters in today's era of TB drives.
You may also like...
-
Critical React Native Vulnerability Exploited in the Wild- Started by Miravi
- Replies: 2
-
Hackers Exploiting Microsoft Office 0-day Vulnerability to Deploy Malware- Started by Brownie2019
- Replies: 3
-
TeamViewer DEX Vulnerabilities Let Attackers Trigger DoS Attack and Expose Sensitive Data
- Started by Brownie2019
- Replies: 1
-
Google has rolled out a Chrome 136 update that resolves a high-severity vulnerability for which a public exploit exists.
- Started by Brownie2019
- Replies: 0
-