False positive for OpenEMR tests


looks like the OpenEMR NVTs are detecting our Software (Synaptic Enterprise Platform) as a vulnerable version of OpenEMR.

The list of NVTs that creates the false positives are appended. If the developer has questions he/she can contact me.


Thanks a lot for your posting, unfortunately it seems it got missed in the past.

This doesn’t look like related to the mentioned OIDs itself. They are rather working based on the detection and version info provided to them by the following detection VT which should have reported in the report in question:

Name: OpenEMR Detection (HTTP)

This has various constraints before a detection of OpenEMR is happening:

  1. A system needs to respond to a HTTP GET request to /interface/login/login.php (in the root dir but also various subdirs are checked) with a HTTP status code of 200 and with the (case insensitive) OpenEMR string included in the response
  2. In addition (and before the previous mentioned various VTs are reporting) a version also needs to be extracted from various additional URLs

Both info were the detection happened from should be included in the report / output of the previous mentioned detection VT.

If the system in question really doesn’t have an OpenEMR instance installed (could be clarified based on the info provided previously) maybe the “HTTP status code of 200 and with the (case insensitive) OpenEMR string included in the response” check could me made a little bit more strict in the future.

Hmm, that ist strange I am fairly sure that there is no OpenEMR running on the machine.

I got the following error description:

Kategorie: Web application abuses
Port: 9402/tcp
Beschreibung: Installed version: 2.2. Fixed version: 5.0.1-4 Installation path / port: /files
Lösung: Update to version or later.

There runs a web service that responds to to / and /files on port 9402.

To be sure I will try to issue a curl request with the /interface/login/login.php URL you haven mentioned.

Thank you.

1 Like

So based on that info the detection by the previously mentioned OpenEMR Detection (HTTP) VT should happen from the following URL:


and the response to that request should contain the previous mentioned constraints.

One important note:

IIRC on older GVM versions the scanner had mixed some results of “interrupted” tasks with current running tasks which might be another explanation. To avoid any scanner side issue please make sure to use the most recent versions of all GVM components listed at GVM Release Version 21.4.4

Sorry for the delayed reply.
The problem vanished after few weeks and never came back.
We upgraded to a newer version as suggested and nearly everything is fine now.