CVE-2025-8088 WinRAR: How to Fix “WinRAR < 7.13 Directory Traversal” (Nessus 248462)

RARLAB WinRAR < 7.13 Directory Traversal (CVE-2025-8088) is a Nessus finding meaning a Windows host runs a WinRAR build older than 7.13, which a crafted archive can trick into writing files outside the folder the user chose, including the Startup folder. Fix it by installing the current WinRAR release on every affected host, because WinRAR does not update itself.

What the scanner is actually detecting

Tenable ships one plugin per WinRAR security release, so a host that has never been updated usually shows more than one WinRAR finding. The two you are most likely to see together:

Both are local checks in the Windows plugin family. Nessus logs on over SMB with credentials, reads the installed software list from the registry (the plugins require the SMB/Registry/Enumerated and installed_sw/RARLAB WinRAR KB items) and compares the recorded WinRAR version with the first fixed release. Nothing is exploited. Because each plugin only asks “is the version lower than X?”, one upgrade to the current release closes both.

Two things follow from that design. A copy of WinRAR that was unpacked or copied without running setup is not registered, so Nessus does not see it. And third-party applications that bundle their own UnRAR.dll are not covered by plugin 248462 at all, even though RARLAB lists UnRAR.dll as affected.

Real-world risk

CVE-2025-8088 is a path traversal in the Windows builds of WinRAR, RAR, UnRAR, UnRAR.dll and the portable UnRAR source code. According to RARLAB, older versions can be tricked during extraction into using a path defined inside a crafted archive instead of the path the user chose. ESET found it being exploited as a zero-day on July 18, 2025. Its write-up describes archives that hide payloads in NTFS alternate data streams: on extraction, a DLL lands in %TEMP% or %LOCALAPPDATA% and a shortcut lands in the user’s Startup folder, so the malware runs at the next logon. ESET attributes the campaign to the Russia-aligned RomCom group, using job-application themed spearphishing against companies in Europe and Canada, and reports that a second group, Paper Werewolf, exploited it too. RARLAB fixed it in WinRAR 7.13 on July 30, 2025. Tenable marks it as exploited in the wild with a CVSS v3 base score of 8.8, and CISA added it to the Known Exploited Vulnerabilities catalog.

The older plugin covers CVE-2023-38831, where a ZIP containing a harmless file and a folder with the same name ran the folder’s content when the user opened the file. Tenable notes it was exploited from April to October 2023, and it is also in the KEV catalog.

Keep it in proportion. Neither bug is reachable over the network: the user has to open or extract a malicious archive. That makes mail and browser-facing workstations the priority, and servers where WinRAR was installed once for an admin task a lower one. The honest concern is WinRAR’s update model. ESET states plainly that “WinRAR has no auto-update feature”, so a copy installed years ago stays vulnerable until someone replaces it.

How to confirm it on the host

List registered WinRAR installs, then check the version of the binaries actually on disk:

Get-ItemProperty 'HKLM:SOFTWAREMicrosoftWindowsCurrentVersionUninstall*',
                 'HKLM:SOFTWAREWOW6432NodeMicrosoftWindowsCurrentVersionUninstall*' -ErrorAction SilentlyContinue |
  Where-Object DisplayName -like 'WinRAR*' |
  Select-Object DisplayName, DisplayVersion, InstallLocation, UninstallString

"$env:ProgramFilesWinRARWinRAR.exe", "${env:ProgramFiles(x86)}WinRARWinRAR.exe" |
  Where-Object { Test-Path $_ } |
  ForEach-Object { [pscustomobject]@{ Path = $_; Version = (Get-Item $_).VersionInfo.FileVersion } }

A current install registers under the key WinRAR archiver with a display name such as WinRAR 7.23 (64 bit). Any version below 7.13 is vulnerable to CVE-2025-8088, and anything below 6.23 also carries CVE-2023-38831. A copy under Program Files (x86) is a separate 32-bit install that a 64-bit upgrade will not touch. If winget is available, winget list --id RARLab.WinRAR --exact gives the same answer.

Look for bundled copies of the vulnerable library that Nessus does not report:

Get-ChildItem 'C:Program Files', 'C:Program Files (x86)' -Recurse -Include 'unrar*.dll' -ErrorAction SilentlyContinue |
  Select-Object FullName, @{ n = 'Version'; e = { $_.VersionInfo.FileVersion } }

On hosts where users handle archives from outside, it is also worth a quick look for unexpected shortcuts in the Startup folders, since that is where the observed exploit placed its payload:

Get-ChildItem 'C:Users*AppDataRoamingMicrosoftWindowsStart MenuProgramsStartup*',
              'C:ProgramDataMicrosoftWindowsStart MenuProgramsStartUp*' -Force -ErrorAction SilentlyContinue |
  Select-Object FullName, LastWriteTime

How to fix it

Upgrade to 7.13 at minimum, but deploy the current stable release (7.23 at the time of writing). RARLAB’s release notes show that versions after 7.13 fixed further archive-handling issues, including a heap overflow in RAR5 recovery volume processing in 7.23. Avoid beta builds in production.

Single machine or small groups: winget

winget upgrade --id RARLab.WinRAR --exact --silent --accept-package-agreements --accept-source-agreements

The winget package installs machine-wide and elevates itself, so run it from an administrator session. –silent suppresses the installer UI, and the two –accept options stop the command from waiting on agreement prompts.

Fleet deployment: Intune, Configuration Manager or GPO

Download the installer from rarlab.com and check its signature before packaging:

Get-AuthenticodeSignature .winrar-x64-723.exe |
  Select-Object Status, @{ n = 'Signer'; e = { $_.SignerCertificate.Subject } }

Expect Valid and a certificate issued to win.rar GmbH, the publisher that signs WinRAR’s binaries. WinRAR’s own help file (the “Hints” topic) documents the unattended install: the -s switch skips all setup questions and uses default settings. Running a newer installer over an existing install upgrades it in place:

winrar-x64-723.exe -s

• Intune (Win32 app): use the command above as the install command, and a detection rule of type File on C:Program FilesWinRAR, file WinRAR.exe, method String (version), operator Greater than or equal to, value 7.23.0.
• Configuration Manager: same command in a script-installer deployment type, with the same file-version detection.
• Group Policy: call the installer from a share in a startup script under Computer Configuration > Policies > Windows Settings > Scripts (Startup/Shutdown), guarded by a version check so it does not reinstall at every boot.

If you hold a WinRAR license, place rarreg.key next to the installer. The help file states the installer applies it automatically when no key is already installed. Roll out in stages, a pilot ring first, as described in our guide to ring-based patch deployment.

Remove WinRAR where it is not needed

Often the better fix is removal. According to Microsoft’s support documentation, Windows 11, version 24H2 handles ZIP, RAR, 7z and TAR archives natively, and 7-Zip covers older builds. Uninstall through your deployment tool or Programs and Features; the registered uninstaller is C:Program FilesWinRARUninstall.exe. WinRAR’s help does not document silent switches for the uninstaller, so validate whichever switch your packaging tool uses on a pilot device first.

Third-party software that bundles UnRAR.dll

Updating WinRAR does not touch a private UnRAR.dll inside another product. ESET advises organizations to update such dependencies, so raise it with the vendor of each application your UnRAR.dll search found and apply their update.

How to verify the fix and rescan

1. Re-run the inventory script. Every WinRAR.exe should report 7.13 or later (ideally the version you deployed), and no copy should remain under Program Files (x86) unless you upgraded it too.
2. Check that the uninstall entry’s DisplayVersion matches the file version, since that registry value is what Nessus reads.
3. Rescan with the same credentialed policy. These are local checks, so an unauthenticated scan cannot confirm closure. Plugins 248462 and 180174 should both close.

What can break and how to roll back

• Scripts calling Rar.exe or UnRAR.exe: command-line behavior changes between releases are listed in RARLAB’s release notes. Test backup or batch jobs that call the console tools in the pilot ring.
• Settings and licensing: WinRAR stores settings under HKCUSoftwareWinRAR and HKLMSoftwareWinRAR, and the license key in the WinRAR folder or %APPDATA%WinRAR. Keep the key file with your package so reinstalled hosts stay licensed.
• Removal: uninstalling WinRAR removes its file associations and context menu entries. Users on Windows builds older than 24H2 will need 7-Zip to open RAR files.

A true rollback means reinstalling a version below 7.13, which reintroduces an actively exploited bug. If a new release breaks something, move to a different fixed release instead, and record any temporary exception with an expiry date.

Common false positive reasons

• Stale uninstall entry: if someone deleted the WinRAR folder by hand, the registry entry can survive and keep the finding alive. Confirm WinRAR.exe exists before remediating, then clean up the entry.
• Failed silent install: not a real false positive, but it explains “we already deployed it”. Compare the file version on disk with the deployment report.
• Old scan data: the finding stays open until a new credentialed scan runs after the upgrade.
• The reverse case: portable copies and bundled UnRAR.dll files are real exposure that this plugin never reports, so a clean scan is not proof that no vulnerable RAR code remains.

FAQ

Does WinRAR update itself?

No. ESET states that WinRAR has no auto-update feature, so every host needs a pushed upgrade or a manual install.

Do I need to fix plugin 180174 separately?

No. Any release at or above 7.13 is also above 6.23, so one upgrade closes both findings.

Are Linux, macOS or Android versions affected?

No. RARLAB states that Unix versions of RAR, UnRAR, the portable UnRAR source and the UnRAR library, as well as RAR for Android, are not affected.

Is 7.13 enough?

It closes CVE-2025-8088, but later releases fixed additional vulnerabilities. Deploy the current stable version.

Tracking this finding across many hosts

Because WinRAR never updates itself, the version drift behind this finding shows up again on newly imaged or forgotten machines. SITEY imports Nessus results uploaded as .nessus exports, merges duplicates within each scanner and can retest individual Nessus findings after a fix. Its AI can draft host-specific upgrade scripts that run only after human approval, deployed by its agents on Windows endpoints and followed by a retest to confirm closure.

Sources

• Tenable: RARLAB WinRAR < 7.13 Directory Traversal (CVE-2025-8088), plugin 248462
• Tenable: WinRAR < 6.23 RCE, plugin 180174
• RARLAB: WinRAR, what’s new in the latest version
• ESET WeLiveSecurity: Update WinRAR tools now, RomCom and others exploiting zero-day vulnerability
• Microsoft Learn: winget upgrade command