Wazuh 4.14.7 caps rule-load warnings at 50, silently hiding ignored custom rules

Silent truncation of load warnings

When Wazuh loads a large custom ruleset, wazuh-analysisd -t and ossec.log will tell you that some rules are being ignored. What they will not tell you, according to a dev.to investigation by Dong Nguyen of ATK New Technology, is that the reporting stops after 50 messages. On Wazuh 4.14.7, anything past that limit is discarded, oldest first, and no log line anywhere records what was lost.

The author demonstrated the effect with a single file, etc/rules/local_rules.xml, containing 60 rules whose if_sid references pointed to rule IDs that do not exist. Every ignored rule generates two warnings — 7617 for the missing signature ID and 7619 for the resulting empty if_sid — so a complete run should have produced 120 warnings. Wazuh printed 50: twenty-five of each type, naming only rules 100835 through 100859. The other 35 rules, 100800 through 100834, were ignored in exactly the same way but never mentioned. The ossec.log output at a real manager start behaved identically, with reporting beginning at rule 100835.

The cap in the source

The post traces the limit to src/analysisd/logmsg.h, which defines ERRORLIST_MAXSIZE as 50 — the maximum size of the log messages list. Both analysisd.c and testrule.c call OSList_SetMaxSize with that value, and OSList_AddData in src/shared/list_op.c deletes the first node whenever the list outgrows its maximum. The result is a bounded list that retains the latest 50 entries and throws away everything older.

That design is defensible for a log. It becomes a real problem, the author argues, because this list is also the only place an operator learns that a rule they wrote will never fire.

Reproduced on a public ruleset

To rule out an artifact of the synthetic test, the author loaded the public SOCFortress Wazuh-Rules set — 69 rule files and 6 decoder files — into a clean 4.14.7 manager. The test run printed 52 warnings about ignored rules: fifty instances of warning 7610 for a missing if_group, plus one 7617/7619 pair. A static check of the same files found 55. The three unreported rules, IDs 900123 through 900125, carried the same missing if_group as the fifty that were reported and had simply fallen off the front of the list.

Why rules get ignored at all

Missing parents are not always typos. Wazuh loads the stock rule files together with files from etc/rules, sorted by file name, and a rule's if_sid target must already be loaded by the time the rule is read. The post's example: a rule in 0010-my_rules.xml that references sid 5715 is ignored, because that file sorts ahead of 0095-sshd_rules.xml, where the parent rule lives. The test command still exits 0, the manager starts normally, and the rule never fires. Renaming the file so it sorts after its parent — local_rules.xml does — makes it load. The same ordering constraint applies inside a single file, where a child rule placed above its parent is dropped.

Working around the limit

The post suggests three habits:

• Test custom files one at a time with wazuh-analysisd -t, so no single run can generate more than 50 messages.
• Count rather than scan: confirm that each rule ID you expect is absent from the ignored-rule lines, and treat any run that prints exactly 50 load warnings as incomplete.
• Check the rules statically before restarting. The author has published a free browser-based checker that predicts warnings 7610, 7612, 7613, 7617/7619 and 7620, along with manager-fatal mistakes such as broken XML and missing decoder parents. It was calibrated case by case against wazuh-analysisd -t on 4.14.7, matching on all 15 cases, and does not upload rule files.

Limits of the findings

The measurements were taken on Wazuh 4.14.7 manager containers only; other versions were not tested. The static checker inspects only the files it is given plus the stock 4.14.7 ruleset, and does not exercise rules against real events.

Why it matters

A detection rule that silently fails to load is a rule that will never raise an alert, and the operator has no reliable signal that it is dead. Worse, because the truncation drops the oldest warnings first, the messages that vanish come from the earliest-loaded rules — which, under filename-sorted load order, are likely to be custom files whose names sort near the front. Anyone operating a large Wazuh ruleset on 4.14.7 should assume load warnings are incomplete and verify custom rules independently of the 50-line output.