AxonHub EUVD-2026-113936

Exploitation requires an authenticated AxonHub principal who holds the project-level write_api_keys scope (CVSS PR:L); it is not exploitable by anonymous/unauthenticated users. The specific trigger is creating a service_account-type API key whose requested scopes are not validated against the creator's own granted scopes, allowing a project user to attach system-level scopes (e.g., read_channels) to the minted key and then call the /admin/graphql endpoint. Limiting factors: a valid account with write_api_keys is mandatory, the deployment must be AxonHub at or before 1.0.0-beta11, no user interaction is needed, and the demonstrated confidentiality impact is reading channel configuration (base URLs, model lists); broader impact (e.g., system credential exposure via data-storage scopes) depends on which system scopes the attacker chooses to mint, which the pre-patch code did not restrict.

This is a genuine but moderate-priority issue rather than a top-tier emergency. The supplied CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N) scores 5.3 (Medium): the attack is network-reachable with low complexity and no user interaction, but it is NOT unauthenticated - PR:L means the attacker must already hold a valid AxonHub account with the project-level write_api_keys scope, which is the single largest limiting factor. The rated impact is confidentiality-only and Low (VC:L), matching the description's stated outcome of reading channel configuration (base URLs, model lists). The vuln.today Decision label is 'this_month' - meaningful but explicitly not act_now/emergency - and this is consistent with the signals: no CISA KEV listing is present in the input, so there is no confirmed active exploitation, and no EPSS probability was provided, so widespread-exploitation likelihood cannot be quantified from this data. A public write-up (hackmd) is referenced, so exploit knowledge is public even though no confirmed working exploit package is supplied. One important nuance worth flagging for responders: the root cause is unvalidated scope assignment on service_account keys, meaning a project user can mint keys carrying arbitrary system-level scopes - the patch evidence shows data storages hold system-wide credentials (DSN, S3 keys, WebDAV passwords) and now require a dedicated read_data_storages scope, so the latent blast radius of the scope-minting flaw is larger than the demonstrated channel-config read, even though the officially rated and description-confirmed impact remains Low confidentiality. Net: prioritize patching within the normal cycle, but it does not warrant emergency out-of-band action on these signals alone.

An attacker who already has an authenticated AxonHub project account with the write_api_keys scope creates a service_account API key and assigns it system-level scopes such as read_channels, which the server fails to validate against the creator's own privileges. Using that minted key, the attacker calls the /admin/graphql endpoint to enumerate every channel's configuration across the whole system, including upstream base URLs and model lists. A public technical write-up describing this scope-escalation path is referenced (hackmd), though no confirmed working exploit package is provided in the input.