Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect 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:00
VLAI
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

Show details on source website

{
  "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:31
VLAI
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.

Show details on source website

{
  "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:14
VLAI
Details

An unauthorized user was able to insert metadata when creating new issue on GitLab CE/EE 14.0 and later.

Show details on source website

{
  "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:32
VLAI
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.

This issue affects PortProtonQt before 0d0f0950ebd948cdf82e8c3e1ebd2bcb9b8bafbe.

Show details on source website

{
  "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:31
VLAI
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.�As a result , it has a high impact on the confidentiality, integrity, and availability of the application.

Show details on source website

{
  "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:23
VLAI
Summary
Talos worker join token can be used to get elevated access level to the Talos API
Details

Impact

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 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.)
  • 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:

Show details on source website

{
  "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:55
VLAI
Summary
Auth0 Laravel SDK has Improper Audience Validation via Auth0-PHP SDK dependency
Details

Description

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.

Show details on source website

{
  "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:30
VLAI
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.

Show details on source website

{
  "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:30
VLAI
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.

Show details on source website

{
  "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:34
VLAI
Summary
Evmos allows unvested token delegations
Details

Impact

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:

  1. Download vesting_setup.json with the following contents:
{
  "start_time": 1679602272,
  "periods": [
    {
      "coins": "100000000000000000000aevmos",
      "length_seconds": 10 
    },
    {
      "coins": "100000000000000000000aevmos",
      "length_seconds": 259200000
    }
  ]
}
  1. 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
Show details on source website

{
  "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
Architecture and Design
  • 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
Architecture and Design

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
Architecture and Design

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
Architecture and Design
  • 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
System Configuration Installation

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.