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: This analysis explains why CVE-2025-66478 was rejected and why the real vulnerability sits in React Server Component runtimes rather than Next.js itself.
Why it matters: It matters because identity, application, and DevSecOps teams need SCA findings that point to the actual vulnerable dependency, or remediation efforts will miss the package that creates exploitability.
By the numbers:
- Any application using versions of these packages below 19.0.1 / 19.1.2 / 19.2.1 is exposed.
- The vulnerability is fully resolved in patched Next.js releases including 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7.
👉 Read Veracode's analysis of CVE-2025-66478 and React Server Component exposure
Context
CVE-2025-66478 is a useful reminder that software composition analysis fails when it treats wrappers as the root cause instead of tracing the vulnerable dependency chain. In application security, the primary keyword is software composition analysis, and the real governance problem is signal quality: teams can only remediate what they can accurately locate.
The issue also has an identity angle because modern application stacks increasingly depend on machine-generated trust, transitive packages, and build-time automation. When vulnerability tooling misattributes the source of a flaw, it creates a control gap between development, security, and release governance, which is typical of large framework ecosystems rather than an unusual edge case.
Key questions
Q: What breaks when SCA points to the wrong package instead of the vulnerable source?
A: Teams waste remediation effort on wrapper frameworks, duplicate alerts inflate the backlog, and the real vulnerable dependency can remain unpatched. The result is slower response, weaker prioritisation, and a false sense of coverage. SCA must resolve findings to the package that contains the flaw, not just the product name that bundles it.
Q: When should organisations prioritise transitive dependency review over top-level package updates?
A: They should do it whenever the vulnerability may live in a bundled runtime, shared library, or deserialisation path that the top-level framework merely invokes. In those cases, a framework upgrade may help, but only a dependency graph confirms whether the vulnerable package was actually removed. That check prevents silent residual exposure.
Q: What do security teams get wrong about duplicate CVEs in SCA?
A: They often assume a duplicate means the issue is gone or that the alert can be ignored. In reality, a duplicate CVE usually means the same flaw is being tracked under a better source identifier. Teams should collapse the noise, then trace the direct dependency that remains vulnerable.
Q: How can developers verify that an SCA finding is truly remediated?
A: Re-run dependency inspection after patching and confirm the vulnerable package no longer appears in the resolved tree. Do not rely only on the top-level framework version or on a scanner’s silence. A clean result requires proof that the vulnerable runtime package has been replaced or removed.
Technical breakdown
Why duplicate CVEs create SCA noise
A duplicate CVE is a record that maps to an already tracked vulnerability, not a second independent flaw. In practice, this matters because scanners and dashboards can surface the same underlying issue through multiple package names, especially when a framework bundles transitive code. The operational risk is not the duplicate entry itself. It is the false sense of breadth it creates, which can push teams to patch the wrong layer or treat every consumer as individually vulnerable when only the shared runtime is exploitable.
Practical implication: validate whether a finding is a true source issue or a duplicate before assigning remediation work.
Transitive dependency risk in React Server Components
React Server Components separate client and server rendering, but the server-side runtime still deserializes data that can be attacker-controlled. That makes the runtime package the security boundary, not the wrapper framework that includes it. If a vulnerability exists in the runtime, any application that imports that package inherits exposure, even when the top-level framework is not the origin. This is why dependency graphs matter more than package labels in modern SCA workflows.
Practical implication: inventory the transitive package, not just the top-level framework, when assessing exploitability.
Direct-dependency principle in vulnerability attribution
The direct-dependency principle says a scanner should attribute a flaw to the exact package that contains the vulnerable code, then link downstream consumers to that source issue. This keeps SBOM and alert data actionable. Without that discipline, organisations get cascade mapping, where every wrapper or consumer appears to have its own defect. That approach inflates the backlog, weakens prioritisation, and obscures the specific upgrade path that actually removes risk.
Practical implication: tune SCA policy to consolidate duplicates and preserve the exact remediation target.
Threat narrative
Attacker objective: The attacker aims to execute arbitrary code on vulnerable servers by abusing the React Server Component runtime path.
- Entry occurs when an attacker crafts a malicious request that targets the vulnerable React Server Component deserialization path.
- Credential access is not the central mechanic here, but the exploit uses server-side processing trust to reach code execution without valid user credentials.
- Impact follows when the vulnerable runtime executes attacker-controlled code, allowing remote code execution in exposed applications.
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.
- Gravity SMTP CVE-2026-4020 API Keys Exposure — CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Signal quality is now a governance control, not just a tooling feature. SCA only works when it distinguishes the actual vulnerable package from the framework that consumes it. When duplicate CVEs are surfaced as if they were separate flaws, remediation queues become polluted and teams spend time on the wrong layer. The governance lesson is straightforward: precision in dependency attribution is part of secure software delivery.
The real attack surface in modern JavaScript stacks is the transitive runtime layer. Framework branding hides the fact that exploitable behaviour often lives in shared server-side packages. That means security teams need package-level visibility across build manifests, lock files, and SBOM data, not only top-level framework labels. The practitioner conclusion is to treat transitive runtime packages as first-class security assets.
Transitive attribution drift: This incident illustrates the failure mode where the reported framework is not the vulnerable source, yet the alerting workflow still points there. That creates a control gap between detection and fixability. Teams that cannot trace the dependency path end up with noisy triage and delayed patching, so the practical answer is to align SCA policy to source-package evidence.
Duplicate CVE handling should reduce work, not obscure accountability. NVD rejection can look like a loss of coverage when it is actually a normalization step. Security programmes that measure success by raw alert counts miss the point, because the real metric is whether the finding resolves to one actionable package. Practitioners should demand deduplication logic that preserves evidence and remediation clarity.
This pattern is a reminder that software supply chain governance and identity governance now overlap. Build pipelines, package registries, and deployment systems are machine identities that decide what code is trusted. If those identities can introduce or amplify false vulnerability signals, the security team loses confidence in the automation layer. The conclusion for practitioners is to govern software trust chains with the same precision used for privileged access.
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.
- From our research: Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, according to The State of Non-Human Identity Security.
- For a broader view of machine trust risk, see The 52 NHI breaches Report, which tracks how unmanaged identities and stale credentials become breach paths.
What this signals
SCA programmes are now measured by whether they preserve source-of-truth attribution across the dependency graph, not by how many alerts they emit. For identity and application teams, that means build systems, package registries, and release pipelines function like machine identities that must be governed with the same care as privileged service accounts. The practical signal is to improve evidence quality before expanding detection volume.
Dependency attribution drift: when the scanner names the wrapper instead of the runtime, remediation drifts away from the true exploit path. That creates a governance problem across DevSecOps and identity-adjacent automation because the pipeline itself becomes a trust boundary. Teams should pair SCA policy with clear ownership for transitive packages and duplicated findings.
If you need a control baseline for how machine identities and runtime trust should be handled, align review workflows with the Top 10 NHI Issues and the 52 NHI Breaches Analysis. The pattern is consistent: once trust is inferred from a label rather than verified from the source, remediation quality drops.
For practitioners
- Audit lock files for the vulnerable runtime packages Inspect package trees for react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack, then confirm whether the vulnerable versions are present in the resolved graph.
- Upgrade the package that actually carries the flaw Move to patched versions of the affected React Server Component packages or the Next.js releases that bundle them, then verify the resolved dependency tree after the update.
- Consolidate duplicate CVEs in SCA workflows Configure triage so duplicate records map back to one source issue and one remediation path, which prevents wrapper frameworks from being treated as independent vulnerabilities.
- Validate exploitability against the runtime path Test whether the vulnerable code is reachable through the application’s actual server component flow before escalating severity or assigning emergency patch work.
Key takeaways
- CVE-2025-66478 is a signal-quality problem as much as a vulnerability problem, because duplicate attribution can send teams to the wrong remediation target.
- The exploitable code sits in React Server Component runtimes, which means transitive dependency visibility is the real control point for SCA accuracy.
- Security teams should consolidate duplicate CVEs, verify the resolved dependency tree, and patch the runtime package that actually contains the flaw.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0002 , Execution; TA0006 , Credential Access | The flaw enables attacker-controlled code execution through a server-side deserialisation path. |
| NIST CSF 2.0 | PR.IP-1 | The article centres on secure software development and dependency control in the pipeline. |
| NIST SP 800-53 Rev 5 | SA-12 | The issue is a software assurance and supply chain traceability problem. |
| CIS Controls v8 | CIS-16 , Application Software Security | The post is about application security controls for open-source dependencies. |
| NIST AI RMF | MAP | The article’s main governance need is to map the actual risk source before acting. |
Map exploitable runtime paths to execution and credential-access techniques, then verify reachability before prioritising fixes.
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 your software uses indirectly through another dependency. It matters because the vulnerable code may live several layers below the framework you selected, so accurate remediation depends on resolving the entire dependency graph, not only the top-level package name.
- 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.
- React Server Components: React Server Components are server-side components that separate rendering work between the browser and the server. Because they deserialize data and execute on the server, their runtime becomes a security boundary, and flaws there can expose applications that merely bundle the package.
What's in the full analysis
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- Exact package inventory command examples for checking resolved React Server Component versions
- The full patched-version matrix for Next.js and the underlying runtime packages
- How Veracode maps duplicate CVEs back to a single source issue in its analysis pipeline
- The vendor's step-by-step remediation guidance for teams working from SBOM and lock-file evidence
👉 Veracode's full post covers the vulnerable package path, affected versions, and remediation steps
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a stronger control model for the identity and trust chains that modern software supply pipelines depend on.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
