NORA missing cross-user token-management authorization
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| getnora-io | nora | affected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Getnora-io | Nora |
|
No CVSS v4.0
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.199% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Getnora-io
Getnora-io nora |
|
| Vendors & Products |
Getnora-io
Getnora-io nora |
| Type | Values Removed | Values Added |
|---|---|---|
| Description | NORA is a self-hosted artifact registry and pull-through cache. Prior to 0.9.5, `nora-registry` authenticates the token-management UI but fails to require administrator authorization. `auth_middleware()` protects `/ui/tokens` and `/api/ui/tokens`, but state-changing requests are checked only with `role.can_write()`, not `role.can_admin()`. `tokens_page()` and `tokens_list()` call `store.list_all_tokens()`, exposing IDs and metadata across all users, while `tokens_revoke()` calls `store.revoke_token` using the supplied token ID without an ownership or admin check. A read bearer token can enumerate other users' token existence, owner, role, description, expiry and last-use metadata. A write bearer token or write-capable OIDC identity can additionally revoke arbitrary admin and service tokens, disrupting the registry and forcing credential recovery. Read-only identities cannot POST a revocation. This issue is fixed in version 0.9.5. | |
| Title | NORA missing cross-user token-management authorization | |
| Weaknesses | CWE-862 | |
| References |
| |
| Metrics |
cvssV3_1
|