Package

openvas-scanner 23.45.1-1
notus-scanner 22.7.2-3
ospd-openvas 22.10.5-1
gvmd 26.24.0
gvm-libs 22.41.0

Distribution: Kali Linux Rolling
Architecture: amd64
Repository: http://http.kali.org/kali, kali-rolling

uname -a
Linux kali 7.1.5+kali-amd64 0000001 SMP PREEMPT_DYNAMIC Kali 7.1.5-1kali1 (2026-07-29) x86_64 GNU/Linux
dpkg -s libc6 | grep '^Version'
Version: 2.43-4

Description

I am experiencing a problem with Notus-based local security checks when scanning a Debian 13 (Trixie) host using SSH credentials.

The Kali packages are fully upgraded according to APT. The installed versions are the current candidates offered by my configured Kali Rolling repository.

The target is correctly identified as Debian 13, SSH authentication succeeds, and the target has 717 installed packages according to dpkg-query.

However, the scan does not successfully perform the Notus-based Debian package checks.

The relevant OpenVAS log messages are:

attack_network_init: INIT MQTT: SUCCESS

parse_server: Invalid URL (null). It must be in format:
schema://host:port. E.g. http://localhost:8080

nasl_notus: Unable to get the response

The last two messages recur during the scan.

Current configuration and observations

/etc/openvas/openvas.conf contains:
mqtt_server_uri = localhost:1883
Mosquitto is running and listening on 127.0.0.1:1883.
notus-scanner.service is active.
/var/lib/notus/products/debian_13.notus exists.
gvm-check-setup reports 95,103 NVTs and 526 Notus product files and reports the GVM installation as OK.
SSH authentication to the target succeeds.
The target's OS is detected as DEB13.
The target's dpkg-query command returns 717 package records in the format expected by gather-package-list.nasl.
openvasd is not installed, and APT does not offer an openvasd package.
The NVT feed updated to version 202610010558. The installed gather-package-list.nasl is dated 2026-09-30.

The current /var/lib/openvas/plugins/notus.inc uses the direct notus() function when that function is available. In the installed OpenVAS 23.45.1 source, the direct NASL Notus request uses openvasd_server, whereas the installed Kali configuration uses the Python Notus scanner and MQTT.

This suggests a possible incompatibility between the current NVT feed and the OpenVAS/Notus components packaged by Kali. I have not established the definitive root cause.

Steps to reproduce

Install or update GVM using the packages available from Kali Rolling.
Synchronize the NVT and Notus feeds.
Configure a target running Debian 13 (Trixie) with valid SSH credentials.
Run a scan using the Full and fast scan configuration.
Inspect /var/log/gvm/openvas.log for the messages shown above.
Check the scan results for Debian package-based vulnerability checks.

Expected result

OpenVAS should successfully communicate with the configured Notus backend and perform Debian 13 package-based vulnerability checks.

Actual result

OpenVAS logs Invalid URL (null) and nasl_notus: Unable to get the response. The expected Notus-based Debian package checks do not appear to complete successfully.

Request

Please investigate whether the current NVT feed is compatible with Kali's packaged OpenVAS 23.45.1-1 and Python Notus 22.7.2-3 stack, and whether a package update, feed compatibility adjustment, or documented configuration change is required.

I can provide relevant logs and further diagnostic output if needed.

Thank You

Peter

Error Message from yesterday's log:

lib misc:WARNING:2026-10-01 17h30.02 utc:390300:b691f5ad-12c0-4e4a-9e8c-837b1df6cb8d: parse_server: Invalid URL (null). It must be in format: schema://host:port. E.g. http://localhost:8080
lib nasl:WARNING:2026-10-01 17h30.02 utc:390300:b691f5ad-12c0-4e4a-9e8c-837b1df6cb8d: nasl_notus: Unable to get the response

Additional diagnostic tests (unsuccessful)

The current notus.inc calls the built-in notus() function whenever it is available. In my setup, this results in the Invalid URL (null) error because openvasd is not installed and openvasd_server is not configured.

For diagnostic purposes, I temporarily changed the condition to if (FALSE) to bypass the direct notus() call and allow execution to reach the legacy fallback code, including update_table_driven_lsc_data() if available.

However, this did not resolve the issue. During a subsequent scan, no relevant MQTT messages appeared when monitoring Mosquitto with mosquitto_sub, and the Notus service showed no corresponding processing activity. The ssh/login/release_notus knowledge-base entry remained FALSE, although the target was correctly identified as Debian 13 (ssh/login/release = DEB13).

I restored the original notus.inc after the test. No permanent feed modifications remain.