CVE-2025-46743
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedAn authenticated user's token could be used by another source after the user had logged out prior to the token expiring.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · moderate confidenceThis is a session token invalidation vulnerability where authenticated tokens remain valid after user logout. When a user logs out, the token is not being invalidated server-side, allowing the expired session token to continue being used by other parties until natural token expiration occurs.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- Low
- User interaction
- Required
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- High
- Availability
- Low
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:L
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Test token validity after logoutAuthenticate with valid credentials to obtain a session token, perform logout, then attempt to use that same token in subsequent API requests to the same endpoints that require authenticationAffected if The token continues to grant access after logout (requests return 200 OK instead of 401 Unauthorized)
-
Inspect logout endpoint implementationReview the backend code for the logout endpoint - check if it performs server-side session invalidation, token blacklist update, or session state removal versus only clearing the token from the client-side responseAffected if The logout function only returns a success response without performing any server-side invalidation operations
-
Verify token blacklist or server-side session storage existsCheck if the application maintains a server-side token blacklist, session store, or revoked tokens table that is consulted during request authenticationAffected if No server-side token revocation mechanism exists or is not consulted during token validation
-
Check token expiration configurationReview the token configuration to determine the token lifetime/expiration period, and check if logout relies solely on client-side token removal rather than server-side expiration enforcementAffected if Tokens have long expiration periods (days/weeks) and logout does not trigger immediate server-side invalidation
-
Review authentication middleware validation logicExamine the middleware or filter that validates incoming tokens - determine if it checks against any server-side revocation list or only validates signature and expiration timestampAffected if The validation logic does not query any server-side state and only verifies token cryptographic properties
You are affected if logout does not actively invalidate tokens server-side and previously issued tokens continue to work after logout until their natural expiration
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
From vendor dataImplement server-side token invalidation at logout time by maintaining a token blacklist or server-side session state, and invalidate tokens immediately upon logout rather than relying solely on client-side token removal.
- Consultation3.0 h
- Implementation8.0 h
- Testing4.0 h
- Review / QA2.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,800.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2025-46743 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2025-46743 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data