Summary
PyJWT==2.8.0 in apiserver/requirements/base.txt does not validate the crit (Critical) header parameter per RFC 7515 §4.1.11. An attacker can craft tokens with unknown critical extensions that PyJWT silently accepts, bypassing any security policies encoded in JWT headers.
CVE Details
- CVE: CVE-2026-32597
- Advisory: GHSA-752w-5fwx-jx9f
- Severity: HIGH —
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N (7.5)
- CWE: CWE-345 (Insufficient Verification of Data Authenticity), CWE-863 (Incorrect Authorization)
Package Details
- Package:
PyJWT
- Current version:
2.8.0
- Fixed version:
2.12.0
- File:
apiserver/requirements/base.txt
Impact
RFC 7515 §4.1.11 states a JWS is invalid if it contains crit header extensions not understood by the recipient. PyJWT accepts such tokens instead of rejecting them.
Exploitation scenarios:
- Policy bypass: Any custom JWT enforcement via
crit (MFA required, scope restrictions, token binding per RFC 7800) is silently ignored by PyJWT
- Split-brain deployments: API gateway with compliant library rejects → Plane backend with PyJWT accepts — authentication inconsistency
- Token forgery: Attacker crafts token with
crit extension that encodes elevated privileges; backend never validates the extension
Affected Code
All JWT verification in the Plane apiserver authentication stack (apiserver/), specifically any call to jwt.decode(...).
Triage Reasoning
Escalating because:
- Direct impact on authentication integrity
2.8.0 → 2.12.0 minor version bump — behavioral changes in JWT decoding warrant human review and test validation- Audit required: are there any custom
crit header usages (or assumptions about no crit) in existing token handling?
Recommended Action
- In
apiserver/requirements/base.txt, change PyJWT==2.8.0 → PyJWT==2.12.0
- Review all
jwt.decode() call sites — check options dict for verify_signature, verify_exp, etc.
- Test auth flows (login, session token, API key) post-upgrade
- Confirm Plane does not issue tokens with
crit headers (in which case this is lower exploitability)
Mitigations In Place
- If Plane only issues HS256 tokens without
crit headers (likely for internal auth), exploitability requires attacker to supply a crafted token — still a bypass risk but reduced in practice
Summary
PyJWT==2.8.0inapiserver/requirements/base.txtdoes not validate thecrit(Critical) header parameter per RFC 7515 §4.1.11. An attacker can craft tokens with unknown critical extensions that PyJWT silently accepts, bypassing any security policies encoded in JWT headers.CVE Details
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N(7.5)Package Details
PyJWT2.8.02.12.0apiserver/requirements/base.txtImpact
RFC 7515 §4.1.11 states a JWS is invalid if it contains
critheader extensions not understood by the recipient. PyJWT accepts such tokens instead of rejecting them.Exploitation scenarios:
crit(MFA required, scope restrictions, token binding per RFC 7800) is silently ignored by PyJWTcritextension that encodes elevated privileges; backend never validates the extensionAffected Code
All JWT verification in the Plane apiserver authentication stack (
apiserver/), specifically any call tojwt.decode(...).Triage Reasoning
Escalating because:
2.8.0 → 2.12.0minor version bump — behavioral changes in JWT decoding warrant human review and test validationcritheader usages (or assumptions about nocrit) in existing token handling?Recommended Action
apiserver/requirements/base.txt, changePyJWT==2.8.0→PyJWT==2.12.0jwt.decode()call sites — checkoptionsdict forverify_signature,verify_exp, etc.critheaders (in which case this is lower exploitability)Mitigations In Place
critheaders (likely for internal auth), exploitability requires attacker to supply a crafted token — still a bypass risk but reduced in practice