CWE-862
Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
14701 vulnerabilities reference this CWE, most recent first.
GHSA-Q6GF-RJFM-W3MV
Vulnerability from github – Published: 2025-06-20 15:30 – Updated: 2026-04-01 18:35Missing Authorization vulnerability in WANotifier WANotifier allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects WANotifier: from n/a through 2.7.7.
{
"affected": [],
"aliases": [
"CVE-2025-49976"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-20T15:15:23Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in WANotifier WANotifier allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects WANotifier: from n/a through 2.7.7.",
"id": "GHSA-q6gf-rjfm-w3mv",
"modified": "2026-04-01T18:35:30Z",
"published": "2025-06-20T15:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49976"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/notifier/vulnerability/wordpress-wanotifier-plugin-2-7-7-broken-access-control-vulnerability?_s_id=cve"
}
],
"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-Q6J2-PQW2-446H
Vulnerability from github – Published: 2024-06-09 12:30 – Updated: 2024-06-09 12:30Missing Authorization vulnerability in MainWP MainWP Staging Extension.This issue affects MainWP Staging Extension: from n/a through 4.0.3.
{
"affected": [],
"aliases": [
"CVE-2023-23639"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-09T10:15:08Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in MainWP MainWP Staging Extension.This issue affects MainWP Staging Extension: from n/a through 4.0.3.",
"id": "GHSA-q6j2-pqw2-446h",
"modified": "2024-06-09T12:30:51Z",
"published": "2024-06-09T12:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23639"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/mainwp-staging-extension/wordpress-mainwp-staging-extension-plugin-4-0-3-subscriber-arbitrary-plugin-activation-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q6JJ-R49P-94FH
Vulnerability from github – Published: 2026-03-30 18:03 – Updated: 2026-03-30 18:03Summary
The get_api_video_file and get_api_video API endpoints in AVideo return full video playback sources (direct MP4 URLs, HLS manifests) for password-protected videos without verifying the video password. While the normal web playback flow enforces password checks via the CustomizeUser::getModeYouTube() hook, this enforcement is completely absent from the API code path. An unauthenticated attacker can retrieve direct playback URLs for any password-protected video by calling the API directly.
Details
The video password protection is enforced in the web UI via CustomizeUser::getModeYouTube() (plugin/CustomizeUser/CustomizeUser.php:787), which calls videoPasswordIsGood() before rendering the video player. However, this hook is only invoked during web page rendering — the API endpoints bypass it entirely.
Vulnerable endpoint 1 — get_api_video_file (plugin/API/API.php:986-1004):
public function get_api_video_file($parameters)
{
global $global;
$obj = $this->startResponseObject($parameters);
$obj->videos_id = $parameters['videos_id'];
if (!self::isAPISecretValid()) {
if (!User::canWatchVideoWithAds($obj->videos_id)) {
return new ApiObject("You cannot watch this video");
}
}
$video = new Video('', '', $obj->videos_id);
$obj->filename = $video->getFilename();
// ...
$obj->video_file = Video::getHigherVideoPathFromID($obj->videos_id);
$obj->sources = getSources($obj->filename, true);
return new ApiObject("", false, $obj);
}
The only access check is User::canWatchVideoWithAds() (objects/user.php:1102-1159), which checks admin status, video active status, owner status, and plugin-level restrictions (subscription/PPV). It does not check video_password. Password-protected videos have status 'a' (active), which passes all checks.
Vulnerable endpoint 2 — get_api_video (plugin/API/API.php:1635-1810):
This endpoint returns video metadata including full videos paths (line 1759) and sources arrays (line 1785) for all videos in query results, with no password verification anywhere in the function.
The intended password check exists but is never called from these endpoints:
Video::verifyVideoPassword() (objects/video.php:543-553) is the proper password verification function, and get_api_video_password_is_correct exists as a separate API endpoint — proving password verification was intended as an access control. But neither get_api_video_file nor get_api_video invoke any password check.
PoC
# Step 1: Identify a password-protected video via the video list API
curl -s 'https://target.com/plugin/API/get.json.php?APIName=video&rowCount=50' | \
python3 -c "
import json, sys
data = json.load(sys.stdin)
for v in data.get('response',{}).get('rows',[]):
if v.get('video_password'):
print(f'ID: {v[\"id\"]}, Title: {v[\"title\"]}, Password Protected: YES')
print(f' Direct sources: {json.dumps(v.get(\"sources\",[])[0] if v.get(\"sources\") else \"none\")}')"
# Step 2: Retrieve full playback sources for the password-protected video
curl -s 'https://target.com/plugin/API/get.json.php?APIName=video_file&videos_id=<PROTECTED_VIDEO_ID>'
# Expected: access denied or password prompt
# Actual: full response with direct MP4/HLS URLs:
# {"error":false,"response":{"videos_id":"123","filename":"video_abc",
# "video_file":"https://target.com/videos/video_abc/video_abc_HD.mp4",
# "sources":[{"src":"https://target.com/videos/video_abc/video_abc_HD.mp4","type":"video/mp4"}]}}
# Step 3: Download the protected video directly
curl -O 'https://target.com/videos/video_abc/video_abc_HD.mp4'
Impact
Any unauthenticated user can retrieve direct playable video URLs for all password-protected videos, completely bypassing the password requirement. The get_api_video endpoint additionally exposes which videos are password-protected (via the video_password field set to '1'), allowing targeted enumeration. This renders the video_password feature ineffective for any content accessible through the API, which includes mobile apps, third-party integrations, and direct API consumers.
Recommended Fix
Add password verification to both API endpoints before returning video sources. In plugin/API/API.php:
public function get_api_video_file($parameters)
{
global $global;
$obj = $this->startResponseObject($parameters);
$obj->videos_id = $parameters['videos_id'];
if (!self::isAPISecretValid()) {
if (!User::canWatchVideoWithAds($obj->videos_id)) {
return new ApiObject("You cannot watch this video");
}
// Check video password protection
$video = new Video('', '', $obj->videos_id);
$storedPassword = $video->getVideo_password();
if (!empty($storedPassword)) {
$providedPassword = @$parameters['video_password'];
if (empty($providedPassword) || !Video::verifyVideoPassword($providedPassword, $storedPassword)) {
return new ApiObject("Video password required", true);
}
}
}
// ... rest of function
}
Apply the same check in get_api_video() before populating the videos and sources fields (around line 1759), replacing source data with an empty object when the password is not provided or incorrect. Also fix get_api_video_password_is_correct to use Video::verifyVideoPassword() instead of direct == comparison (line 1126), which currently fails for bcrypt hashes.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "wwbn/avideo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "26.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34369"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-30T18:03:26Z",
"nvd_published_at": "2026-03-27T19:16:42Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe `get_api_video_file` and `get_api_video` API endpoints in AVideo return full video playback sources (direct MP4 URLs, HLS manifests) for password-protected videos without verifying the video password. While the normal web playback flow enforces password checks via the `CustomizeUser::getModeYouTube()` hook, this enforcement is completely absent from the API code path. An unauthenticated attacker can retrieve direct playback URLs for any password-protected video by calling the API directly.\n\n## Details\n\nThe video password protection is enforced in the web UI via `CustomizeUser::getModeYouTube()` (`plugin/CustomizeUser/CustomizeUser.php:787`), which calls `videoPasswordIsGood()` before rendering the video player. However, this hook is only invoked during web page rendering \u2014 the API endpoints bypass it entirely.\n\n**Vulnerable endpoint 1 \u2014 `get_api_video_file` (`plugin/API/API.php:986-1004`):**\n\n```php\npublic function get_api_video_file($parameters)\n{\n global $global;\n $obj = $this-\u003estartResponseObject($parameters);\n $obj-\u003evideos_id = $parameters[\u0027videos_id\u0027];\n if (!self::isAPISecretValid()) {\n if (!User::canWatchVideoWithAds($obj-\u003evideos_id)) {\n return new ApiObject(\"You cannot watch this video\");\n }\n }\n $video = new Video(\u0027\u0027, \u0027\u0027, $obj-\u003evideos_id);\n $obj-\u003efilename = $video-\u003egetFilename();\n // ...\n $obj-\u003evideo_file = Video::getHigherVideoPathFromID($obj-\u003evideos_id);\n $obj-\u003esources = getSources($obj-\u003efilename, true);\n return new ApiObject(\"\", false, $obj);\n}\n```\n\nThe only access check is `User::canWatchVideoWithAds()` (`objects/user.php:1102-1159`), which checks admin status, video active status, owner status, and plugin-level restrictions (subscription/PPV). It does **not** check `video_password`. Password-protected videos have status `\u0027a\u0027` (active), which passes all checks.\n\n**Vulnerable endpoint 2 \u2014 `get_api_video` (`plugin/API/API.php:1635-1810`):**\n\nThis endpoint returns video metadata including full `videos` paths (line 1759) and `sources` arrays (line 1785) for all videos in query results, with no password verification anywhere in the function.\n\n**The intended password check exists but is never called from these endpoints:**\n\n`Video::verifyVideoPassword()` (`objects/video.php:543-553`) is the proper password verification function, and `get_api_video_password_is_correct` exists as a separate API endpoint \u2014 proving password verification was intended as an access control. But neither `get_api_video_file` nor `get_api_video` invoke any password check.\n\n## PoC\n\n```bash\n# Step 1: Identify a password-protected video via the video list API\ncurl -s \u0027https://target.com/plugin/API/get.json.php?APIName=video\u0026rowCount=50\u0027 | \\\n python3 -c \"\nimport json, sys\ndata = json.load(sys.stdin)\nfor v in data.get(\u0027response\u0027,{}).get(\u0027rows\u0027,[]):\n if v.get(\u0027video_password\u0027):\n print(f\u0027ID: {v[\\\"id\\\"]}, Title: {v[\\\"title\\\"]}, Password Protected: YES\u0027)\n print(f\u0027 Direct sources: {json.dumps(v.get(\\\"sources\\\",[])[0] if v.get(\\\"sources\\\") else \\\"none\\\")}\u0027)\"\n\n# Step 2: Retrieve full playback sources for the password-protected video\ncurl -s \u0027https://target.com/plugin/API/get.json.php?APIName=video_file\u0026videos_id=\u003cPROTECTED_VIDEO_ID\u003e\u0027\n\n# Expected: access denied or password prompt\n# Actual: full response with direct MP4/HLS URLs:\n# {\"error\":false,\"response\":{\"videos_id\":\"123\",\"filename\":\"video_abc\",\n# \"video_file\":\"https://target.com/videos/video_abc/video_abc_HD.mp4\",\n# \"sources\":[{\"src\":\"https://target.com/videos/video_abc/video_abc_HD.mp4\",\"type\":\"video/mp4\"}]}}\n\n# Step 3: Download the protected video directly\ncurl -O \u0027https://target.com/videos/video_abc/video_abc_HD.mp4\u0027\n```\n\n## Impact\n\nAny unauthenticated user can retrieve direct playable video URLs for all password-protected videos, completely bypassing the password requirement. The `get_api_video` endpoint additionally exposes which videos are password-protected (via the `video_password` field set to `\u00271\u0027`), allowing targeted enumeration. This renders the `video_password` feature ineffective for any content accessible through the API, which includes mobile apps, third-party integrations, and direct API consumers.\n\n## Recommended Fix\n\nAdd password verification to both API endpoints before returning video sources. In `plugin/API/API.php`:\n\n```php\npublic function get_api_video_file($parameters)\n{\n global $global;\n $obj = $this-\u003estartResponseObject($parameters);\n $obj-\u003evideos_id = $parameters[\u0027videos_id\u0027];\n if (!self::isAPISecretValid()) {\n if (!User::canWatchVideoWithAds($obj-\u003evideos_id)) {\n return new ApiObject(\"You cannot watch this video\");\n }\n // Check video password protection\n $video = new Video(\u0027\u0027, \u0027\u0027, $obj-\u003evideos_id);\n $storedPassword = $video-\u003egetVideo_password();\n if (!empty($storedPassword)) {\n $providedPassword = @$parameters[\u0027video_password\u0027];\n if (empty($providedPassword) || !Video::verifyVideoPassword($providedPassword, $storedPassword)) {\n return new ApiObject(\"Video password required\", true);\n }\n }\n }\n // ... rest of function\n}\n```\n\nApply the same check in `get_api_video()` before populating the `videos` and `sources` fields (around line 1759), replacing source data with an empty object when the password is not provided or incorrect. Also fix `get_api_video_password_is_correct` to use `Video::verifyVideoPassword()` instead of direct `==` comparison (line 1126), which currently fails for bcrypt hashes.",
"id": "GHSA-q6jj-r49p-94fh",
"modified": "2026-03-30T18:03:26Z",
"published": "2026-03-30T18:03:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-q6jj-r49p-94fh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34369"
},
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/commit/be344206f2f461c034ad2f1c5d8212dd8a52b8c7"
},
{
"type": "PACKAGE",
"url": "https://github.com/WWBN/AVideo"
}
],
"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": "AVideo has Video Password Protection Bypass via API Endpoints Returning Full Playback Sources Without Password Verification"
}
GHSA-Q6JP-GCWW-8V2J
Vulnerability from github – Published: 2022-11-21 23:46 – Updated: 2022-11-28 15:50Impact
The application allow anyone with view access to modify any page of the wiki by importing a crafted XAR package.
Patches
The problem has been patched in XWiki 14.6RC1, 14.6 and 13.10.8.
Workarounds
The problem can be patched immediately by setting the right of the page Filter.WebHome and making sure only main wiki administrators can VIEW it the application is installed on main wiki or edit the page and apply the changed described on https://github.com/xwiki/xwiki-platform/commit/fb49b4f289ee28e45cfada8e97e320cd3ed27113.
References
- https://github.com/xwiki/xwiki-platform/commit/fb49b4f289ee28e45cfada8e97e320cd3ed27113
- https://jira.xwiki.org/browse/XWIKI-19758
For more information
If you have any questions or comments about this advisory: * Open an issue in JIRA * Email us at security ML
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-filter-ui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "13.10.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-filter-ui"
},
"ranges": [
{
"events": [
{
"introduced": "14.0.0"
},
{
"fixed": "14.4.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-filter-ui"
},
"ranges": [
{
"events": [
{
"introduced": "14.5.0"
},
{
"fixed": "14.6-rc-1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-41937"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-21T23:46:47Z",
"nvd_published_at": "2022-11-22T01:15:00Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nThe application allow anyone with view access to modify any page of the wiki by importing a crafted XAR package.\n\n### Patches\n\nThe problem has been patched in XWiki 14.6RC1, 14.6 and 13.10.8.\n\n### Workarounds\n\nThe problem can be patched immediately by setting the right of the page Filter.WebHome and making sure only main wiki administrators can VIEW it the application is installed on main wiki or edit the page and apply the changed described on https://github.com/xwiki/xwiki-platform/commit/fb49b4f289ee28e45cfada8e97e320cd3ed27113.\n\n### References\n\n* https://github.com/xwiki/xwiki-platform/commit/fb49b4f289ee28e45cfada8e97e320cd3ed27113\n* https://jira.xwiki.org/browse/XWIKI-19758\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [JIRA](https://jira.xwiki.org)\n* Email us at [security ML](mailto:security@xwiki.org)",
"id": "GHSA-q6jp-gcww-8v2j",
"modified": "2022-11-28T15:50:11Z",
"published": "2022-11-21T23:46:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-q6jp-gcww-8v2j"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41937"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/fb49b4f289ee28e45cfada8e97e320cd3ed27113"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-19758"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Missing Authorization in Filter Stream Converter Application of XWiki-platform"
}
GHSA-Q6M9-JQWC-4RWW
Vulnerability from github – Published: 2026-03-13 21:31 – Updated: 2026-03-16 15:30Missing Authorization vulnerability in Ays Pro Easy Form easy-form allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Easy Form: from n/a through <= 2.7.9.
{
"affected": [],
"aliases": [
"CVE-2026-32332"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-13T19:54:43Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Ays Pro Easy Form easy-form allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Easy Form: from n/a through \u003c= 2.7.9.",
"id": "GHSA-q6m9-jqwc-4rww",
"modified": "2026-03-16T15:30:34Z",
"published": "2026-03-13T21:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32332"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/easy-form/vulnerability/wordpress-easy-form-plugin-2-7-9-broken-access-control-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:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q6MF-Q7M8-GW96
Vulnerability from github – Published: 2024-11-01 15:32 – Updated: 2026-04-01 18:32Missing Authorization vulnerability in WP Quads Ads by WPQuads – Adsense Ads, Banner Ads, Popup Ads allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Ads by WPQuads – Adsense Ads, Banner Ads, Popup Ads: from n/a through 2.0.84.
{
"affected": [],
"aliases": [
"CVE-2024-47317"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-01T15:15:54Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in WP Quads Ads by WPQuads \u2013 Adsense Ads, Banner Ads, Popup Ads allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Ads by WPQuads \u2013 Adsense Ads, Banner Ads, Popup Ads: from n/a through 2.0.84.",
"id": "GHSA-q6mf-q7m8-gw96",
"modified": "2026-04-01T18:32:16Z",
"published": "2024-11-01T15:32:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47317"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/quick-adsense-reloaded/vulnerability/wordpress-ads-by-wpquads-plugin-2-0-84-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/quick-adsense-reloaded/wordpress-ads-by-wpquads-plugin-2-0-84-broken-access-control-vulnerability?_s_id=cve"
}
],
"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"
}
]
}
GHSA-Q6MX-HM3F-H864
Vulnerability from github – Published: 2024-06-12 09:30 – Updated: 2024-06-12 09:30Missing Authorization vulnerability in Metagauss ProfileGrid.This issue affects ProfileGrid: from n/a through 5.6.6.
{
"affected": [],
"aliases": [
"CVE-2023-52117"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-12T09:15:15Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Metagauss ProfileGrid.This issue affects ProfileGrid: from n/a through 5.6.6.",
"id": "GHSA-q6mx-hm3f-h864",
"modified": "2024-06-12T09:30:48Z",
"published": "2024-06-12T09:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52117"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/profilegrid-user-profiles-groups-and-communities/wordpress-profilegrid-plugin-5-6-6-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-Q6P4-2Q7C-4VW7
Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2022-05-24 19:07Improper authorization in handler for custom URL scheme vulnerability in GU App for Android versions from 4.8.0 to 5.0.2 allows a remote attacker to lead a user to access an arbitrary website via the vulnerable App.
{
"affected": [],
"aliases": [
"CVE-2021-20777"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-07T08:15:00Z",
"severity": "MODERATE"
},
"details": "Improper authorization in handler for custom URL scheme vulnerability in GU App for Android versions from 4.8.0 to 5.0.2 allows a remote attacker to lead a user to access an arbitrary website via the vulnerable App.",
"id": "GHSA-q6p4-2q7c-4vw7",
"modified": "2022-05-24T19:07:09Z",
"published": "2022-05-24T19:07:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20777"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN25850723/index.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q6RQ-4WHR-R879
Vulnerability from github – Published: 2022-05-24 17:33 – Updated: 2023-10-27 13:02Jenkins Active Directory Plugin 2.19 and earlier does not perform a permission check in an HTTP endpoint.
This allows attackers with Overall/Read permission to access the domain health check diagnostic page.
Jenkins Active Directory Plugin 2.20 requires Overall/Administer permission to access the domain health check diagnostic page.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:active-directory"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-2302"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-21T19:25:23Z",
"nvd_published_at": "2020-11-04T15:15:00Z",
"severity": "MODERATE"
},
"details": "Jenkins Active Directory Plugin 2.19 and earlier does not perform a permission check in an HTTP endpoint.\n\nThis allows attackers with Overall/Read permission to access the domain health check diagnostic page.\n\nJenkins Active Directory Plugin 2.20 requires Overall/Administer permission to access the domain health check diagnostic page.",
"id": "GHSA-q6rq-4whr-r879",
"modified": "2023-10-27T13:02:50Z",
"published": "2022-05-24T17:33:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2302"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/active-directory-plugin/commit/e6b5f2bf2f441bd679d35db1bd6f9576b148e3cb"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/active-directory-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2020-11-04/#SECURITY-1999"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Missing permission check in Jenkins Active Directory Plugin allows accessing domain health check page"
}
GHSA-Q6VG-73MW-85MW
Vulnerability from github – Published: 2023-09-30 15:30 – Updated: 2023-09-30 15:30Missing Authorization in GitHub repository hamza417/inure prior to build94.
{
"affected": [],
"aliases": [
"CVE-2023-5321"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-30T14:15:15Z",
"severity": "MODERATE"
},
"details": "Missing Authorization in GitHub repository hamza417/inure prior to build94.",
"id": "GHSA-q6vg-73mw-85mw",
"modified": "2023-09-30T15:30:18Z",
"published": "2023-09-30T15:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5321"
},
{
"type": "WEB",
"url": "https://github.com/hamza417/inure/commit/57fda918bfd2fb863f579841a46363fe8e10c29b"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/b1becc68-e738-458f-bd99-06ee77580d3a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
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.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.