nmap-vulners gives no output about nmap-vulners HOT 16 OPEN

My previous answer post was getting thumbs down, so I'm giving another, more detailed answer.

Please make sure that the VIRTUAL MACHINE you're running nmap-vulners on can access the internet. It seems to need internet access to give some output.

This was MY reason for getting no output, but of course I can't promise it's the reason in every case.

from nmap-vulners.

same here I'm not getting any CVEs kali 2021.1

from nmap-vulners.

For anyone who comes across this issue in the future, make sure to include the -sV flag. The vulners script uses version numbers when searching, so if you don't use the version flag, it won't find any results.

from nmap-vulners.

did you find a solution to this?

from nmap-vulners.

I have the same problem. Found the solution??

from nmap-vulners.

Same issue here. I've looked up several videos, articles, etc to see how everyone else is doing their scans while utilizing vulners - and as far as I can tell, I'm doing the same exact thing, yet my results show normal nmap results... as if vulners never runs within the scan. Would love a solution to this.

Running Kali Linux 2020 and I update/upgrade almost daily - so i dont know if its just not compatible with current version of nmap and/or kali, or what the deal might be..

from nmap-vulners.

Same here (Kali linux) vulners.nse and also a copy from github. Tried to debug with no luck. I see API traffic with vulners.com port 443 but no output.

from nmap-vulners.

Same here (Windows 10). Any solutions for this, it appears it's quite common?

from nmap-vulners.

is ther any solution

from nmap-vulners.

I'm also having the same problem. Has anyone managed to solve this issue yet?
I'm running the script on kali 2021.2 like so:

kali@kali: sudo nmap -sV --script vulners --top-ports 100 X.X.X.X
Starting Nmap 7.91 ( https://nmap.org ) at 2021-06-07 19:38 EDT
Nmap scan report for X.X.X.X
Host is up (0.24s latency).
Not shown: 92 closed ports
PORT STATE SERVICE VERSION
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds Microsoft Windows 7 - 10 microsoft-ds (workgroup: ELS-CHILD)
49152/tcp open msrpc Microsoft Windows RPC
49153/tcp open msrpc Microsoft Windows RPC
49154/tcp open msrpc Microsoft Windows RPC
49155/tcp open msrpc Microsoft Windows RPC
49157/tcp open msrpc Microsoft Windows RPC
MAC Address: XX:XX:XX:XX:XX:XX (VMware)
Service Info: Host: WIN7-HR; OS: Windows; CPE: cpe:/o:microsoft:windows

from nmap-vulners.

same, kali 2021

Devs where u at? x')

from nmap-vulners.

Interestingly when pentesting another network, with both windows and unix machines, I was able to get output from vulners only for the unix machine. I think its because running the nmap -sV option against the unix machines returns actual version numbers for which vulners can then check for vulnerability against. When running -sV against windows machines as shown in in the example below and in my previous comment, nmap only returns ambiguous version information such as "Microsoft Windows RPC" or "netbios-ssn Microsoft Windows netbios-ssn" which is useless in terms of vulnerability scanning. In this case it would be useful for vulners to report this as an error message, something along the lines of "Error ambiguous service version numbers for IP X.X.X.X"

sudo nmap -A --script vulners -T4 -n X.X.X.X/24

Nmap scan report for X.X.X.X
Host is up (0.17s latency).
Not shown: 995 closed ports
PORT STATE SERVICE VERSION
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds Microsoft Windows 2003 or 2008 microsoft-ds
1025/tcp open msrpc Microsoft Windows RPC
3389/tcp open ms-wbt-server Microsoft Terminal Service
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.91%E=4%D=6/10%OT=135%CT=1%CU=32110%PV=Y%DS=2%DC=T%G=Y%TM=60C273
OS:F8%P=x86_64-pc-linux-gnu)SEQ(SP=107%GCD=1%ISR=105%TI=I%II=I%SS=S%TS=0)OP
OS:S(O1=M4E7NW0NNT00NNS%O2=M4E7NW0NNT00NNS%O3=M4E7NW0NNT00%O4=M4E7NW0NNT00N
OS:NS%O5=M4E7NW0NNT00NNS%O6=M4E7NNT00NNS)WIN(W1=FAF0%W2=FAF0%W3=FAF0%W4=FAF
OS:0%W5=FAF0%W6=FAF0)ECN(R=Y%DF=N%T=80%W=FAF0%O=M4E7NW0NNS%CC=N%Q=)T1(R=Y%D
OS:F=N%T=80%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=N)T5(R=Y%DF=N%T=80%W=0
OS:%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=N)T7(R=N)U1(R=Y%DF=N%T=80%IPL=B0%UN=0%RIP
OS:L=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=S%T=80%CD=Z)

Network Distance: 2 hops
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows, cpe:/o:microsoft:windows_server_2003

TRACEROUTE (using port 110/tcp)
HOP RTT ADDRESS

• Hop 1 is the same as for X.X.X.X
  2 269.20 ms X.X.X.X

Nmap scan report for X.X.X.X
Host is up (0.17s latency).
Not shown: 999 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp ProFTPD 1.3.2a
| vulners:
| cpe:/a:proftpd:proftpd:1.3.2a:
| SAINT:C38482A29286C4F6E5C4BD19DFFEC245 10.0 https://vulners.com/saint/SAINT:C38482A29286C4F6E5C4BD19DFFEC245 EXPLOIT
| SAINT:54FCA613A72A46139DD6F86DF77D354A 10.0 https://vulners.com/saint/SAINT:54FCA613A72A46139DD6F86DF77D354A EXPLOIT
| SAINT:0D292D8F05ADFBE8F747F01E40BAF2AF 10.0 https://vulners.com/saint/SAINT:0D292D8F05ADFBE8F747F01E40BAF2AF EXPLOIT
| MSF:EXPLOIT/LINUX/FTP/PROFTP_TELNET_IAC 10.0 https://vulners.com/metasploit/MSF:EXPLOIT/LINUX/FTP/PROFTP_TELNET_IAC EXPLOIT
| MSF:EXPLOIT/FREEBSD/FTP/PROFTP_TELNET_IAC 10.0 https://vulners.com/metasploit/MSF:EXPLOIT/FREEBSD/FTP/PROFTP_TELNET_IAC EXPLOIT
| EDB-ID:16878 10.0 https://vulners.com/exploitdb/EDB-ID:16878 EXPLOIT
| EDB-ID:16851 10.0 https://vulners.com/exploitdb/EDB-ID:16851 EXPLOIT
| EDB-ID:15449 10.0 https://vulners.com/exploitdb/EDB-ID:15449 EXPLOIT
| CVE-2010-4221 10.0 https://vulners.com/cve/CVE-2010-4221
| SSV:26016 9.0 https://vulners.com/seebug/SSV:26016 EXPLOIT
| SSV:24282 9.0 https://vulners.com/seebug/SSV:24282 EXPLOIT
| CVE-2011-4130 9.0 https://vulners.com/cve/CVE-2011-4130
| CVE-2019-12815 7.5 https://vulners.com/cve/CVE-2019-12815
| SSV:20226 7.1 https://vulners.com/seebug/SSV:20226 EXPLOIT
| PACKETSTORM:95517 7.1 https://vulners.com/packetstorm/PACKETSTORM:95517 EXPLOIT
| CVE-2010-3867 7.1 https://vulners.com/cve/CVE-2010-3867
| CVE-2010-4652 6.8 https://vulners.com/cve/CVE-2010-4652
| SSV:12523 5.8 https://vulners.com/seebug/SSV:12523 EXPLOIT
| CVE-2009-3639 5.8 https://vulners.com/cve/CVE-2009-3639
| MSF:ILITIES/SUSE-CVE-2019-18217/ 5.0 https://vulners.com/metasploit/MSF:ILITIES/SUSE-CVE-2019-18217/ EXPLOIT
| EDB-ID:16129 5.0 https://vulners.com/exploitdb/EDB-ID:16129 EXPLOIT
| CVE-2019-19272 5.0 https://vulners.com/cve/CVE-2019-19272
| CVE-2019-19271 5.0 https://vulners.com/cve/CVE-2019-19271
| CVE-2019-19270 5.0 https://vulners.com/cve/CVE-2019-19270
| CVE-2019-18217 5.0 https://vulners.com/cve/CVE-2019-18217
| CVE-2016-3125 5.0 https://vulners.com/cve/CVE-2016-3125
| CVE-2011-1137 5.0 https://vulners.com/cve/CVE-2011-1137
| CVE-2008-7265 4.0 https://vulners.com/cve/CVE-2008-7265
| CVE-2017-7418 2.1 https://vulners.com/cve/CVE-2017-7418
|_ CVE-2012-6095 1.2 https://vulners.com/cve/CVE-2012-6095
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.91%E=4%D=6/10%OT=21%CT=1%CU=32975%PV=Y%DS=2%DC=T%G=Y%TM=60C273F
OS:8%P=x86_64-pc-linux-gnu)SEQ(SP=100%GCD=2%ISR=10C%TI=I%II=I%SS=S%TS=21)OP
OS:S(O1=M4E7NW3ST11%O2=M4E7NW3ST11%O3=M280NW3NNT11%O4=M4E7NW3ST11%O5=M218NW
OS:3ST11%O6=M109ST11)WIN(W1=FFFF%W2=FFFF%W3=FFFF%W4=FFFF%W5=FFFF%W6=FFFF)EC
OS:N(R=Y%DF=Y%T=40%W=FFFF%O=M4E7NW3SLL%CC=N%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=
OS:AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=N)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD
OS:=0%Q=)T6(R=N)T7(R=N)U1(R=Y%DF=N%T=40%IPL=38%UN=0%RIPL=G%RID=G%RIPCK=G%RU
OS:CK=G%RUD=G)IE(R=Y%DFI=S%T=40%CD=S)

Network Distance: 2 hops
Service Info: OS: Unix

TRACEROUTE (using port 3389/tcp)
HOP RTT ADDRESS

• Hop 1 is the same as for X.X.X.X
  2 269.14 ms X.X.X.X

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 4 IP addresses (4 hosts up) scanned in 59.77 seconds

from nmap-vulners.

I had this problem running on CentOS 8
Solved by upgrading nmap version from 7.60 to 7.92

from nmap-vulners.

Hi everyone. I found out that 804a692 broke the script.
Just remove line 135 (Accept-Encoding) and the script will work.

from nmap-vulners.

I also had this problem I both my machines were on host-only, I swithed my kali machine to NAT or what ever one connects your machine to the internet and that seemed to work.

from nmap-vulners.

As what @gMemiy said, just remove line 135 (Accept-Encoding). However, I am still confused that at the majority of time, when I use -d option to see the debug process, I can see that the whole script is not running at all.

Here is what I got:
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 15:31
Completed NSE at 15:31, 0.00s elapsed

You see, I cannot get any debug output from the script. Only a very few times that it can work and I can get some CVEs

from nmap-vulners.