Publishing credentials · Available, opt-in
npm adds tokens that stage a release for approval
Announced September 18, 2026. Sources checked September 21, 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 publishing existing npm packages with token-based automation. Staging requires npm CLI 11.15.0+ and Node.js 22.14.0+; the approving maintainer needs package publish access and two-factor authentication.
What remains uncertain. Existing tokens do not change with this release. npm targets January 2027 for removing direct publishing with bypass-2FA tokens, but has not supplied an exact enforcement day. Treat that month as a planning target, not a newly fixed expiry date.
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 November 2
Announced September 17, 2026. Sources checked September 21, 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 November 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 November 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 September 21, 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