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.

5678 vulnerabilities reference this CWE, most recent first.

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"
}

GHSA-3JPJ-V3XR-5H6G

Vulnerability from github – Published: 2026-04-16 21:09 – Updated: 2026-04-24 20:49
VLAI
Summary
zrok: Broken ownership check in DELETE /api/v2/unaccess allows non-admin to delete global frontend records
Details

Summary The unaccess handler (controller/unaccess.go) contains a logical error in its ownership guard: when a frontend record has environment_id = NULL (the marker for admin-created global frontends), the condition short-circuits to false and allows the deletion to proceed without any ownership verification. A non-admin user who knows a global frontend token can call DELETE /api/v2/unaccess with any of their own environment IDs and permanently delete the global frontend, taking down all public shares routed through it.

Attack Vector: Network — the endpoint is a standard HTTP API call.

Attack Complexity: High — successful exploitation requires prior knowledge of a global frontend token. These tokens are not returned to non-admin users by any standard API endpoint; obtaining one requires an out-of-band step (e.g., leaked server logs, admin documentation for a self-hosted instance, or social engineering).

Privileges Required: Low — a valid user account with at least one registered environment is required; no admin privileges needed.

User Interaction: None.

Scope: Unchanged — the impact stays within the same server instance.

Confidentiality Impact: None — no data is disclosed.

Integrity Impact: None — no data is improperly modified; the record is deleted (not corrupted).

Availability Impact: High — deleting a global frontend disrupts every public share routed through it on the instance, constituting a platform-wide availability impact.

Affected Component controller/unaccess.go — unaccessHandler.Handle (line 56)

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openziti/zrok"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.1.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openziti/zrok/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40304"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T21:09:23Z",
    "nvd_published_at": "2026-04-17T22:16:32Z",
    "severity": "MODERATE"
  },
  "details": "Summary\nThe unaccess handler (controller/unaccess.go) contains a logical error in its ownership guard: when a frontend record has environment_id = NULL (the marker for admin-created global frontends), the condition short-circuits to false and allows the deletion to proceed without any ownership verification. A non-admin user who knows a global frontend token can call DELETE /api/v2/unaccess with any of their own environment IDs and permanently delete the global frontend, taking down all public shares routed through it.\n\nAttack Vector: Network \u2014 the endpoint is a standard HTTP API call.\n\nAttack Complexity: High \u2014 successful exploitation requires prior knowledge of a global frontend token. These tokens are not returned to non-admin users by any standard API endpoint; obtaining one requires an out-of-band step (e.g., leaked server logs, admin documentation for a self-hosted instance, or social engineering).\n\nPrivileges Required: Low \u2014 a valid user account with at least one registered environment is required; no admin privileges needed.\n\nUser Interaction: None.\n\nScope: Unchanged \u2014 the impact stays within the same server instance.\n\nConfidentiality Impact: None \u2014 no data is disclosed.\n\nIntegrity Impact: None \u2014 no data is improperly modified; the record is deleted (not corrupted).\n\nAvailability Impact: High \u2014 deleting a global frontend disrupts every public share routed through it on the instance, constituting a platform-wide availability impact.\n\nAffected Component\ncontroller/unaccess.go \u2014 unaccessHandler.Handle (line 56)",
  "id": "GHSA-3jpj-v3xr-5h6g",
  "modified": "2026-04-24T20:49:03Z",
  "published": "2026-04-16T21:09:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openziti/zrok/security/advisories/GHSA-3jpj-v3xr-5h6g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40304"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openziti/zrok"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openziti/zrok/releases/tag/v2.0.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "zrok: Broken ownership check in DELETE /api/v2/unaccess allows non-admin to delete global frontend records"
}

GHSA-3JQ8-JG75-RQV6

Vulnerability from github – Published: 2018-12-20 22:02 – Updated: 2024-03-04 22:06
VLAI
Summary
Cleartext Transmission of Sensitive Information in Apache nifi
Details

The template upload API endpoint accepted requests from different domain when sent in conjunction with ARP spoofing + man in the middle (MiTM) attack, resulting in a CSRF attack. The required attack vector is complex, requiring a scenario with client certificate authentication, same subnet access, and injecting malicious code into an unprotected (plaintext HTTP) website which the targeted user later visits, but the possible damage warranted a Severe severity level. Mitigation: The fix to apply Cross-Origin Resource Sharing (CORS) policy request filtering was applied on the Apache NiFi 1.8.0 release. Users running a prior 1.x release should upgrade to the appropriate release.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.7.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.nifi:nifi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-17195"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-319",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T20:55:22Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "The template upload API endpoint accepted requests from different domain when sent in conjunction with ARP spoofing + man in the middle (MiTM) attack, resulting in a CSRF attack. The required attack vector is complex, requiring a scenario with client certificate authentication, same subnet access, and injecting malicious code into an unprotected (plaintext HTTP) website which the targeted user later visits, but the possible damage warranted a Severe severity level. Mitigation: The fix to apply Cross-Origin Resource Sharing (CORS) policy request filtering was applied on the Apache NiFi 1.8.0 release. Users running a prior 1.x release should upgrade to the appropriate release.",
  "id": "GHSA-3jq8-jg75-rqv6",
  "modified": "2024-03-04T22:06:28Z",
  "published": "2018-12-20T22:02:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17195"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/nifi/commit/246c090526143943557b15868db6e8fe3fb30cf6"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-3jq8-jg75-rqv6"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/NIFI-5595"
    },
    {
      "type": "WEB",
      "url": "https://nifi.apache.org/security.html#CVE-2018-17195"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Cleartext Transmission of Sensitive Information in Apache nifi"
}

GHSA-3JR5-PX2C-8J7C

Vulnerability from github – Published: 2022-01-26 00:00 – Updated: 2022-02-02 00:02
VLAI
Details

On BIG-IQ Centralized Management 8.x before 8.1.0, an authenticated administrative role user on a BIG-IQ managed BIG-IP device can access other BIG-IP devices managed by the same BIG-IQ system. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-23009"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-25T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "On BIG-IQ Centralized Management 8.x before 8.1.0, an authenticated administrative role user on a BIG-IQ managed BIG-IP device can access other BIG-IP devices managed by the same BIG-IQ system. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.",
  "id": "GHSA-3jr5-px2c-8j7c",
  "modified": "2022-02-02T00:02:02Z",
  "published": "2022-01-26T00:00:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23009"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K47592780"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-3JRQ-728F-H4M6

Vulnerability from github – Published: 2023-06-14 18:30 – Updated: 2024-04-04 04:50
VLAI
Details

Potential vulnerabilities have been identified in the system BIOS of certain HP PC products, which might allow arbitrary code execution, escalation of privilege, denial of service, and information disclosure.

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-2022-31644"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-14T18:15:09Z",
    "severity": "HIGH"
  },
  "details": "Potential vulnerabilities have been identified in the system BIOS of certain HP PC products, which might allow arbitrary code execution, escalation of privilege, denial of service, and information disclosure.",
  "id": "GHSA-3jrq-728f-h4m6",
  "modified": "2024-04-04T04:50:51Z",
  "published": "2023-06-14T18:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31644"
    },
    {
      "type": "WEB",
      "url": "https://support.hp.com/us-en/document/ish_6664419-6664458-16/hpsbhf03806"
    }
  ],
  "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"
    }
  ]
}
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