Sentinel's UI. Node Permissions, Network and CSP rules are added on a separate file called .sentinel-permissions.json to avoid exposing settings.js. All RED.* pass through sentinel's proxy and can't be monkey-patched by custom nodes or plugins anymore. This means you can now install unaudited packages without fearing exposing your data. Only admins have access to Sentinel.
Threats: all threats that Sentinel detected during startup and runtime.
In what circumstances would my Node-red installations benefit from this additional runtime security?
Who are the attackers you have protected from - my own staff / family , Internet based users of my dashboard, authorised but malicious logged-in editors?
You can install public plugins or nodes that havenât been audited without worrying about data exfiltration. Even if your Node-RED instance isnât exposed to the internet, attacks can still come from inside.
A malicious or compromised node can:
Modify the runtime
Alter other installed packages
Tamper with your flows without you noticing
Itâs even possible to reroute messages through âinvisibleâ wiresâlogic that doesnât appear in the editor or in flows.jsonâso your data could be redirected elsewhere without any visible trace.
Imagine you trusted a node or plugin and have been using it for years, with automatic updates enabled. One day, an update could introduce malicious behavior and start doing exactly the kind of things Sentinel is designed to preventâwithout any obvious indication that something has changed.
The key issue is that anyone can publish packages to npm or the Node-RED library, and they become immediately available to any instance pulling from those registries. That means youâre ultimately trusting code that hasnât necessarily been verified.
Security in Node-RED is still an afterthought in many production environments.
If youâre responsible for deploying Node-RED at scale, itâs worth asking directly: What is your actual security model for third-party nodes today?
Because by default, there isnât one.
Most Node-RED instances in production are effectively running with full trust in every installed packageâno permission boundaries, no runtime enforcement, and no visibility into what those nodes are actually doing under the hood.
Sentinel exists to close that gap:
Make capabilities explicit
Enforce them at runtime
Give operators control before and after installation
The challenge isnât the technologyâitâs awareness.
Until teams clearly understand how easily flows and nodes can be abused for data exfiltration or manipulation, security will continue to be deprioritized.
Sentinel isnât expensive when you look at the problem it solvesâit eliminates an entire class of risk. People tend to associate cybersecurity with companies, but thatâs outdated thinking. Your personal environment is just as exposed, and in many ways, less protected.
At home, youâre not just dealing with dataâyouâre dealing with identity, location, habits, and access to everything you own digitally. If that gets compromised, the impact isnât a âbusiness lossââitâs your personal safety, your privacy, and your control over your own life. Thatâs a much harder thing to recover from.
The real question isnât the priceâitâs the cost of not having that protection in place. Sentinel positions itself as a safeguard layer where most people currently have none.
@GogoVega please disclose any security issues you have identified in Allan's work to him in a responsible manner. You're right not to disclose issues publicly, regardless of what others have done.
@AllanOricil if you havent already, I suggest adding a clear means for users to report security issues with you privately.
And to both of you; please keep this forum a constructive place.
So far there hasnât been any private disclosureâno email, no Slack message, and no concrete proof demonstrating an actual bypass of the loader guards.
The âevidenceâ shared publicly appears to be just log output, which on its own isnât sufficient to validate a claim like this. Logs can be fabricated, misinterpreted, or generated from an environment that was misconfiguredâsuch as explicitly granting permissions, altering the setup, or not running under the intended constraints.
If someone is going to make a public security claim, it needs to come with reproducible steps, a clear setup, and verifiable evidence so it can be independently validated. Thatâs the baseline for any credible report.
That said, Iâve been proactively reviewing the surface area and identified two additional native methods that can interact directly with V8 and potentially bypass the loader guards. Those werenât part of the claim being made, but theyâre valid hardening gaps.
Iâll be patching those and releasing version 1.0.5. As always, if anyone has a real finding, the right path is responsible disclosure with reproducible evidence so it can be validated and fixed properly.
I hope this wasnât directed at me, but if it was, I want to clarify my position.
In the Sentinel repo and on the hero page, the vulnerabilities listed are not tied to any specific project or undisclosed issue. They represent common threat classes that exist across the ecosystem, with the goal of helping developers better understand the broader risk landscape.
This is no different from how antivirus or security products communicateâlisting the types of threats they protect against without providing instructions on how to execute them. Sentinel follows the same principle.
Security depends on awarenessâpeople need to understand what theyâre up against in order to effectively defend against bad actors. The intent here is to educate and raise that baseline, not to expose or target anything specific. Iâve also never shared any code, exploit details, or steps that could be used to weaponize these threats.
Iâm not disclosing specific vulnerabilities or targeting any projectâjust communicating the types of risks Sentinel is designed to prevent.
