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:
This has various constraints before a detection of OpenEMR is happening:
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
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.
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.