Wazuh 5.0 will not load custom XML rules; 82% of one public pack uses dropped chaining

Wazuh 5.0, currently in pre-release, will not load the custom XML rules and decoders that 4.x deployments rely on, and no automatic converter exists to move them across. According to an analysis published on dev.to by Dong Nguyen of ATK New Technology, this is not an edge case: in one public community ruleset, 82% of rules depend on syntax the new version removes.

What 5.0 drops

The findings come from the migration guides shipped with the latest pre-release tag, v5.0.0-beta5. Those guides state that custom rules and decoders from 4.x cannot be migrated by copying XML files to the manager; the directories etc/rules/, etc/decoders/ and etc/lists/ no longer exist in 5.0, and a leftover ruleset block in the configuration is treated as a startup error.

Decoders become YAML assets executed by a new engine, while rules become Sigma-style YAML documents stored in the indexer and managed through its content API. Along the way, several long-standing constructs disappear:

• Rule chaining via if_sid, if_group and if_level is unsupported; the guide describes 5.0 rules as self-contained.
• Correlation options, including if_matched_sid, frequency and timeframe, same_* and different_* conditions, and if_fts, are unsupported in rules, with correlation handled separately.
• List-based CDB lookups are unsupported in rules; the guide points to KVDBs at the decoder level.
• The time, weekday and check_diff elements are unsupported, and the options and var elements have no direct equivalent.
• Match and regex conditions no longer search the raw log; 5.0 rules match fields of the normalized event, with event.original as a fallback.

Decoders lose ground too. The guide lists plugin_decoder, accumulate, fts, _null_field, type, use_own_name and the pcre2 and offset options as unsupported, because 5.0 parses with its own field-extraction language rather than regex.

No converter, and the rewrite is on you

The migration guide states that there is no automatic conversion tool and that rules must be rewritten manually. A manager migration issue on the project tracker, number 39109 and closed on 28 September, puts rules, decoders, CDB lists and anything the engine changed structurally out of scope, and leaves the translation to users. The migration tool merged under PR 39197 moves agent keys, groups and API users — not detection content.

Measured impact on a real ruleset

To size the blast radius, the dev.to author ran a static count over the public SOCFortress Wazuh-Rules set: 75 XML files containing 2,211 rules and 105 decoders. The results:

• 1,804 rules, or 82%, use chaining through if_sid, if_group or if_level.
• 8 rules, under 1%, use correlation features such as frequency or same_* conditions.
• 3 rules, under 1%, use CDB lookups or check_diff.
• 399 rules, 18%, need only a format rewrite.

Chaining is the dominant idiom in 4.x content, where a child rule refines a stock parent. Under 5.0, each of those rules must carry its own complete condition, written against normalized field names rather than a parent's decoded fields.

Timeline and upgrade path

v5.0.0-beta5, tagged on 1 September, is the newest 5.0 release, and the 5.0.0 branch already carries an rc1 stage marker. No general availability date has been announced. There is no in-place upgrade from a 4.x manager; the configuration guide describes 5.0 as a fresh install.

Until teams move, 4.x keeps loading XML as before, quirks included. One detail the author measured: wazuh-analysisd surfaces at most 50 load warnings at startup, so teams still writing 4.x rules should validate them before restarting a manager.

The analysis has stated limits. Everything about 5.0 comes from the beta5 migration guides and the linked issue and PR rather than a running 5.0 engine, a pre-release can change before general availability, and the rule counts are a static reading of the XML rather than a runtime measurement.

Why it matters

Few teams run Wazuh on stock content alone; custom rules and community packs carry much of the detection value. As documented, 5.0 turns an upgrade into a content migration project with no converter, no chaining and no in-place upgrade path. Ops teams should inventory their rules now, count how many lean on if_sid-style chaining, and budget the rewrite before committing to a 5.0 deployment. The 82% figure comes from a single ruleset, but child rules refining parents is how Wazuh content has been written for years, so the pattern likely generalises.