Update NL: NCSC heeft dit op HOOG gezet

Het NCSC-NL publiceerde advisory NCSC-2025-0380 met prioriteit Hoog. Op 5 december 2025 heeft NCSC het advies bovendien geüpdatet met een belangrijk detail: er is misbruik waargenomen sinds 3 december én er is inmiddels publieke proof-of-concept code beschikbaar (wat de kans op grootschalig misbruik sterk verhoogt). 

Wat NCSC concreet noemt (handig voor je inventarisatie)

Volgens NCSC zit het probleem in deze React packages/versies: 

• react-server-dom-webpack 19.0 / 19.1.0 / 19.1.1 / 19.2.0

• react-server-dom-parcel 19.0 / 19.1.0 / 19.1.1 / 19.2.0

• react-server-dom-turbopack 19.0 / 19.1.0 / 19.1.1 / 19.2.0

En NCSC benadrukt expliciet: ook als je geen Server Function endpoint “bewust” hebt gebouwd, kun je nog kwetsbaar zijn zolang je app React Server Components ondersteunt. 

Daarnaast noemt NCSC (en React) voorbeelden van frameworks/bundlers die hierdoor geraakt kunnen zijn: Next, React Router, Waku, @parcel/rsc, @vitejs/plugin-rsc, rwsdk. 

 Wat we nu al zien in aanvallen: “bewijs dat ik binnen ben”-checks (RCE)

Bij dit soort RCE-lekken doen aanvallers vaak eerst snelle “recon”-acties om te controleren of ze echt code kunnen uitvoeren en onder welke user de app draait. AWS noemt als typische signalen:

• het uitvoeren van Linux-commando’s zoals whoami, id en uname (wie ben ik / welke privileges / welk OS?)

• pogingen om /etc/passwd te lezen (snelle check of file read werkt)

• het wegschrijven van een testbestand in /tmp/ (bijv. pwned.txt) als “I was here”-marker

• nieuwe (child) processen die ineens door je Node/React-proces worden gestart 

Waarom dit relevant is voor jou: deze acties zijn vaak eerste indicators in logs/EDR, nog vóórdat er echte schade gebeurt (zoals webshells, credentials dumpen of data-exfiltratie).

Waarom je vooral het CVE-record (en advisories) in de gaten moet houden

Bij grote incidenten verandert de informatie snel — en dat zie je hier ook:

• NCSC heeft dit advies op 5 december 2025 geüpdatet met: misbruik waargenomen sinds 3 december én publieke proof-of-concept code beschikbaar (risico omhoog). 

• Affected/fixed versies worden soms bijgesteld of verduidelijkt (bijv. welke Next.js lijnen precies geraakt zijn en welke patchversies je moet pakken). 

• Soms worden CVE’s “herschaft”: bijv. analyses noemen dat CVE-2025-66478 uiteindelijk als duplicaat van CVE-2025-55182 is behandeld. Dat kan verwarring geven als je alleen losse screenshots of oude posts volgt; het CVE-record en vendor advisory zijn je “source of truth”. 

Praktisch advies: zet intern één owner die dagelijks (zolang het hot is) NCSC + vendor advisories + NVD checkt, zodat je niet patcht op basis van verouderde info.

AWS: “patchen is geen optie, het is de maatregel”

Amazon/AWS publiceerde zowel een security bulletin als een AWS Security Blog post. De kernboodschap is hetzelfde:

• Managed AWS services zijn niet geraakt.

• Draai je React/Next.js zelf (EC2, containers, eigen infra)? Update meteen.

• AWS noemt WAF/managed rules als extra laag, maar “geen vervanging voor patchen”. 

AWS meldt ook dat ze in honeypot-telemetrie exploitatiepogingen zien, en dat (delen van) die activiteit verband houden met infrastructuur die historisch aan China-nexus actoren gelinkt is (met de nuance dat attributie lastig blijft).  

“We patchen later wel” — een historisch voorbeeld waarom dat mis kan gaan (Equifax)

Als je ooit twijfelt of patchen echt zo’n verschil maakt: kijk naar Equifax (2017). In een officieel rapport van de U.S. House Committee on Oversight staat dat op 7 maart 2017 een Apache Struts-kwetsbaarheid publiek werd, Equifax intern opdroeg om binnen 48 uur te patchen, maar het uiteindelijk niet volledig deed. Aanvallers kwamen binnen, bleven 76 dagen onopgemerkt en het incident groeide uit tot één van de grootste databreach-verhalen ooit. 

Moraal: bij “internet-brede” kritieke bugs is het tijdvenster tussen disclosure → scanning → misbruik vaak uren tot dagen. En dát is precies waarom NCSC expliciet waarschuwt dat er nu PoC + waargenomen misbruik is. 

Wat moet je updaten (met code-voorbeelden)

Stap 0 — Check wat er écht geïnstalleerd is

Dit is de snelste reality-check:

npm ls next react react-dom react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack

Gebruik je pnpm of yarn?

pnpm why react-server-dom-webpack
yarn why react-server-dom-webpack

 1) Next.js: upgrade Next naar een gefixte versie

Next.js zegt: App Router apps zijn geraakt op 15.x, 16.x, en 14.3.0-canary.77+. Daar is geen config-toggle voor; patchen/upgrade is noodzakelijk. 
NPM (exact zoals Next adviseert):
npm install next@15.0.5   # for 15.0.x
npm install next@15.1.9   # for 15.1.x
npm install next@15.2.6   # for 15.2.x
npm install next@15.3.6   # for 15.3.x
npm install next@15.4.8   # for 15.4.x
npm install next@15.5.7   # for 15.5.x
npm install next@16.0.7   # for 16.0.x
Zit je op 14.3.0-canary.77 of hoger? Downgrade naar stable 14.x:
npm install next@14
Yarn:
yarn add next@15.5.7
# of:
yarn add next@16.0.7
pnpm:
pnpm add next@15.5.7
# of:
pnpm add next@16.0.7

2) React Server Components: upgrade de kwetsbare react-server-dom-* packages

React en NCSC noemen de kwetsbare set heel specifiek, inclusief de gefixte versies: 

• Kwetsbaar: 19.0 / 19.1.0 / 19.1.1 / 19.2.0

• Gefixt: 19.0.1 / 19.1.2 / 19.2.1

Als je deze packages direct in je project hebt staan (komt minder vaak voor dan “transitief via Next/Vite/Parcel”), dan:

NPM
npm install react-server-dom-webpack@19.2.1 react-server-dom-parcel@19.2.1 react-server-dom-turbopack@19.2.1
Yarn
yarn add react-server-dom-webpack@19.2.1 react-server-dom-parcel@19.2.1 react-server-dom-turbopack@19.2.1
pnpm
pnpm add react-server-dom-webpack@19.2.1 react-server-dom-parcel@19.2.1 react-server-dom-turbopack@19.2.1

Als het transitief binnenkomt (meest voorkomend): forceer met overrides/resolutions

npm (package.json → overrides)

{
  "overrides": {
    "react-server-dom-webpack": "19.2.1",
    "react-server-dom-parcel": "19.2.1",
    "react-server-dom-turbopack": "19.2.1"
  }
}

pnpm (package.json → pnpm.overrides)

{
  "pnpm": {
    "overrides": {
      "react-server-dom-webpack": "19.2.1",
      "react-server-dom-parcel": "19.2.1",
      "react-server-dom-turbopack": "19.2.1"
    }
  }
}

Yarn classic/berry (package.json → resolutions)

{
  "resolutions": {
    "react-server-dom-webpack": "19.2.1",
    "react-server-dom-parcel": "19.2.1",
    "react-server-dom-turbopack": "19.2.1"
  }
}

Daarna:

npm install
# of yarn install / pnpm install

3) Verifiëren dat je echt gepatcht bent

Na de upgrade:

npm ls next react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack

En als je met containers/CI werkt: verifieer óók in je gebouwde artifact/image (dus wat er daadwerkelijk draait).

“CVE-2025-66478” — wat is dat nu precies?

Next.js publiceert een advisory onder CVE-2025-66478 om de downstream impact op Next.js te volgen. 

AWS en NCSC melden dat dit CVE-id uiteindelijk als duplicaat/ingetrokken is en verwijzen naar de upstream CVE-2025-55182 als de kern. 

Praktisch maakt dit voor jouw actie weinig uit: patchen naar de gefixte versies blijft de opdracht.

Bronnen:

• https://www.cve.org/CVERecord?id=CVE-2025-55182

• https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

• https://www.ncsc.nl/actueel/nieuws/2025/12/4/kritieke-kwetsbaarheid-in-react-en-next.js

• https://aws.amazon.com/blogs/security/china-nexus-cyber-threat-groups-rapidly-exploit-react2shell-vulnerability-cve-2025-55182/