Publishing credentials · Available, opt-in
npm adds tokens that stage a release for approval
Announced September 18, 2026. Sources checked October 29, 2026.
On September 18, npm introduced an opt-in permission for granular tokens that blocks direct publication while allowing a version to be staged. A maintainer approves release with two-factor authentication. These tokens can still change dist-tags and deprecate versions; they are not read-only credentials.
Who it affects. Teams using token-based npm automation. Since October 2, staged publishing also supports creating public scoped or unscoped packages and private scoped packages with a local session or granular token, including a stage-only token. npm CLI 11.15.0+ and Node.js 22.14.0+ are required; the approving maintainer needs publish access and two-factor authentication.
What remains uncertain. For new public packages, a 0.0.0-stage placeholder is visible, while the submitted version stays unavailable until approval. Existing tokens are not changed by the stage-only option. npm still targets January 2027 for removing direct publishing with bypass-2FA tokens without an exact enforcement day.
One next step. Have the release owner test a stage-and-approve workflow and record its approver and fallback before replacing the current publishing token.
Workflow access · Generally available
Review privileged GitHub workflows before December 2
Announced September 17, 2026. Sources checked October 29, 2026.
GitHub made workflow execution protections generally available on September 17. Its default event policy currently evaluates pull_request_target runs and is scheduled to block them for affected repositories on December 2.
Who it affects. Public repositories without an applicable event policy; the announced enforcement cohort used the default policy before general availability. The default does not cover private or internal repositories, and it does not replace an existing applicable policy. This matters because the trigger can give a workflow access to the base repository's secrets and token.
What remains uncertain. The announcement cannot establish whether a particular repository is in that cohort or which runs its policy would block. Check the repository's effective policy rather than assuming a universal cutoff.
One next step. Assign the workflow owner to review policy insights and the credential access of each affected workflow before December 2, deciding whether the trigger is necessary and documenting a narrowly scoped exception only after reviewing the code it runs.
Client authentication · Confirmed advisory; fix available
Check hostname validation in AWS IoT Python clients
Announced September 17, 2026. Sources checked October 29, 2026.
AWS's September 17 advisory describes missing TLS hostname checks in AWSIoTPythonSDK. An attacker positioned on the network could present a certificate for another hostname, issued by a CA in the device's trust store, to impersonate the endpoint. The corrected SDK is 1.6.1, released July 24.
Who it affects. Versions 1.5.3 to 1.6.0 on Python 3.7+, using the default mutual-TLS connection on port 8883 or WebSocket/SigV4 on port 443. AWS says the port 443 ALPN path is unaffected. This is client certificate validation, not a new certificate-lifetime rule and not a general finding against all AWS IoT clients.
What remains uncertain. The advisory does not establish exploitation on your devices or compromise of their private keys.
One next step. Ask the device-software owner to verify the SDK version, Python version, and connection path, then track the documented upgrade and a connection test for affected devices or derived code. AWS lists no workaround.
Related
Where to go next
Release access: npm recovery, trusted publishing, and an AWS agent fix