Wazuh 5.0 is a rebuild rather than a point release. Filebeat is gone, the manager lives in /var/wazuh-manager/, agents speak HTTPS on port 1517, XML rules are replaced by Sigma YAML evaluated on the indexer, alerts for rule matches are now called findings, and there is no in-place upgrade from 4.x. This page is the change inventory, organised by what each change costs an operator rather than by which component the release notes filed it under.
Release status
The newest published build is beta5, dated 1 September 2026. There is no release candidate on GitHub and Wazuh has not announced a general availability date. The 5.0 documentation site carries the banner “This documentation covers an upcoming release that is still under development”. Everything below comes from that beta documentation and from the migration guides in the Wazuh repository, so re-check anything load-bearing at GA. The 4.x branch is still maintained in parallel. Nothing else on this page depends on the release date.
What you need
- Familiarity with a working Wazuh 4.x deployment. If you are new to Wazuh, start with how the components fit together.
- The ports, paths and log file reference open in a second tab. This page explains the changes; that one is the lookup table.
- Coming from the previous lesson on AI-assisted triage of findings? The field and index names below are what that pipeline reads.
Architecture: four components, one fewer moving part
The component list is unchanged on paper: agent, manager, indexer, dashboard. What changed is the wiring between the manager and the indexer.
In 4.x the manager wrote alerts to alerts.json and Filebeat shipped that file to the indexer. In 5.0 the manager holds a client library called the Wazuh indexer connector, which forwards processed events, inventory data and vulnerability state straight to the indexer over TLS on port 9200. Filebeat is not installed and the manager no longer stores alerts at all.
Two consequences follow, and both bite in production. First, every Filebeat-era troubleshooting habit is dead: no Filebeat service to restart, no registry file, no filebeat test output. Second, the manager’s disk requirement drops but its dependency on indexer availability rises, because there is no on-disk spool file acting as a buffer that you can inspect.
The manager itself is also a cluster by default. Every install is a one-node cluster, <cluster> is a required section in the configuration, and <cluster><key> cannot be omitted.
Paths, config file and service names
Everything under /var/ossec/ moved, and the rename is not cosmetic. Scripts, monitoring checks, backup jobs and Ansible roles all break.
| Item | Wazuh 4.x | Wazuh 5.0 |
|---|---|---|
| Install path | /var/ossec/ |
/var/wazuh-manager/ |
| Main config | etc/ossec.conf |
etc/wazuh-manager.conf |
| XML root element | <ossec_config> |
<wazuh_config> |
| Internal options | etc/internal_options.conf and etc/local_internal_options.conf |
etc/wazuh-manager-internal-options.conf |
| Manager log | logs/ossec.log |
logs/wazuh-manager.log |
| Manager JSON log | logs/ossec.json |
logs/wazuh-manager.json |
| System user and group | wazuh |
wazuh-manager |
The file is also parsed differently. Wazuh 5.0 validates wazuh-manager.conf against a JSON Schema at etc/wazuh-manager.schema.json, and bin/wazuh-manager-conf validate reports the same verdict the daemons apply. Things the 4.x parser tolerated are now fatal: multiple sibling root blocks, the legacy <! ... !> comment form, raw & or < inside values, <var> definitions, and any unknown option. bin/wazuh-manager-conf dump prints the effective document after schema defaults, which is the fastest way to see what the daemons believe.
The manager configuration is much smaller
wazuh-manager.conf now accepts ten sections only: global, logging, remote, auth, indexer, vulnerability-detection, agent-upgrade, task-manager, wdb and cluster. The whole file fits on a screen. The <global> section that ships on beta5 carries two elements, not one:
<global>
<agents_disconnection_time>15m</agents_disconnection_time>
<agents_disconnection_alert_time>0</agents_disconnection_alert_time>
</global>The migration guide marks <agents_disconnection_alert_time> as going. Beta5 still ships it, set to 0, so treat both as present today and plan for the alert timer to leave at some point. <agents_disconnection_time> defaults to 15 minutes and is the one that decides when an agent is marked disconnected.
Everything that used to describe endpoint behaviour is gone from the manager. <syscheck>, <rootcheck>, <sca>, <localfile>, the syscollector wodle, <command> and <active-response> are configured on the agent or pushed through a group’s shared agent.conf. <alerts>, <ruleset>, <integration>, <email_alerts> and <syslog_output> have no manager-side equivalent at all.
The migration guide is precise about the consequences, and they are not uniform. <alerts>, <command> and <ruleset> cause a startup error if you leave them in. <rootcheck>, <syscheck>, <localfile> and the syscollector and open-scap wodles are silently accepted and do nothing, which is worse, because the deployment looks healthy while collecting nothing.
Agent protocol and enrolment
The agent to manager channel is now HTTPS.
| Port | Transport | Purpose |
|---|---|---|
| 1517/TCP | HTTPS, TLS | Wazuh 5.x agent enrolment and connection |
| 1514/TCP or UDP | Wazuh message protocol, AES | Wazuh 4.x agent connection |
| 1515/TCP | Wazuh message protocol, AES | Wazuh 4.x agent enrolment |
| 1516/TCP | Wazuh cluster protocol | Manager cluster communication |
| 55000/TCP | HTTPS, TLS | Manager API |
| 9200/TCP | HTTPS, TLS | Indexer API |
| 9300 to 9400/TCP | TLS | Indexer cluster communication |
| 443/TCP | HTTPS | Dashboard web interface |
A 5.0 agent uses four endpoints on 1517: POST /enroll, POST /stateless for events, POST /stateful for inventory synchronisation, and POST /control for pending work such as active response tasks. Each request carries a per-agent JWT bearer token that the agent signs with its client.keys key, and the manager also checks the request source address against the client.keys entry.
The legacy 1514 channel is served by the <legacy> block inside <remote> and is enabled in the shipped default configuration. Verified on beta5: the stock file contains <legacy><enabled>yes</enabled> with <port>1514</port>, <protocol>tcp</protocol> and <local_ip>0.0.0.0</local_ip>, <auth><port>1515</port> is present, and the manager listens on 1514, 1515, 1516, 1517 and 55000 out of the box. Turn the legacy block off and only 5.x agents can connect, which is a useful hard cutover switch at the end of a migration.
The <remote><https> block in the same file sets <bind_addr>0.0.0.0</bind_addr> and <global_prefix>/wazuh-manager/</global_prefix>, so the agent listener is reachable from anywhere the network allows, and every request path carries that prefix. A probe at the root returns {"error":"not_found"} while /wazuh-manager/ returns {"status":"ok","module":"remoted"}, which is the health check to give a load balancer.
Three changes trip people up:
- Enrolment needs a password by default. The manager generates it at first start and stores it at
/var/wazuh-manager/etc/authd.pass. You copy it to each agent. In 4.x password enrolment was opt-in. - Groups must exist before the agent enrols. The agent declares its groups in
<enrollment><groups>, the manager validates them, and an unknown group means the enrolment is rejected outright. The checksum-based group guessing of 4.x, controlled byremoted.guess_agent_group, has been removed. - The agent config block was renamed.
<client><server>becomes<agent><manager>. An upgraded agent that still has a<client>block keeps connecting, because the address and the<enrollment>sub-block are read as a fallback, but every other option in that block stops taking effect.
Enrolment now negotiates TLS 1.3 only. The manager validates <auth><ciphers> against a fixed list of TLS 1.3 ciphersuite names, so a 4.x-style OpenSSL cipher string is rejected at config load, and <auth><ssl_auto_negotiate> was removed entirely.
The detection model is the biggest change
In 4.x one daemon decoded events and matched XML rules in the same pass, on the manager. In 5.0 those two jobs live in different products.
Decoding and normalisation happen on the manager. wazuh-manager-analysisd now runs the normalization engine. Decoders are YAML, parse with logpar expressions rather than regular expressions, can declare hierarchical parents:, and normalise output into the Wazuh Common Schema. Enrichment runs in the same pipeline and adds geolocation and ASN context on source.ip and destination.ip, plus threat intelligence matches under wazuh.threat.
Detection happens on the indexer. Rules are Sigma YAML with Wazuh extensions, stored as documents in the wazuh-threatintel-rules-a index rather than as files on disk. Rule IDs are UUIDs assigned on creation. Severity is a keyword, one of informational, low, medium, high or critical, in place of the 0 to 16 integer. MITRE and compliance mapping are structured objects instead of strings packed into <group>. Rules are evaluated by detectors, scheduled jobs that run at an interval you choose, and a match writes a finding, an enriched copy of the event, into a findings data stream.
Four 4.x features have no equivalent in the rule format:
if_sid,if_group,if_levelandif_matched_sidrule chaining. Each 5.0 rule is self-contained.frequency,timeframe,same_*anddifferent_*correlation.<list>CDB lookups inside rules. Lookups moved into decoders and CDB lists became KVDBs, using helpers such askvdb_matchandkvdb_get.<time>and<weekday>conditions.
Content is packaged as integrations, each bundling decoders, rules and KVDBs under one category, and each integration’s category decides which data stream its events and findings land in. Content lives in Spaces: Standard is read-only content shipped by Wazuh, and user content is promoted Draft to Test to Custom. Only Custom and Standard content can be attached to a detector.
Indices, data streams and field names
The Setup plugin on the indexer creates every template, policy and stream. There is no wazuh-alerts-* index in 5.0.
A stock beta5 install creates 22 data streams. Grouped, and with the retention its Index State Management policies apply:
| Data stream | Holds | Default retention |
|---|---|---|
wazuh-events-raw-v5 |
Incoming events before processing | 10 minutes |
wazuh-events-v5-<category> |
Normalised, categorised events | 1 hour |
wazuh-findings-v5-<category> |
Findings from detector rule matches | 90 days |
wazuh-active-responses |
Active response execution requests | 3 days |
wazuh-metrics-agents |
Endpoint operational metrics | 30 days |
wazuh-metrics-comms-v4 |
Manager communication and performance metrics | 30 days |
wazuh-metrics-normalization |
Normalisation engine metrics | 30 days |
wazuh-ai-assistant-sessions |
AI assistant conversations | rolls at 1 day, deleted at 7 |
Two names in that table catch people out. The communications metrics stream is wazuh-metrics-comms-v4, with a version suffix the other metrics streams do not carry, and there is a third metrics stream for the normalisation engine that the documentation barely mentions.
Categories are security, system-activity, access-management, applications, network-activity, cloud-services, other and unclassified. Eight of them, and cloud-services is a single stream on beta5 rather than splitting per provider. Data streams roll over at 20 GB primary shard size or 200 million documents, whichever comes first, and Index State Management handles deletion.
Current state lives in separate stateful indices rather than in streams: wazuh-states-sca, wazuh-states-fim-files, wazuh-states-fim-registry-keys, wazuh-states-fim-registry-values, wazuh-states-vulnerabilities, and a wazuh-states-inventory-* family covering users, groups, packages, processes, services, ports, networks, interfaces, protocols, hardware, system, hotfixes and browser extensions.
Field names follow the Wazuh Common Schema. The renames that break the most saved searches:
| Wazuh 4.x field | Wazuh 5.0 field | Note |
|---|---|---|
rule.level |
wazuh.rule.level |
Integer becomes a keyword |
rule.description |
wazuh.rule.title |
|
rule.id |
wazuh.rule.id |
Numeric becomes UUID |
agent.name |
wazuh.agent.name |
|
agent.id |
wazuh.agent.id |
|
full_log |
event.original |
|
data.srcip |
source.ip |
|
syscheck.path |
file.path |
|
timestamp |
@timestamp |
|
location |
wazuh.protocol.location |
Split across several fields |
rule.groups |
no direct equivalent | Use wazuh.integration.name, tags and the compliance object |
Daemons, tools and features that are gone
Count the daemons on the machine rather than in the release notes. On beta5:
/var/wazuh-manager/bin/wazuh-manager-control statuswazuh-manager-clusterd is running...
wazuh-manager-modulesd is running...
wazuh-manager-monitord is running...
wazuh-manager-remoted is running...
wazuh-manager-analysisd is running...
wazuh-manager-db is running...
wazuh-manager-authd is running...
wazuh-manager-apid is running...Eight, and wazuh-manager-monitord is one of them. The GitHub migration guide says monitord is going, with its work (agent disconnection detection, deletion of long-disconnected agents, log rotation) moving into the Task Manager inside wazuh-manager-modulesd, and its monitord.* internal options renamed into the wazuh_modules namespace, for example monitord.rotate_log becoming wazuh_modules.manager_task_log_rotate. Beta5 still ships the daemon and still starts it. Write your monitoring against what your own build runs, and note that an override left under the old name is silently ignored rather than rejected, so the compiled default quietly applies either way.
Gone from the manager, and confirmed absent on beta5: the mail daemon, the client syslog daemon, the agentless daemon, the database output daemon, and integratord. /var/wazuh-manager/bin holds sixteen entries and none of them is manage_agents or agent-auth:
agent_groups
agent_upgrade
cluster_control
rbac_control
verify-agent-conf
wazuh-manager-analysisd
wazuh-manager-apid
wazuh-manager-authd
wazuh-manager-clusterd
wazuh-manager-control
wazuh-manager-db
wazuh-manager-keystore
wazuh-manager-modulesd
wazuh-manager-monitord
wazuh-manager-remoted
wazuh-manager-service-controlThe agent side is different: /var/ossec/bin on a 5.0 agent still ships manage_agents. The removal is manager-side. The manager’s own syslog listener on port 514 is removed as well, so network devices that used to log straight to the manager need a collection host running rsyslog with a Wazuh agent reading the result. OpenSCAP and the CIS-CAT wodle are removed in favour of SCA, and the osquery wodle in favour of the inventory module.
On Windows the NSIS installer is gone: the agent ships as a single MSI. That one is from the documentation; the lab behind this page ran Linux agents only, so treat every Windows detail here as documented rather than verified.
Notifications: from integratord to Alerting plus Notifications
Third-party delivery moved off the manager entirely. The path in 5.0 is an Alerting monitor that queries an index on a schedule, a trigger with a condition, and an action that sends a message through a Notifications channel. Supported channel types include Slack, Microsoft Teams, email, generic webhooks, Amazon SNS and PagerDuty.
The message body is a Mustache template you write, so you control the payload completely instead of adapting to whatever an integration script emitted. Two limits shape the design: the Alerting module supports up to 10 custom monitors per user, and bi-directional integrations of the VirusTotal or Maltiverse kind are not supported by the Notifications plugin at all. Build monitors per severity band and route inside the automation platform, rather than one monitor per tenant or per rule. The walk-through is in setting up Wazuh notifications and webhooks.
Active response runs backwards now
In 4.x the manager decided and pushed. In 5.0 the indexer decides and the manager collects.
An Alerting monitor of the Wazuh-specific active response type writes a document into the wazuh-active-responses data stream. That document names the response, the executable, extra arguments, the location (local, defined-agent or all), the target agent, the type (stateless or stateful) and the stateful timeout. The manager polls the stream, creates a task per targeted agent, and the agent collects it on its next POST /control request.
Nothing fires by default, and active response is not available for 4.x agents connected to a 5.0 manager. My stance has not changed with the new plumbing: leave it off until a specific environment has been tuned and someone has signed off on what gets blocked. The failure modes are covered in when to leave active response off.
Supported operating systems and sizing
Central components run on 64-bit Intel, AMD or ARM Linux (x86_64/AMD64 or AARCH64/ARM64), on Amazon Linux 2023, Ubuntu 24.04 or 26.04, or Red Hat Enterprise Linux 9 or 10. That list is shorter than 4.x supported, and it is the first thing to check against your standard build image.
The manager wants a minimum of 8 GB RAM and 4 cores, with 16 GB and 8 cores recommended. Disk behaves differently: the manager no longer stores alerts, but the vulnerability feed alone needs at least 15 GB, so allocate at least 20 GB. For an all-in-one quickstart the documented tiers are 4 vCPU, 8 GiB and 50 GB for 1 to 25 agents, and 8 vCPU with 16 GiB for up to 100 agents.
Indexer sizing changes shape, because every event is indexed rather than only rule matches. Default retention on the raw and event streams is short precisely because of that. Sizing is covered in Wazuh system requirements and sizing.
API changes
The manager API stays on port 55000 with the same JWT flow: basic auth to POST /security/user/authenticate, then a bearer token with a 900 second default lifetime.
What survives: /agents/* including /agents/insert, /agents/{agent_id}/key, /agents/upgrade and the new /agents/enrollment-tokens; /groups/*; /cluster/*, which absorbed the old /manager/* family; /mitre/*; /security/*; and /overview/agents.
What is gone: /manager/*, /sca/{agent_id}, /syscheck, /rootcheck, /syscollector, /ciscat, /tasks, /active-response, /decoders, /rules, /lists, /logtest, /events and /vulnerability.
Those capabilities did not disappear, they moved to the indexer API on port 9200. State queries go against the wazuh-states-* indices. Content management lives under /_plugins/_content_manager/ with rules, decoders, integrations, kvdbs, filters, promote, space/{space} and a logtest pair at /logtest/normalization and /logtest/detection. Monitors and channels live under /_plugins/_alerting/ and /_plugins/_notifications/.
One behaviour of the Content Manager will bite the first script you write against it: on beta5 the collection endpoints are POST-only, and there is no list or read operation at all. A GET returns a 405 naming the method it does want:
{"error":"Incorrect HTTP method for uri [/_plugins/_content_manager/integrations] and method [GET], allowed: [POST]","status":405}A successful create answers with the new identifier in message and the status in the body rather than only in the response code. Posting a rule on the lab stack returned:
{"message":"38f90df3-ec85-4ee4-8d45-69bdc57b422d","status":201}That identifier is the only record you get, so your content pipeline has to keep its own. There is no endpoint that will list it back to you.
If you automate Wazuh, this is the change that costs the most code. Any rules-as-code pipeline now targets the indexer, not the manager. See the Wazuh API with Python for the request patterns.
Migration reality
There is no in-place upgrade. The official guide is blunt: 4.x environments cannot be upgraded in place, and you cannot copy 4.x configuration files into a 5.x installation.
What can be carried across, per the migration guide:
| Item | How |
|---|---|
| Indexed 4.x data | Snapshot and restore into 5.x, read-only, keeping 4.x mappings. Requires the source to be 4.4.0 or later |
| Agent registrations | Copy client.keys, import through POST /agents/insert on the 5.x API, preserving IDs and keys |
| Agent groups | Archive etc/shared/*/ excluding merged.mg, restore under /var/wazuh-manager/etc/ before any agent connects |
| Custom dashboards, visualisations, saved searches, index patterns | Saved-object export and import, then rewrite index patterns and field references |
| Indexer, manager and dashboard configuration | Read the 4.x file, recreate the setting by hand in the 5.x file |
| Security users, roles, role mappings, auth providers | Recreate by hand |
| Custom rules, decoders and lists | Re-author. No tooling exists |
Restored 4.x indices keep their old mappings and 5.x never writes to them, so they are a historical archive you query through a separate index pattern, not a continuation of your data.
The guide documents no rollback procedure. The rollback is keeping 4.x running until the 5.x deployment has been validated, which is why the parallel deployment is not optional. The step-by-step version of all of this is the 4.x to 5 migration runbook.
Common errors
(1244): Invalid configuration at '/auth/ssl_auto_negotiate': unknown option (does not satisfy 'additionalProperties') [schema /properties/auth]
Cause: a 4.x option that no longer exists was carried into wazuh-manager.conf. The schema rejects unknown options and the manager does not start. The same error format, with a different JSON pointer, appears for every unknown or duplicated element.
Fix: remove the named option. Run bin/wazuh-manager-conf validate before restarting to catch the rest in one pass, rather than one restart at a time.
ERROR: Invalid TLS 1.3 cipher suite 'HIGH' in 'ciphers' option
Cause: <auth><ciphers> still holds a 4.x OpenSSL cipher-list string. Enrolment in 5.0 is TLS 1.3 only and the option is validated against a fixed list of ciphersuite names.
Fix: set a colon-separated TLS 1.3 list, or remove the option to take the default TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256. Until this is fixed, wazuh-manager-authd does not start and no agent can enrol.
UPGRADE BLOCKED: Incompatible version detected
Cause: an agent package upgrade was attempted from a version older than 4.14.0 straight to 5.0.0. Pre-install validation stops it.
Fix: upgrade the agent to the latest 4.14.x first, confirm it starts cleanly, then upgrade to 5.0.0.
ERROR: Enrollment rejected by the manager: invalid request. Invalid Group(s) Name(s)
That is the agent’s log line. The manager logs the name it objected to: wazuh-manager-authd: ERROR: Invalid group: does-not-exist. Both strings are from the beta5 lab, and the agent stays at status='pending' while it retries.
Cause: the agent declared a group in <enrollment><groups> that does not exist on the manager. One unknown group rejects the whole enrolment, and the groups that do exist are not applied either.
Fix: create the group on the manager first, through the dashboard or POST /groups, then restart the agent so it re-enrols. Group handling is covered in agent groups and centralised configuration.
Where to read the primary sources
The change inventory above is compiled from the Wazuh 5.x migration guide and the architecture and component communication page, plus the per-topic guides in the Wazuh migration docs on GitHub, which go into more detail than the documentation site on configuration and rule conversion.
Next: Migrating Wazuh 4.x to 5: The Runbook.
Frequently asked questions
Is Wazuh 5.0 released yet?
As of September 2026 the newest published build is beta5, dated 1 September 2026. No release candidate has been published and Wazuh has not announced a general availability date. Treat every 5.0 detail as documentation for an unreleased version and re-verify it at GA.
Can I upgrade Wazuh 4.x to 5.0 in place?
No. The official migration guide states that 4.x environments cannot be upgraded in place. You deploy a new 5.x environment, recreate configuration and security settings, migrate agent registrations, and cut over. Only the agent packages support an in-place upgrade, and only from 4.14.0 or later.
What happened to Filebeat in Wazuh 5.0?
Filebeat is gone. The manager writes to the indexer through a built-in indexer connector library, configured in the indexer section of wazuh-manager.conf. The manager no longer stores alerts on disk, so there is no alerts.json to tail.
Are Wazuh alerts now called findings?
Yes, for rule matches. In 5.0 a decoded log is an event and an event that matches a Sigma rule becomes a finding. Events land in the wazuh-events-v5 data streams, findings in wazuh-findings-v5. The word alert still appears in the indexer Alerting module, which is a separate concept.
Do my Wazuh 4.x custom rules work in 5.0?
No. XML rules and decoders are replaced by YAML decoders and Sigma-format YAML rules, and there is no conversion tool. Custom content has to be re-authored by hand through the content management system. Budget for this before you plan a cutover date.