0

Rapid 7 has found CVE-2022-26832 on a server running Windows Server 2012 R2 Standard Edition with a French langauge pack installed.

The following is listed as the proof why Rapid 7 thinks the vulnerability exists:

Vulnerable software installed: Microsoft .NET Framework 4.8

Based on the following 2 results:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\Webengine.dll - file does exist C:\Windows\Microsoft.NET\Framework\v2.0.50727\Webengine.dll has version 2.0.50727.8962

One of the remediation steps recommended by Rapid 7 is to install KB5013872 that in turn is made up of KB5013631, KB5013643 and KB5013638.

I have installed the patches and rebooted the server and can see the patches under the Windows update install history, but they have no effect on Rapid 7 reporting the vulnerability.

It is strange that it complains about v2.0.50727 as that is I think .Net version 2 and I think it might have been installed when .Net version 3.5 has been installed.

When going into the Server Manager screens I can see that .Net 3.5 and .Net 4.5 are installed, but greyed out. Not sure if this is why the patches do not apply.

Does anyone have any ideas of why the patching might not work or if this is a false positive reported by Rapid 7?

1 Answer 1

1

We have a similar problem. It looks to me to be false positive findings, but Rapid 7 support disagrees. See their response below.

Rapid 7 Nexpose appears to be issuing incorrect findings on almost all of our Windows Server 2012 R2, 2016, and 2019 servers. On all systems I have spot checked so far, the specific KB recommended by Nexpose IS installed, but each server is still flagged for CVE-2022-30130 and/or CVE-2022-26832, with the same "proof" as the original poster found: C:\Windows\Microsoft.NET\Framework\v2.0.50727\Webengine.dll - file does exist C:\Windows\Microsoft.NET\Framework\v2.0.50727\Webengine.dll has version 2.0.50727.8962

A coworker asked Rapid 7 support, and they suggested rebooting the servers, but all were rebooted as part of the normal patching process.

This is what they wrote: "I've investigated the network vulnerabilities and see that the discrepancy resides in the way the KB patch is applied and file-paths are cleaned up. When the KB is applied we should see the previous versions of the webengine.dll and Mscorlib.dll removed / updated. Both of the vuln-checks are seeing that a vulnerable version of these files still exist on the asset, not cleaned up by the KB's being installed. (In a similar situation why we're seeing the UBR value persist) [server] If we reboot this asset we should see a good amount of vulnerabilities resolve, but if the files do not clear after a reboot, then the Hkey being found would have to be removed."

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .