Webkul Bagisto EUVD-2026-79300

Exploitation requires an existing authenticated Bagisto backend/admin-panel account that holds at least the settings.users.edit permission (PR:L); it is not anonymously exploitable. The attacker must reach the admin.settings.users.update endpoint and submit a user-update request setting role_id to the Administrator role. No user interaction, MFA prompt, or non-default configuration is needed - the flaw is present in the default UserController::update() logic of Bagisto 2.4.9, which omits three authorization checks (grant-permission validation, self-role-change prevention, and subset-of-actor-permissions restriction). The main limiting factor is the requirement to first possess a low-privileged backend credential.

The CVSS vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 8.8 High) is internally consistent with the description: a network-reachable admin-panel endpoint, low attacker privilege (a backend account holding only settings.users.edit), no user interaction, and full compromise of confidentiality, integrity, and availability once the actor self-promotes to Administrator. I broadly AGREE with the 8.8; the only defensible downgrade argument is that this is post-authentication (PR:L) against a backend panel rather than a truly anonymous internet-facing flaw, which meaningfully narrows the attacker population. Real-world urgency signals are LOW: EPSS is 0.15% (5th percentile), the CVE is NOT in CISA KEV, and there is no SSVC decision record in the input. The primary NVD reference is a researcher's GitHub writeup (isukasanuj/bagisto-cve) which very likely contains reproduction steps, but the input provides no explicit POC=YES flag, so weaponized exploit code cannot be confirmed. Net: a genuinely high-impact privilege-escalation bug, but one gated behind an existing low-privileged backend account, so it is a strong internal/insider-threat and post-foothold escalation concern rather than a mass-exploitation emergency.

A low-privileged Bagisto backend operator (or an attacker who has phished/compromised such an account) who holds only the settings.users.edit permission sends a crafted POST to the admin.settings.users.update route setting role_id to the Administrator role on their own account. Because UserController::update() never checks that the actor may grant that role, forbids self-role-changes, or limits assignment to a subset of the actor's own permissions, the account instantly gains full admin capabilities. A public technical writeup exists on GitHub and likely documents the exact request, though no weaponized exploit or active exploitation is confirmed.