What Breaks in Your n8n Security Workflows When Wazuh Upgrades

2026-10-12 · Neetrox

You upgrade Wazuh on a Tuesday. The dashboard loads, the agents reconnect, the release notes said nothing scary. Two weeks later somebody asks why the weekly vulnerability report has been empty since the upgrade.

That is how a Wazuh upgrade breaks an n8n workflow most of the time. Nothing turns red. n8n shows green executions because every node did its job: the HTTP Request got a response, the IF node evaluated, the email went out. The response was an error page, the IF node found no matching rule ID, and the email said "0 findings".

We run Wazuh and n8n together every day and maintain 15 workflows on top of them, so we see each upgrade from the side that breaks. This post covers what changes underneath your workflows, a check you can run in 15 minutes after every upgrade, and how to make the next break fail loudly.

Why the failure is quiet

An n8n workflow talks to Wazuh in three places: the manager API on port 55000, the indexer (where alerts and, since 4.8, vulnerability states live), and the integrator daemon that pushes alerts to an n8n webhook. An upgrade can change any of the three, and the workflow only notices when a node throws an error.

Most of what changes does not throw. An endpoint that returns 404 inside a node with "Continue On Fail" turned on, a query that matches zero documents, a rule ID that no longer fires: to n8n, all of those are successful runs with less data.

1. API endpoints that move or disappear

The clearest example is Wazuh 4.8. Vulnerability detection was rebuilt, the /vulnerability endpoints were removed from the manager API, and findings moved to the indexer in the wazuh-states-vulnerabilities-* indices. The old <vulnerability-detector> block in ossec.conf became <vulnerability-detection>.

Any workflow that pulled vulnerabilities per agent from the API stopped getting them. If the HTTP Request node had error handling that swallowed the failure, the report kept arriving on schedule with nothing in it.

What to check: read the "API" and "breaking changes" sections of the release notes for every version between yours and the target, not only the target. Teams that skip from 4.7 to 4.9 still inherit the 4.8 changes.

2. Rules and decoders you edited in place

Upgrades replace the default ruleset under /var/ossec/ruleset/. If somebody fixed a noisy rule by editing the shipped XML file, that fix is gone after the upgrade and the noise comes back. Changes in /var/ossec/etc/rules/local_rules.xml and your own decoder files survive.

The workflow side of this is subtler. Plenty of n8n workflows route on rule.id, rule.groups or the text of rule.description. When a new ruleset version renumbers, splits or rewords a rule, the IF or Switch node that matched on it simply stops matching. The alert still reaches n8n and falls through the default branch.

What to check: list every rule ID and description your workflows filter on (search the workflow JSON for rule.id and rule.description), and confirm those rules still exist and still fire after the upgrade.

3. Custom integration scripts

If you followed our n8n and Wazuh integration guide, you have a custom-n8n wrapper and a custom-n8n.py sender in /var/ossec/integrations/, run by Wazuh's bundled Python. Two things deserve a look after an upgrade:

  • integratord refuses to run a script that is not owned by root:wazuh and executable. Confirm ownership and mode are still what you set

  • The script runs on the interpreter in /var/ossec/framework/python/, which the upgrade ships fresh. If you ever pip installed an extra package into it, check that it is still there

The sender in our guide only imports requests, which comes with the bundled Python.

What to check: grep -i integrator /var/ossec/logs/ossec.log right after the upgrade, then trigger a test alert above your integration level and watch it arrive in n8n.

4. Indexer queries, index names and fields

Workflows that query the indexer directly (threat hunting, monthly reports, dashboards) depend on index patterns and field names. Alerts live in wazuh-alerts-4.x-* today; the vulnerability data in point 1 is a case where the data moved to a different index entirely. Field names inside decoded events can also change when a decoder is updated, so a query on data.srcip returns nothing if the decoder now writes the address somewhere else.

What to check: run each saved query from your workflows by hand against the indexer after the upgrade, and compare the hit count with the week before. A query that dropped to zero is the one to look at first.

5. Authentication

n8n usually logs in to the API with a POST /security/user/authenticate and reuses the JWT. The token expires after 900 seconds by default, so a workflow that authenticates once and then works through a long list of agents can start getting 401s halfway. That is not upgrade-specific, but upgrades are when people notice, because they also tend to be when somebody rotates the API password or regenerates certificates. If your HTTP Request nodes pin a certificate or a CA, check them too.

Do not forget the n8n side

Upgrading n8n carries the same risk in the other direction. Existing nodes keep the node version they were created with, which protects you most of the time, but n8n publishes a breaking changes list with each release, and Code nodes that read environment variables or require external modules are the usual casualties. Upgrade n8n and Wazuh in separate maintenance windows, so when something breaks you know which side to look at.

A 15-minute check after every Wazuh upgrade

Run this before you close the change ticket. Replace the host and credentials with yours.

# 1. Confirm the API answers and reports the version you expect
TOKEN=$(curl -sk -u wazuh-api-user:PASSWORD -X POST \
  "https://WAZUH_MANAGER:55000/security/user/authenticate?raw=true")
curl -sk -H "Authorization: Bearer $TOKEN" "https://WAZUH_MANAGER:55000/" | python3 -m json.tool

# 2. Confirm the integrator started and found your script
grep -i integrator /var/ossec/logs/ossec.log | tail -20

# 3. Confirm script ownership and mode
ls -l /var/ossec/integrations/custom-n8n*

Then, in n8n:

  1. Open each workflow's last five executions and compare item counts with the same day last week. A node that used to output 40 items and now outputs 0 is your break

  2. Fire a test alert above your integration level and follow it through the webhook workflow end to end

  3. Run every scheduled workflow once by hand (report, hunt, health check) instead of waiting for its schedule

If you keep the workflow JSON in git, a diff of the rule IDs and endpoints it uses, before and after, takes a minute and tells you where to look.

Make the next break fail loudly

The check above catches problems on upgrade day. These two catch them on every other day:

  • An error workflow. In n8n, build a workflow that starts with the Error Trigger node and sends a message to Slack, email or your ticketing tool, then set it as the "Error workflow" in the settings of every production workflow. Turn off "Continue On Fail" on the nodes that talk to Wazuh, so an API error becomes an execution error instead of an empty result

  • A heartbeat. A scheduled workflow that checks when the alert webhook last received something, and alerts if it has been quiet for longer than your environment is ever quiet. If you see 200 alerts a day, six silent hours means something upstream broke

Our free Wazuh Agent Health Checker applies the same idea to agents: it checks every agent every 15 minutes and alerts when one goes quiet.

Who keeps your workflows current

If you built your own workflows, the checklist above is most of the job. Run it after every upgrade and you will catch the breaks before your manager does.

If you bought workflows from us, there are two ways to stop owning this:

  • Updates + Support, $39.99 a month. When a Wazuh upgrade or an API change breaks a workflow you bought, you get the fixed version, along with every other updated version we release, and email support answered within 2 business days. You install the updates yourself. Month to month, cancel anytime

  • Managed SOC Automation, $249 a month. We install the updates, watch the workflow runs, failures, credentials and integrations, and respond the next business day when something breaks. Updates + Support is included

Not sure which one fits? The services page compares them side by side, or book a 15-minute call and ask.

← Back to blog