Account recovery · In effect when announced
npm recovery now includes a publishing pause
Announced September 9, 2026. Sources checked October 29, 2026.
npm extended a protection previously limited to high-impact accounts. During the hold, publishing and access-token creation are unavailable; sign-in and package installation remain available. The hold ends automatically and cannot be lifted early.
Who it affects. This affects npm account holders who sign in with a recovery code, especially maintainers responsible for a release. It is not a new expiry date for all npm tokens.
What remains uncertain. The announcement does not describe every interaction with existing automation. Do not assume a particular CI release path will remain available during an account hold.
One next step. Update one release runbook with the recovery delay and an already authorized fallback maintainer. Keep recovery codes in their secure storage, and record only the owner and procedure in your team inventory.
Publishing credentials · Generally available
npm allows more than one trusted publishing workflow
Announced September 3, 2026. Sources checked October 29, 2026.
Maintainers can now configure separate trusted publishing paths for the same package. Their permissions are additive: matching any one configuration can authorize a publish or stage operation. New configurations permit staging; direct publishing is an additional choice.
Who it affects. This is useful for npm maintainers with several release workflows. npm documents support for GitHub-hosted runners, GitLab.com shared runners, and CircleCI cloud, with up to ten configurations per package. Self-hosted runners are not supported.
What remains uncertain. There is no mandatory migration deadline. OIDC publishing does not remove every token dependency, such as authentication to install private packages, and existing configurations retain their documented behavior.
One next step. Map one remaining publishing token to its workflow and owner. If that workflow is supported, test a narrowly scoped trusted publisher before retiring the old token; review every configuration because one cannot restrict another.
Temporary cloud credentials · Confirmed advisory; fix available
Check SSM Agent versions on nodes with remote-host forwarding
Announced September 10, 2026. Sources checked October 29, 2026.
AWS reports that an authenticated user with remote-host port-forwarding permission can bypass the destination denylist in SSM Agent versions below 3.3.4851.0. Reaching an instance metadata endpoint can expose the instance role's temporary credentials. Version 3.3.4851.0 addresses the issue; its release predates the September advisory.
Who it affects. Assess managed nodes running affected agents and the principals allowed to start remote-host forwarding sessions. This is not a blanket finding that all AWS access keys are compromised.
What remains uncertain. The advisory establishes a possible exposure, not whether your nodes were accessed or credentials were taken. The permissions attached to the instance role determine what exposed credentials could access.
One next step. Ask the managed-node owner to check agent versions and forwarding permissions, then schedule the documented upgrade where needed. Link the version check and completion evidence to the team's follow-up; suspected exposure needs your incident-response process.
Related
Where to go next
Shorter certificate lifetimes. A little preparation goes a long way.