Integration tokens · Rollout complete; header retirement scheduled
Check how integrations handle longer GitHub tokens
Announced October 2, 2026. Sources checked October 5, 2026.
New GitHub App installation tokens now use the stateless format by default. They retain the ghs_ prefix but are approximately 520 characters, rather than 40. Permissions, repository scope and the one-hour lifetime are unchanged. GitHub will stop honoring the X-GitHub-Stateless-S2S-Token override header on November 30, 2026.
Who it affects. GitHub App installation integrations on Enterprise Cloud, including data residency and Actions GITHUB_TOKEN. The original rollout notice excludes Enterprise Server. This is not a new personal-access-token lifetime policy.
What remains uncertain. The announcement cannot establish whether your storage, HTTP intermediaries or log redaction accept the longer format. Its approximate length is not a fixed size to validate against.
One next step. Assign the integration owner an end-to-end check of token handling and redaction, treating tokens as opaque strings; after validating both formats, remove any override header before November 30.
Credential rotation · Confirmed advisory; fix available
Loom's security fix includes credential follow-up
Announced October 2, 2026. Sources checked October 5, 2026.
AWS disclosed authentication and outbound-request flaws in Loom, its open-source agent orchestration platform. Version 1.7.0 addresses the token-disclosure and connection-handling issues; its September 20 release predates this advisory. Version 1.6.1 fixed the separate authentication bypass but did not fully fix token disclosure.
Who it affects. Loom deployments below 1.7.0: users with mcp:write or a2a:write access could trigger the outbound-request flaws. The authentication bypass affects versions below 1.6.1 where no identity provider was configured.
What remains uncertain. The advisory does not establish exploitation in your deployment. Restricting integration-management access is an interim measure, not a complete fix. The upgrade alone does not replace credentials that may have been exposed.
One next step. Have the deployment owner coordinate the 1.7.0 upgrade and AWS's post-upgrade steps: rotate integration OAuth2 client secrets and revoke and reissue tokens active during the affected window. If container role credentials were accessed, follow AWS's session-credential and CloudTrail guidance.
Related
Where to go next
GitHub credential inventories and the next SSH changes