CWE-863
Allowed-with-ReviewIncorrect 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.
5841 vulnerabilities reference this CWE, most recent first.
GHSA-6GJM-6WJ6-4PX5
Vulnerability from github – Published: 2022-08-06 05:20 – Updated: 2022-08-06 05:20Impact
Users electing to prevent others starting private discussions with themselves.
Please note that admins and others with appropriate permissions can always bypass this preference, as was the case before.
Patches
Users of Byobu should update the extension to version 1.1.7, where this has been patched. This version is only supported on v1.2.0 and later of Flarum Core.
Users of Byobu with Flarum 1.0 or 1.1 should upgrade to Flarum 1.2 or later, or evaluate the impact this issue has on your forum's users and choose to disable the extension if needed.
Workarounds
There are no workarounds for this issue.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "fof/byobu"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.0-beta.2"
},
{
"fixed": "1.1.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-35921"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-08-06T05:20:52Z",
"nvd_published_at": "2022-08-01T22:15:00Z",
"severity": "LOW"
},
"details": "### Impact\nUsers electing to prevent others starting private discussions with themselves.\n\n\u003e Please note that admins and others with appropriate permissions can always bypass this preference, as was the case before.\n\n### Patches\nUsers of Byobu should update the extension to version 1.1.7, where this has been patched. **This version is only supported on v1.2.0 and later of Flarum Core.**\n\nUsers of Byobu with Flarum 1.0 or 1.1 should upgrade to Flarum 1.2 or later, or evaluate the impact this issue has on your forum\u0027s users and choose to disable the extension if needed.\n\n### Workarounds\nThere are no workarounds for this issue.",
"id": "GHSA-6gjm-6wj6-4px5",
"modified": "2022-08-06T05:20:52Z",
"published": "2022-08-06T05:20:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FriendsOfFlarum/byobu/security/advisories/GHSA-6gjm-6wj6-4px5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35921"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfFlarum/byobu/commit/23dcf93a30f948d30c678a96681f7fdefeba5171"
},
{
"type": "PACKAGE",
"url": "https://github.com/FriendsOfFlarum/byobu"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Byobu user preference to prevent private discussions being started are not respected"
}
GHSA-6GQR-MX34-WH8R
Vulnerability from github – Published: 2026-04-24 20:39 – Updated: 2026-04-24 20:39TL;DR
This vulnerability affects all Kirby sites where users of a particular role have no permission to create pages, files or users (pages.create, files.create or users.create 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.
Developers' Kirby sites are not affected if they intend all users of their site to be able to create pages, files and users. The vulnerability can only be exploited by authenticated users.
Introduction
An authorization bypass allows authenticated users to perform actions they should not be allowed to perform based on their configured permissions, thereby causing a privilege escalation.
The effects of an authorization bypass 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.create, files.create and users.create permissions (among others). These permissions can again be set in the user blueprint and/or in the blueprint of the target model via options. In affected releases, Kirby allowed to override the options during the creation of pages, files and users by injecting custom dynamic blueprint configuration into the model data. The injected options could include 'create' => true, which then caused an override of the permissions and options configured by the site developer in the user and model blueprints.
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 updated the normalization code that is used during the creation of pages, files and users to include a filter for the blueprint property. This prevents the injection of dynamic blueprint configuration into the creation request.
Credits
Kirby thanks @offset for responsibly reporting the identified issue.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "getkirby/cms"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.9.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "getkirby/cms"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41325"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-24T20:39:36Z",
"nvd_published_at": "2026-04-24T01:16:12Z",
"severity": "HIGH"
},
"details": "### TL;DR\n\nThis vulnerability affects all Kirby sites where users of a particular role have no permission to create pages, files or users (`pages.create`, `files.create` or `users.create` 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\nDevelopers\u0027 Kirby sites are *not* affected if they intend all users of their site to be able to create pages, files and users. The vulnerability can only be exploited by authenticated users.\n\n----\n\n### Introduction\n\nAn authorization bypass allows authenticated users to perform actions they should not be allowed to perform based on their configured permissions, thereby causing a privilege escalation.\n\nThe effects of an authorization bypass 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.create`, `files.create` and `users.create` permissions (among others). These permissions can again be set in the user blueprint and/or in the blueprint of the target model via `options`. In affected releases, Kirby allowed to override the `options` during the creation of pages, files and users by injecting custom dynamic blueprint configuration into the model data. The injected `options` could include `\u0027create\u0027 =\u003e true`, which then caused an override of the permissions and options configured by the site developer in the user and model blueprints.\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 updated the normalization code that is used during the creation of pages, files and users to include a filter for the `blueprint` property. This prevents the injection of dynamic blueprint configuration into the creation request.\n\n### Credits\n\nKirby thanks @offset for responsibly reporting the identified issue.",
"id": "GHSA-6gqr-mx34-wh8r",
"modified": "2026-04-24T20:39:36Z",
"published": "2026-04-24T20:39:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getkirby/kirby/security/advisories/GHSA-6gqr-mx34-wh8r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41325"
},
{
"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:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Kirby is vulnerable to authorization bypass during page, file and user creation via blueprint injection"
}
GHSA-6GQW-JQV7-V88M
Vulnerability from github – Published: 2026-06-19 21:43 – Updated: 2026-06-19 21:43Summary
On a multi-tenant stigmem node, a caller holding a write credential for one tenant can run a decay sweep that acts on every tenant's facts. The candidate-selection queries in lifecycle/decay.py (_select_ttl_candidates, _select_confidence_candidates) carried no tenant_id predicate, and the caller's tenant was not threaded into the sweep or its async worker (run_decay_sweep / _decay_job_worker), reached via POST /v1/decay/sweep.
Impact
A sweep with ttl_seconds=0 expires all tenants' facts — cross-tenant data destruction (integrity and availability). A dry_run sweep returns a global candidate count, acting as a cross-tenant existence/volume oracle (information disclosure).
Affected configurations
This is a cross-tenant break. It is exploitable only on deployments running the opt-in stigmem-plugin-multi-tenant (multiple tenants on one node). A default single-tenant node has only tenant="default" — there is no second tenant to cross — so it is not exploitable on default deployments. The rating is HIGH for the multi-tenant deployments the plugin exists to isolate.
Patches
Fixed in 0.9.0a12 (PR #728): identity.tenant_id is threaded into run_decay_sweep and _decay_job_worker, and AND tenant_id = ? was added to the candidate selectors and the graph-sync. A tenant-B sweep now leaves tenant-A facts untouched, and dry_run counts only the caller's tenant. The check_fact_query_tenant_scope.py CI guard was extended to scan lifecycle/ so this class cannot silently regress.
Workarounds
None other than upgrading to 0.9.0a12. Single-tenant deployments are unaffected.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "stigmem-node"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.0a12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T21:43:02Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nOn a multi-tenant stigmem node, a caller holding a `write` credential for **one** tenant can run a decay sweep that acts on **every** tenant\u0027s facts. The candidate-selection queries in `lifecycle/decay.py` (`_select_ttl_candidates`, `_select_confidence_candidates`) carried no `tenant_id` predicate, and the caller\u0027s tenant was not threaded into the sweep or its async worker (`run_decay_sweep` / `_decay_job_worker`), reached via `POST /v1/decay/sweep`.\n\n### Impact\nA sweep with `ttl_seconds=0` expires **all tenants\u0027** facts \u2014 cross-tenant data destruction (integrity and availability). A `dry_run` sweep returns a global candidate count, acting as a cross-tenant existence/volume **oracle** (information disclosure).\n\n### Affected configurations\nThis is a cross-**tenant** break. It is exploitable **only** on deployments running the opt-in `stigmem-plugin-multi-tenant` (multiple tenants on one node). A default single-tenant node has only `tenant=\"default\"` \u2014 there is no second tenant to cross \u2014 so it is **not exploitable** on default deployments. The rating is HIGH for the multi-tenant deployments the plugin exists to isolate.\n\n### Patches\nFixed in `0.9.0a12` (PR #728): `identity.tenant_id` is threaded into `run_decay_sweep` and `_decay_job_worker`, and `AND tenant_id = ?` was added to the candidate selectors and the graph-sync. A tenant-B sweep now leaves tenant-A facts untouched, and `dry_run` counts only the caller\u0027s tenant. The `check_fact_query_tenant_scope.py` CI guard was extended to scan `lifecycle/` so this class cannot silently regress.\n\n### Workarounds\nNone other than upgrading to `0.9.0a12`. Single-tenant deployments are unaffected.",
"id": "GHSA-6gqw-jqv7-v88m",
"modified": "2026-06-19T21:43:03Z",
"published": "2026-06-19T21:43:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/eidetic-labs/stigmem/security/advisories/GHSA-6gqw-jqv7-v88m"
},
{
"type": "WEB",
"url": "https://github.com/eidetic-labs/stigmem/pull/728"
},
{
"type": "PACKAGE",
"url": "https://github.com/eidetic-labs/stigmem"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "stigmem-node: decay sweep expires and counts facts across all tenants (cross-tenant BOLA)"
}
GHSA-6GW3-344Q-7P6R
Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-10-27 19:00The Ninja Forms WordPress plugin is vulnerable to arbitrary email sending via the trigger_email_action function found in the ~/includes/Routes/Submissions.php file, in versions up to and including 3.5.7. This allows authenticated attackers to send arbitrary emails from the affected server via the /ninja-forms-submissions/email-action REST API which can be used to socially engineer victims.
{
"affected": [],
"aliases": [
"CVE-2021-34648"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-22T18:15:00Z",
"severity": "MODERATE"
},
"details": "The Ninja Forms WordPress plugin is vulnerable to arbitrary email sending via the trigger_email_action function found in the ~/includes/Routes/Submissions.php file, in versions up to and including 3.5.7. This allows authenticated attackers to send arbitrary emails from the affected server via the /ninja-forms-submissions/email-action REST API which can be used to socially engineer victims.",
"id": "GHSA-6gw3-344q-7p6r",
"modified": "2022-10-27T19:00:39Z",
"published": "2022-05-24T19:15:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34648"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/ninja-forms/trunk/includes/Routes/Submissions.php?rev=2543837#L155"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/blog/2021/09/recently-patched-vulnerabilities-in-ninja-forms-plugin-affects-over-1-million-site-owners"
}
],
"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-6GWW-QGC8-R365
Vulnerability from github – Published: 2026-04-22 18:31 – Updated: 2026-04-22 18:31GitLab has remediated an issue in GitLab CE/EE affecting all versions from 11.2 before 18.9.6, 18.10 before 18.10.4, and 18.11 before 18.11.1 that under certain conditions could have allowed an authenticated user with project owner permissions to bypass group fork prevention settings due to improper authorization checks.
{
"affected": [],
"aliases": [
"CVE-2025-9957"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T17:16:33Z",
"severity": "LOW"
},
"details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 11.2 before 18.9.6, 18.10 before 18.10.4, and 18.11 before 18.11.1 that under certain conditions could have allowed an authenticated user with project owner permissions to bypass group fork prevention settings due to improper authorization checks.",
"id": "GHSA-6gww-qgc8-r365",
"modified": "2026-04-22T18:31:44Z",
"published": "2026-04-22T18:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9957"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3275222"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/releases/2026/04/22/patch-release-gitlab-18-11-1-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/work_items/567781"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6H46-9JF5-Q59X
Vulnerability from github – Published: 2026-06-15 17:28 – Updated: 2026-06-15 17:28Description
When a firewall is configured with form-login (or any authenticator using DefaultAuthenticationFailureHandler) and the failure_forward: true option, the handler reads the _failure_path parameter from the failing login request and uses it as the path of an internal subrequest dispatched through HttpKernelInterface::SUB_REQUEST.
Symfony's Firewall::onKernelRequest listener intentionally skips subrequests under the assumption they are internally generated and trusted, which also means AccessListener (the listener that evaluates access_control) does not run. Because the attacker controls the target of the subrequest, an unauthenticated POST to the check path with _failure_path=/admin/whatever performs a local request forgery that executes the target controller outside the firewall perimeter and returns its response to the caller.
Applications that follow Symfony's recommended best practice of protecting administrative areas with broad access_control rules (e.g. ^/admin requires ROLE_ADMIN) and expose read-only GET endpoints under that area (data exports, internal APIs, account views) are fully exposed: any such GET route can be read by an unauthenticated attacker without any developer misconfiguration, debug mode, or state-changing GET handler being required.
Resolution
DefaultAuthenticationFailureHandler no longer honors the request-supplied _failure_path parameter when failure_forward is enabled. The subrequest is always dispatched to the configured failure_path option (defaulting to login_path), which is set by the application owner and not by the request. The redirect branch (failure_forward: false) is unchanged because redirects re-enter the firewall on the next request and are not subject to this bypass.
The patch for this issue is available here for branch 5.4.
Credits
Symfony would like to thank Nguyen Ngoc Toan Thang (@a-tt-om) and Tran Quoc Tri Trung (@teebow1e) for reporting the issue, and Nicolas Grekas for providing the fix.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/security-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.4.53"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.4.53"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/security-http"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.4.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/security-http"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.4.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/security-http"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.4.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.4.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48489"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T17:28:20Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Description\n\nWhen a firewall is configured with `form-login` (or any authenticator using `DefaultAuthenticationFailureHandler`) and the `failure_forward: true` option, the handler reads the `_failure_path` parameter from the failing login request and uses it as the path of an internal subrequest dispatched through `HttpKernelInterface::SUB_REQUEST`.\n\nSymfony\u0027s `Firewall::onKernelRequest` listener intentionally skips subrequests under the assumption they are internally generated and trusted, which also means `AccessListener` (the listener that evaluates `access_control`) does not run. Because the attacker controls the target of the subrequest, an unauthenticated POST to the check path with `_failure_path=/admin/whatever` performs a local request forgery that executes the target controller outside the firewall perimeter and returns its response to the caller.\n\nApplications that follow Symfony\u0027s recommended best practice of protecting administrative areas with broad `access_control` rules (e.g. `^/admin` requires `ROLE_ADMIN`) and expose read-only GET endpoints under that area (data exports, internal APIs, account views) are fully exposed: any such GET route can be read by an unauthenticated attacker without any developer misconfiguration, debug mode, or state-changing GET handler being required.\n\n### Resolution\n\n`DefaultAuthenticationFailureHandler` no longer honors the request-supplied `_failure_path` parameter when `failure_forward` is enabled. The subrequest is always dispatched to the configured `failure_path` option (defaulting to `login_path`), which is set by the application owner and not by the request. The redirect branch (`failure_forward: false`) is unchanged because redirects re-enter the firewall on the next request and are not subject to this bypass.\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/c48a4276309e11aedeeb0ce3a89dfbf0b4fe04ff) for branch 5.4.\n\n### Credits\n\nSymfony would like to thank Nguyen Ngoc Toan Thang (@a-tt-om) and Tran Quoc Tri Trung (@teebow1e) for reporting the issue, and Nicolas Grekas for providing the fix.",
"id": "GHSA-6h46-9jf5-q59x",
"modified": "2026-06-15T17:28:20Z",
"published": "2026-06-15T17:28:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/security/advisories/GHSA-6h46-9jf5-q59x"
},
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/commit/c48a4276309e11aedeeb0ce3a89dfbf0b4fe04ff"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/security-http/CVE-2026-48489.yaml"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-48489.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/symfony/symfony"
},
{
"type": "WEB",
"url": "https://symfony.com/cve-2026-48489"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Symfony: Security Firewall Bypass via failure_forward Subrequest: Unauthenticated Access to access_control-Protected GET Routes"
}
GHSA-6H54-VM3J-P486
Vulnerability from github – Published: 2025-03-08 00:31 – Updated: 2025-03-08 00:31An issue was discovered in the Masquerade module before 1.x-1.0.1 for Backdrop CMS. It allows people to temporarily switch to another user account. The module provides a "Masquerade as admin" permission to restrict people (who can masquerade) from switching to an account with administrative privileges. This permission is not always honored and may allow non-administrative users to masquerade as an administrator. This vulnerability is mitigated by the fact that an attacker must have a role with the "Masquerade as user" permission.
{
"affected": [],
"aliases": [
"CVE-2025-27822"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-07T22:15:37Z",
"severity": "HIGH"
},
"details": "An issue was discovered in the Masquerade module before 1.x-1.0.1 for Backdrop CMS. It allows people to temporarily switch to another user account. The module provides a \"Masquerade as admin\" permission to restrict people (who can masquerade) from switching to an account with administrative privileges. This permission is not always honored and may allow non-administrative users to masquerade as an administrator. This vulnerability is mitigated by the fact that an attacker must have a role with the \"Masquerade as user\" permission.",
"id": "GHSA-6h54-vm3j-p486",
"modified": "2025-03-08T00:31:20Z",
"published": "2025-03-08T00:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27822"
},
{
"type": "WEB",
"url": "https://backdropcms.org/security/backdrop-sa-contrib-2025-006"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6H67-934R-82G7
Vulnerability from github – Published: 2023-11-20 21:01 – Updated: 2023-11-20 21:01Impact
Users are able to bypass the field level security. This means fields that they where not allowed to populate could be populated anyway even in the event that they tried to populate something that they don't have access to.
Patches
This issue has been patched in 1.3.4
Workarounds
None
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "strapi-plugin-protected-populate"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-48218"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-20T21:01:43Z",
"nvd_published_at": "2023-11-20T17:15:13Z",
"severity": "MODERATE"
},
"details": "### Impact\nUsers are able to bypass the field level security. This means fields that they where not allowed to populate could be populated anyway even in the event that they tried to populate something that they don\u0027t have access to.\n\n### Patches\nThis issue has been patched in 1.3.4\n\n### Workarounds\nNone\n",
"id": "GHSA-6h67-934r-82g7",
"modified": "2023-11-20T21:01:43Z",
"published": "2023-11-20T21:01:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/strapi-community/strapi-plugin-protected-populate/security/advisories/GHSA-6h67-934r-82g7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48218"
},
{
"type": "WEB",
"url": "https://github.com/strapi-community/strapi-plugin-protected-populate/commit/05441066d64e09dd55937d9f089962e9ebe2fb39"
},
{
"type": "PACKAGE",
"url": "https://github.com/strapi-community/strapi-plugin-protected-populate"
},
{
"type": "WEB",
"url": "https://github.com/strapi-community/strapi-plugin-protected-populate/releases/tag/v1.3.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Bypass of field access control in strapi-plugin-protected-populate"
}
GHSA-6HQP-GVP9-RMV9
Vulnerability from github – Published: 2024-06-21 18:31 – Updated: 2024-06-21 18:31Incorrect Authorization vulnerability in Artbees JupiterX Core allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects JupiterX Core: from n/a through 3.3.8.
{
"affected": [],
"aliases": [
"CVE-2023-38389"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-21T16:15:11Z",
"severity": "CRITICAL"
},
"details": "Incorrect Authorization vulnerability in Artbees JupiterX Core allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects JupiterX Core: from n/a through 3.3.8.",
"id": "GHSA-6hqp-gvp9-rmv9",
"modified": "2024-06-21T18:31:00Z",
"published": "2024-06-21T18:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38389"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/jupiterx-core/wordpress-jupiter-x-core-plugin-3-3-0-unauthenticated-account-takeover-vulnerability?_s_id=cve"
}
],
"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-6HW5-6GCX-PHMW
Vulnerability from github – Published: 2021-09-08 20:14 – Updated: 2021-09-16 18:57HashiCorp Consul and Consul Enterprise 1.10.1 Txn.Apply endpoint allowed services to register proxies for other services, enabling access to service traffic. Fixed in 1.8.15, 1.9.9 and 1.10.2.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/hashicorp/consul"
},
"ranges": [
{
"events": [
{
"introduced": "1.10.1"
},
{
"fixed": "1.10.2"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.10.1"
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/hashicorp/consul"
},
"ranges": [
{
"events": [
{
"introduced": "1.9.0"
},
{
"fixed": "1.9.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/hashicorp/consul"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.8.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-38698"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2021-09-08T18:12:00Z",
"nvd_published_at": "2021-09-07T12:15:00Z",
"severity": "MODERATE"
},
"details": "HashiCorp Consul and Consul Enterprise 1.10.1 Txn.Apply endpoint allowed services to register proxies for other services, enabling access to service traffic. Fixed in 1.8.15, 1.9.9 and 1.10.2.",
"id": "GHSA-6hw5-6gcx-phmw",
"modified": "2021-09-16T18:57:24Z",
"published": "2021-09-08T20:14:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38698"
},
{
"type": "WEB",
"url": "https://github.com/hashicorp/consul/pull/10824"
},
{
"type": "WEB",
"url": "https://discuss.hashicorp.com/t/hcsec-2021-24-consul-missing-authorization-check-on-txn-apply-endpoint/29026"
},
{
"type": "PACKAGE",
"url": "https://github.com/hashicorp/consul"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202208-09"
},
{
"type": "WEB",
"url": "https://www.hashicorp.com/blog/category/consul"
}
],
"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"
}
],
"summary": "HashiCorp Consul and Consul Enterprise 1.10.1 Txn.Apply endpoint allowed services to register proxies for other services, enabling access to service traffic."
}
Mitigation
- 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
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
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
- 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
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.