How to check if it is this
- The kernel saw a segfault in analysisd:
The reporter on issue 39928 (4.14.5-1, Ubuntu 24.04) saw lines likejournalctl -k | grep 'wazuh-analysisd.*segfault' # or dmesg -T | grep 'wazuh-analysisd.*segfault'wazuh-analysisd[...]: segfault at … ip 000000000041e5a0 … error 6 in wazuh-analysisd[400000+12a000], three of four crashes at the same instruction pointer. The address will differ between builds; what matters is that it iswazuh-analysisdand that it repeats. - It followed a reload, not a restart. 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 is 4.13.0 or later.
/var/ossec/bin/wazuh-control infoprints it.
Why it happens (the maintainer’s analysis)
On 28 October 2026, Wazuh maintainer vikman90 wrote on the issue, from the reporter’s core dump, that this is “a race condition in the ruleset hot reload, introduced in 4.13.0”. In short, 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 and added to the old event list.
os_remove_eventlist()frees that list without taking its mutex, and dereferences an event that is no longer valid (src/analysisd/eventinfo_list.c:120in their symbolized backtrace for 4.14.5-1).
They add that the more events are in flight during a reload, the wider the window, which may explain why it shows up on a high-volume syslog node.
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.
What we measured (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 wazuh-analysisd: INFO: Reloading ruleset followed by wazuh-analysisd: INFO: 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. So 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.
What to do until a fix ships
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.”
Fix status, checked 31 October 2026: 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 or the 4.14.10 branch, and 4.14.11 has no release yet. Until you run a release that contains it:
- Apply rule changes with a full restart, in a quiet window:
The/var/ossec/bin/wazuh-analysisd -t && systemctl restart wazuh-manager-ttest first means a broken rule file stops you before the restart, not after. Measured: we changed a custom rule from level 5 to 12,wazuh-analysisd -tprinted nothing and exited 0, we restarted, andwazuh-logtestmatched the edited rule at level 12. (Our lab container has no systemd, so we restarted with/var/ossec/bin/wazuh-control restart; on a package install, use systemctl.) - Avoid the dashboard and API reload on the affected nodes until you are on a fixed release. On a cluster, that includes
PUT /cluster/analysisd/reload. - Bring a dead daemon back automatically while you wait. A cron entry running
/var/ossec/bin/wazuh-control startevery minute is meant to restart a daemon that died. Measured: with analysisd killed,wazuh-control startstarted 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. This matches the workaround we suggested on the issue on 15 October, before the cause was known.
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, as the reporter on the issue did.
We did not reproduce the crash
20 API reloads, about 5 seconds apart, while the manager processed about 470 events per second of syslog (measured from wazuh-analysisd.state, 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.
Limits of what we measured
The cause, the affected code path and the version it came in are the Wazuh maintainer’s analysis of the reporter’s core dump, quoted from the issue; we have not verified them against the source. The fix status and the description of the fix are read from GitHub on 31 October 2026.
Our lab: one wazuh/wazuh-manager:4.14.8 container (it reports version v4.14.8, revision rc2), no agents and no indexer, measured on 31 October 2026. The crash in the section above is simulated with kill -SEGV, not the race itself, and produced no core dump. We had no 4.14.10-rc2 build to test.