Ni8mare shows how shadow AI turns automation into enterprise risk

At a glance

What this is: Cyera Research Labs says Ni8mare is a CVSS 10 unauthenticated remote code execution flaw in n8n that can turn exposed automation into a master key for connected systems.

Why it matters: For IAM and NHI teams, the risk is that workflow platforms centralize high-value secrets and access paths that traditional controls may not inventory or govern well.

By the numbers:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 38% have no or low visibility, and 47% have only partial visibility.

👉 Read Cyera's analysis of Ni8mare and ShadowAI risk in n8n

Context

Shadow AI is what happens when autonomous or semi-autonomous software runs outside clear inventory, ownership, and policy boundaries. In this case, the issue is not limited to n8n as a product. It is the broader governance problem of workflow systems that accumulate privileged non-human identities, secrets, and downstream access while remaining hard to see from the identity control plane.

Cyera frames Ni8mare as a security leader problem because a public-facing automation platform can sit at the center of enterprise SaaS, data, and development workflows. That pattern is not unusual in modern estates. What is atypical is how quickly a single exposed service can become a control failure across discovery, secrets governance, and incident response when automation has been allowed to sprawl.

Key questions

Q: How should security teams respond when an automation platform holds privileged NHI secrets?

A: Start by assuming the secrets are exposed if the platform has been compromised or publicly reachable. Then inventory every connected account, revoke or rotate the credentials in a controlled order, and verify which downstream services still trust the old access paths. The goal is to restore control of the identity chain, not just patch the application.

Q: Why do workflow automation tools create more risk than ordinary SaaS apps?

A: They often sit in the middle of many systems and hold the credentials needed to move data or trigger actions across them. That makes them identity concentrators, not just applications. When compromise occurs, the attacker may inherit broad operational reach through stored secrets and trusted integrations.

Q: What is the difference between patching a vulnerable automation engine and governing it properly?

A: Patching closes the software flaw, but governance addresses ownership, inventory, privilege, rotation, and monitoring of the NHIs the platform uses. A properly governed system has named owners, limited credentials, clear revocation paths, and logging for every high-risk connection. Without that, the same blast radius remains after the patch.

Q: How can organisations reduce ShadowAI risk without blocking automation outright?

A: Keep the automation, but move it under explicit identity governance. That means discovery across self-hosted and cloud-hosted instances, approved connector lists, least-privilege secrets, network segmentation, and continuous review of workflows that can reach sensitive systems. The objective is controlled use, not blanket prohibition.

Technical breakdown

Why automation platforms become high-blast-radius identity hubs

Workflow automation platforms often bind together APIs, service accounts, OAuth grants, and database credentials so one workflow can orchestrate many systems. That convenience creates concentrated trust. If an attacker reaches the runtime, they may inherit access to the platform’s stored secrets and the permissions of connected systems. The identity risk is not only authentication at the front door. It is also the implicit trust chain between workflows, connectors, and the NHI inventory behind them. In practice, the larger the integration surface, the more likely the platform has become an identity hub rather than a simple app.

Practical implication: Practitioners should treat automation platforms as privileged identity infrastructure and inventory every NHI they can access.

How unauthenticated RCE changes the secrets exposure model

Unauthenticated remote code execution means an attacker may not need prior credentials to execute code on the target system. In an automation platform, that shifts the problem from limited application compromise to potential secret harvesting, workflow tampering, and lateral access through connectors. Once code execution is possible, attackers can often enumerate environment variables, local files, and runtime metadata that expose tokens or passwords. The important nuance for IAM and NHI teams is that the attack surface is not just the vulnerable binary. It includes every downstream system that trusts the compromised platform.

Practical implication: Teams should assume stored secrets are exposed once the platform is compromised and rotate them as a unit, not one by one.

Why ShadowAI complicates discovery and containment

ShadowAI is harder to govern than traditional shadow IT because it may not appear as a clearly owned application. It can run in cloud-hosted, self-hosted, or endpoint-local forms, and it may be embedded in business workflows rather than managed by a central technical team. That makes discovery, ownership, and remediation slower. For responders, the core question becomes whether the platform is public-facing, what it connects to, and whether those connections were ever reviewed as NHIs. Without that mapping, containment stops at patching while the real blast radius remains unknown.

Practical implication: Security teams need cross-domain discovery that links exposed automation to owners, secrets, and connected identities before remediation starts.

Threat narrative

Attacker objective: The attacker aims to turn a single automation foothold into broad access across the enterprise systems that the platform orchestrates.

1. Entry via unauthenticated remote code execution in a public-facing n8n instance.
2. Credential harvesting from the automation runtime, where API keys, OAuth tokens, and database passwords may be stored or reachable.
3. Impact through workflow abuse and downstream access to connected SaaS, data, and operational systems.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Ni8mare is a governance event, not just a vulnerability event. The technical flaw matters, but the larger lesson is that workflow automation has become a privileged identity layer in many enterprises. When a single platform controls many integrations, the blast radius is determined by how many secrets and service accounts it can reach. Practitioners should classify these systems as identity infrastructure and govern them accordingly.

ShadowAI is the next phase of shadow IT because it combines invisibility with execution authority. Traditional shadow IT often hides software sprawl; ShadowAI hides software sprawl that can also act on data, trigger workflows, and call external systems. That changes the risk equation for discovery and response. Security teams need inventory that captures both the runtime and the non-human identities behind it.

Identity blast radius is the right concept for automation platforms. In this context, blast radius is not only where the platform sits, but what it can sign into, modify, or disclose. A vulnerable workflow engine can expose much more than code execution if the attached credentials are overly broad or unsegmented. The right control objective is to reduce the number and privilege of reachable NHIs before a compromise happens.

Reactive patching is necessary but insufficient when credentials live inside orchestration layers. If teams only patch and restart, they may preserve the same trust relationships that made exploitation valuable in the first place. The better question is which connectors, tokens, and privileged workflows should never have been colocated. Practitioners should use this as a trigger to rebuild privilege boundaries, not just close a CVE.

Modern IAM programs need a process for automation-owned identities that behaves more like PAM than basic account hygiene. These identities often hold durable, high-value access that is invisible to traditional joiner-mover-leaver logic. They need ownership, rotation, revocation, and monitoring with clear accountability. Security leaders should treat workflow platforms as governed access brokers, not merely applications.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% having only partial visibility.
• That visibility gap should push teams toward the 52 NHI Breaches Analysis to pressure-test how hidden identities expand blast radius.

What this signals

Identity blast radius is the metric that matters most after Ni8mare. When a workflow engine can reach dozens of services, the security question shifts from whether one application is patched to whether the connected identity graph is segmented, owned, and continuously reviewed. Teams that cannot map those dependencies should expect slower containment and wider remediation scope.

Cyera’s warning about hidden automation aligns with a broader programme reality. As more AI-enabled workflows emerge, the discovery problem becomes an identity problem, and the identity problem becomes an access problem. Security leaders should pair exposure management with continuous NHI inventory so they can see which runtimes hold durable access before those runtimes become incident paths.

For practitioners

• Inventory every exposed automation runtime Search public IP space, internal networks, and endpoint telemetry for n8n instances or similar workflow engines. Map each finding to an owner, deployment model, and business function before remediation starts.
• Rotate all secrets reachable from the platform Treat API keys, OAuth tokens, database passwords, and certificates accessed by the compromised automation layer as potentially exposed. Reissue them under a documented sequence so dependent workflows fail in a controlled way.
• Segment workflow access from core production systems Place automation services behind Zero Trust Network Access or equivalent controls, and restrict their ability to reach sensitive SaaS and data services unless each connection is explicitly approved.
• Review workflow nodes that accept inbound requests Inspect form, webhook, and similar trigger nodes for authentication, input validation, and abuse logging. These are the edges where public exposure becomes enterprise-wide impact.
• Build a response playbook for automation-owned NHIs Define who can revoke, reissue, and validate non-human identities used by automation workflows, and rehearse the process before the next exposure event occurs.

Key takeaways

• Ni8mare shows that automation platforms can become concentrated identity risk points when they store secrets and connect to many downstream systems.
• A single unauthenticated RCE in a workflow engine can create far more damage than a normal application bug because the platform may already hold privileged NHIs.
• Security teams should respond by inventorying automation, rotating reachable secrets, and segmenting workflow access before the next exposed runtime becomes a control failure.

Key terms

• Shadow AI: Shadow AI is AI-enabled software or automation that operates outside approved inventory, ownership, or governance processes. In security practice, it creates hidden execution paths, hidden data access, and hidden non-human identities that can expand enterprise risk before teams notice the system exists.
• Identity blast radius: Identity blast radius is the amount of damage possible when one non-human identity or trusted runtime is compromised. It is determined by the number of systems, permissions, and data stores the identity can reach, not just by where the initial flaw appears.
• Automation-owned non-human identity: An automation-owned non-human identity is a service account, token, or credential set used by a workflow platform to connect to other systems. These identities often carry durable access and need explicit ownership, rotation, monitoring, and revocation because they can outlive the workflow that created them.
• Workflow engine privilege hub: A workflow engine privilege hub is a platform that concentrates many credentials and integrations in one runtime. When that runtime is compromised, the attacker may inherit the access of every connected service, which makes governance, segmentation, and secret hygiene critical.

Deepen your knowledge

Ni8mare response, automation identity sprawl, and ShadowAI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model for workflow platforms that hold privileged access, it is worth exploring.

This post draws on content published by Cyera: What Ni8mare teaches security leaders about ShadowAI and modern risk. Read the original.