Rescan and Investigate not returning accurate status

InsightVM
1

I’m working on resolving “Default or Guessable SNMP community names: public”

I get a list of assets that have this vulnerability and then start disabling SNMP and rescan. After rescan, assets still show as having this vulnerability. I’ve repeated this and get the same result. Oddly, some printers (Zebra) seem to show as no longer being vulnerable. But HP printers keep showing as vulnerable. I can print the printer config and it shows public is disabled. I can hit it with an SNMP browser and it does not show public as being there. If I try the investigate option in R7 it still says the vulnerability is there. If I delete the asset in R7 and rescan then it shows the vulnerability is not there.

Is there an issue with rescanning or investigate options that prevent it from actually scanning the asset again? Are there any suggested fixes to this behavior? Do I just have to delete assets and rescan then when I’m having trouble getting a vulnerability to show as being resolved?

Thanks!

2 Likes
2

I have the same problem, SNMP vulns on some assets, when fixed, require us to delete the asset and rescan to clear the vuln in Rapid7.

3

We’ve encountered the same problem with these “ghost vulnerabilities”, and unfortunately have to delete the asset.

4

We have the same issue and have had it for years. hopefully they fix it.

5

Same thing here. Happens on all of our SNMP capable devices. We’ve tried disabling SNMP and even renaming the community - nothing.

6

Weill i thought i am the only one facing the trouble. We did every tests , even collecting the tcpdump.the vuln devices doesnt use the public names as they say. still shows as vulnerable. We dont want to delete the asset to lose the history. :frowning:

7

Same problem here. The only way is to delete the asset and scan the asset again. Hopefully Rapid7 will fix that soon.

8

Still not fixed =/

9

I know :frowning: I also addressed that directly to our CSMA. But I have no idea if anything will ever happen. It seems to have been a problem for a long time….

10

also wanna mention, not only SNMP vulnerabilities are affected, sometimes also FTP vulnerabilities! Tip: check here too.

11

Was there ever any resolution to this. We also have this issue of SNMP vulnerabilities not being resolved on re-scan the only fix so far has been to remove the asset entirely and re-scan.

12

I’m seeing the same issue, and not only with SNMP-related vulnerabilities. It also affects other findings such as TLS misconfigurations and weak ciphers on both clients and servers.

We’ve spent a lot of time troubleshooting and verifying the configurations, and the last “possible” solution I tried was deleting the affected asset and re‑scanning it. After confirming that this worked, I deleted all Windows-based assets (servers and clients) from the console one day before our global scan to start from a clean slate.

It looks like, after a re‑scan and importing the new results, the console does not properly purge the old scan data.