Wazuh 5.0.0-rc2 was published on 30 October 2026. If you maintain custom 4.x rules and decoders, the question is whether anything we measured on rc1 moved. We re-ran all eight of those checks on rc2 in a lab with Docker, one manager, one indexer and one 4.14.7 agent. All eight came out the same. GA has not been released, so treat this as a release candidate and not a verdict.

1. The analysis binary has no 4.x rule keywords

We counted occurrences of if_sid, if_matched_sid, same_srcip and frequency in the rc2 wazuh-manager-analysisd binary with grep -a -o piped to wc -l. All four were 0. We also searched the rest of the rc2 bin and lib directories: if_sid, if_matched_sid and same_srcip appear in no file. The 4.14.7 binary contains all of them. We are not quoting its exact counts, because our counting method was not the same across runs.

2. Your XML files load without a word

We dropped 4.x rule, decoder and list XML into both the old etc directories and the new /etc/wazuh-manager, then restarted. The restart produced 116 new log lines (124 on rc1). Zero of them mentioned rules, decoders, lists or xml. wazuh-manager-analysisd -t returned 0 and wazuh-manager-conf validate returned 0. A passing config check does not tell you the rules are doing anything.

3. srcip is rejected as a field

Posting content that uses srcip to the content manager rules endpoint returned HTTP 400: "Error in Security Analytics. The following fields are not part of the Wazuh Common Schema (WCS): [srcip]". Same body, same message as rc1.

4. Unparsed lines are not indexed by default

index_unclassified_events is false in all four spaces (standard, custom, draft, test). We sent 16 log lines: 12 documents were indexed, and the 4 lines from our home-made app, which had no rewritten decoder, were in no index. On rc1 it was also 4 of 16.

5. Indexer flush is 20 seconds

From the binary, the default analysisd.indexer_flush_interval is 20 s, allowed range 1 to 3600. Measured delay from event to visible document was at most 20.2 s, with the sawtooth about 20 s apart. Setting it to 0 is now refused at config load ("Allowed range: 1 to 3600"), and afterwards the manager still listed analysisd as running; on rc1 the same setting stopped analysisd. The "5 s flush gives 7.1 s worst case" figure is from rc1 only. We did not re-run it on rc2.

6. Active response does not reach a 4.14.7 agent

A 4.14.7 agent enrolled and its events were indexed. We then triggered an active response through an indexer monitor. The manager created the task, and remoted logged: "task type 'active_response' not supported for legacy agents, not delivered". The agent's active-responses.log had no active response line. The rc2 release notes add an active response allowlist, which we did not test.

7. Frequency rules have no working replacement yet

Our 4.x frequency rule, rewritten as a Sigma aggregation rule, saved without complaint (HTTP 201). Creating a detector for it returned HTTP 500: "Cannot invoke "java.util.Map.containsKey(Object)" because "this.fieldMappings" is null", a NullPointerException. We tried three times, once after an attempt to add a field mapping, and got the same error each time, so the rule never ran. Two correlation rules also saved (HTTP 201), but after sending our 16 log lines three times and waiting 200 s there were zero correlation alerts. The stock ruleset raised no finding for our nine pre-auth SSH disconnects from one IP. All of this matches rc1. One small difference: the field-mapping request itself now returns HTTP 500, where rc1 returned 200; the detector fails either way.

8. A rewritten child rule fires next to its parent

In 4.x our child rule raised only the child alert for the root-login line. Rewritten in Sigma, with the parent's condition copied into the child, both matched: logtest on that line listed parent-100510 and child-of-100510-user-root, and the detector produced a finding for each on the same event. Same as rc1. In our runs that meant two findings for one event; we have not yet tested excluding the child's case from the parent.

What this does not cover

The "5 s flush gives 7.1 s worst case" figure in item 5 is from rc1 only. Untested on either release candidate: TLS with the security plugin on, multiple nodes, a 5.x agent, CDB lists in the new key-value store, and whether Sigma timeframe is honoured.

One change that will break lab scripts: the rc2 notes say manager configuration moved from /var/wazuh-manager/etc to /etc/wazuh-manager with no symlink, which broke our rc1 lab scripts until we fixed the paths.

What we can run for you and what it costs is on one page: https://vct.atkvn.com/wazuh-5-migration.html