ENISA Technical Advisory on Secure Package Managers: Essential DevSecOps Guidance
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2025-55182 | Unauthenticated RCE in React Server Components (React2Shell) CVE-2025-55182 is a critical (CVSS 10.0) pre-authentication remote code execution flaw (CWE-502, deserialization of untrusted data) in React Server Components, specifically the react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack packages in versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0. It is triggered when the vulnerable code unsafely deserializes payloads from HTTP requests sent to Server Function endpoints, requiring no authentication or user interaction. An attacker gains arbitrary code execution on the affected server (CVSS scope changed, with high impact to confidentiality, integrity, and availability), and reporting notes a campaign in which hackers used the flaw to breach 766 Next.js hosts and steal credentials. Any React/Next.js application exposing Server Functions with the affected React versions is in scope, which given the ubiquity of React and Next.js is a very large deployed base. Exploitation is confirmed in the wild: the flaw was added to CISA's Known Exploited Vulnerabilities catalog on 2025-12-05 with known ransomware use, EPSS puts the 30-day exploitation probability at 99.8%, multiple public PoC/scanner repositories are available, and coverage has dubbed the flaw React2Shell. Do: Upgrade the react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack packages to the vendor-patched releases (any version later than the vulnerable 19.0.0, 19.1.0, 19.1.1, and 19.2.0 line) and update Next.js per Vercel's advisory; as a KEV entry, U.S. federal agencies must apply vendor mitigations per BOD 22-01 or discontinue use. Audit internet-exposed Server Function endpoints for the vulnerable React versions and review logs for exploitation activity, including the reported campaign that breached 766 Next.js hosts and stole credentials, then rotate any exposed credentials. | 10.0 | 100% | KEV ransomware PoC ×7 |
| mass≈1M+ internet-facing Next.js/React Server Components deployments (order-of-magnitude estimate) |
Full article768 words · extracted from securityaffairs.com · click to collapse
ENISA’s first Technical Advisory on Secure Package Managers helps developers safely use third-party packages.
ENISA has released its first Technical Advisory on Package Managers, focusing on how developers can safely consume third-party packages. The document (March 2026, v1.1) follows public feedback incorporating 15 contributions from stakeholders, experts, and the open-source community.
“This document focuses on how developers can securely use package managers as part of their software development life cycle.” states the report. “In particular, this document, outlines common risks involved in the use of third-party packages, presents secure practices for selecting, integrating, and monitoring packages and describes approaches for addressing vulnerabilities found in dependencies.”
Modern software relies on package managers like npm, pip, and Maven for code reuse and easy updates, but they carry supply chain risks, as seen in 2025 attacks (npm, XRP, Shai-Hulud 2.0). This advisory guides secure package selection, integration, monitoring, and vulnerability mitigation at the application level, using npm/GitHub examples while applying principles broadly.
Package managers are essential in modern software, automating installation, updates, and removal of libraries with their dependencies. They involve packages (reusable code), dependencies (direct or transitive), developers (publishers), applications (consumers), repositories (npm, PyPI), and the managers themselves (npm, pip).
Developers publish code, which others download and integrate. For example, npm install express fetches express plus ~68 dependencies. Not all installed code runs at runtime, reachability analysis identifies active modules, helping prioritize security risks, as vulnerabilities in unused code are less likely exploitable.
Packages boost collaboration through sharing and reuse, efficiency by avoiding reinventing the wheel, consistency with standardized components, maintainability via centralized updates, and quality from repeated testing across projects. Yet this interconnectedness amplifies risks: a vulnerability in express, with 100k+ direct dependencies and over 1M transitive ones, can devastate entire ecosystems. React’s CVE-2025-55182 (CVSS 10.0) threatened 12M sites. A single malicious dependency cascades globally, turning convenience into a massive attack surface.
Package risks come in two main forms. First, inherent vulnerabilities from poor coding (e.g., input validation flaws, path traversal, info leaks, unsafe deserialization) or abandoned packages like node-serialize or crypto-js. Second, supply chain attacks—malicious packages, compromised legit packages (event-stream, ua-parser-js), typosquatting (crossenv), or namespace confusion, can ripple widely, as seen with npm, which affects 2.6B weekly downloads and millions of downstream projects.
When selecting and integrating third-party packages, developers should follow a careful, structured approach to reduce security risks. During the selection phase, it’s crucial to choose packages from trusted sources with clear provenance and maintainers with a reliable reputation. Scanning for known vulnerabilities using tools like npm audit or OSV, verifying signatures and package integrity, and reviewing maintainer activity and popularity metrics help ensure that dependencies are both secure and actively maintained. Minimizing the number of dependencies and avoiding packages with unsafe scripts further reduces the attack surface.
During integration, developers should adopt practices that enforce transparency and control. Generating a Software Bill of Materials (SBOM) allows teams to track exactly what code is included in a project. Running vulnerability scans in CI/CD pipelines, using lockfiles and SHA hashes to enforce integrity, employing local package proxies, skipping install scripts when possible, and pinning specific package versions help prevent unexpected changes. Committing lockfiles and reviewing changelogs before upgrades ensures that updates are deliberate and safe, maintaining the security and reliability of the software supply chain.
Effective monitoring and mitigation are essential for securing third-party packages. For monitoring, integrate SBOM-based scanners like Grype or osv-scanner into CI/CD pipelines to continuously track vulnerabilities. Keep up with CVEs via EUVD, OSV.dev, Snyk, NVD, or Dependabot, and watch for outdated packages, deprecations, or changes in maintainers that could signal risks.
For mitigation, prioritize fixes using CVSS scores, EPSS, KEV catalogs, VEX statements, and reachability analysis with tools such as CodeQL or Semgrep. Address issues by patching, isolating affected components, or rolling back to safe versions, while updating SBOMs, mitigation notes, and notifying stakeholders to maintain long-term supply chain security.
“This document is intended to serve as a starting point with concise guidance on package consumption
within software projects, encouraging risk aware decision making when consuming and managing thirdparty packages. While many of the listed examples focus on npm, pip and GitHub, the recommendations are designed to apply across package manager ecosystems.” concludes the report. “The software supply chain landscape continues to evolve, with new tools, processes and risks emerging over time. Therefore, organisations should treat this subject as an ongoing activity and periodically review and update their practices to reflect changes in available tooling, threats and ecosystem-specific guidance.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, ENISA)
Text extracted automatically; images, tables and formatting may be missing. Original: https://securityaffairs.com/189333/security/enisa-technical-advisory-on-secure-package-managers-essential-devsecops-guidance.html