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.

5659 vulnerabilities reference this CWE, most recent first.

GHSA-85JX-FM8M-X8C6

Vulnerability from github – Published: 2026-03-10 23:44 – Updated: 2026-03-10 23:44
VLAI
Summary
zot’s create-only policy allows overwrite attempts of existing latest tag (update permission not required)
Details

zot’s dist-spec authorization middleware infers the required action for PUT /v2/{name}/manifests/{reference} as create by default, and only switches to update when the tag already exists and reference != "latest".

as a result, when latest already exists, a user who is allowed to create (but not allowed to update) can still pass the authorization check for an overwrite attempt of latest.

affected component

  • file: pkg/api/authz.go (DistSpecAuthzHandler)
  • condition: slices.Contains(tags, reference) && reference != "latest" (line 352 at the pinned commit)

severity

HIGH category: CWE-863 (incorrect authorization)

note: impact depends on how a deployment uses latest (for example, if latest is treated as a protected or “push-once” tag), and on how access control is provisioned (users with create but without update). the attached poc demonstrates a real overwrite of latest (tag digest changes) under a create-only policy.

steps to reproduce

  1. configure access control so user attacker has create but not update on a repository.
  2. ensure the repository has an existing tag named latest.
  3. attempt to push a new manifest to /v2/acme/app/manifests/latest (example repository name).
  4. observe that the authorization check is evaluated as create (not update) for latest, so the request passes authorization even though the tag already exists.

the attached poc demonstrates this deterministically with canonical.log and control.log markers.

expected vs actual

  • expected: overwriting an existing tag should require update permission, including latest (or latest should be explicitly documented as exempt).
  • actual: when reference=="latest" and the tag exists, the middleware keeps the action as create instead of switching to update.

security impact

this can break least-privilege expectations in deployments that rely on the create vs update split to prevent tag overwrites (for example, “push-once” policies). if latest is used as a high-trust tag in ci/cd, this can create supply-chain risk because a create-only principal can overwrite an existing latest tag while other existing tags correctly require update.

suggested fix

remove the special-case exemption for latest when determining whether an existing tag requires update permission (treat latest the same as other tags), or document and enforce an explicit policy rule for latest.

notes / rationale

  • oci distribution spec does not define a standard authorization model; this report is about zot’s own create vs update semantics and the observable behavior in DistSpecAuthzHandler.
  • zot documentation describes immutable tags as being enforceable via authorization policies (create-only “push once”, update disallowed). if latest is exempt, this control does not apply to latest unless documented otherwise.

addendum.md poc.zip PR_DESCRIPTION.md RUNNABLE_POC.md

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "zotregistry.dev/zot/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "zotregistry.dev/zot"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0-20210831063041-c8779d9e87d9"
            },
            {
              "last_affected": "1.4.4-20251014054906-73eef25681af"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-31801"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-10T23:44:25Z",
    "nvd_published_at": "2026-03-10T21:16:49Z",
    "severity": "HIGH"
  },
  "details": "zot\u2019s dist-spec authorization middleware infers the required action for `PUT /v2/{name}/manifests/{reference}` as `create` by default, and only switches to `update` when the tag already exists and `reference != \"latest\"`.\n\nas a result, when `latest` already exists, a user who is allowed to `create` (but not allowed to `update`) can still pass the authorization check for an overwrite attempt of `latest`.\n\n## affected component\n\n- file: `pkg/api/authz.go` (`DistSpecAuthzHandler`)\n- condition: `slices.Contains(tags, reference) \u0026\u0026 reference != \"latest\"` (line 352 at the pinned commit)\n\n## severity\n\nHIGH\ncategory: CWE-863 (incorrect authorization)\n\nnote: impact depends on how a deployment uses `latest` (for example, if `latest` is treated as a protected or \u201cpush-once\u201d tag), and on how access control is provisioned (users with `create` but without `update`). the attached poc demonstrates a real overwrite of `latest` (tag digest changes) under a create-only policy.\n\n## steps to reproduce\n\n1. configure access control so user `attacker` has `create` but not `update` on a repository.\n2. ensure the repository has an existing tag named `latest`.\n3. attempt to push a new manifest to `/v2/acme/app/manifests/latest` (example repository name).\n4. observe that the authorization check is evaluated as `create` (not `update`) for `latest`, so the request passes authorization even though the tag already exists.\n\nthe attached poc demonstrates this deterministically with `canonical.log` and `control.log` markers.\n\n## expected vs actual\n\n- expected: overwriting an existing tag should require `update` permission, including `latest` (or `latest` should be explicitly documented as exempt).\n- actual: when `reference==\"latest\"` and the tag exists, the middleware keeps the action as `create` instead of switching to `update`.\n\n## security impact\n\nthis can break least-privilege expectations in deployments that rely on the `create` vs `update` split to prevent tag overwrites (for example, \u201cpush-once\u201d policies). if `latest` is used as a high-trust tag in ci/cd, this can create supply-chain risk because a create-only principal can overwrite an existing `latest` tag while other existing tags correctly require `update`.\n\n## suggested fix\n\nremove the special-case exemption for `latest` when determining whether an existing tag requires `update` permission (treat `latest` the same as other tags), or document and enforce an explicit policy rule for `latest`.\n\n## notes / rationale\n\n- oci distribution spec does not define a standard authorization model; this report is about zot\u2019s own create vs update semantics and the observable behavior in `DistSpecAuthzHandler`.\n- zot documentation describes immutable tags as being enforceable via authorization policies (create-only \u201cpush once\u201d, update disallowed). if `latest` is exempt, this control does not apply to `latest` unless documented otherwise.\n\n[addendum.md](https://github.com/user-attachments/files/24986139/addendum.md)\n[poc.zip](https://github.com/user-attachments/files/24986140/poc.zip)\n[PR_DESCRIPTION.md](https://github.com/user-attachments/files/24986141/PR_DESCRIPTION.md)\n[RUNNABLE_POC.md](https://github.com/user-attachments/files/24986142/RUNNABLE_POC.md)",
  "id": "GHSA-85jx-fm8m-x8c6",
  "modified": "2026-03-10T23:44:25Z",
  "published": "2026-03-10T23:44:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/project-zot/zot/security/advisories/GHSA-85jx-fm8m-x8c6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31801"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/project-zot/zot"
    },
    {
      "type": "WEB",
      "url": "https://github.com/project-zot/zot/releases/tag/v2.1.15"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "zot\u2019s create-only policy allows overwrite attempts of existing latest tag (update permission not required)"
}

GHSA-85JX-X9R4-45M2

Vulnerability from github – Published: 2025-06-26 21:31 – Updated: 2025-10-22 21:29
VLAI
Summary
Magento Authenticated Security feature bypass
Details

Magento versions 2.4.8, 2.4.7-p5, 2.4.6-p10, 2.4.5-p12, 2.4.4-p13 and earlier are affected by an Incorrect Authorization vulnerability that could result in a Security feature bypass. A high-privileged attacker could leverage this vulnerability to bypass security measures and gain limited unauthorized access. Exploitation of this issue does not require user interaction.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/project-community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.7-beta1"
            },
            {
              "fixed": "2.4.7-p6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.6-p1"
            },
            {
              "fixed": "2.4.6-p11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.5-p13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.5"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.6"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.7"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.8"
      ]
    }
  ],
  "aliases": [
    "CVE-2025-49549"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-22T21:29:16Z",
    "nvd_published_at": "2025-06-25T18:15:22Z",
    "severity": "LOW"
  },
  "details": "Magento versions 2.4.8, 2.4.7-p5, 2.4.6-p10, 2.4.5-p12, 2.4.4-p13 and earlier are affected by an Incorrect Authorization vulnerability that could result in a Security feature bypass. A high-privileged attacker could leverage this vulnerability to bypass security measures and gain limited unauthorized access. Exploitation of this issue does not require user interaction.",
  "id": "GHSA-85jx-x9r4-45m2",
  "modified": "2025-10-22T21:29:16Z",
  "published": "2025-06-26T21:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49549"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/magento/magento2"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb25-50.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Magento Authenticated Security feature bypass"
}

GHSA-85RG-G6CG-264M

Vulnerability from github – Published: 2022-05-17 00:41 – Updated: 2022-05-17 00:41
VLAI
Details

The netsnmp_udp_fmtaddr function (snmplib/snmpUDPDomain.c) in net-snmp 5.0.9 through 5.4.2.1, when using TCP wrappers for client authorization, does not properly parse hosts.allow rules, which allows remote attackers to bypass intended access restrictions and execute SNMP queries, related to "source/destination IP address confusion."

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2008-6123"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-02-12T16:30:00Z",
    "severity": "MODERATE"
  },
  "details": "The netsnmp_udp_fmtaddr function (snmplib/snmpUDPDomain.c) in net-snmp 5.0.9 through 5.4.2.1, when using TCP wrappers for client authorization, does not properly parse hosts.allow rules, which allows remote attackers to bypass intended access restrictions and execute SNMP queries, related to \"source/destination IP address confusion.\"",
  "id": "GHSA-85rg-g6cg-264m",
  "modified": "2022-05-17T00:41:19Z",
  "published": "2022-05-17T00:41:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-6123"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=485211"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A10289"
    },
    {
      "type": "WEB",
      "url": "http://bugs.gentoo.org/show_bug.cgi?id=250429"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2009-06/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2009-07/msg00002.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2010-02/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "http://net-snmp.svn.sourceforge.net/viewvc/net-snmp/trunk/net-snmp/snmplib/snmpUDPDomain.c?r1=17325\u0026r2=17367\u0026pathrev=17367"
    },
    {
      "type": "WEB",
      "url": "http://net-snmp.svn.sourceforge.net/viewvc/net-snmp?view=rev\u0026revision=17367"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/34499"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/35416"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/35685"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2009/02/12/2"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2009/02/12/4"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2009/02/12/7"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2009-0295.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1021921"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-85WF-FVJ6-C5XF

Vulnerability from github – Published: 2026-03-25 18:31 – Updated: 2026-03-25 21:30
VLAI
Details

Incorrect Authorization vulnerability in Drupal Material Icons allows Forceful Browsing.This issue affects Material Icons: from 0.0.0 before 2.0.4.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-3210"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T16:16:21Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect Authorization vulnerability in Drupal Material Icons allows Forceful Browsing.This issue affects Material Icons: from 0.0.0 before 2.0.4.",
  "id": "GHSA-85wf-fvj6-c5xf",
  "modified": "2026-03-25T21:30:32Z",
  "published": "2026-03-25T18:31:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3210"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/sa-contrib-2026-011"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-85X2-R8XV-WW8C

Vulnerability from github – Published: 2026-04-30 21:03 – Updated: 2026-04-30 21:03
VLAI
Summary
Kirby CMS's `pages.access/list` and `files.access/list` permissions are not consistently checked in the Panel and REST API
Details

TL;DR

This vulnerability affects all Kirby sites where users of a particular role have no permission to access or list pages or files (pages.access, pages.list, files.access or files.list permission is disabled). This can be due to configuration in the user blueprint(s), via options in the model blueprint(s) or via a combination of both settings.

This vulnerability is of high severity for affected sites.

Consumers' Kirby sites are not affected if they intend all users to be able to access all pages and files of the site. The vulnerability can only be exploited by authenticated users. Write actions are not affected by this vulnerability.

Introduction

Missing authorization allows authenticated users to perform actions they are not intended to have access to.

The effects of missing authorization can include unauthorized access to sensitive information as well as unauthorized changes to content or system information.

Impact

Kirby's user permissions control which user role is allowed to perform specific actions to content models in the CMS. These permissions are defined for each role in the user blueprint (site/blueprints/users/...). It is also possible to customize the permissions for each target model in the model blueprints (such as in site/blueprints/pages/...) using the options feature. The permissions and options together control the authorization of user actions.

Kirby provides the pages.access, pages.list, files.access and files.list permissions (among others). The list permissions control whether affected models appear in lists throughout the Panel and REST API. The access permissions have the same effect but also disable direct access to the affected models.

In affected releases, Kirby did not consistently hide non-listable models (models for which the respective access or list permission was disabled) in the following scenarios:

  • The changes dialog in the Panel listed changed models even if they were not listable.
  • The REST API respected the permissions during direct model access, but did not consistently filter collections as well as related models that are included in the API responses for convenience. This includes:
  • missing permission checks for children, drafts, files, parents and siblings of pages,
  • missing permission checks for parents and siblings (next/nextWithTemplate, prev/prevWithTemplate) of files,
  • missing permission checks for children, drafts and files of the site model,
  • missing permission checks for files of users,
  • incorrect permission checks for pages.access instead of pages.list for the site and pages children and search routes and
  • incorrect permission checks for files.access instead of files.list for the account, site, pages and users files and search routes,
  • The Panel images for site, pages and users were displayed in lists of the parent model even if the image files were not listable.
  • The link targets for the previous and next files in the files view were not gated by the files being listable.

Patches

The problem has been patched in Kirby 4.9.0 and Kirby 5.4.0. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, we have added permission checks for $model->isListable() in all of the affected places. This ensures that results are filtered by the listable property, thereby enforcing the pages.access, pages.list, files.access and files.list permissions consistently.

Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.8.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "getkirby/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.3.3"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "getkirby/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42137"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-30T21:03:20Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### TL;DR\n\nThis vulnerability affects all Kirby sites where users of a particular role have no permission to access or list pages or files (`pages.access`, `pages.list`, `files.access` or `files.list` permission is disabled). This can be due to configuration in the user blueprint(s), via `options` in the model blueprint(s) or via a combination of both settings.\n\n**This vulnerability is of high severity for affected sites.**\n\nConsumers\u0027 Kirby sites are *not* affected if they intend all users to be able to access all pages and files of the site. The vulnerability can only be exploited by authenticated users. Write actions are *not* affected by this vulnerability.\n\n----\n\n### Introduction\n\nMissing authorization allows authenticated users to perform actions they are not intended to have access to.\n\nThe effects of missing authorization can include unauthorized access to sensitive information as well as unauthorized changes to content or system information.\n\n### Impact\n\nKirby\u0027s user permissions control which user role is allowed to perform specific actions to content models in the CMS. These permissions are defined for each role in the user blueprint (`site/blueprints/users/...`). It is also possible to customize the permissions for each target model in the model blueprints (such as in `site/blueprints/pages/...`) using the `options` feature. The permissions and options together control the authorization of user actions.\n\nKirby provides the `pages.access`, `pages.list`, `files.access` and `files.list` permissions (among others). The `list` permissions control whether affected models appear in lists throughout the Panel and REST API. The `access` permissions have the same effect but also disable direct access to the affected models.\n\nIn affected releases, Kirby did not consistently hide non-listable models (models for which the respective `access` or `list` permission was disabled) in the following scenarios:\n\n- The changes dialog in the Panel listed changed models even if they were not listable.\n- The REST API respected the permissions during direct model access, but did not consistently filter collections as well as related models that are included in the API responses for convenience. This includes:\n  - missing permission checks for children, drafts, files, parents and siblings of pages,\n  - missing permission checks for parents and siblings (`next`/`nextWithTemplate `, `prev`/`prevWithTemplate`) of files,\n  - missing permission checks for children, drafts and files of the site model,\n  - missing permission checks for files of users,\n  - incorrect permission checks for `pages.access` instead of `pages.list` for the site and pages children and search routes and\n  - incorrect permission checks for `files.access` instead of `files.list` for the account, site, pages and users files and search routes,\n- The Panel images for site, pages and users were displayed in lists of the parent model even if the image files were not listable.\n- The link targets for the previous and next files in the files view were not gated by the files being listable.\n\n### Patches\n\nThe problem has been patched in [Kirby 4.9.0](https://github.com/getkirby/kirby/releases/tag/4.9.0) and [Kirby 5.4.0](https://github.com/getkirby/kirby/releases/tag/5.4.0). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability.\n\nIn all of the mentioned releases, we have added permission checks for `$model-\u003eisListable()` in all of the affected places. This ensures that results are filtered by the listable property, thereby enforcing the `pages.access`, `pages.list`, `files.access` and `files.list` permissions consistently.",
  "id": "GHSA-85x2-r8xv-ww8c",
  "modified": "2026-04-30T21:03:20Z",
  "published": "2026-04-30T21:03:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/security/advisories/GHSA-85x2-r8xv-ww8c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getkirby/kirby"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/releases/tag/4.9.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/releases/tag/5.4.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kirby CMS\u0027s `pages.access/list` and `files.access/list` permissions are not consistently checked in the Panel and REST API"
}

GHSA-85XX-79FP-6RMF

Vulnerability from github – Published: 2021-12-09 00:01 – Updated: 2021-12-11 00:01
VLAI
Details

An improper access control vulnerability [CWE-284] in FortiWLC 8.6.1 and below may allow an authenticated and remote attacker with low privileges to execute any command as an admin user with full access rights via bypassing the GUI restrictions.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-42758"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-08T11:15:00Z",
    "severity": "HIGH"
  },
  "details": "An improper access control vulnerability [CWE-284] in FortiWLC 8.6.1 and below may allow an authenticated and remote attacker with low privileges to execute any command as an admin user with full access rights via bypassing the GUI restrictions.",
  "id": "GHSA-85xx-79fp-6rmf",
  "modified": "2021-12-11T00:01:13Z",
  "published": "2021-12-09T00:01:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42758"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.com/advisory/FG-IR-21-200"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-85XX-V6P7-PV64

Vulnerability from github – Published: 2025-07-07 18:32 – Updated: 2025-07-07 18:32
VLAI
Details

In Splunk Enterprise versions below 9.4.2, 9.3.5, 9.2.6, and 9.1.9 and Splunk Cloud Platform versions below 9.3.2411.103, 9.3.2408.112, and 9.2.2406.119, a low-privileged user that does not hold the "admin" or "power" Splunk roles, and has read-only access to a specific alert, could suppress that alert when it triggers. See Define alert suppression groups to throttle sets of similar alerts.

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-2025-20300"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-07T18:15:25Z",
    "severity": "MODERATE"
  },
  "details": "In Splunk Enterprise versions below 9.4.2, 9.3.5, 9.2.6, and 9.1.9 and Splunk Cloud Platform versions below 9.3.2411.103, 9.3.2408.112, and 9.2.2406.119, a low-privileged user that does not hold the \"admin\" or \"power\" Splunk roles, and has read-only access to a specific alert, could suppress that alert when it triggers. See [Define alert suppression groups to throttle sets of similar alerts](https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/9.4/manage-alert-trigger-conditions-and-throttling/define-alert-suppression-groups-to-throttle-sets-of-similar-alerts).",
  "id": "GHSA-85xx-v6p7-pv64",
  "modified": "2025-07-07T18:32:28Z",
  "published": "2025-07-07T18:32:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20300"
    },
    {
      "type": "WEB",
      "url": "https://advisory.splunk.com/advisories/SVD-2025-0708"
    }
  ],
  "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-8643-3FQ3-VWCR

Vulnerability from github – Published: 2026-01-10 12:30 – Updated: 2026-01-10 12:30
VLAI
Details

The Templately plugin for WordPress is vulnerable to Arbitrary File Write in all versions up to, and including, 3.4.8. This is due to inadequate input validation in the save_template_to_file() function where user-controlled parameters like session_id, content_id, and ai_page_ids are used to construct file paths without proper sanitization. This makes it possible for unauthenticated attackers to write arbitrary .ai.json files to locations within the uploads directory.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-0831"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-10T10:15:50Z",
    "severity": "MODERATE"
  },
  "details": "The Templately plugin for WordPress is vulnerable to Arbitrary File Write in all versions up to, and including, 3.4.8. This is due to inadequate input validation in the `save_template_to_file()` function where user-controlled parameters like `session_id`, `content_id`, and `ai_page_ids` are used to construct file paths without proper sanitization. This makes it possible for unauthenticated attackers to write arbitrary `.ai.json` files to locations within the uploads directory.",
  "id": "GHSA-8643-3fq3-vwcr",
  "modified": "2026-01-10T12:30:16Z",
  "published": "2026-01-10T12:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0831"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/templately/tags/3.4.5/includes/API/AIContent.php#L38"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/templately/tags/3.4.5/includes/Core/Importer/Utils/AIUtils.php#L414"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3426051"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/778242f4-5dfa-4d72-a032-8b5521c5b8ce?source=cve"
    }
  ],
  "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"
    }
  ]
}

GHSA-86C4-QJG9-RJ6M

Vulnerability from github – Published: 2022-03-31 00:00 – Updated: 2022-04-06 00:01
VLAI
Details

In Telecom, there is a possible leak of TTY mode change due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12LAndroid ID: A-203880906

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-39789"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-30T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "In Telecom, there is a possible leak of TTY mode change due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12LAndroid ID: A-203880906",
  "id": "GHSA-86c4-qjg9-rj6m",
  "modified": "2022-04-06T00:01:49Z",
  "published": "2022-03-31T00:00:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39789"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/android-12l"
    }
  ],
  "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-86JG-35XJ-3VV5

Vulnerability from github – Published: 2025-05-30 15:30 – Updated: 2025-05-30 18:48
VLAI
Summary
Mattermost fails to properly enforce access control restrictions for System Manager roles
Details

Mattermost versions 10.7.x <= 10.7.0, 10.5.x <= 10.5.3, 9.11.x <= 9.11.12 fails to properly enforce access control restrictions for System Manager roles, allowing authenticated users with System Manager privileges to view team details they should not have access to via direct API requests to team endpoints, even when explicitly configured with 'No access' to Teams in the System Console.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.6.0-rc1"
            },
            {
              "fixed": "10.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0-rc1"
            },
            {
              "fixed": "10.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0-rc1"
            },
            {
              "fixed": "9.11.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0-20250414154356-6f33b721de76"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-3611"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-30T18:48:31Z",
    "nvd_published_at": "2025-05-30T15:15:41Z",
    "severity": "LOW"
  },
  "details": "Mattermost versions 10.7.x \u003c= 10.7.0, 10.5.x \u003c= 10.5.3, 9.11.x \u003c= 9.11.12 fails to properly enforce access control restrictions for System Manager roles, allowing authenticated users with System Manager privileges to view team details they should not have access to via direct API requests to team endpoints, even when explicitly configured with \u0027No access\u0027 to Teams in the System Console.",
  "id": "GHSA-86jg-35xj-3vv5",
  "modified": "2025-05-30T18:48:32Z",
  "published": "2025-05-30T15:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3611"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/6f33b721de76b39a7714bfe0d5e9c1306869a3e3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "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"
    }
  ],
  "summary": "Mattermost fails to properly enforce access control restrictions for System Manager roles"
}
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