Token rotation · Available; optional adoption
Test expiring GitHub App user tokens gradually
Announced October 13, 2026. Sources checked October 19, 2026.
Requesting offline_access returns an expiring user access token and a refresh token even when the app has disabled token expiration. It applies to that authorization and does not change future sessions or grant additional permissions.
Who it affects. GitHub App developers using user access tokens, especially those who previously disabled expiration. This is separate from installation tokens and their recent format change. GitHub identifies Enterprise Server 3.23 for offline_access support.
What remains uncertain. There is no mandatory migration date in the announcement. Existing non-expiring tokens do not become expiring merely because an app enables expiration. GitHub documents eight-hour user tokens and six-month refresh tokens; using a refresh token invalidates it and the old user token.
One next step. Have the integration owner test one authorization with offline_access, including refresh and reauthentication, before planning how to retire existing non-expiring tokens.
Registry credentials · Generally available on github.com
Remove placeholder tokens from anonymous registry access
Announced October 12, 2026. Sources checked October 19, 2026.
An organization-level registry can now allow Dependabot to reach its host without storing or sending credentials. This supports mirrors that allow anonymous reads, including repositories using only security updates without a dependabot.yml file.
Who it affects. Organizations using Dependabot with a reachable registry that does not require authentication. Access remains limited to the repositories granted that registry definition. The option is available on github.com; GitHub lists Enterprise Server 3.24 for server availability.
What remains uncertain. The option does not make an authenticated registry anonymous or establish network reachability. An existing registry's authentication method cannot be edited; switching requires deleting its definition and recreating it. No migration deadline is announced.
One next step. Ask the registry owner to check whether a placeholder token is still needed. If anonymous reads are intended, plan the documented recreation with the same repository access and verify a Dependabot update afterward.
Credential exposure · Confirmed advisory; fix available
Check SageMaker Git-clone logs for credential exposure
Announced October 14, 2026. Sources checked October 19, 2026.
The SDK's Git-clone error handling can leave plaintext repository credentials in logs readable by authenticated users with log access. AWS identifies fixes in V2 version 2.257.3 and V3 version 3.10.0.
Who it affects. SageMaker Python SDK V2 before 2.257.3 and V3 from 3.0.0 to before 3.10.0, including affected derivative code. This concerns credentials used for Git repositories; it is not a claim that every SageMaker workload or AWS account credential was exposed.
What remains uncertain. The advisory does not establish whether your jobs logged credentials or whether anyone accessed them. An SDK upgrade alone does not resolve credentials already recorded in retained logs.
One next step. Assign the SDK owner an upgrade and failed-clone log review with the security owner. AWS advises rotating credentials found in affected output; pending upgrade, avoid credentials in Git URLs and restrict log access. Record findings without copying secrets.
Related
Where to go next
Lifecycle checks: TLS renewal, npm trust, and AWS passwords