{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/vendors/lin-snow/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Ech0"],"_cs_severities":["high"],"_cs_tags":["credential-access","token-revocation","web-application"],"_cs_type":"advisory","_cs_vendors":["lin-snow"],"content_html":"\u003cp\u003eEch0, a self-hosted platform, has a vulnerability concerning the revocation of access tokens created with the \u0026ldquo;never expire\u0026rdquo; option. These tokens, lacking an \u003ccode\u003eexp\u003c/code\u003e (expiration) claim, bypass three revocation mechanisms. Specifically, the logout function panics when attempting to process these tokens due to a nil pointer dereference, while the admin\u0026rsquo;s \u0026ldquo;Delete token\u0026rdquo; function removes the database record without blacklisting the JTI (JWT ID). This means that if a \u0026ldquo;never expire\u0026rdquo; token is compromised, it remains valid until the \u003ccode\u003eJWT_SECRET\u003c/code\u003e is rotated, an action that affects all users on the platform. This issue was found by aisage.io. Version 4.5.6 is affected.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn administrator creates an access token with the \u0026ldquo;never expire\u0026rdquo; option. This token lacks the \u003ccode\u003eexp\u003c/code\u003e claim in its JWT.\u003c/li\u003e\n\u003cli\u003eThe attacker obtains a \u0026ldquo;never expire\u0026rdquo; token through theft or compromise (e.g., stolen laptop, exposed configuration file).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen token in an HTTP Authorization header to access protected resources. The middleware accepts the token since it has a valid signature.\u003c/li\u003e\n\u003cli\u003eThe legitimate owner attempts to revoke the token via logout. The logout handler attempts to parse the token and extract the expiration time.\u003c/li\u003e\n\u003cli\u003eParsing of the token in the logout handler leads to a panic because it attempts to access \u003ccode\u003e.Time\u003c/code\u003e field of a nil \u003ccode\u003eExpiresAt\u003c/code\u003e claim (present only on tokens with expiry). The token revocation is skipped.\u003c/li\u003e\n\u003cli\u003eThe administrator attempts to delete the access token via the admin panel. This action removes the metadata for the token from the database, but does not blacklist the JTI.\u003c/li\u003e\n\u003cli\u003eThe attacker continues to use the token for authorized requests, bypassing revocation attempts.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains perpetual access to the system, leveraging the scopes associated with the stolen token.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised \u0026ldquo;never expire\u0026rdquo; tokens grant attackers persistent authenticated access to Ech0 instances. This access remains valid until the \u003ccode\u003eJWT_SECRET\u003c/code\u003e is rotated, forcing a platform-wide reset. Administrators are misled by the \u0026ldquo;Delete token\u0026rdquo; function, which appears to revoke access but does not. The need to rotate the \u003ccode\u003eJWT_SECRET\u003c/code\u003e for proper revocation introduces a blast radius, requiring every user to log in again.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eReplace \u0026ldquo;never expire\u0026rdquo; tokens with very long-lived tokens, ensuring an \u003ccode\u003eexp\u003c/code\u003e claim exists. See code example in the overview section.\u003c/li\u003e\n\u003cli\u003eModify the logout handler to gracefully handle tokens with a nil \u003ccode\u003eExpiresAt\u003c/code\u003e field. See code example in the overview section.\u003c/li\u003e\n\u003cli\u003eWhen deleting an access token through the admin panel, blacklist the corresponding JTI. See code example in the overview section.\u003c/li\u003e\n\u003cli\u003eRotate the JWT secret immediately if a \u0026ldquo;never expire\u0026rdquo; token is suspected of being compromised. This invalidates all active tokens and prevents further unauthorized access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-07T21:34:01Z","date_published":"2026-05-07T21:34:01Z","id":"/briefs/2024-04-29-ech0-token-revocation/","summary":"Ech0's access tokens with the 'never expire' option cannot be revoked through logout or deletion, leading to persistent access until the JWT secret is rotated instance-wide.","title":"Ech0 'Never Expire' Access Tokens Cannot Be Revoked","url":"https://feed.craftedsignal.io/briefs/2024-04-29-ech0-token-revocation/"}],"language":"en","title":"CraftedSignal Threat Feed — Lin-Snow","version":"https://jsonfeed.org/version/1.1"}