TL;DR: React2Shell (CVE-2025-55182) is a 10.0 CVSS remote code execution flaw in React 19 that attackers began exploiting within hours, while Palo Alto Networks said nearly 1 million vulnerable instances remained live and React sees 55 million weekly downloads, according to AccuKnox analysis. Static scanning, container gating, and runtime enforcement now have to work as one control chain, because discovery without execution blocking leaves production exposed.

NHIMG editorial — based on content published by AccuKnox: Combat React2Shell with runtime detection beyond static scanning

By the numbers:

• React is downloaded 55 million times per week and powers a massive share of modern web applications.
• Cloudflare’s deployment caused a 25-minute service interruption during emergency patching.

Questions worth separating out

Q: What breaks when static scanning is the only control for React2Shell exposure?

A: Static scanning breaks at the point of production reality.

Q: Why do vulnerable workloads increase identity and access risk beyond the CVE itself?

A: Because the exploit runs inside a service that already has permissions.

Q: How do security teams know whether runtime controls are actually reducing exposure?

A: They should look for blocked exploit attempts, quarantined images, and workload policies that stop unknown processes from executing in production.

Practitioner guidance

• Implement continuous runtime enforcement for critical workloads Block suspicious process execution in containers, Kubernetes pods, and VMs so a known exploit cannot run just because a vulnerable package exists in production.
• Re-enable authenticated scanning across all environments Run authenticated DAST and continuous SAST against production, staging, and internal services so hidden deployments do not remain outside the vulnerability inventory.
• Quarantine vulnerable container images before promotion Gate image promotion on container scanning and SBOM checks, then quarantine images that still carry affected React dependencies or transitive packages.

What's in the full article

AccuKnox's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step CNAPP control mapping across SAST, DAST, image scanning, and runtime enforcement.
• The staged Acme Corporation example showing how authenticated scanning, quarantine, and runtime blocking fit together.
• Specific workload policy actions such as virtual patching and process execution controls for React Server Components.
• The remediation sequence used to correlate vulnerability findings with cloud and Kubernetes workloads.

👉 Read AccuKnox's analysis of React2Shell runtime detection and CNAPP controls →

React2Shell and runtime enforcement: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: MongoBleed (CVE-2025-14847) leaks heap memory from exposed MongoDB instances before authentication, exposing passwords, API keys, and PII while over 213,000 instances remain internet-facing, according to AccuKnox. The real lesson is that pre-authentication vulnerabilities need pre-authentication controls, with network policy, runtime enforcement, and asset discovery doing the work patch cycles cannot.

NHIMG editorial — based on content published by AccuKnox: Stopping MongoBleed Attacks with Zero Trust Network Policy and eBPF

By the numbers:

• Patch releases between December 17 and 24, 2025 did not cover legacy MongoDB 3.6, 4.0, and 4.2 instances.

Questions worth separating out

Q: What fails when a pre-authentication database flaw is exposed to the internet?

A: The failure is not only the vulnerable code, but the assumption that authentication will contain the risk.

Q: Why do exposed databases create NHI governance risk?

A: Because databases often store or process the secrets that power non-human identities, including service accounts, API keys and machine tokens.

Q: What do security teams get wrong about patching SAP vulnerabilities?

A: They often treat patching as an infrastructure task instead of a control-state change.

Practitioner guidance

• Inventory every MongoDB instance and version Continuously map databases across Kubernetes, VMs, and cloud accounts so exposed legacy versions are visible before a threat report lands.
• Restrict database access with workload-aware policy Use microsegmentation to allow MongoDB traffic only from approved services, internal ranges, or known workload identities.
• Rotate secrets exposed during the vulnerability window Treat any credential that may have been present in memory, logs, or adjacent automation as compromised until proven otherwise.

What's in the full article

AccuKnox's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step mapping of MongoBleed attack vectors to specific AccuKnox controls and enforcement points.
• Detailed CSPM and KSPM discovery logic for identifying exposed MongoDB instances across Kubernetes, VMs, and cloud environments.
• Runtime blocking examples based on eBPF and Linux Security Modules for exploitation containment.
• Action-oriented guidance for prioritising patching versus compensating controls in legacy MongoDB estates.

👉 Read AccuKnox's analysis of MongoBleed and exposed MongoDB controls →

MongoBleed and exposed MongoDB instances: are your controls enough?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: OpenClaw reached 247,000 GitHub stars but also accumulated 512 vulnerabilities, including a CVSS 8.8 WebSocket auth bypass and over 53,000 exposed instances, according to AccuKnox. ClawArmor argues that application-layer fixes are not enough because prompt injection, tool abuse, and sandbox bypass require kernel-level enforcement that constrains runtime behaviour.

NHIMG editorial — based on content published by AccuKnox: Introducing ClawArmor and securing OpenClaw instances with sandboxing

By the numbers:

• A full audit identified 512 vulnerabilities in OpenClaw, including 8 critical issues.

Questions worth separating out

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime agent choice as an access event, not as a simple application action.

Q: Why do application-layer controls often fail for AI agent security?

A: Because the agent’s dangerous actions happen after the model has already produced a decision.

Q: What breaks when AI agents are given broad inherited permissions?

A: Broad inherited permissions break the assumption that access is tied to a narrow business need.

Practitioner guidance

• Define kernel-enforced allowlists for agent workloads Restrict file paths, binaries, and outbound destinations at the Linux kernel layer so the agent cannot override policy through prompts or tool calls.
• Remove broad execution paths from agent containers Do not mount the Docker socket, do not grant privileged mode, and do not leave shell utilities or package managers available unless explicitly required.
• Separate agent secrets from general runtime context Store credentials outside the agent process and deny direct access to .aws, .kube, .ssh, and other key material from the workload identity.

What's in the full article

AccuKnox's full article covers the operational detail this post intentionally leaves for the source:

• The specific KubeArmor policy structure used to block file, process, and egress actions in OpenClaw deployments.
• The full default-configuration risk matrix showing how each exposed path maps to a control outcome.
• Deployment guidance for Kubernetes and bare metal environments, including policy application and telemetry flow.
• The practical differences between application-layer patching and kernel-level sandbox enforcement for AI agents.

👉 Read AccuKnox's analysis of OpenClaw sandboxing and kernel-level enforcement →

OpenClaw sandboxing and kernel enforcement: are runtime controls enough?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Four SAP npm packages were poisoned to steal developer credentials, cloud secrets, and CI/CD tokens during npm install, and the attack chain completed in seconds, according to AccuKnox. That timing exposes a governance gap: detection after execution is too late when supply chain malware weaponises trusted install workflows.

NHIMG editorial — based on content published by AccuKnox covering the SAP npm supply chain attack: SAP npm supply chain attack. Legacy Detect-and-Respond Tools Leave Your Doors Wide Open

By the numbers:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.

Questions worth separating out

Q: What breaks when malicious npm packages execute during CI/CD installs?

A: The main failure is that package installation becomes code execution inside a trusted build context.

Q: Why do CI/CD runners create such high credential risk?

A: They often contain many reusable secrets at once, including cloud keys, package tokens, SSH material, and cluster credentials.

Q: How can security teams tell whether secret management is actually working?

A: Look for fewer plaintext secrets, narrower reuse, faster rotation, and a shrinking set of credentials that remain valid across multiple systems.

Practitioner guidance

• Block unapproved execution in build environments Enforce process allowlisting so downloaded runtimes, postinstall scripts, and unexpected binaries cannot execute inside CI/CD runners or developer workstations.
• Deny direct reads of secret-bearing paths Restrict access to ~/.ssh, ~/.aws/credentials, ~/.npmrc, Kubernetes service account tokens, and /proc/self/environ at the syscall layer.
• Scope and rotate publish tokens aggressively Separate package publishing credentials from routine development access, apply narrow repository scope, and rotate tokens after any suspicious install or build event.

What's in the full article

AccuKnox's full post covers the operational detail this post intentionally leaves for the source:

• Kernel-level enforcement mechanics using eBPF and Linux Security Modules in workload environments.
• How file access controls stop reads from ~/.ssh, ~/.aws/credentials, ~/.npmrc, and /proc/self/environ.
• Process whitelisting behaviour for blocking downloaded runtimes such as Bun before execution.
• CI/CD-specific deployment patterns for Kubernetes runners, VMs, and bare-metal build hosts.

👉 Read AccuKnox's analysis of the SAP npm supply chain attack and runtime controls →

SAP npm supply chain attack: what runtime controls need to block?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: React2Shell (CVE-2025-55182) allows unauthenticated remote code execution through React Server Components and frameworks such as Next.js, because crafted HTTP requests can abuse unsafe RSC payload deserialization in default deployments, according to Xygeni. The issue turns framework-level trust into a server-side execution path, so patching, SBOM review, and runtime detection now matter more than static dependency checks.

NHIMG editorial — based on content published by Xygeni: React2Shell analysis across React Server Components and Next.js

By the numbers:

• Security researchers confirm nearly 100% exploitation reliability for React2Shell, and report that 39% of cloud environments run vulnerable instances.
• Researchers also found that 44% of all environments run publicly exposed Next.js applications affected by React2Shell.

Questions worth separating out

Q: What breaks when a framework trusts serialized request data too much?

A: When a framework trusts serialized request data too much, an unauthenticated HTTP request can become server-side execution.

Q: Why do server-side framework flaws create identity risk as well as application risk?

A: Server-side framework flaws create identity risk because the application runtime usually runs with a workload identity, service account, or token set that already has real permissions.

Q: How do security teams know whether React2Shell-style exposure is actually contained?

A: They need three signals: all deployed builds reference fixed versions, no vulnerable RSC packages appear in compiled artefacts or dependency trees, and logs show no suspicious requests or abnormal outbound activity after disclosure.

Practitioner guidance

• Patch vulnerable React server packages immediately Upgrade affected React and Next.js versions to the patched releases and verify that transitive framework packages no longer pull in vulnerable RSC implementations.
• Scan for exposed RSC endpoints and default framework paths Identify public Next.js and other RSC-enabled deployments, then confirm which endpoints accept React Flight payloads over HTTP.
• Correlate SCA results with runtime telemetry Use software composition analysis alongside logs for malformed multipart payloads, repeated 500 responses, and suspicious Next-Action headers.

What's in the full article

Xygeni's full analysis covers the operational detail this post intentionally leaves for the source:

• Package-version mapping for the affected React server components and Next.js releases
• Detection logic for malformed React Flight traffic and characteristic error responses
• Patch sequencing guidance for large JavaScript estates with transitive framework dependencies
• Temporary WAF and cloud-provider response options while remediation is rolling out

👉 Read Xygeni's analysis of React2Shell exposure across React Server Components and Next.js →

React2Shell and Next.js exposure: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: React2Shell highlights how embedding powerful deserialisation and protocol interpreters in request paths can turn developer convenience into remote code execution risk, according to Pixee’s analysis of the CVE-2025-55182 pattern and the older Struts OGNL failure mode. The lesson is that architectural trust boundaries matter before a CVE does, because abstract risk becomes concrete exploitability quickly.

NHIMG editorial — based on content published by Pixee: React2Shell: The Next Struts2-Style Bug Parade?

Questions worth separating out

Q: What breaks when request-path interpreters are not tightly bounded?

A: The boundary between data and code collapses.

Q: Why does PQC planning matter to IAM and PAM teams?

A: Because authentication, privileged access, and workload trust all depend on cryptographic primitives that may need post-quantum replacement.

Q: How can security teams know whether a framework pattern is becoming dangerous?

A: Look for repeated coupling of request handling with interpreters, decoders, or module-loading behaviour.

Practitioner guidance

• Review request-path interpreter exposure Inventory frameworks and middleware where user input can reach expression engines, deserialisers, or function invocation logic.
• Add architectural pattern checks to AppSec review Create a review step for interpreter-heavy designs such as OGNL-style evaluation, unsafe deserialisation, and server-function decoding.
• Map RCE blast radius to identity assets Assume any server-side execution bug can expose API keys, service account tokens, and session material.

What's in the full article

Pixee's full article covers the code-level and historical detail this post intentionally leaves for the source:

• A closer comparison between React2Shell and Struts OGNL failures that shows how the same risk pattern recurs across framework generations.
• Specific references to CVE-2025-55182, the affected React and Next.js configurations, and why the bug is being treated as concrete exploit risk.
• The article's discussion of abstract versus concrete risk, including how teams may miss architectural danger until exploitation begins.
• Pixee's framing of why storytelling and metaphor matter when AppSec teams try to communicate latent framework risk to management.

👉 Read Pixee's analysis of React2Shell and the request-path interpreter risk →

React2Shell and request-path interpreters: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: CVE-2026-41242 in protobufjs lets attacker-influenced schema metadata reach JavaScript code generation in Node.js applications that load untrusted .proto files or JSON descriptors through reflection APIs, according to Corgea. The issue matters because many teams treat schema inputs as data, yet runtime compilation can turn them into executable code paths.

NHIMG editorial — based on content published by Corgea covering CVE-2026-41242 in protobufjs: attacker-controlled schema metadata reaching JavaScript code generation in Node.js applications

Questions worth separating out

Q: What breaks when protobuf schema data is allowed to drive code generation?

A: The break point is the trust boundary between metadata and executable code.

Q: Why do dynamic protobuf loaders increase risk in Node.js services?

A: They let schema content cross trust boundaries at runtime instead of being validated at build time.

Q: How do security teams know whether protobufjs is actually dangerous in their environment?

A: Check reachability, not just version.

Practitioner guidance

• Block untrusted schema compilation in production Do not allow customer, partner, or remotely fetched .proto files and descriptor JSON to reach runtime compilation paths.
• Trace transitive protobufjs exposure across the dependency tree Run lockfile and SBOM review for protobufjs, then verify whether the installed version is reachable through @grpc/proto-loader, Firebase clients, Google Cloud SDKs, or other dynamic tooling.
• Classify descriptor loading as a code-input trust boundary Review Root.fromJSON, remote descriptor fetches, reflection clients, and schema registry integrations as if they were executable inputs.

What's in the full analysis

Corgea's full analysis covers the operational detail this post intentionally leaves for the source:

• Package-version guidance for affected protobufjs releases and the fixed versions to pin in direct and transitive dependencies
• Code examples and detection paths for finding Root.fromJSON, reflection loaders, and remote descriptor fetches in real codebases
• Remediation workflow for rotating process secrets and checking for unexpected schema uploads before patch deployment
• Dependency-tree review tactics for identifying protobufjs when it arrives through gRPC, Firebase, or cloud SDK tooling

👉 Read Corgea's analysis of CVE-2026-41242 in protobufjs →

Protobufjs CVE-2026-41242: where do schema trust controls fail?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Trivy was hit by two supply chain attacks in March 2026, with the first stealing a privileged GitHub token through a dangerous pull_request_target workflow and the second reusing incomplete rotation to poison releases, tags, and downstream packages, according to ARMO. The pattern shows that CI/CD trust, not just code integrity, is now the governing control point for open-source consumers.

NHIMG editorial — based on content published by ARMO: When Your Friend’s House Burns Down Twice: The Trivy Supply Chain Attacks Explained

Questions worth separating out

Q: What breaks when CI/CD workflow actions or build credentials are tampered with?

A: A poisoned workflow action can turn trusted automation into a credential-exfiltration path, especially when runners hold deployment tokens, cloud keys, or signing material.

Q: Why do standing CI/CD tokens create so much risk in supply chain attacks?

A: Standing tokens remain usable long after the moment they were created, so a compromise can persist through normal operations and even through partial remediation.

Q: How do security teams know if credential rotation actually worked?

A: They need proof that every consumer rejected the old credential, every dependent workflow has moved to the replacement, and no residual access path still functions.

Practitioner guidance

• Harden pull_request_target workflows Separate untrusted pull-request validation from any workflow that can read repository secrets, write releases, or invoke privileged tokens.
• Make credential revocation atomic Rotate and revoke the old token, not just issue a replacement, then verify that caches, mirrors, runners, and delegated grants no longer accept the prior credential.
• Pin consumers to immutable references Replace tag-based dependency trust with commit SHAs or equivalent immutable references for critical build inputs, and monitor for tag movement as a security event.

What's in the full article

ARMO's full blog covers the operational detail this post intentionally leaves for the source:

• The exact malicious workflow path in apidiff.yaml and how the pull_request_target pattern enabled token theft
• The full tag-poisoning method used to rewrite 75 of 76 release tags without changing the visible workflow file
• The forensic indicators that distinguished the malicious commits from legitimate maintainers' releases
• The downstream canister-based C2 and npm worm propagation details for teams investigating exposure

👉 Read ARMO's analysis of the Trivy supply chain attacks and credential theft chain →

Trivy supply chain compromise: what CI/CD teams need to rethink?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: React2Shell is a CVSS 10.0 React Server Components flaw that drove rapid patching and emergency mitigations, but Pixee argues the real problem is the unreviewed backlog of lower-visibility CVEs that teams struggle to triage and contextualise. The operational lesson is that systematic dependency management matters more than headline-driven security purchases.

NHIMG editorial — based on content published by Pixee: Why You Shouldn't Buy a Security Product in Response to React2Shell

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

Questions worth separating out

Q: What fails when teams treat CVSS as the only vulnerability priority signal?

A: Teams end up fixing the loudest issues first and leaving the most relevant ones in the backlog.

Q: Why do internet-facing application flaws often become identity risks?

A: Because web application compromise frequently exposes the components attackers need to reach identity controls, including configuration files, session tokens, admin interfaces, or service credentials.

Q: How should security teams reduce exposure to routine CVEs without buying more tools?

A: Standardise automated dependency updates, keep tests strong enough to support fast merges, and make patching part of the normal release path.

Practitioner guidance

• Build contextual CVE triage rules Classify findings by reachability, exploitability, authentication barriers, and whether the vulnerable code path is actually used in your deployment.
• Automate dependency updates end to end Use automated pull requests, regression testing, and standard release pipelines so patching happens continuously rather than as a crisis response.
• Treat runtime controls as temporary containment Keep WAF rules and virtual patches for immediate risk reduction, but do not count them as remediation.

What's in the full article

Pixee's full article covers the operational detail this post intentionally leaves for the source:

• How the React2Shell remediation workflow maps to dependency update tooling and release pipelines
• The practical limits of WAF rules and virtual patches when facing deserialization exploitation
• Examples of the backlog triage problem across medium and high severity CVEs
• Pixee's rationale for focusing on systematic vulnerability management rather than emergency purchases

👉 Read Pixee's analysis of React2Shell and the backlog problem in AppSec →

React2Shell and the backlog problem: what should teams change?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: A covert storage and retrieval layer was used in the GemStuffer campaign, with 155 RubyGems package artifacts, hardcoded RubyGems API keys, and valid .gem archives carrying scraped data from UK council portals, according to Corgea. The pattern matters because package registries can be abused for outbound exfiltration and publishing abuse, not just dependency delivery.

NHIMG editorial — based on content published by Corgea: GemStuffer RubyGems registry-abuse campaign and the use of package publishing as exfiltration

Questions worth separating out

Q: What breaks when package publishing is not separated from build and runtime identities?

A: When publishing is not separated from build and runtime identities, any process that reaches the registry can turn into an exfiltration path.

Q: Why do AI provider keys need the same governance as other NHI secrets?

A: Because they authenticate automated access to external services, often with spend authority and operational reach.

Q: What do security teams get wrong about package registry monitoring?

A: Teams often watch dependency installation while ignoring registry writes.

Practitioner guidance

• Restrict registry publishing to approved release identities Allow gem push and RubyGems API writes only from signed release workflows, not from general CI jobs, app runtimes, or scraping hosts.
• Audit and rotate RubyGems API tokens as privileged secrets Inventory where RubyGems credentials exist, including temporary home directories and build images.
• Detect abnormal package creation and upload behaviour Alert on unexpected POSTs to https://rubygems.org/api/v1/gems, gem build activity from non-release hosts, and processes that set HOME to a /tmp path before pushing packages.

What's in the full analysis

Corgea's full analysis covers the operational detail this post intentionally leaves for the source:

• Package-level indicators and filenames tied to the GemStuffer campaign, including representative artifacts and registry-abuse patterns.
• The exact Ruby execution and packaging sequence used to fetch public council pages, stage content, and publish .gem archives.
• Detection guidance for Ruby processes that override HOME, create credentials in temporary directories, or push to RubyGems from non-release contexts.
• Remediation actions for registry governance, including release workflow restrictions and API token rotation.

👉 Read Corgea's analysis of the GemStuffer RubyGems registry-abuse campaign →

RubyGems as an exfiltration layer: what security teams missed?

Explore further

View Full Forum →  |  NHI Foundation Course →