CVE-2026-92918 is a sensitive information exposure in admin3 through version 3.0.0. User session tokens are saved in the audit log, so a user who can view logs can read them and replay them as login credentials. NVD scores it High (8.8). We could not confirm a fixed version.
What's affected
The NVD record lists admin3 through 3.0.0 as affected. The weakness is CWE-532, insertion of sensitive information into a log file. The vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.
The record says the session tokens are persisted in the event body when the application publishes a login event, and that a user holding the log view permission can read them from the logs API. The tokens can then be used as bearer credentials for full user access.
We did not find a vendor advisory or release naming a fix. The project's repository is the place to look for anything after 3.0.0. Until you have confirmed a fix, treat all existing log entries as sensitive.
How to check if you're exposed
Check the version of admin3 you run. Then look at who holds the log view permission. In an admin framework that role is often given to auditors, support staff or developers, and each of them could read tokens that belong to others.
Check your stored logs too. If tokens are written to the audit table or files, anyone with database or backup access can read them as well, so the exposure is wider than the API alone.
Paste a lockfile or SBOM into the free in-browser dependency scan to see whether this package is in your tree, including as a transitive dependency. Safeguard's reachability analysis can then show whether your code actually calls the affected path, which helps you order the work.
What to do now
- Restrict the log view permission to the smallest group possible.
- Invalidate current sessions and force users to sign in again once you have cut off the leak, so tokens already in the logs are useless.
- Purge or redact the token field from stored audit logs and from backups where you can.
- Check the project repository for a release after 3.0.0 and update when a fix exists.
- Shorten session lifetimes so a stolen token expires quickly.
Why it matters
Logs are copied, shipped and read by many people. A secret that lands in a log therefore spreads to every place that logs go. A session token is a password with an expiry, and anyone who has one can act as the user. The record explains that this application writes the token into the body of a login event, and then serves those events through an API.
The fix is to leave secrets out of event data and to treat log access as sensitive. The attacker needs an account with the log permission, which is why the score is high but not at the top. The KEV flag in the record is false and no source we read reports exploitation.
Quick check
Is a fixed version available?
We could not confirm one. Check the project repository for versions after 3.0.0.
Why clear sessions after the fix?
Tokens already stored in logs remain valid until they expire or are revoked, so invalidating sessions makes any copies useless.
Sources
Last reviewed: 18 October 2026.
