Splitting Wazuh 5.0 events per tenant silently turns off detection

If you run Wazuh for several customers, there is a good chance you separate them the 4.x way: an agent group or label per tenant, a Filebeat processor that sets an index prefix, one wazuh-alerts-<tenant>-* pattern per customer, and dashboard roles on top. We tried to rebuild that on Wazuh 5.0.0-rc2. The index split still works. Detection on the split events does not, and nothing tells you.

Everything below was measured on 7 November 2026 in throwaway Docker containers: wazuh-manager and wazuh-indexer 5.0.0-rc2, one wazuh-agent 4.14.7, and an sshd "Failed password" line as the test event. 5.0 is not GA yet, so treat this as a release-candidate result.

What changes in 5.0

There is no Filebeat in the 5.0.0-rc2 manager image. The manager writes to the indexer itself, and the target index comes from one file, /etc/wazuh-manager/outputs/default/indexer.yml:

index: "wazuh-events-v5-${wazuh.integration.category}"

Events land in data streams such as wazuh-events-v5-system-activity, and rule matches go to wazuh-findings-v5-<category>. So the Filebeat processor that set your tenant prefix has nowhere to run.

Test 1: is the tenant still in the event?

We put the agent into a group called tenant-t1 (the manager accepted it: the API shows "group":["tenant-t1"]) and also set <labels><label key="tenant">t1</label></labels> in the agent's ossec.conf.

The indexed event carries neither. Under wazuh.agent there is only id, name, version and host details, and the index mapping has no field for agent groups or labels. On the manager side, the 5.0 agent database has no labels table and the labels endpoint of the agent config API returns 404.

So the field most MSSPs use as the tenant key is not available to route on. The closest thing in the event is the agent name.

Test 2: split the index anyway

We edited indexer.yml to add the agent name:

index: "wazuh-events-v5-${wazuh.integration.category}-${wazuh.agent.name}"

The manager accepted the file, kept it across a restart, and created a new data stream, wazuh-events-v5-system-activity-<agent>, from the existing system-activity template. New events went there.

Then we waited for findings. Before the edit, the same sshd event produced a finding within two minutes, once the detectors had been running for a few minutes (the very first event, sent about two minutes after the detectors were created, got none in five minutes, so we only compare events sent after that). After the edit, events in the new stream produced none in four to five minutes of polling, across two separate runs.

The reason is in Security Analytics. The standard detector that matched our event, wazuh-generic-1 (50 rules, runs every two minutes), lists its inputs by exact name:

wazuh-events-v5-access-management, ...-applications, ...-cloud-services,
...-network-activity, ...-other, ...-security, ...-system-activity

No wildcard, so a stream with a suffix is simply not read.

Can you add the new stream to the detector?

Not to the standard one. Every attempt to change its inputs (the exact new stream name, wazuh-events-v5-system-activity*, wazuh-events-v5-*) returned HTTP 400: "Standard detectors cannot be modified by users. Only enabling or disabling is allowed."

What did work was a new custom detector: same detector type, the same 50 pre-packaged rule IDs copied from the standard one, and the exact per-tenant stream name as input. Events sent after it was created got findings again, in 62 to 123 seconds across four test events (polling every 20 seconds). The custom detector survived a manager restart and a forced content resync that rewrote the standard detectors.

The catches we hit with that workaround:

• Wildcards are rejected for these doc-level monitors too ("Index patterns are not supported for doc level monitors"), so you need one input entry per tenant stream.
• The stream has to exist before you can add it: pointing a detector at a stream that has no events yet returns "Indices not found".
• Events that arrived before the custom detector existed were never back-filled.
• The copied rule list is fixed. When the content updates add or remove rules in the standard detector, your copy will not follow.
• Findings for the tenant stream still land in the shared wazuh-findings-v5-system-activity stream, so findings are not split per tenant.

What we did not test

Other detectors that also read system-activity (linux, auditd, wazuh-fim and others), a real content update that changes the rule set, an indexer restart, and the GA release. We will rerun this when 5.0 GA ships.

If you plan the upgrade

Before moving a multi-tenant setup to 5.0, check two things on a test manager: whether your tenant key is still present in the event, and whether events in each tenant's stream produce findings. A per-tenant index that fills up nicely while detection stays silent looks healthy on every dashboard.

If you run Wazuh for several customers and want your own layout checked on 5.0 before you upgrade, write to [email protected].