| パッケージ | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| strapi | < 5.33.3 | 5.33.3 |
| @strapi/admin | < 5.33.3 | 5.33.3 |
| @strapi/plugin-users-permissions | < 5.33.3 | 5.33.3 |
CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N (2.1 — Low)@strapi/admin and @strapi/plugin-users-permissions <=5.33.2In Strapi versions prior to 5.33.3, changing or resetting a user's password did not invalidate the user's existing refresh-token sessions by default. The refresh-token invalidation step in the users-permissions and admin authentication controllers was conditional on a caller-supplied deviceId. When a password change or reset request did not include a deviceId, no refresh tokens were revoked, leaving every prior session active.
An attacker who had previously obtained a refresh token could continue minting new access tokens after the legitimate user reset their password, allowing persistent unauthorized access for the lifetime of the refresh token (up to 30 days by default). Rotating credentials no longer terminated an active attacker session, defeating password reset as a containment measure.
The patch invalidates all refresh tokens associated with the user on every password change and password reset, regardless of whether a deviceId is supplied. A new device-scoped session is then issued to the caller as part of the response.
Indicators that an instance running an unpatched version may have been exploited:
POST /api/auth/refresh or POST /admin/access-token requests using a refresh token issued before the user's most recent password change. Reviewable by correlating refresh-token iat claims against password-change events in audit logsstrapi_session with created_at earlier than the user's most recent password-reset timestamp and status = 'active'これらの製品をお使いですか？サイトをスキャンして、脆弱なバージョンが公開されていないか確認しましょう。
無料でサイトをスキャン