Node-RED flaw exploited: why *incident logs* matter as much as patching

What happened

On 3 November 2026, researchers disclosed active exploitation of CVE-2026-58115, a critical vulnerability in Node-RED, a flow-based programming tool used in industrial control systems, building automation and healthcare monitoring. ^[1] Attackers are using it to deploy Linux bots and backdoors on unprotected servers.

Node-RED sits inside products from major automation vendors and is often installed on Raspberry Pi devices in manufacturing, hospitals and smart buildings. That makes it a target, and it makes the question of when operators became aware, and what they did, a regulatory one.

The evidence question

Reporting deadlines are counted from when you became aware of the incident, not from when it happened.

Under the Swedish Cybersecurity Act, which implements NIS2, essential and important entities must send an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours and a final report within one month. ^[2] For manufacturers, the CRA requires reporting actively exploited vulnerabilities from 11 September 2026, with a preliminary report within 24 hours from becoming aware. ^[3]

It's like when you lose your bank card. The clock starts when you notice it's gone, not when someone actually stole it. And you'll need to show you noticed when you say you did.

Why logs matter as much as patches

Patching closes the vulnerability. Logs are what tell a supervisor, an auditor or a court when you knew about it and what you did.

A patch log shows when the update was applied. But that doesn't prove when you first became aware of the vulnerability, or whether the log itself has been edited since. When a question comes six months later, you need a record of each step that nobody can quietly change: when the vulnerability was first flagged internally, when it was escalated, when the patch was applied and when the reports were sent.

That's where the tampering question comes in. A log you can edit is a diary. A log you can prove hasn't changed is evidence.

How a digital witness fits here

In this case, the thing to seal is each step of the incident timeline: the first detection note, the decision to escalate, the patch deployment record and each report as it is sent to the supervisor or ENISA's reporting platform.

Sealing takes a fingerprint of the record, not the record itself, so nothing leaves your systems. The fingerprint goes to WitniumChain, which gives you a witness ID back. If the record is questioned later, anyone you share it with can calculate the fingerprint again and compare it with the sealed one. A change of a single character makes the fingerprints stop matching.

It doesn't show that the incident was handled well, or that the report was complete. What it does is give you a record of when each step was taken, in a way that holds up when someone asks.

How it would work

1. Seal the first detection note when vulnerability CVE-2026-58115 is flagged.
2. Seal the escalation decision and the patch deployment log as they happen.
3. Seal each report (early warning, notification, final report) when it is sent.

You can do this through the REST API, the SDK or the MCP server. The first 2,000 witnesses a month are free.

What this means for you

If your organisation uses Node-RED or similar tools in production:

• Can you show when you became aware of CVE-2026-58115, and when you patched it?
• If a supervisor asked in six months whether you met the 24-hour or 72-hour deadline, do you have a record that nobody could have quietly changed?
• Do the people who keep your incident logs have the access to change them?

Those are the questions worth asking before the next incident, not during it.

What to watch

11 September 2026: the CRA's reporting requirements for actively exploited vulnerabilities apply from this date. ^[3]

15 January 2026: the Swedish Cybersecurity Act's incident reporting requirements applied from this date. ^[2]