Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

7198 vulnerabilities reference this CWE, most recent first.

GHSA-5974-GFQC-WRCM

Vulnerability from github – Published: 2026-10-09 20:53 – Updated: 2026-10-09 20:53
VLAI
Summary
Contao: Improper access control in the table access voter
Details

Due to a caching defect in the security voter that governs table-level access to Contao's Data Container (DCA) backend, a low-privileged, non-admin backend user can obtain unauthorized read, create, update, and delete access to database tables outside their assigned module permissions. This includes tables containing sensitive personal data, such as frontend member records and newsletter subscriber e-mail addresses.

Vulnerability Details

In plain terms: Contao's backend is organized into modules (e.g. "News", "Members"). Every backend user is assigned to a group, and that group decides which modules, and therefore which database tables, they are allowed to work with. Before Contao lets a user touch a table, it is supposed to check: "does this user's group actually include this table?"

To avoid doing that check over and over, Contao remembers the answer for the rest of the request. The problem is that it remembers the answer under the wrong label. Instead of remembering "is this user allowed to access table X", it only remembers "is this user allowed to access something", without recording which table the answer was actually about.

So if a request first checks a table the user IS allowed to see, and then checks a second, completely different table the user is NOT allowed to see, Contao reuses the first answer for the second table too. The user ends up with access to a table their group was never given permission for.

Technical detail

Contao's backend enforces per-table access control through a chain of Symfony security voters. The relevant one is TableAccessVoter::hasAccessToModule(), in core-bundle/src/Security/Voter/DataContainer/TableAccessVoter.php:

```php private array $canAccessTable = []; private array $canReadAccessTable = [];

private function hasAccessToModule(TokenInterface $token, ...): bool
{
    $tokenHash = hash('xxh128', serialize($token));

    if (isset($this->canAccessTable[$tokenHash]) || (...)) {
        return $this->canAccessTable[$tokenHash] ?? $this->canReadAccessTable[$tokenHash];
    }

    $table = $subject->getDataSource();

    foreach ($GLOBALS['BE_MOD'] as $modules) {
        ...
        return $this->canAccessTable[$tokenHash] = true;  // or false
    }
}

```

The cache key, $tokenHash, is built only from the current user's security token. It does not include the table being checked. Because TableAccessVoter is a normal, shared Symfony service, this cache stays alive for the whole duration of one HTTP request. So the first table checked for a user in a request decides the cached answer for every other table checked afterwards in that same request, whether or not that answer is actually correct for the second table.

This is made worse by DefaultDataContainerVoter, a low-priority, permissive fallback voter that grants access to any table-related permission unless another voter explicitly denies it. When TableAccessVoter gives a wrong "no opinion" answer because of the stale cache, this fallback voter turns that into a full grant.

Most database tables in Contao have no second, table-specific check to catch this. Only tl_content, tl_favorites, tl_form, tl_form_field, tl_module, tl_image_size(_item), tl_job, tl_layout, tl_page, tl_preview_link, tl_undo, and tl_user have one. Tables such as tl_member (website member data), tl_newsletter_recipients (subscriber e-mail addresses), tl_news, tl_calendar_events, tl_faq, and tl_comments rely only on the defective check described above.

Credits

This security vulnerability was found by Sven Jäger of SySS GmbH.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "contao/core-bundle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.7.0"
            },
            {
              "fixed": "5.7.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107851"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-09T20:53:42Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "Due to a caching defect in the security voter that governs table-level access to Contao\u0027s Data Container (DCA) backend, a low-privileged, non-admin backend user can obtain unauthorized read, create, update, and delete access to database tables outside their assigned module permissions. This includes tables containing sensitive personal data, such as frontend member records and newsletter subscriber e-mail addresses.\n\n### Vulnerability Details\n\nIn plain terms: Contao\u0027s backend is organized into modules (e.g. \"News\", \"Members\"). Every backend user is assigned to a group, and that group decides which modules, and therefore which database tables, they are allowed to work with. Before Contao lets a user touch a table, it is supposed to check: \"does this user\u0027s group actually include this table?\"\n\nTo avoid doing that check over and over, Contao remembers the answer for the rest of the request. The problem is that it remembers the answer under the wrong label. Instead of remembering \"is this user allowed to access table X\", it only remembers \"is this user allowed to access something\", without recording which table the answer was actually about.\n \nSo if a request first checks a table the user IS allowed to see, and then checks a second, completely different table the user is NOT allowed to see, Contao reuses the first answer for the second table too. The user ends up with access to a table their group was never given permission for.\n \n### Technical detail\n \nContao\u0027s backend enforces per-table access control through a chain of Symfony security voters. The relevant one is\n`TableAccessVoter::hasAccessToModule()`, in `core-bundle/src/Security/Voter/DataContainer/TableAccessVoter.php`:\n \n```php\n    private array $canAccessTable = [];\n    private array $canReadAccessTable = [];\n \n    private function hasAccessToModule(TokenInterface $token, ...): bool\n    {\n        $tokenHash = hash(\u0027xxh128\u0027, serialize($token));\n \n        if (isset($this-\u003ecanAccessTable[$tokenHash]) || (...)) {\n            return $this-\u003ecanAccessTable[$tokenHash] ?? $this-\u003ecanReadAccessTable[$tokenHash];\n        }\n \n        $table = $subject-\u003egetDataSource();\n \n        foreach ($GLOBALS[\u0027BE_MOD\u0027] as $modules) {\n            ...\n            return $this-\u003ecanAccessTable[$tokenHash] = true;  // or false\n        }\n    }\n ```\n\nThe cache key, `$tokenHash`, is built only from the current user\u0027s security token. It does not include the table being checked. Because `TableAccessVoter` is a normal, shared Symfony service, this cache stays alive for the whole duration of one HTTP request. So the first table checked for a user in a request decides the cached answer for every other table checked afterwards in that same request, whether or not that answer is actually correct for the second table.\n \nThis is made worse by `DefaultDataContainerVoter`, a low-priority, permissive fallback voter that grants access to any table-related permission unless another voter explicitly denies it. When `TableAccessVoter` gives a wrong \"no opinion\" answer because of the stale cache, this fallback voter turns that into a full grant.\n \nMost database tables in Contao have no second, table-specific check to catch this. Only `tl_content`, `tl_favorites`, `tl_form`, `tl_form_field`, `tl_module`, `tl_image_size(_item)`, `tl_job`, `tl_layout`, `tl_page`, `tl_preview_link`, `tl_undo`, and `tl_user` have one. Tables such as `tl_member` (website member data), `tl_newsletter_recipients` (subscriber e-mail addresses), `tl_news`, `tl_calendar_events`, `tl_faq`, and `tl_comments` rely only on the defective check described above.\n\n### Credits\n\nThis security vulnerability was found by Sven J\u00e4ger of SySS GmbH.",
  "id": "GHSA-5974-gfqc-wrcm",
  "modified": "2026-10-09T20:53:42Z",
  "published": "2026-10-09T20:53:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/contao/contao/security/advisories/GHSA-5974-gfqc-wrcm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/contao/contao/commit/9d6f582a4cc6a758ce11d1043fc9c0ba62c5f4c9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/contao/contao"
    },
    {
      "type": "WEB",
      "url": "https://github.com/contao/contao/releases/tag/5.7.12"
    }
  ],
  "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": "Contao: Improper access control in the table access voter"
}

GHSA-5984-MR35-258V

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

Zoho Remote Access Plus Server Windows Desktop Binary fixed from 10.1.2121.1 is affected by incorrect access control. The installation directory is vulnerable to weak file permissions by allowing full control for Windows Everyone user group (non-admin or any guest users), thereby allowing privilege escalation, unauthorized password reset, stealing of sensitive data, access to credentials in plaintext, access to registry values, tampering with configuration files, etc.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-42954"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-17T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "Zoho Remote Access Plus Server Windows Desktop Binary fixed from 10.1.2121.1 is affected by incorrect access control. The installation directory is vulnerable to weak file permissions by allowing full control for Windows Everyone user group (non-admin or any guest users), thereby allowing privilege escalation, unauthorized password reset, stealing of sensitive data, access to credentials in plaintext, access to registry values, tampering with configuration files, etc.",
  "id": "GHSA-5984-mr35-258v",
  "modified": "2022-07-13T00:01:43Z",
  "published": "2022-05-24T19:20:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42954"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/nestedif/vulnerability-disclosure-improper-filesystem-permission-misconfigured-acls-zoho-r-a-p-56e195464b51"
    }
  ],
  "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-5993-WWPG-M92C

Vulnerability from github – Published: 2021-11-23 17:56 – Updated: 2023-12-05 22:47
VLAI
Summary
Apache Ozone user impersonation due to non-validation of Ozone S3 tokens
Details

In Apache Ozone before 1.2.0, Authenticated users with valid Ozone S3 credentials can create specific OM requests, impersonating any other user.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.hadoop:hadoop-ozone-ozone-manager"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-39236"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-11-22T19:05:30Z",
    "nvd_published_at": "2021-11-19T10:15:00Z",
    "severity": "HIGH"
  },
  "details": "In Apache Ozone before 1.2.0, Authenticated users with valid Ozone S3 credentials can create specific OM requests, impersonating any other user.",
  "id": "GHSA-5993-wwpg-m92c",
  "modified": "2023-12-05T22:47:46Z",
  "published": "2021-11-23T17:56:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39236"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/ozone/pull/1871"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/ozone/commit/60e078729e18ef1be276f35659957ac553d266f7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/ozone"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/HDDS-4763"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/q0lhspolnwfbsw33w98b7b1923n1np4d"
    },
    {
      "type": "WEB",
      "url": "https://mail-archives.apache.org/mod_mbox/ozone-dev/202111.mbox/%3C0fd74baa-88a0-39a2-8f3a-b982acb25d5a%40apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2021/11/19/7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache Ozone user impersonation due to non-validation of Ozone S3 tokens"
}

GHSA-5997-5448-JFQF

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

A duplicate SystemPrincipal object could be created when parsing a non-system html document via DOMParser::ParseFromSafeString. This could have lead to bypassing web security checks. This vulnerability affects Firefox < 109.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-23604"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-02T17:15:10Z",
    "severity": "MODERATE"
  },
  "details": "A duplicate \u003ccode\u003eSystemPrincipal\u003c/code\u003e object could be created when parsing a non-system html document via \u003ccode\u003eDOMParser::ParseFromSafeString\u003c/code\u003e. This could have lead to bypassing web security checks. This vulnerability affects Firefox \u003c 109.",
  "id": "GHSA-5997-5448-jfqf",
  "modified": "2024-04-04T04:29:46Z",
  "published": "2023-06-02T18:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23604"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1802346"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2023-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-59GF-XXWW-6GV7

Vulnerability from github – Published: 2026-09-03 21:31 – Updated: 2026-09-03 21:31
VLAI
Details

Incorrect Authorization (CWE-863) in Kibana can lead to information disclosure via Exploiting Incorrectly Configured Access Control Security Levels (CAPEC-180).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-82299"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-03T19:17:29Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect Authorization (CWE-863) in Kibana can lead to information disclosure via Exploiting Incorrectly Configured Access Control Security Levels (CAPEC-180).",
  "id": "GHSA-59gf-xxww-6gv7",
  "modified": "2026-09-03T21:31:15Z",
  "published": "2026-09-03T21:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82299"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/kibana-9-4-6-9-5-3-security-update-esa-2026-175/390163"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-59HR-796Q-5P86

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

Rockwell Automation FactoryTalk Services Platform v6.11 and earlier, if FactoryTalk Security is enabled and deployed contains a vulnerability that may allow a remote, authenticated attacker to bypass FactoryTalk Security policies based on the computer name. If successfully exploited, this may allow an attacker to have the same privileges as if they were logged on to the client machine.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-32960"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-01T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "Rockwell Automation FactoryTalk Services Platform v6.11 and earlier, if FactoryTalk Security is enabled and deployed contains a vulnerability that may allow a remote, authenticated attacker to bypass FactoryTalk Security policies based on the computer name. If successfully exploited, this may allow an attacker to have the same privileges as if they were logged on to the client machine.",
  "id": "GHSA-59hr-796q-5p86",
  "modified": "2022-04-13T00:00:51Z",
  "published": "2022-04-03T00:01:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32960"
    },
    {
      "type": "WEB",
      "url": "https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/1131785"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-21-161-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-59PP-RVHC-93RH

Vulnerability from github – Published: 2024-12-19 12:32 – Updated: 2024-12-19 12:32
VLAI
Details

Incorrect authorization vulnerability in HTTP POST method in Govee Home application on Android and iOS allows remote attacker to control devices owned by other users via changing "device", "sku" and "type" fields' values.  This issue affects Govee Home applications on Android and iOS in versions before 5.9.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-4617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-19T10:15:13Z",
    "severity": "CRITICAL"
  },
  "details": "Incorrect authorization vulnerability in HTTP POST method in Govee Home application on Android and iOS allows remote attacker to control devices owned by other users via changing \"device\", \"sku\" and \"type\" fields\u0027 values.\u00a0\nThis issue affects Govee Home applications on Android and iOS in versions\u00a0before 5.9.",
  "id": "GHSA-59pp-rvhc-93rh",
  "modified": "2024-12-19T12:32:40Z",
  "published": "2024-12-19T12:32:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4617"
    },
    {
      "type": "WEB",
      "url": "https://apps.apple.com/us/app/govee-home/id1395696823"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/en/posts/2024/12/CVE-2023-4617"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/posts/2024/12/CVE-2023-4617"
    },
    {
      "type": "WEB",
      "url": "https://play.google.com/store/apps/details?id=com.govee.home"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-59W7-V8RR-PR4P

Vulnerability from github – Published: 2026-09-22 20:36 – Updated: 2026-09-22 20:36
VLAI
Summary
OpenBao's Templated Policies Allow Privilege Escalation via Wildcard Characters
Details

Impact

ACL Policies

OpenBao supports "templated polices": Policies with placeholders that are replaced at evaluation time.

This allows you to write a single policy which e.g. grants user "alice" access to all entries in a key value engine prefixed with alice/ while granting "bob" access to bob/, "carol" access to carol/, etc.

If the data used in the template can be controlled by an attacker (e.g. your system allows the user to freely select their username) and "globbing" characters are considered valid ( e.g. * is a valid username) they will be able to escalate their privileges.

The problematic characters are *, + and /.

PKI Secrets Engine allowed_uri_sans_template and allowed_domains Polices

The PKI secrets engine allows you to limit the "common names" a user can requests a TLS certificate for. Similar to the ACL polices this allows you to restrict e.g. "alice" to alice.example.com, "bob" to bob.example.com, etc. via templates.

Again, if an attacker can control this data freely, they can trick the PKI engine into using e.g. the *.example.com glob effectively allowing them to issue certificates for any subdomain of example.com

The problematic character in this case is *.

SSH Secrets Engine allowed_users and allowed_domains Polices

The SSH secrets engine allows you to limit the "principal" a user can request as SSH certificate for. Similar to ACL and PKI, this allows templates.

The problematic character in this case is , as the template result is split at all commas and each entry will be allowed.

Am I affected?

You are affected, if a) you use a templated policy (ACL, PKI or SSH) and b) your users can modify data used by your template freely.

If you can guarantee that the data used in your templates will never contain the problematic characters, you are not affected. For example, if you use {{ identity.entity.id }} in your policy, you are not affected, because identity.entity.id is randomly generated by OpenBao.

Even with this vulnerability patched: Using user controllable data in your policies is probably not the best idea.

Patches

All three have been patched in OpenBao v2.6.0.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openbao/openbao"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260710001938-2d4ebafec5c5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openbao/openbao"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.0"
            },
            {
              "last_affected": "1.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-71543"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:36:49Z",
    "nvd_published_at": "2026-09-21T15:17:31Z",
    "severity": "HIGH"
  },
  "details": "## Impact\n\n### ACL Policies\n\nOpenBao supports \"templated polices\": Policies with placeholders that are replaced at evaluation time.\n\nThis allows you to write a single policy which e.g. grants user \"alice\" access to all entries in a key value engine prefixed with `alice/` while granting \"bob\" access to `bob/`, \"carol\" access to `carol/`, etc.\n\nIf the data used in the template can be controlled by an attacker (e.g. your system allows the user to freely select their username) and \"globbing\" characters are considered valid ( e.g. `*` is a valid username) they will be able to escalate their privileges.\n\nThe problematic characters are `*`, `+` and `/`.\n\n### PKI Secrets Engine `allowed_uri_sans_template` and `allowed_domains` Polices\n\nThe PKI secrets engine allows you to limit the \"common names\" a user can requests a TLS certificate for. Similar to the ACL polices this allows you to restrict e.g. \"alice\" to  `alice.example.com`, \"bob\" to  `bob.example.com`, etc. via templates.\n\nAgain, if an attacker can control this data freely, they can trick the PKI engine into using e.g. the `*.example.com` glob effectively allowing them to issue certificates for any subdomain of `example.com`\n\nThe problematic character in this case is `*`.\n\n### SSH Secrets Engine `allowed_users` and `allowed_domains` Polices\n\nThe SSH secrets engine allows you to limit the \"principal\" a user can request as SSH certificate for. Similar to ACL and PKI, this allows templates.\n\nThe problematic character in this case is `,` as the template result is split at all commas and each entry will be allowed.\n\n## Am I affected?\n\nYou are affected, if a) you use a templated policy (ACL, PKI or SSH) and b) your users can modify data used by your template freely.\n\nIf you can guarantee that the data used in your templates will never contain the problematic characters, you are not affected. For example, if you use `{{ identity.entity.id }}` in your policy, you are not affected, because `identity.entity.id` is randomly generated by OpenBao.\n\n\n\nEven with this vulnerability patched: Using user controllable data in your policies is probably not the best idea.\n\n## Patches\n\nAll three have been patched in OpenBao v2.6.0.",
  "id": "GHSA-59w7-v8rr-pr4p",
  "modified": "2026-09-22T20:36:49Z",
  "published": "2026-09-22T20:36:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/security/advisories/GHSA-59w7-v8rr-pr4p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-71543"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/pull/3401"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/pull/3473"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/commit/2d4ebafec5c524408b3d4ac1198df909cb7ac8c1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/commit/e516ce508e1481504cadbfbf62052364339093bc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashicorp/vault/blob/main/CHANGELOG.md#201"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openbao/openbao"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/releases/tag/v2.6.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": " OpenBao\u0027s Templated Policies Allow Privilege Escalation via Wildcard Characters"
}

GHSA-59XQ-494M-CHP8

Vulnerability from github – Published: 2022-04-29 00:00 – Updated: 2022-05-11 00:02
VLAI
Details

Zoho ManageEngine Access Manager Plus before 4302, Password Manager Pro before 12007, and PAM360 before 5401 are vulnerable to access-control bypass on a few Rest API URLs (for SSOutAction. SSLAction. LicenseMgr. GetProductDetails. GetDashboard. FetchEvents. and Synchronize) via the ../RestAPI substring.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-29081"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-28T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Zoho ManageEngine Access Manager Plus before 4302, Password Manager Pro before 12007, and PAM360 before 5401 are vulnerable to access-control bypass on a few Rest API URLs (for SSOutAction. SSLAction. LicenseMgr. GetProductDetails. GetDashboard. FetchEvents. and Synchronize) via the ../RestAPI substring.",
  "id": "GHSA-59xq-494m-chp8",
  "modified": "2022-05-11T00:02:08Z",
  "published": "2022-04-29T00:00:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29081"
    },
    {
      "type": "WEB",
      "url": "https://www.manageengine.com/privileged-session-management/advisory/cve-2022-29081.html"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/research/tra-2022-14"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5C44-88QH-4C5H

Vulnerability from github – Published: 2026-07-20 12:33 – Updated: 2026-07-20 12:33
VLAI
Details

SurrealDB versions before 3.1.0 contain a field-level SELECT permission bypass vulnerability in indexed COUNT fast paths. Attackers can execute COUNT queries on indexed fields with field-level SELECT restrictions to confirm or recover restricted field values through repeated guesses.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-63742"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-20T12:19:43Z",
    "severity": "MODERATE"
  },
  "details": "SurrealDB versions before 3.1.0 contain a field-level SELECT permission bypass vulnerability in indexed COUNT fast paths. Attackers can execute COUNT queries on indexed fields with field-level SELECT restrictions to confirm or recover restricted field values through repeated guesses.",
  "id": "GHSA-5c44-88qh-4c5h",
  "modified": "2026-07-20T12:33:09Z",
  "published": "2026-07-20T12:33:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-c8jx-96c9-8xrp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63742"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/surrealdb-before-field-permission-bypass-via-indexed-count"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

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.