Notifications
Clear all
Topic starter
11/07/2026 8:27 pm
TL;DR: Hundreds of live tokens were found within hours by a new JWT detector, according to TruffleHog, while also showing that shared-secret JWTs appeared 28 times more often than public-key JWTs in a large GitHub sample. The result is a sharper view of how stateless credentials complicate exposure detection, revocation, and remediation.
NHIMG editorial — based on content published by TruffleHog: TruffleHog now detects JWTs with public-key signatures and verifies them for liveness
By the numbers:
- Shared-secret-based JWTs were 28x more frequently than public-key ones in several hundred gigabytes of recent GitHub content.
Questions worth separating out
Q: How should security teams handle leaked JWTs that cannot be centrally revoked?
A: Treat them as time-bounded but live access, not as ordinary text secrets.
Q: Why do JWTs create different risk than API keys in identity programmes?
A: JWTs embed identity and authorisation claims inside the credential, so a leaked token can carry both proof and permission.
Q: What should teams get wrong about JWT liveness detection?
A: They should not treat local liveness checks as the same thing as business-authorised access.
Practitioner guidance
- Map JWT classes to revocation paths Document which token types rely on expiry only, which can be invalidated by signing-key rotation, and which support a central revocation check.
- Separate detection from proof of liveness Record whether your scanning pipeline can verify a JWT locally, infer likely validity, or only flag exposure.
- Shorten token lifetimes where revocation is weak Reduce the blast radius of leaked JWTs by cutting expiration windows, especially for tokens issued to SaaS integrations and cloud workloads where central invalidation is limited.
What's in the full article
TruffleHog's full post covers the operational detail this post intentionally leaves for the source:
- The detector logic for parsing JWT headers, payloads, and signatures before liveness checks
- The exact OIDC Discovery workflow used to verify public-key JWTs
- The edge cases TruffleHog will not verify today, including non-routing IP issuers and shared-secret tokens
- The trade-offs behind ignoring HMAC-based JWTs while preserving actionable findings
👉 Read TruffleHog's analysis of live JWT detection and revocation limits →
JWT liveness verification: what it means for IAM and secret scanning?
Explore further
11/07/2026 8:56 pm
Stateless access creates a revocation gap, not just a detection gap. JWTs are designed so applications can validate them without a central lookup, which makes them operationally efficient and governance-light until something leaks. Once exposure occurs, the same design that reduced latency also removes the simplest invalidation path. The implication is that leaked JWTs are not ordinary secrets with a tidy reset path; they are live access artefacts whose remediation depends on how the issuer and application were built.
A few things that frame the scale:
- The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
A question worth separating out:
Q: How do security teams reduce the blast radius of exposed JWTs?
A: Limit token lifetime, improve where tokens are stored, and remove unnecessary reliance on stateless access where revocation matters. If a token type cannot be invalidated cleanly after exposure, it should be designed with much tighter expiry and stronger surrounding monitoring.
👉 Read our full editorial: JWT liveness verification exposes the limits of stateless access
