This blog post applies the lessons from Node4Shell to the upcoming Node.js security releases on 11 November 2026 and shows SAP BAIP teams why the buildpack release, not the SAP Note, should trigger their restage.
The Node.js project has announced security releases for Wednesday, 11 November 2026. Updates are planned for all supported release lines: 26.x, 24.x and 22.x. For each line, the most severe issue fixed is rated HIGH. CVE details and the number of vulnerabilities will only be published with the release.
For SAP customers running custom SAP Cloud Application Programming Model (CAP) applications on SAP Business AI Platform (BAIP) Cloud Foundry, the next step is predictable. Cloud Foundry will ship a new nodejs-buildpack, SAP will roll it out on the BAIP landscapes, and SAP will most likely publish a security note some days later.
Only two weeks ago, Node4Shell showed us how this sequence plays out in practice. This post explains what that experience means for next week, and what SAP teams can prepare today.
The Node4Shell timeline was:
21.10.2026: Node4Shell (CVE-2026-111497) is published.
22.10.2026, 19:42: Cloud Foundry releases nodejs-buildpack v1.9.6 with the fix. SAP rolls it out on all BAIP Cloud Foundry landscapes.
28.10.2026: SAP publishes security note 3843368 (CVSS 9.8).
The fixed buildpack was available on BAIP about one day after the vulnerability was published. The SAP Note followed six days later. Running applications don't pick up a new buildpack automatically; they only use the fixed version after they have been restaged or redeployed. Teams that waited for the SAP Note therefore left their productive CAP applications vulnerable for about a week.
The key point: for Node.js on BAIP, the SAP Note is not the starting signal. The buildpack release is.
What to expect next week
11.11.2026: Node.js publishes the patched versions and CVE details.
~ 1-2 days later: New nodejs-buildpack (after v1.9.6) is released and rolled out on BAIP Cloud Foundry.
some days later: SAP security note for BAIP expected.
The exact buildpack version number isn't known yet. What matters is that the buildpack version shown for your applications is newer than v1.9.6 and contains the patched Node.js versions from 11 November.
Make a list of all CAP applications on BAIP Cloud Foundry, across all subaccounts and spaces, with their owners. During Node4Shell, the most time was lost finding out which applications existed and who was allowed to restage them. A quick overview per space:
cf apps
Search your mta.yaml files for buildpack URLs that pin a fixed release, for example:
buildpack: https://github.com/cloudfoundry/nodejs-buildpack/releases/download/v1.9.1/nodejs-buildpack-cflinuxfs4-v1.9.1.zip
instead of:
buildpack: nodejs_buildpack
For these applications, a restage doesn't help, because it downloads the same old buildpack again. Fix this now, while there is no time pressure, and redeploy. Then next week a restage is enough.
The same applies to package.json. If the engines field pins an exact version, for example "node": "20.11.0", the buildpack can't switch to a patched version. Use a major-version range instead:
"engines": { "node": "^22" }
The Node.js project points out that end-of-life versions are always affected by security releases, and they won't get a fix. Any application still on Node.js 20 or older won't be fixed by a restage at all. Check the CAP release schedule as well. Moving to Node.js 22 or newer may require a CAP upgrade, which turns a five-minute restage into a project. Plan that work this week, not after the CVEs are public.
Agree in advance who restages which application, and in which order. Start with internet-facing applications and those processing external input. The command itself is simple:
cf restage <app> --strategy rolling
The rolling strategy replaces instances one at a time, so the application stays available.
- Watch the Node.js security release announcement on 11 November and assess the published CVEs for your applications.
- Watch for the new nodejs-buildpack release and its rollout on your BAIP landscape. Don't wait for the SAP Note.
- Restage or redeploy as soon as the new buildpack is available.
- Verify the result for every application:
cf app <app>
The buildpacks line must show a version newer than v1.9.6.
- Don't trust local updates. As with Node4Shell, a developer who updates Node.js on their machine on 11 November and deploys immediately is not protected. On Cloud Foundry, the Node.js version comes from the buildpack, not from the developer's machine.
- When the SAP Note is published, use it to confirm your assessment and document the result. By then, the work should already be done.
Node4Shell wasn't a one-off. Security releases for Node.js arrive several times a year, and each one follows the same path to BAIP: upstream release, new buildpack, SAP Note. Monitoring only SAP Security Notes means always being about a week behind.
Applications that are updated regularly can be patched with a restage. Applications that were left untouched after go-live often need an emergency upgrade first. Regular small updates are much cheaper than one large upgrade under time pressure.
Prepare this week, restage as soon as the new buildpack is available, and treat the SAP Note as confirmation, not as the trigger.
