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.
6598 vulnerabilities reference this CWE, most recent first.
GHSA-23R4-5MXP-C7G5
Vulnerability from github – Published: 2021-08-23 19:41 – Updated: 2022-08-15 20:04Impact
Developers that use the REST API to signup users and also allow users to login anonymously. When an anonymous user is first signed up using REST, the server creates session incorrectly, particularly the authProvider field in _Session class under createdWith shows the user logged in creating a password. If a developer later depends on the createdWith field to provide a different level of access between a password user and anonymous user, the server incorrectly classified the session type as being created with a password.
The server currently doesn't use createdWith to make decisions on how things work internally, so if a developer isn't using createdWith directly, there's nothing to worry about. The vulnerability only affects users who depend on createdWith by using it directly.
Patches
Upgrade to version 4.5.1.
Workarounds
Don't use the createdWith Session field to make decisions if you allow anonymous login.
References
n/a
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "parse-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-39138"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-23T17:07:34Z",
"nvd_published_at": "2021-08-19T16:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nDevelopers that use the REST API to signup users and also allow users to login anonymously. When an anonymous user is first signed up using REST, the server creates session incorrectly, particularly the `authProvider` field in `_Session` class under `createdWith` shows the user logged in creating a password. If a developer later depends on the `createdWith` field to provide a different level of access between a password user and anonymous user, the server incorrectly classified the session type as being created with a `password`.\n\nThe server currently doesn\u0027t use `createdWith` to make decisions on how things work internally, so if a developer isn\u0027t using `createdWith` directly, there\u0027s nothing to worry about. The vulnerability only affects users who depend on `createdWith` by using it directly. \n\n### Patches\nUpgrade to version 4.5.1.\n\n### Workarounds\nDon\u0027t use the `createdWith` Session field to make decisions if you allow anonymous login.\n\n### References\nn/a",
"id": "GHSA-23r4-5mxp-c7g5",
"modified": "2022-08-15T20:04:54Z",
"published": "2021-08-23T19:41:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-23r4-5mxp-c7g5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39138"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/commit/147bd9a3dc43391e92c36e05d5db860b04ca27db"
},
{
"type": "PACKAGE",
"url": "https://github.com/parse-community/parse-server"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/releases/tag/4.5.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "parse-server new anonymous user session acts as if it\u0027s created with password"
}
GHSA-23RX-C3G5-HV9W
Vulnerability from github – Published: 2024-05-08 14:33 – Updated: 2024-05-08 14:33The Deno sandbox may be unexpectedly weakened by allowing file read/write access to privileged files in various locations on Unix and Windows platforms. For example, reading /proc/self/environ may provide access equivalent to --allow-env, and writing /proc/self/mem may provide access equivalent to --allow-all.
Users who grant read and write access to the entire filesystem may not realize that these access to these files may have additional, unintended consequences. The documentation did not reflect that this practice should be undertaken to increase the strength of the security sandbox.
Impact
Users who run code with --allow-read or --allow-write may unexpectedly end up granting additional permissions via file-system operations.
Patches
Deno 1.43 and above require explicit --allow-all access to read or write /etc, /dev on unix platform (as well as /proc and /sys on linux platforms), and any path starting with \\ on Windows.
Workarounds
The security sandbox in previous versions of Deno allows for denial of access to these files, but it requires an explicit addition of deny flags: --deny-read=/dev --deny-read=/sys --deny-read=/proc --deny-read=/etc --deny-write=/dev --deny-write=/sys --deny-write=/proc --deny-write=/etc. Note that symlinks in allowed locations may defeat this protection in earlier versions of Deno.
Reporters
This vulnerability was reported by a number of analysts. Thanks to oliver@secfault-security.com, finn@secfault-security.com, @leesh3288, and @cristianstaicu for their reports and analysis.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "deno"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.43.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-34346"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-08T14:33:16Z",
"nvd_published_at": "2024-05-07T21:15:09Z",
"severity": "HIGH"
},
"details": "The Deno sandbox may be unexpectedly weakened by allowing file read/write access to privileged files in various locations on Unix and Windows platforms. For example, reading `/proc/self/environ` may provide access equivalent to `--allow-env`, and writing `/proc/self/mem` may provide access equivalent to `--allow-all`.\n\nUsers who grant read and write access to the entire filesystem may not realize that these access to these files may have additional, unintended consequences. The documentation did not reflect that this practice should be undertaken to increase the strength of the security sandbox. \n\n### Impact\n\nUsers who run code with `--allow-read` or `--allow-write` may unexpectedly end up granting additional permissions via file-system operations.\n\n### Patches\n\nDeno 1.43 and above require explicit `--allow-all` access to read or write `/etc`, `/dev` on unix platform (as well as `/proc` and `/sys` on linux platforms), and any path starting with `\\\\` on Windows.\n\n### Workarounds\n\nThe security sandbox in previous versions of Deno allows for denial of access to these files, but it requires an explicit addition of deny flags: `--deny-read=/dev --deny-read=/sys --deny-read=/proc --deny-read=/etc --deny-write=/dev --deny-write=/sys --deny-write=/proc --deny-write=/etc`. Note that symlinks in allowed locations may defeat this protection in earlier versions of Deno.\n\n### Reporters\n\nThis vulnerability was reported by a number of analysts. Thanks to [oliver@secfault-security.com](mailto:oliver@secfault-security.com), [finn@secfault-security.com](mailto:finn@secfault-security.com), @leesh3288, and @cristianstaicu for their reports and analysis.\n",
"id": "GHSA-23rx-c3g5-hv9w",
"modified": "2024-05-08T14:33:16Z",
"published": "2024-05-08T14:33:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/denoland/deno/security/advisories/GHSA-23rx-c3g5-hv9w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34346"
},
{
"type": "PACKAGE",
"url": "https://github.com/denoland/deno"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Deno permission escalation vulnerability via open of privileged files with missing `--deny` flag"
}
GHSA-23XR-9XXR-VG3C
Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2024-01-30 22:12An improper authorization vulnerability exists in Jenkins Mesos Plugin 0.17.1 and earlier in MesosCloud.java that allows attackers with Overall/Read access to obtain credentials IDs for credentials stored in Jenkins.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.17.1"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:mesos"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-1000420"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-30T22:12:36Z",
"nvd_published_at": "2019-01-09T23:29:00Z",
"severity": "MODERATE"
},
"details": "An improper authorization vulnerability exists in Jenkins Mesos Plugin 0.17.1 and earlier in MesosCloud.java that allows attackers with Overall/Read access to obtain credentials IDs for credentials stored in Jenkins.",
"id": "GHSA-23xr-9xxr-vg3c",
"modified": "2024-01-30T22:12:36Z",
"published": "2022-05-13T01:48:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000420"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2018-09-25/#SECURITY-1013%20(1)"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106532"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Improper authorization vulnerability in Jenkins Mesos Plugin"
}
GHSA-2424-V4CF-7RR6
Vulnerability from github – Published: 2022-05-24 17:02 – Updated: 2024-04-04 02:40Cloudera CDH before 5.6.1 allows authorization bypass via direct internal API calls.
{
"affected": [],
"aliases": [
"CVE-2016-3131"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-26T14:15:00Z",
"severity": "MODERATE"
},
"details": "Cloudera CDH before 5.6.1 allows authorization bypass via direct internal API calls.",
"id": "GHSA-2424-v4cf-7rr6",
"modified": "2024-04-04T02:40:40Z",
"published": "2022-05-24T17:02:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-3131"
},
{
"type": "WEB",
"url": "https://docs.cloudera.com/documentation/other/security-bulletins/topics/Security-Bulletin.html#tsb_120"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-242M-WGG2-VV66
Vulnerability from github – Published: 2023-07-13 03:30 – Updated: 2024-04-04 06:06An issue has been discovered in GitLab CE/EE affecting all versions starting from 13.7 before 15.11.10, all versions starting from 16.0 before 16.0.6, all versions starting from 16.1 before 16.1.1. This allowed a developer to remove the CODEOWNERS rules and merge to a protected branch.
{
"affected": [],
"aliases": [
"CVE-2023-2576"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-13T03:15:09Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 13.7 before 15.11.10, all versions starting from 16.0 before 16.0.6, all versions starting from 16.1 before 16.1.1. This allowed a developer to remove the CODEOWNERS rules and merge to a protected branch.",
"id": "GHSA-242m-wgg2-vv66",
"modified": "2024-04-04T06:06:08Z",
"published": "2023-07-13T03:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2576"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1898054"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/410123"
}
],
"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-2443-WH6V-5RJF
Vulnerability from github – Published: 2022-05-24 17:04 – Updated: 2022-05-24 17:04Cloud Foundry Cloud Controller API (CAPI), version 1.88.0, allows space developers to list all global service brokers, including service broker URLs and GUIDs, which should only be accessible to admins.
{
"affected": [],
"aliases": [
"CVE-2019-11294"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-12-19T20:15:00Z",
"severity": "MODERATE"
},
"details": "Cloud Foundry Cloud Controller API (CAPI), version 1.88.0, allows space developers to list all global service brokers, including service broker URLs and GUIDs, which should only be accessible to admins.",
"id": "GHSA-2443-wh6v-5rjf",
"modified": "2022-05-24T17:04:41Z",
"published": "2022-05-24T17:04:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11294"
},
{
"type": "WEB",
"url": "https://www.cloudfoundry.org/blog/cve-2019-11294"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-2455-M68H-QWXV
Vulnerability from github – Published: 2026-06-19 15:33 – Updated: 2026-06-23 15:32Incorrect Authorization vulnerability in Apache APISIX.
An attacker can capitalise on authz-casdoor plugin under default configuration to authenticate themselves with credentials from a different source. This issue affects Apache APISIX: from 2.14.1 through 3.16.0.
Users are recommended to upgrade to version 3.17.0, which fixes the issue.
{
"affected": [],
"aliases": [
"CVE-2026-47339"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-19T14:16:22Z",
"severity": "MODERATE"
},
"details": "Incorrect Authorization vulnerability in Apache APISIX.\n\nAn attacker can capitalise on authz-casdoor plugin under default configuration to authenticate themselves with credentials from a different source.\nThis issue affects Apache APISIX: from 2.14.1 through 3.16.0.\n\nUsers are recommended to upgrade to version 3.17.0, which fixes the issue.",
"id": "GHSA-2455-m68h-qwxv",
"modified": "2026-06-23T15:32:30Z",
"published": "2026-06-19T15:33:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47339"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/lk4q5o855cocc7zq5wh1zlctfmcq6f76"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/06/19/9"
}
],
"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:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/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"
}
]
}
GHSA-245J-3RXM-CQMG
Vulnerability from github – Published: 2026-09-09 21:31 – Updated: 2026-09-09 21:31An issue was discovered in Cyrus IMAP before 3.12.4. JMAP snooze bypasses the destination-mailbox ACL. An authenticated user with insert permissions on another user's snoozed mailbox could cause insertion of mail to that user's inbox, or any other of their mailboxes whose id was known to the user, despite having no insert permissions to the target mailbox.
{
"affected": [],
"aliases": [
"CVE-2026-61907"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-09T19:17:28Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Cyrus IMAP before 3.12.4. JMAP snooze bypasses the destination-mailbox ACL. An authenticated user with insert permissions on another user\u0027s snoozed mailbox could cause insertion of mail to that user\u0027s inbox, or any other of their mailboxes whose id was known to the user, despite having no insert permissions to the target mailbox.",
"id": "GHSA-245j-3rxm-cqmg",
"modified": "2026-09-09T21:31:55Z",
"published": "2026-09-09T21:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61907"
},
{
"type": "WEB",
"url": "https://cyrusimap.org"
},
{
"type": "WEB",
"url": "https://www.cyrusimap.org/3.12/imap/download/release-notes/3.10/x/3.10.4.html"
},
{
"type": "WEB",
"url": "https://www.cyrusimap.org/3.12/imap/download/release-notes/3.12/x/3.12.4.html"
},
{
"type": "WEB",
"url": "https://www.cyrusimap.org/3.12/imap/download/release-notes/3.8/x/3.8.8.html"
}
],
"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-245V-P8FJ-VWM2
Vulnerability from github – Published: 2026-04-03 18:29 – Updated: 2026-04-27 16:43Summary
Any authenticated user, machine or controller under a Juju controller can modify the resources of an application within the entire controller.
This one is very straightforward to just read in the code:
Step 1: The authorisation mechanism for the resource handler is defined here. One is only required to have been authed as either a user, machine or controller to pass this check. One requires no permissions on the controller nor does one need any further permissions on the models themselves.
This handler is available under the following path format /:modeluuid/applications/:application/resources/:resources. See here. The handler defines no authorizer as supported by the handler struct here.
One needs to know the following three bits of information to poison the resource cache on the controller: - model uuid - application name in the model - resource name in the model
Given that a lot of deployments use the charm name for applications and the resources for charms are published on charm hub, this is a very low bar to meet, only requiring the model uuid.
Step 2: If one passes the very basic authz check of step 1, one is now allowed free rein for 'PUT' and 'GET' methods to the handler. This security report will only focus on 'PUT' as it is the most interesting. The 'PUT' handler will gladly take whatever is uploaded to it as long as it has the same file extension defined by the resource.
If the resource already exists in the controller's cache, it will be uploaded with whatever is supplied by the upload, see here and here.
That is it. One can successfully poison the resource cache for any model in the controller.
PoC
A proof of concept has not been done for this because it is so obvious from the code read that it is not deemed necessary.
A realistic example of how this can be used: if there is a compromised workload in Juju that has machine credentials, then one can modify the OCI resources for any other model in the controller. For example, if the controller was running a k8s vault, one could change the docker image in use to a trojan horse version that allows obtaining root access to all the vault secrets.
Once this poison has been performed, the attacker can then leverage the vault secrets to go other places.
Impact
Any charm deployment where a resource could be modified to inject security vulnerabilities into another workload. The most obvious is OCI containers as one gets execution escalation, but if a file resource had security controls in it, this could also be leveraged. For the file case, this would need to be examined on a case-by-case basis.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/juju/juju"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260120044552-26ff93c903d5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-68153"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-03T18:29:54Z",
"nvd_published_at": "2026-04-03T16:16:23Z",
"severity": "HIGH"
},
"details": "### Summary\nAny authenticated user, machine or controller under a Juju controller can modify the resources of an application within the entire controller.\n\nThis one is very straightforward to just read in the code:\n\n**Step 1:**\nThe authorisation mechanism for the resource handler is defined [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/internal/handlers/resources/resources.go#L77). One is only required to have been authed as either a user, machine or controller to pass this check. One requires no permissions on the controller nor does one need any further permissions on the models themselves.\n\nThis handler is available under the following path format `/:modeluuid/applications/:application/resources/:resources`. See [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/apiserver.go#L949). The handler defines no authorizer as supported by the handler struct [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/apiserver.go#L696).\n\nOne needs to know the following three bits of information to poison the resource cache on the controller:\n- model uuid\n- application name in the model\n- resource name in the model\n\nGiven that a lot of deployments use the charm name for applications and the resources for charms are published on charm hub, this is a very low bar to meet, only requiring the model uuid.\n\n**Step 2:**\nIf one passes the very basic authz check of step 1, one is now allowed free rein for \u0027PUT\u0027 and \u0027GET\u0027 methods to the handler. This security report will only focus on \u0027PUT\u0027 as it is the most interesting. The \u0027PUT\u0027 handler will gladly take whatever is uploaded to it as long as it has the same file extension defined by the resource.\n\nIf the resource already exists in the controller\u0027s cache, it will be uploaded with whatever is supplied by the upload, see [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/internal/handlers/resources/resources.go#L219) and [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/domain/resource/service/resource.go#L388).\n\nThat is it. One can successfully poison the resource cache for any model in the controller.\n\n### PoC\nA proof of concept has not been done for this because it is so obvious from the code read that it is not deemed necessary.\n\nA realistic example of how this can be used: if there is a compromised workload in Juju that has machine credentials, then one can modify the OCI resources for any other model in the controller. For example, if the controller was running a k8s vault, one could change the docker image in use to a trojan horse version that allows obtaining root access to all the vault secrets.\n\nOnce this poison has been performed, the attacker can then leverage the vault secrets to go other places.\n\n### Impact\nAny charm deployment where a resource could be modified to inject security vulnerabilities into another workload. The most obvious is OCI containers as one gets execution escalation, but if a file resource had security controls in it, this could also be leveraged. For the file case, this would need to be examined on a case-by-case basis.",
"id": "GHSA-245v-p8fj-vwm2",
"modified": "2026-04-27T16:43:56Z",
"published": "2026-04-03T18:29:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/juju/juju/security/advisories/GHSA-245v-p8fj-vwm2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68153"
},
{
"type": "WEB",
"url": "https://github.com/juju/juju/commit/26ff93c903d55b0712c6fb3f6b254710edb971d4"
},
{
"type": "PACKAGE",
"url": "https://github.com/juju/juju"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"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": "Juju has a resource poisoning vulnerability"
}
GHSA-2486-F4HQ-9M5C
Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2022-05-24 17:40The Hide-Thread-Content plugin through 2021-01-27 for MyBB allows remote attackers to bypass intended content-reading restrictions by clicking on reply or quote in the postbit.
{
"affected": [],
"aliases": [
"CVE-2021-3337"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-28T20:15:00Z",
"severity": "HIGH"
},
"details": "The Hide-Thread-Content plugin through 2021-01-27 for MyBB allows remote attackers to bypass intended content-reading restrictions by clicking on reply or quote in the postbit.",
"id": "GHSA-2486-f4hq-9m5c",
"modified": "2022-05-24T17:40:33Z",
"published": "2022-05-24T17:40:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3337"
},
{
"type": "WEB",
"url": "https://github.com/snlbaral/Hide-Thread-Content/issues/1"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/161185/MyBB-Hide-Thread-Content-1.0-Information-Disclosure.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.