# FreeBSD vulnerability false positive **URL:** \ **Category:** InsightVM\ **Created:** [April 9, 2025, 7:16am UTC](https://discuss.rapid7.com/t/freebsd-vulnerability-false-positive/50021 "2025-04-09T07:16:57Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![esingh](https://discuss.rapid7.com/letter_avatar_proxy/v4/letter/e/9e8a1a/32.png) [@esingh](https://discuss.rapid7.com/u/esingh)\ **Post date:** [April 9, 2025, 7:16am UTC](https://discuss.rapid7.com/t/freebsd-vulnerability-false-positive/50021/1 "2025-04-09T07:16:57Z")
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. ---
**Author:** ![talford](https://discuss.rapid7.com/letter_avatar_proxy/v4/letter/t/58956e/32.png) [@talford](https://discuss.rapid7.com/u/talford)\ **Post date:** [April 9, 2025, 10:47am UTC](https://discuss.rapid7.com/t/freebsd-vulnerability-false-positive/50021/2 "2025-04-09T10:47:48Z")
I’ve got the same thing occurring on 300+ Windows 10\11 workstations. I have ticket logged with support. ---
**Author:** ![ShivPrakash](https://discuss.rapid7.com/letter_avatar_proxy/v4/letter/s/ba9def/32.png) [@ShivPrakash](https://discuss.rapid7.com/u/ShivPrakash)\ **Post date:** [April 11, 2025, 7:22am UTC](https://discuss.rapid7.com/t/freebsd-vulnerability-false-positive/50021/3 "2025-04-11T07:22:16Z")
Same for us. Marked as False Positive ---
**Author:** ![talford](https://discuss.rapid7.com/letter_avatar_proxy/v4/letter/t/58956e/32.png) [@talford](https://discuss.rapid7.com/u/talford)\ **Post date:** [April 11, 2025, 8:09am UTC](https://discuss.rapid7.com/t/freebsd-vulnerability-false-positive/50021/4 "2025-04-11T08:09:57Z")
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. ---
**Author:** ![esingh](https://discuss.rapid7.com/letter_avatar_proxy/v4/letter/e/9e8a1a/32.png) [@esingh](https://discuss.rapid7.com/u/esingh)\ **Post date:** [April 14, 2025, 4:11am UTC](https://discuss.rapid7.com/t/freebsd-vulnerability-false-positive/50021/5 "2025-04-14T04:11:18Z")
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. ---
**Author:** ![Princeol](https://discuss.rapid7.com/letter_avatar_proxy/v4/letter/p/58956e/32.png) [@Princeol](https://discuss.rapid7.com/u/Princeol)\ **Post date:** [April 14, 2025, 7:12pm UTC](https://discuss.rapid7.com/t/freebsd-vulnerability-false-positive/50021/6 "2025-04-14T19:12:36Z")
Same here. We’ve marked it as a false positive after validating we have the latest firmware. ---
**Author:** ![kneser](https://discuss.rapid7.com/user_avatar/discuss.rapid7.com/kneser/32/2004_2.png) [@kneser](https://discuss.rapid7.com/u/kneser)\ **Post date:** [May 22, 2025, 11:58am UTC](https://discuss.rapid7.com/t/freebsd-vulnerability-false-positive/50021/7 "2025-05-22T11:58:49Z")
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](https://docs.rapid7.com/insightvm/correlate-assets-with-insight-agent-uuids/) 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](https://nmap.org/book/man-os-detection.html) [Chapter 8. Remote OS Detection](https://nmap.org/book/osdetect.html) **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. ---
**Author:** ![rrdias](https://discuss.rapid7.com/letter_avatar_proxy/v4/letter/r/d6d6ee/32.png) [@rrdias](https://discuss.rapid7.com/u/rrdias)\ **Post date:** [May 30, 2025, 5:11pm UTC](https://discuss.rapid7.com/t/freebsd-vulnerability-false-positive/50021/8 "2025-05-30T17:11:24Z")
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? ---
**Author:** ![kneser](https://discuss.rapid7.com/user_avatar/discuss.rapid7.com/kneser/32/2004_2.png) [@kneser](https://discuss.rapid7.com/u/kneser)\ **Post date:** [June 9, 2025, 12:25pm UTC](https://discuss.rapid7.com/t/freebsd-vulnerability-false-positive/50021/9 "2025-06-09T12:25:35Z")
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. ---
**Author:** ![ascruggs1](https://discuss.rapid7.com/letter_avatar_proxy/v4/letter/a/5f8ce5/32.png) [@ascruggs1](https://discuss.rapid7.com/u/ascruggs1)\ **Post date:** [June 17, 2025, 9:14pm UTC](https://discuss.rapid7.com/t/freebsd-vulnerability-false-positive/50021/10 "2025-06-17T21:14:16Z")
As of 6/17/2025 its still being reported on some of our PC’s. ---
**Author:** ![cmarquez](https://discuss.rapid7.com/letter_avatar_proxy/v4/letter/c/b5e925/32.png) [@cmarquez](https://discuss.rapid7.com/u/cmarquez)\ **Post date:** [July 7, 2025, 4:31pm UTC](https://discuss.rapid7.com/t/freebsd-vulnerability-false-positive/50021/11 "2025-07-07T16:31:18Z")
What is interesting, this just showed up this past weekend. One day it was 15 machines, next it was 9. We have been sending our desktop team on a wild goose chase until I read this. Any updates? ---
**Author:** ![ascruggs1](https://discuss.rapid7.com/letter_avatar_proxy/v4/letter/a/5f8ce5/32.png) [@ascruggs1](https://discuss.rapid7.com/u/ascruggs1)\ **Post date:** [July 7, 2025, 5:10pm UTC](https://discuss.rapid7.com/t/freebsd-vulnerability-false-positive/50021/12 "2025-07-07T17:10:50Z")
I just checked and the vulnerability is only on 3 windows computers since April 2025. They’re all the same model but I’m not sure if it has something to with that (OptiPlex AIO 7410 35W). I’ve stopped reporting it and just started to ignore it! ---
**Author:** ![krees](https://discuss.rapid7.com/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@krees](https://discuss.rapid7.com/u/krees)\ **Post date:** [July 31, 2025, 11:53am UTC](https://discuss.rapid7.com/t/freebsd-vulnerability-false-positive/50021/13 "2025-07-31T11:53:10Z")
Is there an update to this? We are having the same issue. ---
**Author:** ![srednas](https://discuss.rapid7.com/letter_avatar_proxy/v4/letter/s/9de053/32.png) [@srednas](https://discuss.rapid7.com/u/srednas)\ **Post date:** [June 16, 2026, 12:21pm UTC](https://discuss.rapid7.com/t/freebsd-vulnerability-false-positive/50021/14 "2026-06-16T12:21:19Z")
A year or so later… Still an issue 😑