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.
5548 vulnerabilities reference this CWE, most recent first.
GHSA-Q94G-3GCF-66X7
Vulnerability from github – Published: 2026-04-22 18:31 – Updated: 2026-07-06 20:16Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-47c7-qrm7-mqw7. This link is maintained to preserve external references.
Original Description
The id utility in uutils coreutils miscalculates the groups= section of its output. The implementation uses a user's real GID instead of their effective GID to compute the group list, leading to potentially divergent output compared to GNU coreutils. Because many scripts and automated processes rely on the output of id to make security-critical access-control or permission decisions, this discrepancy can lead to unauthorized access or security misconfigurations.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "coreutils"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.8.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-30T17:51:17Z",
"nvd_published_at": "2026-04-22T17:16:40Z",
"severity": "MODERATE"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-47c7-qrm7-mqw7. This link is maintained to preserve external references.\n\n### Original Description\nThe id utility in uutils coreutils miscalculates the groups= section of its output. The implementation uses a user\u0027s real GID instead of their effective GID to compute the group list, leading to potentially divergent output compared to GNU coreutils. Because many scripts and automated processes rely on the output of id to make security-critical access-control or permission decisions, this discrepancy can lead to unauthorized access or security misconfigurations.",
"id": "GHSA-q94g-3gcf-66x7",
"modified": "2026-07-06T20:16:40Z",
"published": "2026-04-22T18:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35370"
},
{
"type": "WEB",
"url": "https://github.com/uutils/coreutils/issues/10006"
},
{
"type": "PACKAGE",
"url": "https://github.com/uutils/coreutils"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Duplicate Advisory: uutils coreutils has an Incorrect Authorization issue",
"withdrawn": "2026-07-06T20:16:40Z"
}
GHSA-Q969-VW55-R9VR
Vulnerability from github – Published: 2023-03-31 21:30 – Updated: 2023-04-11 06:30An authentication bypass vulnerability in the web client interface for the CL4NX printer before firmware version 1.13.3-u724_r2 provides remote unauthenticated attackers with access to execute commands intended only for valid/authenticated users, such as file uploads and configuration changes.
{
"affected": [],
"aliases": [
"CVE-2023-23594"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-31T19:15:00Z",
"severity": "CRITICAL"
},
"details": "An authentication bypass vulnerability in the web client interface for the CL4NX printer before firmware version 1.13.3-u724_r2 provides remote unauthenticated attackers with access to execute commands intended only for valid/authenticated users, such as file uploads and configuration changes.",
"id": "GHSA-q969-vw55-r9vr",
"modified": "2023-04-11T06:30:29Z",
"published": "2023-03-31T21:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23594"
},
{
"type": "WEB",
"url": "https://d2n1rly8br52rx.cloudfront.net/content-blocks/files/pages/Vulnerability-Disclosure.pdf"
},
{
"type": "WEB",
"url": "https://hackandpwn.com/disclosures/CVE-2023-23594.pdf"
},
{
"type": "WEB",
"url": "https://www.satoamerica.com/products/printers/industrial-thermal-printers/cl4nx-plus"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q99W-VH6V-Q3V7
Vulnerability from github – Published: 2026-06-18 13:03 – Updated: 2026-06-18 13:03Summary
In affected releases, a surviving pairing-scoped session for a device could re-establish node token authority after that node token had been revoked. Revocation should require the device to lose that authority unless it is approved again through the normal pairing flow.
This issue affects token revocation and device-role containment. It does not allow unauthenticated device creation.
Affected configurations
This affects deployments where an already paired device keeps a same-device session with pairing-related scope after its node token is revoked.
Impact
A device that should have lost node WebSocket authority could regain it without renewed approval. That weakens revocation as an operator control and can keep node-level access alive longer than intended.
The impact is limited to devices that already had a legitimate pairing/session foothold.
Patched Versions
The first stable patched version is 2026.5.26.
Mitigations
Upgrade to openclaw@2026.5.26 or later. If a node token was revoked on an older version, restart the gateway and remove/re-pair the affected device to ensure no stale session remains active.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.5.26"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53843"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T13:03:24Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nIn affected releases, a surviving pairing-scoped session for a device could re-establish node token authority after that node token had been revoked. Revocation should require the device to lose that authority unless it is approved again through the normal pairing flow.\n\nThis issue affects token revocation and device-role containment. It does not allow unauthenticated device creation.\n\n### Affected configurations\n\nThis affects deployments where an already paired device keeps a same-device session with pairing-related scope after its node token is revoked.\n\n### Impact\n\nA device that should have lost node WebSocket authority could regain it without renewed approval. That weakens revocation as an operator control and can keep node-level access alive longer than intended.\n\nThe impact is limited to devices that already had a legitimate pairing/session foothold.\n\n### Patched Versions\n\nThe first stable patched version is `2026.5.26`.\n\n### Mitigations\n\nUpgrade to `openclaw@2026.5.26` or later. If a node token was revoked on an older version, restart the gateway and remove/re-pair the affected device to ensure no stale session remains active.",
"id": "GHSA-q99w-vh6v-q3v7",
"modified": "2026-06-18T13:03:24Z",
"published": "2026-06-18T13:03:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-q99w-vh6v-q3v7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53843"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-node-token-revocation-bypass-via-pairing-scoped-device-session"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "OpenClaw: Pairing-scoped device session could restore revoked node token authority"
}
GHSA-Q99X-MJMH-V8W7
Vulnerability from github – Published: 2024-11-11 15:31 – Updated: 2024-11-12 21:26A flaw was found in moodle. Matrix room membership and power levels are incorrectly applied and revoked for suspended Moodle users.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "4.4.0"
},
{
"fixed": "4.4.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "4.3.0"
},
{
"fixed": "4.3.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-43433"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-11-12T21:26:47Z",
"nvd_published_at": "2024-11-11T13:15:04Z",
"severity": "LOW"
},
"details": "A flaw was found in moodle. Matrix room membership and power levels are incorrectly applied and revoked for suspended Moodle users.",
"id": "GHSA-q99x-mjmh-v8w7",
"modified": "2024-11-12T21:26:47Z",
"published": "2024-11-11T15:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43433"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2304261"
},
{
"type": "PACKAGE",
"url": "https://github.com/moodle/moodle"
},
{
"type": "WEB",
"url": "https://moodle.org/mod/forum/discuss.php?d=461202"
},
{
"type": "WEB",
"url": "http://git.moodle.org/gw?p=moodle.git\u0026a=search\u0026h=HEAD\u0026st=commit\u0026s=MDL-81951"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Moodle\u0027s user/power level management inconsistent with suspended users"
}
GHSA-Q9H3-R6WR-P3J3
Vulnerability from github – Published: 2025-06-11 15:30 – Updated: 2025-06-11 17:50Incorrect Authorization vulnerability in Drupal Commerce Eurobank (Redirect) allows Functionality Misuse. This issue affects Commerce Eurobank (Redirect): from 0.0.0 before 2.1.1.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/commerce_eurobank_redirect"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-48445"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-11T17:49:57Z",
"nvd_published_at": "2025-06-11T15:15:42Z",
"severity": "HIGH"
},
"details": "Incorrect Authorization vulnerability in Drupal Commerce Eurobank (Redirect) allows Functionality Misuse. This issue affects Commerce Eurobank (Redirect): from 0.0.0 before 2.1.1.",
"id": "GHSA-q9h3-r6wr-p3j3",
"modified": "2025-06-11T17:50:14Z",
"published": "2025-06-11T15:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48445"
},
{
"type": "WEB",
"url": "https://www.drupal.org/sa-contrib-2025-066"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Drupal Commerce Eurobank (Redirect) Incorrect Authorization vulnerability"
}
GHSA-Q9HR-J4RF-8FJC
Vulnerability from github – Published: 2023-01-25 22:02 – Updated: 2023-02-07 21:21Impact
All versions of Argo CD starting with v1.8.2 are vulnerable to an improper authorization bug causing the API to accept certain invalid tokens.
OIDC providers include an aud (audience) claim in signed tokens. The value of that claim specifies the intended audience(s) of the token (i.e. the service or services which are meant to accept the token). Argo CD does validate that the token was signed by Argo CD's configured OIDC provider. But Argo CD does not validate the audience claim, so it will accept tokens that are not intended for Argo CD.
If Argo CD's configured OIDC provider also serves other audiences (for example, a file storage service), then Argo CD will accept a token intended for one of those other audiences. Argo CD will grant the user privileges based on the token's groups claim, even though those groups were not intended to be used by Argo CD.
This bug also increases the blast radius of a stolen token. If an attacker steals a valid token for a different audience, they can use it to access Argo CD.
Patches
A patch for this vulnerability has been released in the following Argo CD versions:
- v2.6.0-rc5
- v2.5.8
- v2.4.20
- v2.3.14
The patch introduces a new allowedAudiences to the OIDC config block. By default, the client ID is the only allowed audience. Users who want Argo CD to accept tokens intended for a different audience may use allowedAudiences to specify those audiences.
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-cm
data:
oidc.config: |
name: Example
allowedAudiences:
- audience-1
- audience-2
- argocd-client-id # If `allowedAudiences` is non-empty, Argo CD's client ID must be explicitly added if you want to allow it.
``
Even though [the OIDC spec requires the audience claim](https://openid.net/specs/openid-connect-core-1_0.html#IDToken), some tokens may not include it. To avoid a breaking change in a patch release, versions < 2.6.0 of Argo CD will skip the audience claim check for tokens that have no audience. In versions >= 2.6.0, Argo CD will reject all tokens which do not have an audience claim. Users can opt into the old behavior by setting an option:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-cm
data:
oidc.config: |
name: Example
skipAudienceCheckWhenTokenHasNoAudience: true
Workarounds
There is no workaround besides upgrading.
Credits
The Argo CD team would like to express their gratitude to Vladimir Pouzanov (@farcaller) from Indeed, who discovered the issue, reported it confidentially according to our guidelines, and actively worked with the project to provide a remedy. Many thanks to Vladimir!
References
- How to configure OIDC in Argo CD
- OIDC spec section discussing the audience claim
- JWT spec section discussing the audience claim
For more information
- Open an issue in the Argo CD issue tracker or discussions
- Join us on Slack in channel #argo-cd
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd"
},
"ranges": [
{
"events": [
{
"introduced": "1.8.2"
},
{
"fixed": "2.3.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.20"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd"
},
"ranges": [
{
"events": [
{
"introduced": "2.5.0"
},
{
"fixed": "2.5.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd"
},
"ranges": [
{
"events": [
{
"introduced": "2.6.0-rc1"
},
{
"fixed": "2.6.0-rc5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-22482"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-25T22:02:52Z",
"nvd_published_at": "2023-01-26T21:18:00Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nAll versions of Argo CD starting with v1.8.2 are vulnerable to an improper authorization bug causing the API to accept certain invalid tokens.\n\nOIDC providers include an `aud` (audience) claim in signed tokens. The value of that claim specifies the intended audience(s) of the token (i.e. the service or services which are meant to accept the token). Argo CD _does_ validate that the token was signed by Argo CD\u0027s configured OIDC provider. But Argo CD _does not_ validate the audience claim, so it will accept tokens that are not intended for Argo CD.\n\nIf Argo CD\u0027s configured OIDC provider also serves other audiences (for example, a file storage service), then Argo CD will accept a token intended for one of those other audiences. Argo CD will grant the user privileges based on the token\u0027s `groups` claim, even though those groups were not intended to be used by Argo CD.\n\nThis bug also increases the blast radius of a stolen token. If an attacker steals a valid token for a different audience, they can use it to access Argo CD.\n\n### Patches\n\nA patch for this vulnerability has been released in the following Argo CD versions:\n\n* v2.6.0-rc5\n* v2.5.8\n* v2.4.20\n* v2.3.14\n\nThe patch introduces a new `allowedAudiences` to the OIDC config block. By default, the client ID is the only allowed audience. Users who _want_ Argo CD to accept tokens intended for a different audience may use `allowedAudiences` to specify those audiences.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: argocd-cm\ndata:\n oidc.config: |\n name: Example\n allowedAudiences:\n - audience-1\n - audience-2\n - argocd-client-id # If `allowedAudiences` is non-empty, Argo CD\u0027s client ID must be explicitly added if you want to allow it.\n``\n\nEven though [the OIDC spec requires the audience claim](https://openid.net/specs/openid-connect-core-1_0.html#IDToken), some tokens may not include it. To avoid a breaking change in a patch release, versions \u003c 2.6.0 of Argo CD will skip the audience claim check for tokens that have no audience. In versions \u003e= 2.6.0, Argo CD will reject all tokens which do not have an audience claim. Users can opt into the old behavior by setting an option:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: argocd-cm\ndata:\n oidc.config: |\n name: Example\n skipAudienceCheckWhenTokenHasNoAudience: true\n```\n\n### Workarounds\n\nThere is no workaround besides upgrading.\n\n### Credits \n\nThe Argo CD team would like to express their gratitude to Vladimir Pouzanov (@farcaller) from Indeed, who discovered the issue, reported it confidentially according to our [guidelines](https://github.com/argoproj/argo-cd/blob/master/SECURITY.md#reporting-a-vulnerability), and actively worked with the project to provide a remedy. Many thanks to Vladimir!\n\n### References\n\n* [How to configure OIDC in Argo CD](https://argo-cd.readthedocs.io/en/latest/operator-manual/user-management/#existing-oidc-provider)\n* [OIDC spec section discussing the audience claim](https://openid.net/specs/openid-connect-core-1_0.html#IDToken)\n* [JWT spec section discussing the audience claim](https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3)\n\n### For more information\n\n* Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)\n* Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd\n",
"id": "GHSA-q9hr-j4rf-8fjc",
"modified": "2023-02-07T21:21:41Z",
"published": "2023-01-25T22:02:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-q9hr-j4rf-8fjc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22482"
},
{
"type": "PACKAGE",
"url": "https://github.com/argoproj/argo-cd"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "JWT audience claim is not verified"
}
GHSA-Q9M6-5CW7-GV47
Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2022-07-13 00:01There is an arbitrary password modification vulnerability in a D-LINK DSL-2888A router product. An attacker can use this vulnerability to modify the password of the admin user without authorization.
{
"affected": [],
"aliases": [
"CVE-2021-33346"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-24T16:15:00Z",
"severity": "CRITICAL"
},
"details": "There is an arbitrary password modification vulnerability in a D-LINK DSL-2888A router product. An attacker can use this vulnerability to modify the password of the admin user without authorization.",
"id": "GHSA-q9m6-5cw7-gv47",
"modified": "2022-07-13T00:01:25Z",
"published": "2022-05-24T19:06:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33346"
},
{
"type": "WEB",
"url": "https://github.com/EmYiQing/CVE"
},
{
"type": "WEB",
"url": "https://www.dlink.com/en/security-bulletin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q9MX-5PVJ-QH3X
Vulnerability from github – Published: 2022-05-24 17:07 – Updated: 2023-01-31 21:30A Local Privilege Escalation issue was discovered in Avast Secure Browser 76.0.1659.101. The vulnerability is due to an insecure ACL set by the AvastBrowserUpdate.exe (which is running as NT AUTHORITY\SYSTEM) when AvastSecureBrowser.exe checks for new updates. When the update check is triggered, the elevated process cleans the ACL of the Update.ini file in %PROGRAMDATA%\Avast Software\Browser\Update\ and sets all privileges to group Everyone. Because any low-privileged user can create, delete, or modify the Update.ini file stored in this location, an attacker with low privileges can create a hard link named Update.ini in this folder, and make it point to a file writable by NT AUTHORITY\SYSTEM. Once AvastBrowserUpdate.exe is triggered by the update check functionality, the DACL is set to a misconfigured value on the crafted Update.ini and, consequently, to the target file that was previously not writable by the low-privileged attacker.
{
"affected": [],
"aliases": [
"CVE-2019-17190"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-01-27T16:15:00Z",
"severity": "HIGH"
},
"details": "A Local Privilege Escalation issue was discovered in Avast Secure Browser 76.0.1659.101. The vulnerability is due to an insecure ACL set by the AvastBrowserUpdate.exe (which is running as NT AUTHORITY\\SYSTEM) when AvastSecureBrowser.exe checks for new updates. When the update check is triggered, the elevated process cleans the ACL of the Update.ini file in %PROGRAMDATA%\\Avast Software\\Browser\\Update\\ and sets all privileges to group Everyone. Because any low-privileged user can create, delete, or modify the Update.ini file stored in this location, an attacker with low privileges can create a hard link named Update.ini in this folder, and make it point to a file writable by NT AUTHORITY\\SYSTEM. Once AvastBrowserUpdate.exe is triggered by the update check functionality, the DACL is set to a misconfigured value on the crafted Update.ini and, consequently, to the target file that was previously not writable by the low-privileged attacker.",
"id": "GHSA-q9mx-5pvj-qh3x",
"modified": "2023-01-31T21:30:19Z",
"published": "2022-05-24T17:07:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17190"
},
{
"type": "WEB",
"url": "https://www.avast.com/bug-bounty-credits/en/a-tribute-to-our-security-research-community"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/156844/Avast-Secure-Browser-76.0.1659.101-Local-Privilege-Escalation.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2020/Mar/25"
}
],
"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-Q9R7-JM84-GWH8
Vulnerability from github – Published: 2022-06-14 00:00 – Updated: 2024-09-17 00:31In Festo Controller CECC-X-M1 product family in multiple versions, the http-endpoint "cecc-x-web-viewer-request-on" POST request doesn’t check for port syntax. This can result in unauthorized execution of system commands with root privileges due to improper access control command injection.
{
"affected": [],
"aliases": [
"CVE-2022-30308"
],
"database_specific": {
"cwe_ids": [
"CWE-78",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-13T14:15:00Z",
"severity": "CRITICAL"
},
"details": "In Festo Controller CECC-X-M1 product family in multiple versions, the http-endpoint \"cecc-x-web-viewer-request-on\" POST request doesn\u00e2\u20ac\u2122t check for port syntax. This can result in unauthorized execution of system commands with root privileges due to improper access control command injection.",
"id": "GHSA-q9r7-jm84-gwh8",
"modified": "2024-09-17T00:31:00Z",
"published": "2022-06-14T00:00:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30308"
},
{
"type": "WEB",
"url": "https://cert.vde.com/en/advisories/VDE-2022-020"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q9X2-H7VP-CFX6
Vulnerability from github – Published: 2022-05-24 17:43 – Updated: 2022-05-24 17:43Insufficient policy enforcement in QR scanning in Google Chrome on iOS prior to 89.0.4389.72 allowed an attacker who convinced the user to scan a QR code to bypass navigation restrictions via a crafted QR code.
{
"affected": [],
"aliases": [
"CVE-2021-21186"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-09T18:15:00Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in QR scanning in Google Chrome on iOS prior to 89.0.4389.72 allowed an attacker who convinced the user to scan a QR code to bypass navigation restrictions via a crafted QR code.",
"id": "GHSA-q9x2-h7vp-cfx6",
"modified": "2022-05-24T17:43:59Z",
"published": "2022-05-24T17:43:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21186"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2021/03/stable-channel-update-for-desktop.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1153445"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BBT54RKAE5XLMWSHLVUKJ7T2XHHYMXLH"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/FE5SIKEVYTMDCC5OSXGOM2KRPYLHYMQX"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LCIDZ77XUDMB2EBPPWCQXPEIJERDNSNT"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202104-08"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4886"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.