TL;DR: CVE-2025-66478 was rejected as a duplicate of CVE-2025-55182, but the underlying flaw remained in React Server Component runtimes that Next.js and other frameworks bundle, according to Veracode Threat Research. The incident shows that SCA accuracy now depends on tracing transitive dependencies to the true source package, not the wrapper framework.
At a glance
What this is: Veracode’s analysis says CVE-2025-66478 was noise at the framework layer because the exploitable flaw lived in React Server Component runtimes, not in Next.js itself.
Why it matters: IAM and security teams should care because inaccurate dependency attribution creates remediation churn, hides the real source package, and weakens software supply chain governance.
Context
CVE attribution is only useful when it points to the component that can actually be exploited. In modern JavaScript supply chains, wrapper frameworks often bundle transitive packages that carry the real defect, so surface-level alerts can send teams toward the wrong fix.
This case sits in application security and supply chain governance rather than identity proper, but it still matters to identity and platform teams because access to release pipelines, dependency graphs, and remediation workflows determines how quickly the real source package gets patched. The pattern is typical of dense framework ecosystems where consumers inherit vulnerability exposure from deeper runtime layers.
Key questions
A: Start with the lock file and dependency tree, not the headline CVE label. Identify the package that actually executes the vulnerable code, confirm whether the framework only consumes it, and then patch the source dependency. That avoids wasted effort on wrapper updates that do not remove the exploitable path.
Q: Why does misattributing a vulnerability to a wrapper framework create remediation risk?
A: Because the wrong label sends teams toward the wrong fix. If the exploitable code sits in a bundled runtime or nested package, updating the top-level framework may not remove the vulnerable component. Accurate attribution keeps remediation focused on the package that can actually execute attacker-controlled input.
Q: How do security teams know whether an SCA tool is giving them reliable results?
A: Look for source-level attribution, duplicate CVE consolidation, and clean transitive dependency reporting. A reliable tool shows the vulnerable package, the consuming frameworks, and the resolved fixed version without multiplying the same issue across every wrapper in the tree.
Q: What is the difference between a vulnerable source package and an affected framework?
A: The vulnerable source package contains the flaw and must be patched directly. An affected framework may bundle or execute that package, but it is not necessarily the defect location. Security teams should treat the framework as the exposure context and the source package as the remediation target.
Technical breakdown
Why duplicate CVE handling matters in SCA
Software Composition Analysis works when it maps a vulnerability to the package that actually contains the flaw. If a tool propagates the same issue to every downstream framework that bundles the package, it creates cascade mapping, where one defect appears as many alerts. That breaks prioritisation because teams spend time triaging consumers instead of patching the vulnerable source. In this article, the signal was that the React Server Component runtime was the defective layer, while Next.js was only an affected consumer. Precise SCA should preserve that distinction and consolidate duplicate advisories around one root issue.
Practical implication: Practitioners should tune SCA to preserve source-package attribution and suppress wrapper-level duplicates.
How transitive dependencies create false vulnerability scope
A transitive dependency is a package pulled in indirectly by a direct dependency. It may be invisible at the top level, yet still execute in production and expose the application to remote code execution if the vulnerable path is reached. The article’s key lesson is that a framework update is not proof of safety unless the bundled runtime version also changes. In React Server Components, the server-side deserialisation path is what matters, because that is where crafted input can trigger the flaw. Dependency graph inspection has to extend beyond the manifest to the lock file and nested package tree.
Practical implication: Teams should validate lock files and nested packages, not just top-level framework versions.
Why SCA noise becomes a governance problem
When SCA reports the wrong layer, it does not just waste developer time. It degrades vulnerability governance by obscuring ownership, delaying remediation, and undermining trust in the alerting process. Over time, noisy findings encourage teams to ignore alerts or assume that a missing alert means no risk exists. The real control objective is accurate software bill of materials intelligence, because only a clean dependency picture lets teams distinguish an actual exploitable package from a benign wrapper. That is a governance issue as much as a tooling issue, especially in large environments with many distributed owners.
Practical implication: Security leaders should measure SCA quality by attribution accuracy and duplicate suppression, not alert volume.
Threat narrative
Attacker objective: The attacker’s objective is remote code execution through the vulnerable React Server Component runtime.
- Entry occurs through a malicious request aimed at a vulnerable React Server Component runtime that deserialises client-supplied data on the server.
- The attacker leverages the unsafe deserialisation path in the affected react-server-dom-* package to reach remote code execution.
- Impact is achieved when the server processes the crafted request and executes attacker-controlled code within the application runtime.
Breaches seen in the wild
- Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
- ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Source attribution, not framework attribution, is now the decisive SCA control: modern application stacks routinely bundle vulnerable code through multiple abstraction layers, and the security value sits in naming the package that can actually be fixed. When tools over-attribute a flaw to every wrapper framework, they reduce remediation quality and inflate operational noise. Practitioners should treat source-level mapping as part of vulnerability governance, not a cosmetic reporting detail.
Transitive dependency blind spots are a software supply chain risk, not just an application security inconvenience: the issue here was not whether Next.js was popular, but whether the vulnerable RSC runtime could be traced correctly through nested packages. That distinction matters because the wrong fix often follows the wrong label. Teams need clean dependency lineage so they can patch the real runtime rather than chase top-level consumers.
SCA accuracy now determines whether developers trust the security queue: if every consumed package inherits the same CVE, alert fatigue becomes inevitable and real exposure gets lost. Precision in duplicate handling and SBOM correlation is therefore a control objective, not a reporting preference. The practitioner conclusion is simple: no trust in attribution, no trust in prioritisation.
Dependency graph clarity is a governance boundary for modern build pipelines: organisations that cannot distinguish a source package from a wrapper have not really governed their software supply chain. This is where application security intersects identity and access governance, because the pipeline must know which component deserves update authority, validation, and change tracking. Practitioners should make source-of-truth dependency mapping a formal control.
Real-time vulnerability triage must follow execution paths, not marketing labels: the affected layer is the one that deserialises untrusted input and can be reached in production, not the framework name that appears in a dashboard headline. That means remediation ownership should sit with the teams that control runtime packages and release cadence. The conclusion for practitioners is to govern the executable path, then the wrapper.
What this signals
Source-package attribution is becoming a supply chain control, not a reporting nicety: when dependency ecosystems are deep, the difference between a fixable runtime and an affected wrapper determines whether remediation is fast or stalled. Security teams should expect more value from SCA tools that can collapse duplicate findings while preserving the real source package.
Dependency graph hygiene is now part of build governance: teams that cannot explain which transitive package is executing in production cannot reliably answer whether a CVE matters. That pushes software security toward stronger package lineage, stronger release validation, and better change ownership across development and platform teams.
For practitioners
- Inventory the real runtime packages Check lock files and dependency trees for react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack so you can identify the version actually executing in your build.
- Validate the patched bundled versions Confirm that the bundled React Server Component runtime is at or above 19.0.1, 19.1.2, or 19.2.1 after upgrading the consuming framework.
- Test for duplicate CVE suppression Verify that your SCA tool consolidates duplicate advisories and still preserves the source package that requires remediation.
- Re-run post-upgrade dependency checks Repeat inventory scans after remediation to make sure the vulnerable transitive package disappeared from the resolved tree.
Key takeaways
- The article shows that a critical-looking framework alert can still be noise if the real defect lives deeper in the dependency chain.
- The operational risk is misdirected remediation, alert fatigue, and weaker trust in SCA results when wrapper frameworks are treated as the defect source.
- Teams need source-level attribution, duplicate CVE consolidation, and post-upgrade dependency validation to keep vulnerability management accurate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006 — Credential Access | The article centres on a crafted request path leading to code execution through a vulnerable runtime. |
| Recommendation — Map exploitable request paths to TA0006 and review where untrusted input reaches runtime execution. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Misattributed package risk often reflects weak dependency and runtime visibility in application delivery. |
| Recommendation — Use API8 to tighten dependency and runtime configuration checks that expose vulnerable components. | ||
| NIST CSF 2.0 | PR.DS-10 — Data in Transit is Protected | The article is about securing application execution paths and their supporting software supply chain. |
| Recommendation — Apply PR.DS-10 to ensure vulnerable runtime components are identified before they can process untrusted input. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Correcting SCA noise depends on knowing exactly which packages are deployed and nested. |
| Recommendation — Use CIS-2 to maintain an accurate software inventory that includes transitive packages and bundle contents. | ||
Key terms
- Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
- Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
- Duplicate CVE: A duplicate CVE is a vulnerability record that refers to the same underlying flaw as another entry. The duplicate is useful when it consolidates reporting, but harmful when it creates confusion about where the issue lives or which package needs to be updated.
- Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It helps security and platform teams align identity control with broader governance and operational risk.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org