The rule fired, the alert is in alerts.json, and the block did not happen. This line is written by a Wazuh active response, not by the rule engine. There are two different cases. In the first, the alert had no usable source IP in the places the script reads. In the second, on Windows agents, measured on 4.14.7, netsh.exe and route-null.exe wrote this line for every alert we sent, including one with a valid data.srcip: the IP was there and was still rejected.

Case 1 below is built from reading the Wazuh 4.14.7 source and the public documentation. The Windows case was measured on a Windows 11 agent.

Check it in one minute

The message goes to the active response log of the host where the response ran, the agent or the manager depending on location:

grep "Cannot read 'srcip'" /var/ossec/logs/active-responses.log | tail -n 5

Then look at what triggers the response. On the manager:

grep -A8 '<active-response>' /var/ossec/etc/ossec.conf

If it is bound by level or rules_group, it runs for every matching rule, including rules whose events carry no IP.

To test the response directly, with an address you control (we used the documentation range), call it through the manager API:

curl -k -X PUT "https://<manager>:55000/active-response?agents_list=<agent id>" \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ -d '{"command":"!netsh.exe","alert":{"data":{"srcip":"203.0.113.78"}}}'

The leading ! runs the executable by name. With "command":"netsh" the 4.14.7 API answered "The command used is not defined in the configuration." (error 1652) because no active-response block used that command yet. On Windows the log is C:\Program Files (x86)\ossec-agent\active-response\active-responses.log.

Why it happens (case 1)

In 4.14.7 the response reads the source IP with get_srcip_from_json() in src/active-response/active_responses.c. Reading the code, it does this, in order:

  1. It needs parameters.alert.data in its input to be an object. If not, there is no IP.
  2. If data.win.eventdata.ipAddress is a string, that is the candidate. If not, it tries data.win.eventdata.destinationIp.
  3. Only if neither Windows field is a string does it read data.srcip.
  4. The candidate must parse as an IPv4 or IPv6 address. If it does not, there is no IP. There is no fall-back to the next field.

When nothing comes back, firewalls/default-firewall-drop.c writes this line to logs/active-responses.log and exits with an error:

Cannot read 'srcip' from data or invalid IP format

So there are three practical causes. The event has no srcip: the decoder for that source does not extract one, or it lands under another name. The JSON decoder keeps the key's own name (we saw this in wazuh-logtest on 4.14.7 with Nextcloud and Office 365 events), so an address under a key such as src_ip becomes data.src_ip, which this function does not read. The field exists but is not an IP address, for example a host name. Or, on Windows events, win.eventdata.ipAddress is present as a string but is not a valid address, and the function returns nothing without trying destinationIp or data.srcip.

The message does not mean your rule failed. The rule matched, the alert was written, and only the response step found nothing to act on.

Fix (case 1)

Bind the response only to rules whose events carry an address. Use rules_id, which the documentation describes as limiting the command to when the listed rules fire, instead of a level or group that also catches rules without an IP:

<active-response> <command>firewall-drop</command> <location>local</location> <rules_id>100100</rules_id> <!-- your rule ID(s) --> <timeout>600</timeout> </active-response>

Then make the decoder name the field srcip for the sources you want to block on. For a regex decoder, order maps each capture group to a field name, and srcip is one of the names it accepts. Test the decoder with wazuh-logtest and confirm srcip appears in the decoding phase before relying on the response. Finally, check the value is an address: if the field holds a host name or a placeholder, the response cannot use it, whatever the binding.

Windows agents (4.14.7, measured): every IP fails

From a 4.14.7 manager we sent active responses to a Windows 11 agent running 4.14.7, through the API as shown above, and read the agent's active-responses.log. For both netsh.exe and route-null.exe, an alert carrying only data.win.eventdata.ipAddress = 203.0.113.77 gave "Cannot read 'srcip' from data", and so did an alert carrying only data.srcip = 203.0.113.78. Word for word, from the agent:

2026/10/03 19:51:29 active-response/bin/netsh.exe: Cannot read 'srcip' from data 2026/10/03 19:51:39 active-response/bin/route-null.exe: Cannot read 'srcip' from data

The data.srcip row rules out the field name: a plain, valid address was rejected too. Afterwards there was no Wazuh firewall rule and no route for either address on the machine. The Windows responses print the short form of the message, without "or invalid IP format".

Why, from the code: at v4.14.7, netsh.c (line 76) and route-null.c (line 29) both call get_srcip_from_json(), which checks the address with get_ip_version(), which calls getaddrinfo() (active_responses.c, line 576). We found no WSAStartup call in active_responses.c, netsh.c or route-null.c; on Windows, the socket functions need it first. That fits the cause proposed in wazuh/wazuh issue 38739, still open. This is our reading of the code plus the result above, not a debugger run.

Workaround: we found no central workaround you can apply from the manager. The check fails before netsh runs, whatever field carries the IP, and the binding and decoder fixes above do not change that on Windows.

Limits of what we measured

For case 1 we have not triggered the message on a running Linux agent or manager, and have not measured which releases print the shorter text. The Windows case was measured on one Windows 11 Pro agent running 4.14.7 with a 4.14.7 manager, by calling the responses through the API; we did not measure 4.14.8 or earlier releases, and the WSAStartup explanation is from reading the code, not a debugger.

Full write-up with the lab output: https://atkvn.com/fix-cannot-read-srcip-from-data.html