Wazuh Vulnerability Detection RocksDB Error

I noticed a minor issue with the Vulnerability Detection in Wazuh 4.9. It seemed that some of my recent application updates weren’t being recognised by Wazuh. I then checked if the syscollector was working as it should.

On the endpoint inventory page, I saw the correct latest scan date and also the current versions of the installed packages. Now I knew that the syscollector was working fine, the latest data was being stored correctly to the Wazuh inventory.

I then came across this message in the log:
var/ossec/logs/ossec.log

wazuh-modulesd:vulnerability-scanner: ERROR: VulnerabilityScannerFacade::start: Failed to open RocksDB database. Reason: Corruption: IO error: No such file or directory: While open a file for random read: queue/indexer/wazuh-states-vulnerabilities-siem/000113.ldb: No such file or directory in file queue/indexer/wazuh-states-vulnerabilities-siem/MANIFEST-0005

I did a bit of digging and found a few issues on the Wazuh GitHub repository and on the Wazuh mailing list:

As this is only in my homelab and I have backups, I decided to rename the directory that stores the events for the vulnerability detection module:
/var/ossec/queue/vd/event/

Then I restarted Wazuh and looked at the logs:

wazuh-modulesd:vulnerability-scanner: INFO: Starting database file decompression.
wazuh-modulesd:vulnerability-scanner: INFO: Database decompression finished.
wazuh-modulesd:vulnerability-scanner: INFO: Vulnerability scanner module started.
wazuh-modulesd:vulnerability-scanner: INFO: Initiating update feed process.
wazuh-modulesd:vulnerability-scanner: ERROR: Error updating feed: [json.exception.out_of_range.403] key ‘date Updated’ not found, trying to re-download the feed.
wazuh-modulesd:vulnerability-scanner: INFO: Initiating update feed process.
wazuh-modulesd:vulnerability-scanner: INFO: Triggered a re-scan after content update.
wazuh-modulesd:vulnerability-scanner: INFO: Feed update process completed.

It all took about 30 minutes after the restart, and then I looked at the Endpoint Vulnerability Detection dashboard and saw that the latest inventory data had been successfully processed.

This is possibly not the best way to handle this, as you are likely to lose data. From what I’ve seen on my test machine, it looks like the previous Vulnerability Detection event data is now missing.

But Wazuh has already fixed this for the 4.10 release:

Adds a more verbose logging option for RocksDB to give more details in case of failure.

The logger helper class was updated because the utils methods lack of logging.

Executes a repair method by default when the opening fails due to corruption (for queues and wrapper). It also prints a warning message after a successful recovery. This mechanism is optional in the wrapper and can be disabled in the constructor