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.
5678 vulnerabilities reference this CWE, most recent first.
GHSA-7GPQ-38WJ-HV97
Vulnerability from github – Published: 2022-04-12 00:00 – Updated: 2022-04-20 00:00Improper access control vulnerability in Samsung Security Supporter prior to version 1.2.40.0 allows attacker to set the arbitrary folder as Secret Folder without Samsung Security Supporter permission
{
"affected": [],
"aliases": [
"CVE-2022-28778"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-11T20:15:00Z",
"severity": "LOW"
},
"details": "Improper access control vulnerability in Samsung Security Supporter prior to version 1.2.40.0 allows attacker to set the arbitrary folder as Secret Folder without Samsung Security Supporter permission",
"id": "GHSA-7gpq-38wj-hv97",
"modified": "2022-04-20T00:00:57Z",
"published": "2022-04-12T00:00:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28778"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2022\u0026month=4"
}
],
"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-7GVM-PRWV-W6HM
Vulnerability from github – Published: 2026-03-26 21:31 – Updated: 2026-03-27 21:31Incorrect Authorization vulnerability in Drupal File Access Fix (deprecated) allows Forceful Browsing.This issue affects File Access Fix (deprecated): from 0.0.0 before 1.2.0.
{
"affected": [],
"aliases": [
"CVE-2026-3525"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-26T21:17:08Z",
"severity": "MODERATE"
},
"details": "Incorrect Authorization vulnerability in Drupal File Access Fix (deprecated) allows Forceful Browsing.This issue affects File Access Fix (deprecated): from 0.0.0 before 1.2.0.",
"id": "GHSA-7gvm-prwv-w6hm",
"modified": "2026-03-27T21:31:34Z",
"published": "2026-03-26T21:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3525"
},
{
"type": "WEB",
"url": "https://www.drupal.org/sa-contrib-2026-020"
}
],
"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-7GXG-937V-GFC4
Vulnerability from github – Published: 2022-05-24 19:14 – Updated: 2022-05-24 19:14An unauthorized user was able to insert metadata when creating new issue on GitLab CE/EE 14.0 and later.
{
"affected": [],
"aliases": [
"CVE-2021-22239"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-09T15:15:00Z",
"severity": "MODERATE"
},
"details": "An unauthorized user was able to insert metadata when creating new issue on GitLab CE/EE 14.0 and later.",
"id": "GHSA-7gxg-937v-gfc4",
"modified": "2022-05-24T19:14:00Z",
"published": "2022-05-24T19:14:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22239"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22239.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/336301"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7H94-344F-429F
Vulnerability from github – Published: 2026-07-23 09:32 – Updated: 2026-07-23 09:32An Incorrect Authorization vulnerability in Linux-Gaming PortProtonQt allows any users to mount and unmount arbitrary file systems and modify the network configuration via NetworkManager.
This issue affects PortProtonQt before 0d0f0950ebd948cdf82e8c3e1ebd2bcb9b8bafbe.
{
"affected": [],
"aliases": [
"CVE-2026-59678"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-23T08:16:25Z",
"severity": "HIGH"
},
"details": "An Incorrect Authorization vulnerability in Linux-Gaming PortProtonQt allows any users to mount and unmount arbitrary file systems and modify the network configuration via NetworkManager.\n\n\n\n\n\n\nThis issue affects PortProtonQt before 0d0f0950ebd948cdf82e8c3e1ebd2bcb9b8bafbe.",
"id": "GHSA-7h94-344f-429f",
"modified": "2026-07-23T09:32:00Z",
"published": "2026-07-23T09:32:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59678"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=CVE-2026-59678"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-7HC9-W8Q3-PJPJ
Vulnerability from github – Published: 2025-08-12 03:31 – Updated: 2025-08-12 03:31Due to broken authorization, SAP Business One (SLD) allows an authenticated attacker to gain administrator privileges of a database by invoking the corresponding API.�As a result , it has a high impact on the confidentiality, integrity, and availability of the application.
{
"affected": [],
"aliases": [
"CVE-2025-42951"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-12T03:15:27Z",
"severity": "HIGH"
},
"details": "Due to broken authorization, SAP Business One (SLD) allows an authenticated attacker to gain administrator privileges of a database by invoking the corresponding API.\ufffdAs a result , it has a high impact on the confidentiality, integrity, and availability of the application.",
"id": "GHSA-7hc9-w8q3-pjpj",
"modified": "2025-08-12T03:31:52Z",
"published": "2025-08-12T03:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-42951"
},
{
"type": "WEB",
"url": "https://me.sap.com/notes/3625403"
},
{
"type": "WEB",
"url": "https://url.sap/sapsecuritypatchday"
}
],
"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"
}
]
}
GHSA-7HGC-PHP5-77QQ
Vulnerability from github – Published: 2022-09-16 17:21 – Updated: 2022-09-19 20:23Impact
Talos worker nodes use a join token to get accepted into the Talos cluster. A misconfigured Kubernetes environment may allow workloads to access the join token of the worker node. A malicious workload could then use the join token to construct a Talos CSR (certificate signing request). Due to improper validation while signing a worker node CSR, a Talos control plane node might issue a Talos certificate which allows full access to the Talos API to a worker node that presented a maliciously constructed CSR. Accessing the Talos API with full access on a control plane node might reveal sensitive information, which could allow full-level access to the cluster (Kubernetes and Talos PKI, etc.)
In order to exploit the weakness, a Kubernetes workload would need to access the join token, and then construct a specific kind of Talos CSR in order to obtain a privileged certificate. The Talos API join token is stored in the machine configuration on the worker node. When configured correctly, Kubernetes workloads do not have access to the machine configuration, and thus cannot access the token, nor acquire elevated privileges.
It is possible that users have misconfigured Kubernetes in such a way as to allow a workload to access the machine configuration and reveal the join token. Misconfigurations that may allow the machine configuration to be accessed on a worker node by the Kubernetes workload are:
- allowing a
hostPathmount to mount the machine config directly from the host filesystem (hostPathmounts should not be allowed for untrusted workloads, and are disabled by default in recent versions of Talos.) - reading machine configuration from a cloud metadata server from Kubernetes pods with host networking (on cloud platforms, when machine config is stored in the cloud metadata server, and the cloud metadata server doesn't provide enough protection to prevent access from non-host workloads)
Patches
The problem was fixed in Talos 1.2.2.
Workarounds
Enabling the Pod Security Standards mitigates the vulnerability by denying hostPath mounts and host networking by default in the baseline policy. Talos enables Pod Security Admission plugin by default since Talos v1.1.0.
Clusters that don't run untrusted workloads are not affected.
Clusters with correct Pod Security configurations which don't allow hostPath mounts, and secure access to cloud metadata server (or machine configuration is not supplied via cloud metadata server) are not affected.
References
For more information
If you have any questions or comments about this advisory:
- Email us at security@siderolabs.com
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/talos-systems/talos"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.2.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-36103"
],
"database_specific": {
"cwe_ids": [
"CWE-732",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-16T17:21:09Z",
"nvd_published_at": "2022-09-13T17:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\nTalos worker nodes use a join token to get accepted into the Talos cluster. A misconfigured Kubernetes environment may allow workloads to access the join token of the worker node. A malicious workload could then use the join token to construct a Talos CSR (certificate signing request). Due to improper validation while signing a worker node CSR, a Talos control plane node might issue a Talos certificate which allows full access to the Talos API to a worker node that presented a maliciously constructed CSR. Accessing the Talos API with full access on a control plane node might reveal sensitive information, which could allow full-level access to the cluster (Kubernetes and Talos PKI, etc.)\n\nIn order to exploit the weakness, a Kubernetes workload would need to access the join token, and then construct a specific kind of Talos CSR in order to obtain a privileged certificate. The Talos API join token is stored in the machine configuration on the worker node. When configured correctly, Kubernetes workloads do not have access to the machine configuration, and thus cannot access the token, nor acquire elevated privileges.\n\nIt is possible that users have misconfigured Kubernetes in such a way as to allow a workload to access the machine configuration and reveal the join token. Misconfigurations that may allow the machine configuration to be accessed on a worker node by the Kubernetes workload are:\n\n* allowing a `hostPath` mount to mount the machine config directly from the host filesystem (`hostPath` mounts should not be allowed for untrusted workloads, and are disabled by default in recent versions of Talos.)\n* reading machine configuration from a cloud metadata server from Kubernetes pods with host networking (on cloud platforms, when machine config is stored in the cloud metadata server, and the cloud metadata server doesn\u0027t provide enough protection to prevent access from non-host workloads)\n\n### Patches\n\nThe problem was fixed in Talos 1.2.2.\n\n### Workarounds\n\nEnabling the [Pod Security Standards](https://www.talos.dev/v1.2/kubernetes-guides/configuration/pod-security/) mitigates the vulnerability by denying `hostPath` mounts and host networking by default in the [baseline](https://kubernetes.io/docs/concepts/security/pod-security-standards/#baseline) policy. Talos enables Pod Security Admission plugin by default since [Talos v1.1.0](https://www.talos.dev/v1.1/introduction/what-is-new/#pod-security-admission).\n\nClusters that don\u0027t run untrusted workloads are not affected.\nClusters with correct Pod Security configurations which don\u0027t allow `hostPath` mounts, and secure access to cloud metadata server (or machine configuration is not supplied via cloud metadata server) are not affected.\n\n### References\n\n* [Talos v1.2.2 release](https://github.com/siderolabs/talos/releases/tag/v1.2.2)\n* [Fixing commit](https://github.com/siderolabs/talos/commit/9eaf33f3f274e746ca1b442c0a1a0dae0cec088f)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Email us at [security@siderolabs.com](mailto:security@siderolabs.com)\n",
"id": "GHSA-7hgc-php5-77qq",
"modified": "2022-09-19T20:23:28Z",
"published": "2022-09-16T17:21:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/security/advisories/GHSA-7hgc-php5-77qq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36103"
},
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/commit/9eaf33f3f274e746ca1b442c0a1a0dae0cec088f"
},
{
"type": "PACKAGE",
"url": "https://github.com/siderolabs/talos"
},
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/releases/tag/v1.2.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Talos worker join token can be used to get elevated access level to the Talos API"
}
GHSA-7HH9-GP72-WH7H
Vulnerability from github – Published: 2025-12-17 20:55 – Updated: 2025-12-17 20:55Description
In applications built with the Auth0-PHP SDK, the audience validation in access tokens is performed improperly. Without proper validation, affected applications may accept ID tokens as Access tokens.
Affected product and versions
Users are affected if they meet the following preconditions:
- Applications using the Auth0 laravel-auth0 SDK with versions between 7.0.0 and 7.19.0,
- Auth0 laravel-auth0 SDK uses the Auth0-PHP SDK with versions between 8.0.0 and 8.17.0.
Resolution
Upgrade Auth0/laravel-auth0 to version 7.20.0 or greater.
Acknowledgement
Okta would like to thank Jafar Sadiq (iaf4r) for their discovery and responsible disclosure.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "auth0/login"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.20.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-17T20:55:50Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Description\nIn applications built with the Auth0-PHP SDK, the audience validation in access tokens is performed improperly. Without proper validation, affected applications may accept ID tokens as Access tokens.\n\n### Affected product and versions\nUsers are affected if they meet the following preconditions:\n\n- Applications using the Auth0 laravel-auth0 SDK with versions between 7.0.0 and 7.19.0,\n- Auth0 laravel-auth0 SDK uses the Auth0-PHP SDK with versions between 8.0.0 and 8.17.0.\n\n### Resolution\nUpgrade Auth0/laravel-auth0 to version 7.20.0 or greater.\n\n### Acknowledgement\nOkta would like to thank Jafar Sadiq (iaf4r) for their discovery and responsible disclosure.",
"id": "GHSA-7hh9-gp72-wh7h",
"modified": "2025-12-17T20:55:50Z",
"published": "2025-12-17T20:55:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/auth0/laravel-auth0/security/advisories/GHSA-7hh9-gp72-wh7h"
},
{
"type": "WEB",
"url": "https://github.com/auth0/laravel-auth0/commit/a1c3344dc0e5a36e8f56c8cfc535728d3d7558f3"
},
{
"type": "PACKAGE",
"url": "https://github.com/auth0/laravel-auth0"
},
{
"type": "WEB",
"url": "https://github.com/auth0/laravel-auth0/releases/tag/7.20.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Auth0 Laravel SDK has Improper Audience Validation via Auth0-PHP SDK dependency"
}
GHSA-7HHV-H469-WC4Q
Vulnerability from github – Published: 2025-11-15 09:30 – Updated: 2025-11-15 09:30GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.9 before 18.3.6, 18.4 before 18.4.4, and 18.5 before 18.5.2 that could have allowed an authenticated attacker to bypass access control restrictions and view GitLab Pages content intended only for project members by authenticating through OAuth providers.
{
"affected": [],
"aliases": [
"CVE-2025-7736"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-15T08:15:48Z",
"severity": "LOW"
},
"details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.9 before 18.3.6, 18.4 before 18.4.4, and 18.5 before 18.5.2 that could have allowed an authenticated attacker to bypass access control restrictions and view GitLab Pages content intended only for project members by authenticating through OAuth providers.",
"id": "GHSA-7hhv-h469-wc4q",
"modified": "2025-11-15T09:30:25Z",
"published": "2025-11-15T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7736"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3250156"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/releases/2025/11/12/patch-release-gitlab-18-5-2-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/556098"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7HPJ-6M83-46CJ
Vulnerability from github – Published: 2024-11-04 21:30 – Updated: 2024-11-05 21:30Chamilo LMS 1.11.26 is vulnerable to Incorrect Access Control via main/auth/profile. Non-admin users can manipulate sensitive profiles information, posing a significant risk to data integrity.
{
"affected": [],
"aliases": [
"CVE-2024-30616"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-04T19:15:06Z",
"severity": "HIGH"
},
"details": "Chamilo LMS 1.11.26 is vulnerable to Incorrect Access Control via main/auth/profile. Non-admin users can manipulate sensitive profiles information, posing a significant risk to data integrity.",
"id": "GHSA-7hpj-6m83-46cj",
"modified": "2024-11-05T21:30:43Z",
"published": "2024-11-04T21:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30616"
},
{
"type": "WEB",
"url": "https://github.com/chamilo/chamilo-lms/commit/a1a1e4df70dc65ae4fc7857135f4d3ee185548e7"
},
{
"type": "WEB",
"url": "https://github.com/bahadoumi/Vulnerability-Research/tree/main/CVE-2024-30616"
}
],
"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"
}
]
}
GHSA-7HRH-V6WP-53VW
Vulnerability from github – Published: 2024-06-06 19:10 – Updated: 2024-10-15 23:34Impact
What kind of vulnerability is it? Who is impacted?
At the moment, users are able to delegate tokens that have not yet been vested. This affects employees and grantees who have funds managed via ClawbackVestingAccount.
Patches
Has the problem been patched? What versions should users upgrade to?
The PR linked to this advisory includes part of the fix. The remainder is in a second advisory on the Cosmos SDK fork.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
There is no effective workaround to fix or remediate this issue without a new release. The best solution is to contain the information about this vulnerability to minimize the number of users who know about it and can thus exploit it.
References
Are there any links users can visit to find out more?
See the integration tests for more details on the exploit, or use the following to reproduce it on the CLI:
- Download
vesting_setup.jsonwith the following contents:
{
"start_time": 1679602272,
"periods": [
{
"coins": "100000000000000000000aevmos",
"length_seconds": 10
},
{
"coins": "100000000000000000000aevmos",
"length_seconds": 259200000
}
]
}
- Run the following CLI commands to reproduce the issue locally:
evmosd tx vesting create-clawback-vesting-account evmos1rn7fmq6he0s4uz9mwzzqwwm7fmmepd39cusn0t --vesting vesting_setup.json --from dev0 --fees 2000000000000000aevmos --home ~/.tmp-evmosd --yes
# Verify that the balance contains zero locked tokens, 1000000000000000aevmos vested, 1000000000000000aevmos unvested
evmosd q vesting balances evmos1rn7fmq6he0s4uz9mwzzqwwm7fmmepd39cusn0t --home ~/.tmp-evmosd
evmosd keys add key1 --recover --home ~/.tmp-evmosd
# Enter the following mnemonic
skate tell option purity cattle poverty street act bone govern way various
evmosd q staking validators --home ~/.tmp-evmosd | grep operator_address
# Substitute the operator address from the previous query
# Note that this delegates 70% of the user's available stake
evmosd tx staking delegate <operator_address> 70000000000000000000aevmos --fees 5000000000000000aevmos --gas 300000 --from key1 --home ~/.tmp-evmosd --yes
# Re-run the same command
evmosd tx staking delegate <operator_address> 70000000000000000000aevmos --fees 5000000000000000aevmos --gas 300000 --from key1 --home ~/.tmp-evmosd --yes
# Note that the total delegations now exceed the user's vested balance
evmosd q staking delegations evmos1rn7fmq6he0s4uz9mwzzqwwm7fmmepd39cusn0t --home ~/.tmp-evmosd
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/evmos/v18"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "18.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/evmos/v17"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "17.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/evmos/v16"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "16.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/evmos/v15"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "15.0.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/evmos/v14"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "14.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/evmos/v13"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "13.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/evmos/v12"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "12.1.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/evmos/v11"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "11.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/evmos/v10"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "10.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/evmos/v9"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "9.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/evmos/v8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "8.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/evmos/v7"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "7.0.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/evmos/v6"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "6.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-37154"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-06-06T19:10:21Z",
"nvd_published_at": "2024-06-06T19:15:58Z",
"severity": "MODERATE"
},
"details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nAt the moment, users are able to delegate tokens that have not yet been vested. This affects employees and grantees who have funds managed via `ClawbackVestingAccount`.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\n[The PR linked to this advisory](https://github.com/evmos/evmos-ghsa-7hrh-v6wp-53vw/pull/1) includes part of the fix. The remainder is in a [second advisory on the Cosmos SDK fork](https://github.com/evmos/cosmos-sdk/security/advisories/GHSA-wj6f-x5wv-8pqv).\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nThere is no effective workaround to fix or remediate this issue without a new release. The best solution is to contain the information about this vulnerability to minimize the number of users who know about it and can thus exploit it.\n\n### References\n_Are there any links users can visit to find out more?_\n\nSee the integration tests for more details on the exploit, or use the following to reproduce it on the CLI:\n\n1. Download `vesting_setup.json` with the following contents:\n```\n{\n \"start_time\": 1679602272,\n \"periods\": [\n {\n \"coins\": \"100000000000000000000aevmos\",\n \"length_seconds\": 10 \n },\n {\n \"coins\": \"100000000000000000000aevmos\",\n \"length_seconds\": 259200000\n }\n ]\n}\n```\n\n2. Run the following CLI commands to reproduce the issue locally:\n```\nevmosd tx vesting create-clawback-vesting-account evmos1rn7fmq6he0s4uz9mwzzqwwm7fmmepd39cusn0t --vesting vesting_setup.json --from dev0 --fees 2000000000000000aevmos --home ~/.tmp-evmosd --yes\n\n# Verify that the balance contains zero locked tokens, 1000000000000000aevmos vested, 1000000000000000aevmos unvested\nevmosd q vesting balances evmos1rn7fmq6he0s4uz9mwzzqwwm7fmmepd39cusn0t --home ~/.tmp-evmosd\n\nevmosd keys add key1 --recover --home ~/.tmp-evmosd\n# Enter the following mnemonic\nskate tell option purity cattle poverty street act bone govern way various\n\nevmosd q staking validators --home ~/.tmp-evmosd | grep operator_address\n\n# Substitute the operator address from the previous query\n# Note that this delegates 70% of the user\u0027s available stake\nevmosd tx staking delegate \u003coperator_address\u003e 70000000000000000000aevmos --fees 5000000000000000aevmos --gas 300000 --from key1 --home ~/.tmp-evmosd --yes\n\n# Re-run the same command\nevmosd tx staking delegate \u003coperator_address\u003e 70000000000000000000aevmos --fees 5000000000000000aevmos --gas 300000 --from key1 --home ~/.tmp-evmosd --yes\n\n# Note that the total delegations now exceed the user\u0027s vested balance\nevmosd q staking delegations evmos1rn7fmq6he0s4uz9mwzzqwwm7fmmepd39cusn0t --home ~/.tmp-evmosd\n```",
"id": "GHSA-7hrh-v6wp-53vw",
"modified": "2024-10-15T23:34:18Z",
"published": "2024-06-06T19:10:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/evmos/evmos/security/advisories/GHSA-7hrh-v6wp-53vw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37154"
},
{
"type": "PACKAGE",
"url": "https://github.com/evmos/evmos"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2024-2904"
}
],
"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"
}
],
"summary": "Evmos allows unvested token delegations"
}
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.