CVE-2026-85105 is a high severity (CVSS 7.3) authorization bypass in NousResearch hermes-agent 0.18.0. Manipulating the session_id argument of the _sess_nowait function in session management bypasses authorization checks. The vendor did not respond to the disclosure, and no fix is confirmed.
What's affected
The record lists NousResearch hermes-agent 0.18.0. The function is _sess_nowait in the file s71.py, part of the session management component. Changing the session_id argument results in an authorization bypass, and the record says it can be started remotely. The record also says the vendor was contacted early about the disclosure and did not respond.
I could not retrieve the VulDB pages, which block automated requests, so I have only the record. I found no second source on the severity, the affected range beyond 0.18.0, or a patch. Treat the fix status as unknown and check the project's repository and releases for anything newer.
The vector is network, low complexity, no privileges and no interaction, with low impact on each of confidentiality, integrity and availability. That puts it in the high band overall, at 7.3.
How to check if you're exposed
Find out whether you run hermes-agent and which version. Check how it was installed. If it came from a Python package manager, ask for the version:
pip list | grep -i hermes
If you run it from a source checkout or a container image, read the version file or the image tag. Version 0.18.0 is the one named in the record, so treat nearby versions as unconfirmed rather than safe.
Then ask who can reach the service. The weakness is network based and needs no account, so exposure is decided by where the agent listens. If it is on a loopback address or a private network behind authentication, the exposure is small. If it is reachable from the internet, treat it as the priority.
What to do now
- Find every hermes-agent deployment and record its version and who can reach it.
- Take the agent off any public network, or put it behind a proxy that requires authentication.
- Check the project's repository and release notes for a fix, because the record names none.
- Review session records and logs for session identifiers used by clients they do not belong to.
- Keep a note to recheck the project each week until a fixed release appears.
Why it matters
The record lists improper authorization, CWE-285, and authorization bypass through a user controlled key, CWE-639. This is the classic insecure direct object reference: the application takes an identifier from the request, here a session id, and uses it to find a record without asking whether the caller is allowed to use that record.
For an agent that holds conversations, context and possibly credentials in its sessions, that exposure may be significant, even though the CVSS impact values are low. The lack of a vendor response means you will have to reduce exposure yourself. The record does not list this CVE as exploited in the wild.
Quick check
Is there a patched version?
None is confirmed. The record says the vendor did not respond to the disclosure. Check the project's repository.
Does the attacker need an account?
The vector lists no privileges required, so a remote caller who can reach the service is enough.
Sources
Last reviewed: 18 October 2026.
