{"affected":[{"ranges":[{"events":[{"introduced":"e6bf11a812d7aa8b69d854ba8ef02d65516f5564"},{"fixed":"3131f1701194b581ab4b3e5e9d81194fc9c83508"}],"repo":"https://github.com/nerves-hub/nerves_hub_web","type":"GIT"}]}],"aliases":["GHSA-9vr9-463q-46qp","CVE-2026-119446"],"credits":[{"name":"Amr Kadry","type":"FINDER"},{"name":"Amr Kadry","type":"REPORTER"},{"name":"Josh Kalderimis","type":"REMEDIATION_DEVELOPER"},{"name":"Jonatan Männchen / EEF","type":"COORDINATOR"}],"database_specific":{"capec_ids":["CAPEC-61"],"cpe_ids":["cpe:2.3:a:nerves-hub:nerves_hub_web:*:*:*:*:*:*:*:*"],"cwe_ids":["CWE-384"]},"details":"## Summary\n\nSession Fixation vulnerability in the CLI login flow in nerves-hub nerves_hub_web allows an unauthenticated attacker to obtain an API token for another user's account via a crafted login link. Starting a CLI login with `POST /api/auth/cli_session` needs no authentication and returns a polling token, a confirmation URL that carries that token, and a confirmation code. When a signed-in user opens that URL and clicks Confirm, `NervesHub.Accounts.verify_cli_session_token/2` creates an API token for the user's account and stores it on the login, and the next poll of `GET /api/auth/cli_session/<token>` returns it to whoever started the login.\n\nThe confirmation code is only displayed and is never compared with anything, so it cannot show that the person confirming is the one who started the login. The confirm form carries a CSRF token and the page cannot be framed, so the attacker has to persuade the user to open the link and click the button themselves.\n\nThis issue affects nerves_hub: from 2.5.0 before 2.5.3.\n\n## Details\n\n**1. Starting a login.** `nh user login`, like any client of this flow, calls `POST /api/auth/cli_session`, which needs no authentication. `NervesHubWeb.API.UserController.cli_session/2` calls `NervesHub.Accounts.generate_cli_session_token/1`, which stores a waiting login in the CLI session cache under a random UUID token with a six-digit confirmation code, and responds with the token, the code, and the URL `/auth/cli/<token>`.\n\n**2. Approving a login.** `GET /auth/cli/<token>` requires a signed-in web user. `NervesHubWeb.SessionController.cli/2` finds the login by the token from the URL, shows the code, and renders a form that posts back to `/auth/cli/<token>`. The form carries no code field. `cli_confirm/2` passes the signed-in user and the token to `NervesHub.Accounts.verify_cli_session_token/2`, which creates an API token for that user with `create_user_api_token/2` and stores it on the login. Nothing compares the confirmation code with anything.\n\n**3. Collecting the token.** `GET /api/auth/cli_session/<token>`, also unauthenticated, returns the stored API token once the login is confirmed. Whoever started the login holds the token from step 1 and can poll until it arrives. The token is an ordinary API token and stays valid until the user deletes it.\n\n## Proof of concept\n\n1. With no account, run `curl -X POST https://<host>/api/auth/cli_session`. Note `token`, `url` and `confirmation_code` from the response.\n2. Send `url` to someone with a NervesHub account, with a message such as \"Please verify your NervesHub CLI access. Your code is `<confirmation_code>`.\"\n3. They open it while signed in, see the code they were told to expect, and click \"Confirm login\".\n4. `curl https://<host>/api/auth/cli_session/<token>` returns `\"status\": \"ready\"` and a `user_token`.\n5. Send API requests with `Authorization: token <user_token>`. They run as the person who confirmed.\n\n## Impact\n\nAn attacker with no account obtains an API token for any NervesHub user they can persuade to open a link and click Confirm. The token acts as that user through the API in every organization they belong to, at their role, until the user deletes it on the account page. Signing out of the web does not revoke it.\n\n## Workarounds\n\nBlock `POST /api/auth/cli_session` at the reverse proxy until the upgrade. It is the only entry point that creates a CLI login, so no link can be produced while it is blocked. CLIs can still sign in with an email and password (`nh user auth`, `POST /api/users/auth`), or use an API token created on the account page.\n\n## Solutions\n\nUpgrading does not revoke tokens already handed out. A token from a CLI login is an ordinary API token with a note the client chose, so one an attacker obtained looks like any other. After upgrading, users should review their API tokens on the account page and delete any they do not recognise.","id":"EEF-CVE-2026-119446","modified":"2026-11-10T10:44:15.757170Z","published":"2026-11-10T10:44:15.336Z","references":[{"type":"ADVISORY","url":"https://github.com/nerves-hub/nerves_hub_web/security/advisories/GHSA-9vr9-463q-46qp"},{"type":"WEB","url":"https://cna.erlef.org/cves/CVE-2026-119446.html"},{"type":"WEB","url":"https://github.com/nerves-hub/nerves_hub_web/commit/e6bf11a812d7aa8b69d854ba8ef02d65516f5564"},{"type":"FIX","url":"https://github.com/nerves-hub/nerves_hub_web/commit/3131f1701194b581ab4b3e5e9d81194fc9c83508"}],"related":[],"schema_version":"1.7.3","severity":[{"score":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H","type":"CVSS_V4"}],"summary":"Session fixation in the CLI login flow allows an unauthenticated attacker to obtain a user's API token","upstream":[]}