CVE-2025-8088 WinRAR Detector #1135 #1187

wannabemrrobot · 2025-08-19T11:11:04Z

This PR adds a detector for CVE-2025-8088 (WinRAR RCE vulnerability) in osv-scalibr.
The detector supports:

Default WinRAR installation paths.
Portable WinRAR builds.
Renamed winrar.exe binaries in user-specified paths.

This ensures broader coverage by detecting vulnerable WinRAR executables even outside standard installation directories.

detector/cve/untested/cve20258088/cve20258088.go

detector/cve/untested/cve20258088/cve20258088_dummy.go

detector/cve/untested/cve20258088/cve20258088.go

…r registry

wannabemrrobot · 2025-08-20T20:32:48Z

@erikvarga
Fixed, kindly review and let me know if I need to mark it as resolved.

erikvarga · 2025-08-21T10:53:35Z

detector/list/list.go

@@ -67,6 +68,8 @@ var Untested = InitMap{
 	cve202011978.Name: {cve202011978.New},
 	// CVE-2024-2912 BentoML detector.
 	cve20242912.Name: {cve20242912.New},
+	// CVE-2025-8088 WinRAR RCE detector


Can you add a new CVE list (with just this one detector) instead of adding this to Untested? Also add it to All and detectorNames.

erikvarga · 2025-08-21T10:56:18Z

detector/cve/cve20258088/cve20258088.go

+		Vulnerability: osvschema.Vulnerability{
+			ID:      "CVE-2025-8088",
+			Summary: "WinRAR path traversal vulnerability (<7.13)",
+			Details: "Detects WinRAR installs or portables < 7.13, using robust and reliable PE analysis.",


The finding details should be about the vulnerability, i.e. "A path traversal vulnerability affecting the Windows version of WinRAR allows the attackers to execute arbitrary code by..."

erikvarga · 2025-08-21T10:57:03Z

detector/cve/cve20258088/cve20258088.go

+	}}}
+}
+
+// Scan checks for the presence of the BentoML CVE-2025-8088 vulnerability on the filesystem.


BentoML? You mean WinRAR?

My bad, it has been mistakenly copied when creating stub. Kindly ignore, will fix and create PR

erikvarga · 2025-08-21T11:00:32Z

detector/cve/cve20258088/cve20258088.go

+
+					vuln := &inventory.PackageVuln{
+						Package: pkg,
+						Vulnerability: osvschema.Vulnerability{


Return the same Vulnerability as in DetectedFinding() here. For other extractors we usually have a shared helper lib, e.g.

osv-scalibr/detector/cve/untested/cve20242912/cve20242912.go

Line 101 in 396e8cf

func (d Detector) DetectedFinding() inventory.Finding {

erikvarga · 2025-08-21T11:05:27Z

detector/cve/cve20258088/cve20258088.go

+						Vulnerability: osvschema.Vulnerability{
+							ID:       "CVE-2025-8088",
+							Summary:  "WinRAR vulnerable version detected (installed package)",
+							Details:  fmt.Sprintf("Installed WinRAR %s detected via package index", normalizedVersion),


Details should be the same for each instance of the vulnerability. If you want to store instance-specific info, add an "extra" key to the DatabaseSpecific field. See as an example:

osv-scalibr/detector/cve/untested/cve20242912/cve20242912.go

Line 255 in 396e8cf

"extra": fmt.Sprintf("%s %s %s", pkg.Name, pkg.Version, strings.Join(pkg.Locations, ", ")),

erikvarga · 2025-08-21T11:11:43Z

detector/cve/cve20258088/cve20258088.go

+
+			if isAffectedVersion(normalizedVersion) {
+				log.Infof("Vulnerable WinRAR package found(Delete them): %s, Package: %s, Version: %s", path, prodName, normalizedVersion)
+				pkg := &extractor.Package{


Since this isn't a package that was found during the extraction step it's fine to leave this out from the vuln.

But the portables and non-default installations will be found in this step only. May I know why we need to leave this packages even if it is vulnerable?

The main concern is that this is a package outside of Inventory.Packages which breaks assumptions further down the code like the serialization of PackageVulns into a proto (where we'll only store a reference to the field in Inventory.Packages - this is still WIP and hasn't been submitted though.)

If we remove the custom file walking logic though then this shouldn't be a problem in either case.

erikvarga · 2025-08-21T11:12:39Z

detector/cve/cve20258088/cve20258088.go

+					Metadata:     nil,
+				}
+
+				affected := []osvschema.Affected{{


Same as for step 1, pls move the vuln creation logic into a helper func and use it both here and in DetectedFinding (with potentially different databaseSpecific data)

erikvarga · 2025-08-21T11:18:52Z

detector/cve/cve20258088/cve20258088.go

+
+		// Indicator 2: PE resource analysis - extract version info from PE resources
+		// Now check PE resources for ALL .exe/.dll files, not just regex matches
+		version, prodName := extractPEVersion(path)


We already extracted this information in the dotnetpe extractor AFAIK.

How about you have a separate step that looks at already extracted dotnetpe Packages and does name / version matching on those? And then you only need to do the file name matching here.

If we could reuse this, extracting PE info for portables and non-default location installations will get covered. So, this covers the concern, right?
#1187 (comment)

The PE extractor checks for PE executables in any location, not just default installs. So its results should already contain any info extracted here.

erikvarga · 2025-08-21T11:20:47Z

detector/cve/cve20258088/cve20258088.go

+		prodName = "RAR"
+	}
+
+	archRegex := regexp.MustCompile(`(?i)(x64|x86|arm64|arm32|portable)`)


Make regexps global vars so they're compiled at init time.

erikvarga · 2025-08-21T11:25:14Z

detector/cve/cve20258088/cve20258088.go

+
+// isAffectedVersion returns true if version < 7.13
+func isAffectedVersion(ver string) bool {
+	parts := strings.Split(ver, ".")


We have a built-in version comparison library in SCALIBR:

osv-scalibr/semantic/parse.go

Line 43 in 396e8cf

func Parse(str string, ecosystem string) (Version, error) {

You can do something like semantic.Parse(ver).CompareStr("7.13")

wannabemrrobot · 2025-08-25T12:04:22Z

Hi @erikvarga ,

I wanted to kindly follow up on my earlier comments regarding the issue comments for the PR.
Just checking if there’s any update or if I can provide more details to help move this issue forward.

erikvarga

Sorry for the delay, team was low on capacity so couldn't find time to give another review round until now

erikvarga · 2025-09-03T16:36:57Z

detector/cve/cve20258088/cve20258088.go

+		}
+	}
+
+	// === Phase 2: Filesystem scan (existing logic) ===


dotnetpe is supposed to find executables from any directory within the ScanRoot - it just checks if the binary has a correct extension:

osv-scalibr/extractor/filesystem/language/dotnet/dotnetpe/dotnetpe.go

Line 104 in e1df6d3

if !slices.Contains(peExtensions, ext) {

In your SCALIBR CLI invocation you set the root to C:\Users\ganes\Desktop\public-sharables so it should find the binaries from under there I believe. Not sure how it found anything under C:\Program Files if that wasn't the path specified. Can you try with --root= instead of -root?

I think it's fine to leave out the deepScan parameter - supposedly all the potential executables should have been found by the inventory extractors already and we shouldn't need to re-walk the filesystem. So it should be fine to only implement the deepScan=false method which goes through the PackageIndex but doesn't traverse the filesystem.

erikvarga · 2025-09-03T16:37:43Z

detector/cve/cve20258088/cve20258088.go

+
+		// Indicator 2: PE resource analysis - extract version info from PE resources
+		// Now check PE resources for ALL .exe/.dll files, not just regex matches
+		version, prodName := extractPEVersion(path)


The PE extractor checks for PE executables in any location, not just default installs. So its results should already contain any info extracted here.

erikvarga · 2025-09-03T16:40:38Z

detector/cve/cve20258088/cve20258088.go

+
+			if isAffectedVersion(normalizedVersion) {
+				log.Infof("Vulnerable WinRAR package found(Delete them): %s, Package: %s, Version: %s", path, prodName, normalizedVersion)
+				pkg := &extractor.Package{


The main concern is that this is a package outside of Inventory.Packages which breaks assumptions further down the code like the serialization of PackageVulns into a proto (where we'll only store a reference to the field in Inventory.Packages - this is still WIP and hasn't been submitted though.)

If we remove the custom file walking logic though then this shouldn't be a problem in either case.

CVE-2025-8088 WinRAR Detector

4bb9768

wannabemrrobot mentioned this pull request Aug 19, 2025

PRP: Detector for WinRAR Path Traversal RCE (CVE-2025-8088) #1135

Open

erikvarga reviewed Aug 20, 2025

View reviewed changes

cve-2025-8088 detector - lint error fixes, package refractor, detecto…

411e10e

…r registry

erikvarga reviewed Aug 21, 2025

View reviewed changes

erikvarga reviewed Sep 3, 2025

View reviewed changes

CVE-2025-8088 WinRAR Detector #1135 #1187

Are you sure you want to change the base?

CVE-2025-8088 WinRAR Detector #1135 #1187

Conversation

wannabemrrobot commented Aug 19, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

wannabemrrobot commented Aug 20, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wannabemrrobot commented Aug 25, 2025

Uh oh!

erikvarga left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!