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.
14539 vulnerabilities reference this CWE, most recent first.
GHSA-XV4R-4885-GWPG
Vulnerability from github – Published: 2026-07-14 00:09 – Updated: 2026-07-14 00:09Summary
Kimai contains an authenticated improper authorization vulnerability in Team-related assignment APIs. A Teamlead who can edit their own team can use backend API endpoints to add users or activities that fall outside their intended visible or manageable scope, even when the frontend correctly hides those targets.
This affects both team member assignment and team activity assignment. The issue is caused by treating "may edit this team" as equivalent to "may attach any referenced object to this team", without performing a second authorization check on the target user or activity.
Details
The issue affects at least the following API routes:
POST /api/teams/{id}/members/{userId}POST /api/teams/{id}/activities/{activityId}
In both cases, the backend checks whether the caller may edit the Team, but it does not verify whether the referenced User or Activity falls inside the caller's allowed management scope.
For team member assignment, the frontend form correctly limits the visible user choices. In src/Form/TeamEditForm.php, the team edit form uses UserType:
$builder->add('users', UserType::class, [
'label' => 'add_user.label',
'help' => 'team.add_user.help',
'mapped' => false,
'multiple' => false,
'expanded' => false,
'required' => false,
'ignore_users' => $team !== null ? $team->getUsers() : []
]);
In src/Form/Type/UserType.php, the user selector is built from UserRepository::getQueryBuilderForFormType():
$query = new UserFormTypeQuery();
$query->setUser($options['user']);
$qb = $this->userRepository->getQueryBuilderForFormType($query);
$users = $qb->getQuery()->getResult();
And in src/Repository/UserRepository.php, Teamlead-visible candidates are limited to team members from teams they lead:
if (null !== $user && $user->isTeamlead()) {
$userIds = [];
foreach ($user->getTeams() as $team) {
if ($team->isTeamlead($user)) {
foreach ($team->getUsers() as $teamMember) {
$userIds[] = $teamMember->getId();
}
}
}
$userIds = array_unique($userIds);
$qb->setParameter('teamMember', $userIds);
$or->add($qb->expr()->in('u.id', ':teamMember'));
}
However, the actual member-assignment API does not reuse that restriction. In src/API/TeamController.php:
#[IsGranted('edit', 'team')]
#[Route(methods: ['POST'], path: '/{id}/members/{userId}', name: 'post_team_member', requirements: ['id' => '\d+', 'userId' => '\d+'])]
public function postMemberAction(Team $team, #[MapEntity(mapping: ['userId' => 'id'])] User $member): Response
{
if ($member->isInTeam($team)) {
throw new BadRequestHttpException('User is already member of the team');
}
$team->addUser($member);
$this->teamService->saveTeam($team);
}
For activity assignment, the same pattern appears. In src/API/TeamController.php:
#[IsGranted('edit', 'team')]
#[Route(methods: ['POST'], path: '/{id}/activities/{activityId}', name: 'post_team_activity', requirements: ['id' => '\d+', 'activityId' => '\d+'])]
public function postActivityAction(Team $team, #[MapEntity(mapping: ['activityId' => 'id'])] Activity $activity, ActivityRepository $activityRepository): Response
{
if ($team->hasActivity($activity)) {
throw new BadRequestHttpException('Team has already access to activity');
}
$team->addActivity($activity);
$activityRepository->saveActivity($activity);
}
The Team voter only checks whether the current user may edit that team, not whether the referenced object is within the Teamlead's legitimate scope. In src/Voter/TeamVoter.php:
if (!$user->isAdmin() && !$user->isSuperAdmin() && !$user->isTeamleadOf($subject)) {
return false;
}
return $this->permissionManager->hasRolePermission($user, $attribute . '_team');
For activities, this is especially risky because later authorization logic may trust the team assignment that was just written. In src/Security/RolePermissionManager.php:
public function checkTeamAccessActivity(Activity $activity, User $user): bool
{
if ($activity->getProject() !== null && !$this->checkTeamAccessProject($activity->getProject(), $user)) {
return false;
}
return $this->checkTeamAccess($activity->getTeams(), $user);
}
So once a Teamlead is able to write a new team/activity relation, later access-control decisions may treat that relation as legitimate input.
A PoC was provided, but removed for security reasons.
Impact
This vulnerability allows a Teamlead to use their own editable team as an expansion container for objects that should remain outside their authorized scope. In the validated member-assignment case, the attacker can forcibly add users who are not supposed to be manageable through that Teamlead's visible range. In the activity-assignment case, the attacker can attach activities that are outside the intended authorization boundary of the team.
Once such relations are written, downstream authorization, visibility, and business workflows may start treating them as legitimate. This can affect user scoping, team-based access control, customer/project/activity visibility, time-entry behavior, statistics, and reporting. The issue therefore breaks the trustworthiness of Team as a security isolation container.
Solution
Several new permission checks were added to src/API/TeamController.php -
- Check if user can be accessed with #[IsGranted('access_user', 'member')] before adding as new team member
- Check if customer can be seen with #[IsGranted('view', 'customer')] before a team is granted access to a customer
- Check if project can be seen with #[IsGranted('view', 'project')] before a team is granted access to a project
- Check if activity can be seen with #[IsGranted('view', 'activity')] before a team is granted access to an activity
See https://www.kimai.org/en/security/ghsa-xv4r-4885-gwpg for more information.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.57.0"
},
"package": {
"ecosystem": "Packagist",
"name": "kimai/kimai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.58.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-52825"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-14T00:09:03Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nKimai contains an authenticated improper authorization vulnerability in Team-related assignment APIs. A Teamlead who can edit their own team can use backend API endpoints to add users or activities that fall outside their intended visible or manageable scope, even when the frontend correctly hides those targets.\n\nThis affects both team member assignment and team activity assignment. The issue is caused by treating \"may edit this team\" as equivalent to \"may attach any referenced object to this team\", without performing a second authorization check on the target user or activity.\n\n### Details\n\nThe issue affects at least the following API routes:\n\n- `POST /api/teams/{id}/members/{userId}`\n- `POST /api/teams/{id}/activities/{activityId}`\n\nIn both cases, the backend checks whether the caller may edit the `Team`, but it does not verify whether the referenced `User` or `Activity` falls inside the caller\u0027s allowed management scope.\n\nFor team member assignment, the frontend form correctly limits the visible user choices. In `src/Form/TeamEditForm.php`, the team edit form uses `UserType`:\n\n```php\n$builder-\u003eadd(\u0027users\u0027, UserType::class, [\n \u0027label\u0027 =\u003e \u0027add_user.label\u0027,\n \u0027help\u0027 =\u003e \u0027team.add_user.help\u0027,\n \u0027mapped\u0027 =\u003e false,\n \u0027multiple\u0027 =\u003e false,\n \u0027expanded\u0027 =\u003e false,\n \u0027required\u0027 =\u003e false,\n \u0027ignore_users\u0027 =\u003e $team !== null ? $team-\u003egetUsers() : []\n]);\n```\n\nIn `src/Form/Type/UserType.php`, the user selector is built from `UserRepository::getQueryBuilderForFormType()`:\n\n```php\n$query = new UserFormTypeQuery();\n$query-\u003esetUser($options[\u0027user\u0027]);\n\n$qb = $this-\u003euserRepository-\u003egetQueryBuilderForFormType($query);\n$users = $qb-\u003egetQuery()-\u003egetResult();\n```\n\nAnd in `src/Repository/UserRepository.php`, Teamlead-visible candidates are limited to team members from teams they lead:\n\n```php\nif (null !== $user \u0026\u0026 $user-\u003eisTeamlead()) {\n $userIds = [];\n foreach ($user-\u003egetTeams() as $team) {\n if ($team-\u003eisTeamlead($user)) {\n foreach ($team-\u003egetUsers() as $teamMember) {\n $userIds[] = $teamMember-\u003egetId();\n }\n }\n }\n $userIds = array_unique($userIds);\n $qb-\u003esetParameter(\u0027teamMember\u0027, $userIds);\n $or-\u003eadd($qb-\u003eexpr()-\u003ein(\u0027u.id\u0027, \u0027:teamMember\u0027));\n}\n```\n\nHowever, the actual member-assignment API does not reuse that restriction. In `src/API/TeamController.php`:\n\n```php\n#[IsGranted(\u0027edit\u0027, \u0027team\u0027)]\n#[Route(methods: [\u0027POST\u0027], path: \u0027/{id}/members/{userId}\u0027, name: \u0027post_team_member\u0027, requirements: [\u0027id\u0027 =\u003e \u0027\\d+\u0027, \u0027userId\u0027 =\u003e \u0027\\d+\u0027])]\npublic function postMemberAction(Team $team, #[MapEntity(mapping: [\u0027userId\u0027 =\u003e \u0027id\u0027])] User $member): Response\n{\n if ($member-\u003eisInTeam($team)) {\n throw new BadRequestHttpException(\u0027User is already member of the team\u0027);\n }\n\n $team-\u003eaddUser($member);\n $this-\u003eteamService-\u003esaveTeam($team);\n}\n```\n\nFor activity assignment, the same pattern appears. In `src/API/TeamController.php`:\n\n```php\n#[IsGranted(\u0027edit\u0027, \u0027team\u0027)]\n#[Route(methods: [\u0027POST\u0027], path: \u0027/{id}/activities/{activityId}\u0027, name: \u0027post_team_activity\u0027, requirements: [\u0027id\u0027 =\u003e \u0027\\d+\u0027, \u0027activityId\u0027 =\u003e \u0027\\d+\u0027])]\npublic function postActivityAction(Team $team, #[MapEntity(mapping: [\u0027activityId\u0027 =\u003e \u0027id\u0027])] Activity $activity, ActivityRepository $activityRepository): Response\n{\n if ($team-\u003ehasActivity($activity)) {\n throw new BadRequestHttpException(\u0027Team has already access to activity\u0027);\n }\n\n $team-\u003eaddActivity($activity);\n $activityRepository-\u003esaveActivity($activity);\n}\n```\n\nThe `Team` voter only checks whether the current user may edit that team, not whether the referenced object is within the Teamlead\u0027s legitimate scope. In `src/Voter/TeamVoter.php`:\n\n```php\nif (!$user-\u003eisAdmin() \u0026\u0026 !$user-\u003eisSuperAdmin() \u0026\u0026 !$user-\u003eisTeamleadOf($subject)) {\n return false;\n}\n\nreturn $this-\u003epermissionManager-\u003ehasRolePermission($user, $attribute . \u0027_team\u0027);\n```\n\nFor activities, this is especially risky because later authorization logic may trust the team assignment that was just written. In `src/Security/RolePermissionManager.php`:\n\n```php\npublic function checkTeamAccessActivity(Activity $activity, User $user): bool\n{\n if ($activity-\u003egetProject() !== null \u0026\u0026 !$this-\u003echeckTeamAccessProject($activity-\u003egetProject(), $user)) {\n return false;\n }\n\n return $this-\u003echeckTeamAccess($activity-\u003egetTeams(), $user);\n}\n```\n\nSo once a Teamlead is able to write a new team/activity relation, later access-control decisions may treat that relation as legitimate input.\n\n*A PoC was provided, but removed for security reasons.*\n\n### Impact\n\nThis vulnerability allows a Teamlead to use their own editable team as an expansion container for objects that should remain outside their authorized scope. In the validated member-assignment case, the attacker can forcibly add users who are not supposed to be manageable through that Teamlead\u0027s visible range. In the activity-assignment case, the attacker can attach activities that are outside the intended authorization boundary of the team.\n\nOnce such relations are written, downstream authorization, visibility, and business workflows may start treating them as legitimate. This can affect user scoping, team-based access control, customer/project/activity visibility, time-entry behavior, statistics, and reporting. The issue therefore breaks the trustworthiness of `Team` as a security isolation container.\n\n# Solution\n\nSeveral new permission checks were added to `src/API/TeamController.php` -\n- Check if user can be accessed with `#[IsGranted(\u0027access_user\u0027, \u0027member\u0027)]` before adding as new team member \n- Check if customer can be seen with `#[IsGranted(\u0027view\u0027, \u0027customer\u0027)]` before a team is granted access to a customer\n- Check if project can be seen with `#[IsGranted(\u0027view\u0027, \u0027project\u0027)]` before a team is granted access to a project\n- Check if activity can be seen with `#[IsGranted(\u0027view\u0027, \u0027activity\u0027)]` before a team is granted access to an activity\n\nSee [https://www.kimai.org/en/security/ghsa-xv4r-4885-gwpg](https://www.kimai.org/en/security/ghsa-xv4r-4885-gwpg) for more information.",
"id": "GHSA-xv4r-4885-gwpg",
"modified": "2026-07-14T00:09:03Z",
"published": "2026-07-14T00:09:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kimai/kimai/security/advisories/GHSA-xv4r-4885-gwpg"
},
{
"type": "PACKAGE",
"url": "https://github.com/kimai/kimai"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Kimai has Improper Authorization in Team Member and Team Activity Assignment APIs Which Allows Expansion of Team Scope Beyond Authorized Visibility"
}
GHSA-XV66-85XP-GVQ8
Vulnerability from github – Published: 2025-09-26 06:30 – Updated: 2025-09-26 06:30The ShopEngine Elementor WooCommerce Builder Addon – All in One WooCommerce Solution plugin for WordPress is vulnerable to unauthorized access due to an incorrect capability check on the post_save() function in all versions up to, and including, 4.8.3. This makes it possible for authenticated attackers, with Editor-level access and above, to update the plugin's settings.
{
"affected": [],
"aliases": [
"CVE-2025-10173"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-26T04:15:41Z",
"severity": "LOW"
},
"details": "The ShopEngine Elementor WooCommerce Builder Addon \u2013 All in One WooCommerce Solution plugin for WordPress is vulnerable to unauthorized access due to an incorrect capability check on the post_save() function in all versions up to, and including, 4.8.3. This makes it possible for authenticated attackers, with Editor-level access and above, to update the plugin\u0027s settings.",
"id": "GHSA-xv66-85xp-gvq8",
"modified": "2025-09-26T06:30:49Z",
"published": "2025-09-26T06:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10173"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3365569%40shopengine\u0026new=3365569%40shopengine\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/2d8b816f-815a-4109-b34b-06e806c765e8?source=cve"
}
],
"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-XV69-6RF3-W5G2
Vulnerability from github – Published: 2022-05-24 17:45 – Updated: 2023-10-27 13:56Jenkins Cloud Statistics Plugin 0.26 and earlier does not perform a permission check in an HTTP endpoint.
This allows attackers with Overall/Read permission and knowledge of random activity IDs to view related provisioning exception error messages.
Jenkins Cloud Statistics Plugin 0.27 requires Overall/Administer permission to access provisioning exception error messages.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.26"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:cloud-stats"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.27"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-21631"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-15T17:26:41Z",
"nvd_published_at": "2021-03-30T12:16:00Z",
"severity": "MODERATE"
},
"details": "Jenkins Cloud Statistics Plugin 0.26 and earlier does not perform a permission check in an HTTP endpoint.\n\nThis allows attackers with Overall/Read permission and knowledge of random activity IDs to view related provisioning exception error messages.\n\nJenkins Cloud Statistics Plugin 0.27 requires Overall/Administer permission to access provisioning exception error messages.",
"id": "GHSA-xv69-6rf3-w5g2",
"modified": "2023-10-27T13:56:20Z",
"published": "2022-05-24T17:45:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21631"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/cloud-stats-plugin/commit/07dd3da346a65083a93a071036409f1128e0b133"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/cloud-stats-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2021-03-30/#SECURITY-2246"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/03/30/1"
}
],
"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 Cloud Statistics Plugin"
}
GHSA-XV6F-4Q9W-8Q96
Vulnerability from github – Published: 2024-04-03 15:30 – Updated: 2025-03-17 18:31In the Linux kernel, the following vulnerability has been resolved:
parisc: BTLB: Fix crash when setting up BTLB at CPU bringup
When using hotplug and bringing up a 32-bit CPU, ask the firmware about the BTLB information to set up the static (block) TLB entries.
For that write access to the static btlb_info struct is needed, but since it is marked __ro_after_init the kernel segfaults with missing write permissions.
Fix the crash by dropping the __ro_after_init annotation.
{
"affected": [],
"aliases": [
"CVE-2024-26705"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T15:15:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: BTLB: Fix crash when setting up BTLB at CPU bringup\n\nWhen using hotplug and bringing up a 32-bit CPU, ask the firmware about the\nBTLB information to set up the static (block) TLB entries.\n\nFor that write access to the static btlb_info struct is needed, but\nsince it is marked __ro_after_init the kernel segfaults with missing\nwrite permissions.\n\nFix the crash by dropping the __ro_after_init annotation.",
"id": "GHSA-xv6f-4q9w-8q96",
"modified": "2025-03-17T18:31:38Z",
"published": "2024-04-03T15:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26705"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/54944f45470af5965fb9c28cf962ec30f38a8f5b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/913b9d443a0180cf0de3548f1ab3149378998486"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa52be55276614d33f22fbe7da36c40d6432d10b"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XV7R-59FX-748W
Vulnerability from github – Published: 2025-10-27 03:30 – Updated: 2026-01-20 15:31Missing Authorization vulnerability in KingAddons.com King Addons for Elementor king-addons allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects King Addons for Elementor: from n/a through <= 51.1.37.
{
"affected": [],
"aliases": [
"CVE-2025-62889"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-27T02:15:47Z",
"severity": "HIGH"
},
"details": "Missing Authorization vulnerability in KingAddons.com King Addons for Elementor king-addons allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects King Addons for Elementor: from n/a through \u003c= 51.1.37.",
"id": "GHSA-xv7r-59fx-748w",
"modified": "2026-01-20T15:31:35Z",
"published": "2025-10-27T03:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62889"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/king-addons/vulnerability/wordpress-king-addons-for-elementor-plugin-51-1-37-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/king-addons/vulnerability/wordpress-king-addons-for-elementor-plugin-51-1-37-broken-access-control-vulnerability"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/king-addons/vulnerability/wordpress-king-addons-for-elementor-plugin-51-1-37-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:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XV9G-HFXF-CG8G
Vulnerability from github – Published: 2024-12-09 15:31 – Updated: 2026-04-23 15:33Missing Authorization vulnerability in Themewinter WPCafe allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WPCafe: from n/a through 2.2.22.
{
"affected": [],
"aliases": [
"CVE-2023-47805"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-09T13:15:30Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Themewinter WPCafe allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WPCafe: from n/a through 2.2.22.",
"id": "GHSA-xv9g-hfxf-cg8g",
"modified": "2026-04-23T15:33:35Z",
"published": "2024-12-09T15:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47805"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wp-cafe/vulnerability/wordpress-wpcafe-plugin-2-2-19-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:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XV9X-Q8HF-FRGH
Vulnerability from github – Published: 2024-11-09 06:30 – Updated: 2024-11-09 06:30The Top Store theme for WordPress is vulnerable to unauthorized arbitrary plugin installation due to a missing capability check on the top_store_install_and_activate_callback() function in all versions up to, and including, 1.5.4. This makes it possible for authenticated attackers, with subscriber-level access and above, to install arbitrary plugins which can contain other exploitable vulnerabilities to elevate privileges and gain remote code execution.
{
"affected": [],
"aliases": [
"CVE-2024-10673"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-09T04:15:04Z",
"severity": "HIGH"
},
"details": "The Top Store theme for WordPress is vulnerable to unauthorized arbitrary plugin installation due to a missing capability check on the top_store_install_and_activate_callback() function in all versions up to, and including, 1.5.4. This makes it possible for authenticated attackers, with subscriber-level access and above, to install arbitrary plugins which can contain other exploitable vulnerabilities to elevate privileges and gain remote code execution.",
"id": "GHSA-xv9x-q8hf-frgh",
"modified": "2024-11-09T06:30:24Z",
"published": "2024-11-09T06:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10673"
},
{
"type": "WEB",
"url": "https://themes.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=247826%40top-store\u0026new=247826%40top-store\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/80510ade-cb58-45b3-89f2-2cbbc5640cae?source=cve"
}
],
"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-XVFH-9HMQ-G2VH
Vulnerability from github – Published: 2025-06-06 15:30 – Updated: 2026-04-01 18:35Missing Authorization vulnerability in De paragon No Spam At All allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects No Spam At All: from n/a through 1.3.
{
"affected": [],
"aliases": [
"CVE-2025-24778"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-06T13:15:26Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in De paragon No Spam At All allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects No Spam At All: from n/a through 1.3.",
"id": "GHSA-xvfh-9hmq-g2vh",
"modified": "2026-04-01T18:35:17Z",
"published": "2025-06-06T15:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24778"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/no-spam-at-all/vulnerability/wordpress-no-spam-at-all-1-3-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:L",
"type": "CVSS_V3"
}
]
}
GHSA-XVG6-W59C-3823
Vulnerability from github – Published: 2024-06-09 12:30 – Updated: 2024-06-09 12:30Missing Authorization vulnerability in OnTheGoSystems WooCommerce Multilingual & Multicurrency.This issue affects WooCommerce Multilingual & Multicurrency: from n/a through 5.3.4.
{
"affected": [],
"aliases": [
"CVE-2024-30466"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-09T11:15:50Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in OnTheGoSystems WooCommerce Multilingual \u0026 Multicurrency.This issue affects WooCommerce Multilingual \u0026 Multicurrency: from n/a through 5.3.4.",
"id": "GHSA-xvg6-w59c-3823",
"modified": "2024-06-09T12:30:51Z",
"published": "2024-06-09T12:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30466"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/woocommerce-multilingual/wordpress-woocommerce-multilingual-multicurrency-plugin-5-3-4-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:L",
"type": "CVSS_V3"
}
]
}
GHSA-XVMJ-4X57-G9GG
Vulnerability from github – Published: 2025-10-22 15:31 – Updated: 2026-01-20 15:31Missing Authorization vulnerability in etruel WPeMatico RSS Feed Fetcher wpematico allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WPeMatico RSS Feed Fetcher: from n/a through <= 2.8.3.
{
"affected": [],
"aliases": [
"CVE-2025-49922"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-22T15:15:38Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in etruel WPeMatico RSS Feed Fetcher wpematico allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WPeMatico RSS Feed Fetcher: from n/a through \u003c= 2.8.3.",
"id": "GHSA-xvmj-4x57-g9gg",
"modified": "2026-01-20T15:31:23Z",
"published": "2025-10-22T15:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49922"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/wpematico/vulnerability/wordpress-wpematico-rss-feed-fetcher-plugin-2-8-3-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/wpematico/vulnerability/wordpress-wpematico-rss-feed-fetcher-plugin-2-8-3-broken-access-control-vulnerability"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/wpematico/vulnerability/wordpress-wpematico-rss-feed-fetcher-plugin-2-8-3-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"
}
]
}
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.