CVE-2019-0708 plugins

Hi openvas team,
Have you updated this rule recently, remote check?I want to write according to other people’s, but because of the limited level, I can’t write it with nasl.


a remote/active VT for this specific RDP vulnerability is currently in the works and should arrive in the feed soon.


Haven’t updated yet?

I updated feed on sunday, and find information CVE-2019-0708, but i can’t scan our windows servers and don’t show any vulnerability about CVE-2019-0708 .
I 'm waiting the update. Thanks.

Thanks for your reply.But,where is the information about CVE-2019-0708?

Are you using the community or GSF feed ? It might only come up on the GSF, the GCE does not give you any SLA on timing or availability.

If you look at the SecInfo it´s already part of the GSF:

Last updated: Fri, May 24, 2019 10:29 PM

Sorry, i’ m not openvas team. CVE-2019-0708 can find on Secinfo->CVE and search.

I mean the remote check.

okay,The remote rdp check policy haven’t updated.

Scan Authenticated …


I scanned a few Windows hosts which I know are vulnerable to CVE-2019-0708; however, OpenVAS did not detect it.

I ran greenbone-nvt-sync without issues.

Can you assist?
Thank you!

Openvas detection CVE-2019-0708 method is authorized to scan

How can i check it?Thanks.

As already explained twice the VTs covering that specific CVE currently requires an authenticated scan. See the following documentation on how to configure such an authenticated scan:

1 Like

An authenticated scan means you own the system you are scanning.

I work for an ISP, and often scan our subscribers’ systems for vulnerabilities, which we do not own or control.

I am able to detect the BlueKeep vulnerability using rdpscan, and also using Nexpose.

I am curious as to why this particular CVE requires an authenticated scan in OpenVAS.

I’m just curious. Why do you scan? As a service for your customers?

That is correct. Occasionally a subscriber will need some insight and we strive to provide that when it’s needed.

Just for the record, a Remote-Check for this CVE is available in the feed since quite some time:

Hi @cfi, it’s seems like this plugin has problem on processing TLS.
I use this plugin to scan a target and the target doesn’t response to the connect_initial_request packet - same as when using with --notls option. But, with no --notls option, the python script detects the vulnerability on the target successfully.
Another case, when a target “Forcing RDP to use TLS Encryption”, it responses “TLS required by server” to the “Negotiate Request”, but this plugin does not processing this.