u/DirectDifficulty8548

Hi Wazuh Community,

We have enabled the following settings on our Wazuh Manager:

<logall>yes</logall>g
<logall_json>yes</logall_json>

We also enabled archive forwarding in Filebeat:

archives:
  enabled: true

As I understand it, all events are stored locally on the Wazuh Manager under /var/ossec/logs/archives/, and Filebeat also sends the archive events to the Wazuh Indexer as wazuh-archives-*.

Our concern is that the archive files on the Manager can grow very quickly and eventually fill the Manager disk.

What is the recommended way to optimize this setup?

1. Can we keep only a short retention period (for example, 7 days) for archive files on the Wazuh Manager after confirming they have been successfully indexed?
2. Can the Wazuh Indexer be used as the main long-term storage for wazuh-archives-*?
3. What is the recommended method to automatically clean up old archive files on the Manager without affecting Filebeat or losing events?
4. What is the recommended retention method for wazuh-archives-* on the Indexer to prevent the Indexer disk from becoming full as well?

We want to keep archive collection enabled while preventing both the Manager and Indexer storage from filling up.

Thank you.

Hello Wazuh Team and Community members,

We are currently running Wazuh 4.14.4 on Ubuntu Server, and a recent Tenable vulnerability scan reported that the Wazuh Dashboard includes Node.js 18.19.0, which is flagged for multiple security vulnerabilities.

I understand that the Wazuh Dashboard uses a bundled Node.js runtime, and manually replacing the Node.js binary is not officially supported.

I have a few questions:

1. Does upgrading from Wazuh 4.14.4 to 4.14.6 update the bundled Node.js version?
2. If not, is there an official plan or estimated timeline for Wazuh to ship a Dashboard package with an updated Node.js runtime?
3. Is there any supported method to remediate these findings without waiting for a new Wazuh release?
4. For organizations that must remediate vulnerabilities identified by scanners such as Tenable, what is the recommended approach? Should this be handled as a vendor dependency with compensating controls until an updated package is released?

Our environment is a production SOC deployment, so we would like to avoid any unsupported modifications to the bundled Node.js runtime.

Any guidance from the Wazuh team or other community members who have encountered the same issue would be greatly appreciated.

Thank you.