Brief · Builders
Your agent checked who you were, then forgot.
CVE-2026-114463 is a Critical authorization bypass in Nous Research's Hermes Agent webhook gateway. Tenable lists CVSS 3.1 9.1 (Critical); NVD has not published a score as of Oct 23, 2026. Affected: through 2026.8.19. Fixed in v0.22.2; the fix PR merged Sep 18. Not on CISA KEV. No exploitation reported. EPSS sits around 0.4%.
Here's the bug in one sentence. The gateway authenticated the exact route from the URL, then looked up that route's tools by splitting a composite session id on colons. So a route named build:external quietly got build's terminal and file tools.
Per the researcher advisory, Hermes builds chat_id as webhook:{route_name}:{delivery_id}, then recovers the route with a colon split and loads that route's toolsets. Authentication used the URL segment. Authorization used the split. Those are two different strings when the route name itself contains :. Same family as an admin page that only checks login in the browser: you proved you belonged on the weak door, and the house handed you the keys to the strong one.
The attacker still needs a valid HMAC for the weak route, plus a colon-named route sitting next to a more powerful sibling (think build:external next to build, or github:issues next to github). That is not the default layout, but it is exactly how people namespace webhook routes. The advisory's PoC is a correctly signed POST to /webhooks/build:external that ends up with [terminal, file] instead of [web].
My take: the CVSS is loud because remote + high impact. The preconditions are quieter. Patch on schedule, not because the sky fell.
Sidebar: more agent plumbing, same week
- Flowise CVE-2026-41137: CSVAgent lets custom Pandas read code run on the server. Authenticated RCE (or easier if Flowise auth defaults are weak). Fixed in 3.1.0.
- CrewAI CVE-2026-92206: unsafe reflection in
load_agent_from_repository, CVSS 8.8. Needs the target to load a malicious agent config. ZDI lists no patched version yet; treat repository-loaded agents as untrusted code until one ships.
What to do:
- Upgrade Hermes Agent to v0.22.2 or later. The fix keys toolset lookup on the authenticated route (
source.user_id), with no colon split. - If you cannot upgrade yet: rename every webhook route so no name contains
:. That closes the ambiguity without the patch. - Audit colon-named routes now. Per the advisory, review agent logs for webhook sessions on
:-named routes that used tools outside that route's configured toolsets. Treat any hit as privilege escalation until proven otherwise. - Keep privileged toolsets off shared-prefix siblings. Do not put
terminal/fileonbuildifbuild:externalexists for a partner, CI, or public-repo hook. Separate secrets per route, and assume a leaked partner secret is enough for the weak door. - Incident response, if a colon route was reachable with a leaked or partner-held secret:
- Preserve webhook and agent logs for those routes before you rotate.
- Check which tools ran on the weak route versus what it was configured for.
- Rotate every route secret the agent host could read, plus LLM provider keys and connected-service tokens on that box.
- Rebuild or re-image if terminal/file tools actually ran under the wrong grant.