vulnerabilities not reporting in wazuh agents

[Veera]

Hi,

I am raising this query after reviewing several existing discussions related to vulnerabilities not being reported.

We are currently operating a Wazuh cluster with thousands of agents. However, a set of these agents is not reporting vulnerability data.

could you advise on the recommended starting points for troubleshooting this issue from the agent side?

For context, our environment was initially deployed with version 4.9.2 and subsequently upgraded in sequence through the following versions:
4.12.0 → 4.13.1 → 4.14.0 → 4.14.1 → 4.14.2 → 4.14.4.1.
The current running version is WAZUH_VERSION: 4.14.4-1.

Though the packages details are reported below  

Menu (☰)
 → Security Operations
     → IT Hygiene
         → Software

However, no entries are observed under the vulnerabilities section (Critical/High/Medium/Low).

Additionally, executing the following command on the master node managing the agent:

grep "vulnerability-detector" /var/ossec/logs/ossec.log | grep "Agent <YOUR_AGENT_ID>"

returns no output, including when reviewing logs under /var/ossec/logs/wazuh/2026/Apr/*.

In this scenario, what would be the recommended next step for troubleshooting?

[Stuti Gupta]

Hi Veera

The syscollector module is enabled by default on all agents in the ossec.conf file. Please make sure to follow this https://documentation.wazuh.com/current/upgrade-guide/upgrading-central-components.html#configuring-vulnerability-detection

To diagnose the issue, share possible error or warning messages on the affected agents:
grep -iE 'sync|error|warn' /var/ossec/logs/ossec.log

Also, share the os details of the affected agent

Please check the ossec.log from the manager grep -iE 'sync|error|warn' /var/ossec/logs/ossec.log

In the logs, if there is an error: "indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-vulnerabilities-wazuh', retrying until the connection is successful."
This could happen if the configuration is not correct. Make sure you have followed all the steps.

In case you have these errors
2025/10/20 08:56:30 indexer-connector: ERROR: Could not connect to server, status code: -1.
2025/10/20 08:56:30 indexer-connector: WARNING: Failed to sync agent

This error indicates that the indexer connector that is responsible for the IT hygiene indices is sometimes not able to update, as it cannot connect and sync.
Also, can you please confirm the wazuh-indexer status is active?
If it is, then check.

Query the indexer’s health with Indexer
Indexer management > Dev Tools
 GET _cluster/health.

The cluster status must be:
Wazuh v4.8.0–v4.9.0: green
Wazuh v4.9.1 and later: green or yellow

If everything is working and fine. Then, please enable debug logs, set wazuh_modules.debug=2 in /var/ossec/etc/local_internal_options.conf, then restart the wazuh-manager using the command systemctl restart wazuh-manager

Then check and share the logs related to the vulnerability. You can use the following command:
cat /var/ossec/logs/ossec.log | grep vuln

Also, verify the certificates are valid using the following command and share the output
curl -u <user>:<pass> --cacert <path.pem> --cert <path-client.pem> --key <path-client-key.pem> -X GET "https://<IP>:9200/_cluster/health"

The paths to the certs are defined in the ossec.conf file, under the <indexer> section. 

[Veera]

Also, verify the certificates are valid using the following command and share the output
curl -u <user>:<pass> --cacert <path.pem> --cert <path-client.pem> --key <path-client-key.pem> -X GET "https://<IP>:9200/_cluster/health"

The paths to the certs are defined in the ossec.conf file, under the <indexer> section. 

What is the username and password to be used?  

Is that command to be executed from the agent or from the master server?

[Md. Nazmur Sakib]

The username or password will be your indexer user password.

You can use the user admin and the admin user password that you use for login to the dashboard.

Ex:

curl -u admin:Your_admin_Pass --cacert /etc/filebeat/certs/root-ca.pem --cert <path-client.pem> --key <path-client-key.pem> -X GET "https://<indexer_address>:9200/_cluster/health"

The paths to the certs and the indexer address you can find in the ossec.conf file, under the <indexer> section.

You need to run this message from the Wazuh manager server Command line interface. If you have multiple Wazuh managers, run this in all the Wazuh manager nodes.

This way, we can verify if you have configured the <indexer> configuration correctly.

Also, share the ossec.log from the Wazuh manager’s server related to vulnerability and indexer connector. For this run, this command.

cat /var/ossec/logs/ossec.log | grep -iE "vulnerability|indexer-connector|error|warn"


This will help us understand your issue better and help you accordingly.

[Veera]

Hi ,

Here are the details of logs attached.

cat /var/ossec/logs/ossec.log | grep -iE "vulnerability|indexer-connector|error|warn" -logs attached as wazuh_manager_apr11

2 agent logs are attached .

grep -iE 'sync|error|warn' /var/ossec/logs/ossec.log  

zgrep grep -iE 'sync|error|warn' /var/ossec/logs/wazuh/2026/May/*

also the logs of  #grep  agent_name /var/ossec/logs/ossec.log  from the manager is atatched.

Query the indexer’s health with Indexer
Indexer management > Dev Tools

 GET _cluster/health.             -->  ALL GREEN in status

####

Also, verify the certificates are valid using the following command and share the output
curl -u <user>:<pass> --cacert <path.pem> --cert <path-client.pem> --key <path-client-key.pem> -X GET "https://<IP>:9200/_cluster/health"

unable to execute as  finding the path of the  cert/key files in a docker based server setup  is challenging.

Will a find command/location of the files? ,. Or any referecnce document will be helpful...

#####

Note in the sample 2 agent logs shared the  "agent1"  is  not  showing any vulnerabilities. also no packages listed under 

Menu (☰)
 → Security Operations
     → IT Hygiene
         → Software

For the agent2 ,   no vulnerabilities reported but  the packages are listed under the above menu .

[Veera]

Hi  @nazmur...@wazuh.com @stuti...@wazuh.com    / Team,

Kindly review  the logs and update.. 

[Veera]

For  executing the below command ..

curl -u admin:Your_admin_Pass --cacert /etc/filebeat/certs/root-ca.pem --cert <path-client.pem> --key <path-client-key.pem> -X GET "https://<indexer_address>:9200/_cluster/health"

  We have a clustered setup running on Docker(docker swarm based cluster with multinode), with separate nodes for the master, worker, indexer, and dashboard components. The corresponding certificate files are stored in a common shared filesystem. Please refer to the attached file for the complete certificate file details; the content shared here has been trimmed for public sharing purposes  .  

Let me know the right  file to be used for   <path-client.pem> , <path-client-key.pem> and root-ca.pem as wazuh01.indexer is our master indexer(primary)  in the cluster. 

[Stuti Gupta]

Hi @Veera,

Most of the logs shared so far appear to be related to agent enrollment/connectivity issues, for example:

WARNING: Duplicate name 'myserver1', rejecting enrollment. ERROR: Too many connections. Rejecting. ERROR: (1208): Unable to connect to enrollment service ERROR: SSL error (5). Connection refused by the manager

These are usually related to duplicate agent registration entries, connectivity issues between the agent and manager, or multiple agents attempting enrollment simultaneously.

However, as you mentioned earlier, some affected agents are already visible under:

Menu (☰)
→ Security Operations
→ IT Hygiene
→ Software

This means the syscollector inventory data is already reaching the manager/indexer successfully.

Because of that, it is somewhat unusual that the software inventory is visible while vulnerabilities are not being populated for the same agents. The enrollment/connectivity issues may affect some agents, but they may not fully explain the vulnerability detection behavior for all affected agents. https://documentation.wazuh.com/current/user-manual/agent/agent-management/agent-connection.html

Since you are using the Docker deployment, please check the manager configuration files from the Docker host filesystem (outside the container).

Based on the standard Wazuh Docker structure, please verify these files: Check the docker compose.yml file 

./config/wazuh_cluster/wazuh_manager.conf

and:

   - ./config/wazuh_indexer_ssl_certs/root-ca-manager.pem
   - ./config/wazuh_indexer_ssl_certs/wazuh.master.pem
    - ./config/wazuh_indexer_ssl_certs/wazuh.master-key.pem
Please check whether the following sections are properly configured inside:

<vulnerability-detection>
<indexer>

You can check them using:

grep -nE "vulnerability-detection|indexer|" ./config/wazuh_cluster/wazuh_manager.conf

Also, please share the output of:

grep -iE "vulnerability|indexer-connector|indexer|warn|error" <WAZUH_DOCKER_VOLUME_PATH>/wazuh_logs/ossec.log

and from Dashboard, Index management > Dev Tools:

GET _cat/indices?v

[Veera]

Hi  Stuti,

Thanks for the updates.

I am able to run the curl command successfully .. refer to  (curl_and_grep-errors.txt)

Attached the logs

You can check them using:

grep -nE "vulnerability-detection|indexer|" ./config/wazuh_cluster/wazuh_manager.conf         (curl_and_grep-errors.txt)

Also, please share the output of:

grep -iE "vulnerability|indexer-connector|indexer|warn|error" <WAZUH_DOCKER_VOLUME_PATH>/wazuh_logs/ossec.log      (master_logs_2026-05-13_2)

and from Dashboard, Index management > Dev Tools:

GET _cat/indices?v      (wazuh_indices_Status.txt)

[Stuti Gupta]

Hi @Veera,

Before concluding whether the indexer configuration is correct, could you please confirm whether port 9250 is configured in your environment?

In the default Wazuh Docker deployment, the indexer usually uses:
9200:9200

But from your curl output, the requests are working on:
https://mywazuh.dyn.nesc.mynet.net:9250

Could you please confirm whether 9250 is configured through a custom Docker mapping or through a load balancer or proxy configuration?

If 9250 is already configured correctly in your environment, then the issue may be related to the manager connection problems shown in the logs:

ERROR: Too many connections. Rejecting. ERROR: (1208): Unable to connect to enrollment service ERROR: SSL error (5). Connection refused by the manager

Since vulnerability detection depends on proper communication between the agents and manager, these connection problems may affect vulnerability data for some agents even though the software inventory is already visible in the Dashboard.
And the error you are getting is because, depending on the number of agents simultaneously requesting registration on the Wazuh Manager master node, the system processes a maximum number of agents, and the remaining agents generate the error you're seeing. So, as the system registers the agents it's working with, it will eventually finish processing all of them.

I'm wondering if you have any network issues that could be causing a lack of connection between the agent and the worker nodes. If this is happening, the agent might lose its normal connection, and after unsuccessfully attempting to reconnect to the worker node a number of times, it returns to the registration process on the master node. This could cause problems not only in processing the current agents but also in constantly queuing new agents.

The problem could be related to network issues or difficulty processing a high volume of requests on the server hosting the Wazuh Manager master.

I recommend checking the connections to port 1515 on the server hosting the Wazuh Manager master. These connections should only last a few milliseconds, so if you see persistent connections, your network load is very high, and you should review your network infrastructure.

If it's not a network issue, then the load on the master server is exceeding the number of requests it can handle. Therefore, I recommend load balancing the connections to port 1515 between the master and the worker nodes, which accept the requests and then forward them to the master node. To do this, you should create a load balancer for port 1515 that targets all Wazuh Manager nodes. https://documentation.wazuh.com/current/user-manual/agent/agent-management/agent-connection.html

[Veera]

Hi Stuti,

Thanks for the details ..

I confirm the wazuh manager(master) to the  indexer(or indexer master) is on port 9200.  Kindly ignore the port tests on port 9250 .

[Stuti Gupta]

Then the cause is the connection between the agent and the manager. Please go through the steps and explanation mentioned here:

ERROR: Too many connections. Rejecting. ERROR: (1208): Unable to connect to enrollment service ERROR: SSL error (5). Connection refused by the manager

Since vulnerability detection depends on proper communication between the agents and manager, these connection problems may affect vulnerability data for some agents even though the software inventory is already visible in the Dashboard.
And the error you are getting is because, depending on the number of agents simultaneously requesting registration on the Wazuh Manager master node, the system processes a maximum number of agents, and the remaining agents generate the error you're seeing. So, as the system registers the agents it's working with, it will eventually finish processing all of them.

I'm wondering if you have any network issues that could be causing a lack of connection between the agent and the worker nodes. If this is happening, the agent might lose its normal connection, and after unsuccessfully attempting to reconnect to the worker node a number of times, it returns to the registration process on the master node. This could cause problems not only in processing the current agents but also in constantly queuing new agents.

The problem could be related to network issues or difficulty processing a high volume of requests on the server hosting the Wazuh Manager master.

I recommend checking the connections to port 1515 on the server hosting the Wazuh Manager master. These connections should only last a few milliseconds, so if you see persistent connections, your network load is very high, and you should review your network infrastructure.

If it's not a network issue, then the load on the master server is exceeding the number of requests it can handle. Therefore, I recommend load balancing the connections to port 1515 between the master and the worker nodes, which accept the requests and then forward them to the master node. To do this, you should create a load balancer for port 1515 that targets all Wazuh Manager nodes. https://documentation.wazuh.com/current/user-manual/agent/agent-management/agent-connection.html 

[Stuti Gupta]

Also, please check the logs related to the indexer in the Wazuh Manager container.

[Veera]

Hi Stuti,

Attached are the logs from an agent that is not reporting vulnerability data.

The connectivity between the agent and the worker node appears to be functioning correctly. However, the Wazuh logs clearly indicate intermittent disconnections. At the same time, there are no corresponding logs on either the worker or master nodes related to the affected agent or agent ID.

The logs from the worker node to which the agent is connected are also attached for reference.

Additionally, please review the indexer-related logs from the Wazuh Manager container. The manager logs containing all warning and error entries are attached as well.

From the network validation performed using ping, nc, netstat, and ss, there does not appear to be any observable network drop or instability.

Please let us know if there is a more effective method to isolate, confirm, or measure potential network interruptions between the agent, worker, and master nodes.

[Stuti Gupta]

There is a connection issue. From the timestamps in the logs, the agent was previously connected, but later it started showing the following errors:

2026/05/14 12:37:23 wazuh-agentd: WARNING: (1404): Authentication error. Wrong key or corrupt payload. Message received from agent '2292' at 'any'.

2026/05/14 12:37:23 wazuh-agentd: WARNING: (1214): Problem receiving message from 'mywazuh-lb.net'.

In this case, please verify that the client.keys file on the Wazuh agent matches the key stored on the Wazuh manager.

Wazuh manager: /var/ossec/etc/client.keys
Linux/Unix agent: /var/ossec/etc/client.keys
macOS agent: /Library/Ossec/etc/client.keys
Windows agent: C:\Program Files (x86)\ossec-agent\client.keys

More information is available here:
Wazuh authentication error troubleshooting

The reason the vulnerabilities are not showing for those agents is already visible in the logs. The affected agents are having communication and authentication problems with the manager. The errors Invalid agent-info response format, Agent key already in use, and Authentication error. Wrong key or corrupt payload indicate that the agent registration or authentication key is not matching correctly.

From the logs you shared, this may be happening because the agent was trying to reconnect to the Wazuh manager but failed authentication multiple times. After repeated failures, the agent may be attempting to register again, which can cause the manager to detect a duplicated or mismatched key.

Please first verify that the affected agent is using the correct key from the manager. If the issue continues, remove the old agent entry from the manager and register the agent again.

Because of this issue, the manager is not receiving proper agent information and Syscollector inventory from that agent. If the inventory data is not received correctly, Vulnerability Detection cannot generate vulnerability entries for that agent, which is why the agent does not appear in the dashboard. Once the agent reconnects correctly and sends fresh inventory data, the vulnerabilities should start appearing again.