Wazuh: wazuh-analysisd segfault after a ruleset reload (4.13 and later)

You edit rules, save, reload the ruleset from the dashboard or the API, and shortly afterwards wazuh-analysisd dies with a segmentation fault. A full restart with the same rules is fine.

Check if it is this

The kernel saw a segfault in analysisd:

journalctl -k | grep 'wazuh-analysisd.*segfault'
# or
dmesg -T | grep 'wazuh-analysisd.*segfault'

The reporter on wazuh/wazuh issue 39928 (4.14.5-1) saw lines like wazuh-analysisd[...]: segfault at ... error 6 in wazuh-analysisd[...], with three of four crashes at the same instruction pointer. The address will differ between builds. What matters is that it is wazuh-analysisd and that it repeats.

Then compare the crash time with when rules were saved and reloaded. A crash a few seconds to minutes after a reload, and none after a full restart, is the pattern in the issue. Your version should be 4.13.0 or later; /var/ossec/bin/wazuh-control info prints it.

Why it happens

According to the Wazuh maintainer who analysed the reporter's core dump, on 28 October 2026, this is "a race condition in the ruleset hot reload, introduced in 4.13.0". As they describe it, w_hotreload_reload() takes the ruleset lock as writer, switches the global ruleset pointers, releases the lock, and then frees the old ruleset. The event processing threads never take that lock, so events already in flight keep being matched against the old ruleset. os_remove_eventlist() frees that list without taking its mutex and dereferences an event that is no longer valid. The more events in flight during a reload, the wider the window.

This is the maintainer's analysis, quoted from the issue. We have not verified it against the source.

Which reload

Per the same comment, only the API path reaches the hot reload: PUT /manager/analysisd/reload and PUT /cluster/analysisd/reload, which the dashboard uses. wazuh-control reload does not hot reload; it restarts the services.

We measured this on the wazuh-manager 4.14.8 Docker image, which reports revision rc2. After PUT /manager/analysisd/reload, wazuh-analysisd kept the same PID and ossec.log showed "Reloading ruleset" followed by "Ruleset reloaded successfully". After wazuh-control reload, every daemon we checked except wazuh-execd came back with a new PID, and analysisd was down for about 9 seconds. If your crashes line up with the dashboard or the API, it is the hot reload path. If you only ever use wazuh-control reload, it is probably something else.

Fix status

Pull request 40907, "Fix analysisd crash when reloading the ruleset under load", was merged on 30 October into the 4.14.11 branch and the issue was closed. According to the pull request, the rule matching threads now take a lock that the reload waits for, so the old ruleset is freed only when no event is still using it. We have not tested the fixed build. The merge commit is not in v4.14.10-rc2, and 4.14.11 has no release yet.

What to do until then

Before the fix, the maintainer wrote: "We'll work on a fix for 4.14.x. Until then, apply ruleset changes with a full restart (systemctl restart wazuh-manager) instead of a reload."

/var/ossec/bin/wazuh-analysisd -t && systemctl restart wazuh-manager

The -t test first means a broken rule file stops you before the restart, not after. We changed a custom rule from level 5 to 12, wazuh-analysisd -t printed nothing and exited 0, we restarted, and wazuh-logtest matched the edited rule at level 12. Our lab container has no systemd, so we restarted with /var/ossec/bin/wazuh-control restart.

Avoid the dashboard and API reload on affected nodes until you run a release that contains the fix. On a cluster, that includes PUT /cluster/analysisd/reload.

To bring a dead daemon back automatically, a cron entry running /var/ossec/bin/wazuh-control start every minute is meant to do that. With analysisd killed, wazuh-control start started only analysisd, with a new PID, and left every other daemon on its existing PID. We tested this after one simulated crash, not over days. Pause it during planned maintenance, or it will start daemons you stopped on purpose.

A crash is silent

We killed wazuh-analysisd with kill -SEGV in the lab to see what a crash looks like from the outside. In the next 20 seconds ossec.log got no line at all, nothing restarted it, and every other daemon kept running with the same PID. Only wazuh-control status showed that analysisd was gone. The manager looks alive while no rule is being evaluated, and nothing in the log says so. If you cannot avoid reloads yet, alert on analysisd being down.

We did not reproduce the crash

We ran 20 API reloads, about 5 seconds apart, while the manager processed about 470 events per second of syslog, measured from wazuh-analysisd.state, with 0 events dropped. analysisd survived all 20. That does not mean your node is safe. The maintainer's analysis says the window grows with the number of events in flight, and our lab was small: one manager, no agents, the default ruleset plus one custom rule. We did not test large rulesets or many CDB lists, more event threads, reloads less than a second apart, more than 500 events per second, a cluster, or events arriving from agents. The crash in the silent-crash test is simulated with kill -SEGV, not the race itself.

Full write-up, including the fix status as read from GitHub on 31 October 2026: https://atkvn.com/fix-wazuh-analysisd-segfault-after-rule-reload.html