I’m getting a vulnerability that shows up when running a scan of our firewalls. Our FortiGate firewalls came back with the vulnerability shown in the title along with their public IP addresses. The remediation mentioned upgrade to latest version of FreeBSD. These firewalls already have the latest firmware and patches according to FortiGate. Is it possible this is a false positive?, Has anyone else encountered this.
1 Like
I’ve got the same thing occurring on 300+ Windows 10\11 workstations. I have ticket logged with support.
2 Likes
Same for us. Marked as False Positive
Update from R7 Support: Apparently this is occurring because we aren’t running authenticated scans on our systems (even though they have the agent and running auth scans in our environment is logistically unrealistic). What this doesn’t explain is why <10% of our systems are reporting this (the detected systems are no different that any others), or why this has suddenly started on an 18 year old vulnerability, where the modified date of the vuln in insightVM is a couple weeks ago. As sprakash has said,there’s no option other than to mark it as a false positive.
1 Like
Exactly my point, same scenario as yours and it makes no sense that it doesn’t pick the entire population but rather a small percent and the vulnerability version that it picks should have been picked a long time back.
Rapid7 needs to finetune it, these stuff takes time for customers.
Same here. We’ve marked it as a false positive after validating we have the latest firmware.
Hey folks,
Just putting a quick update in here: We’re aware of this one and currently working on it. FreeBSD is an operating system and we’re seeing obsolete results for it flag on assets that are not running FreeBSD, such as Windows. I’ve described two common scenarios we see this issue in below.
Just to be clear; moving to authenticated scanning is not a requirement to resolve this, and our intended solution would not require customers to make any changes to their current setups with regards to unauthenticated scanning or Agent Correlation, from scenario 1.
Scenario 1:
The most common report on this so far has been from a combination of unauthenticated scans on assets that also run the Insight Agent, and rely on Agent Correlation to prevent duplicate entries within the console. This would match what talford has described so far, in which Windows assets are showing the FreeBSD result despite having data from an authoritative source via the Agent. For an at-a-glance validation, on the asset page of an affected asset you can expect to see a R7 Agent Unique Identifier, and the operating system as some form of Windows, and the FreeBSD Obsolete Version vulnerability result.
Scenario 2:
Due to the way that our obsolete checks function and are run in unauthenticated scans, this issue can also show in other areas, such as esingh’s original FortiGate case. We’ve had less report of this, but have qualified it to the same underlying cause. For these scenarios, we would want to work with affected customers a bit more via a support case before validating the issue, as there can be other factors at play.
Increases in FreeBSD findings:
For a bit of additional context, the FreeBSD finding in unauthenticated scans come from the NMAP process, which we’ve observed has been more aggressive in determining FreeBSD as the operating system. Our obsolete checks for operating systems in unauthenticated scans require the operating system finding to meet a certain threshold of certainty, which the more aggressive determination from NMAP has recently begun to meet. The modified date on this particular vulnerability marks a change in how we approach that certainty for unauthenticated scans, which was done to improve accuracy and findings when running unauthenticated scans, and so the combination of these two factors result in the FreeBSD Obsolete Version finding.
Due to the nature of unauthenticated scans, this isn’t a consistent experience. NMAP will use a variety of different information sources that it can get from the asset to make the operating system determination, which means environmental factors do impact the result. From the data we’ve looked at so far, it also matches talford’s report about it only affecting a certain amount of assets, even though they are not meaningfully different than those which aren’t affected.
For more information on the NMAP side, see the following:
OS Detection | Nmap Network Scanning
Chapter 8. Remote OS Detection
Next steps:
I’ll update this thread once we have rolled out a solution, and if customers have an open support case around this issue, those will of course also be updated (likely by me as well!). I’ll do my best to answer any questions around this, but there is only so much we can disclose on the forums, and I will encourage customers who see this to go through our usual support process for further information and validation of the issue in their environments.
2 Likes
Just a thought and might be way off base, the InsightVM agent requires a UDP port to be open to the scan engine for detecting the host has the Agent. Have you check to make sure the port is open to the scan engine(s) you use?
A good suggestion in general but unfortunately this doesn’t resolve the issue. Agent Correlation, the method by which a scan can find an Agent ID via port 31400 UDP for correlation purposes, doesn’t affect the findings of the scan in this case.
This issue is a result of unauthenticated scans determining the operating system to be FreeBSD (see previous post for an explanation of that), and then running the FreeBSD Obsolete Version check against it.
Regardless of how the data from the scan is correlated into an existing asset within the InsightVM Security Console, this FreeBSD Obsolete Version finding will integrate into the assert. That’s how we end up with Windows 11 assets showing an obsolete version finding for an entirely different operating system, FreeBSD.
As of 6/17/2025 its still being reported on some of our PC’s.