Is there a public PoC exploit available for EUVD-2026-36423?

Yes, a public proof-of-concept exploit is available for EUVD-2026-36423. Prioritise patching immediately. EPSS: 0.0%.

PbootCMS EUVD-2026-36423

Q: What is the CVSS score of EUVD-2026-36423?

EUVD-2026-36423 has a CVSS 4.0 base score of 5.5 (Medium). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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. EPSS exploitation probability: 0.0%.

| CVE-2026-12066 MEDIUM

Weak Password Recovery Mechanism for Forgotten Password (CWE-640)

2026-06-12 VulDB

GHSA-4rj6-94pr-r3h5

PHP Information Disclosure Pbootcms N A

5.5

CVSS 4.0 · Vendor: VulDB

Severity by source

Vendor (VulDB) PRIMARY

5.5 MEDIUM

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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

vuln.today AI

8.2 HIGH

Unauthenticated network-accessible recovery endpoint; account takeover yields high integrity impact; limited info disclosure during checkcode probing warrants C:L.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (VulDB).

CVSS VectorVendor: VulDB

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

Jun 12, 2026 - 14:23 vuln.today

CVSS changed

Jun 12, 2026 - 14:22 NVD

6.9 (MEDIUM) 5.5 (MEDIUM)

DescriptionCVE.org

A security flaw has been discovered in PbootCMS up to 3.2.12. This vulnerability affects the function retrieve of the file apps/home/controller/MemberController.php of the component Password Handler. The manipulation of the argument username/password/email/checkcode results in weak password recovery. It is possible to launch the attack remotely. The exploit has been released to the public and may be used for attacks.

AnalysisAI

Weak password recovery in PbootCMS up to 3.2.12 allows remote unauthenticated attackers to take over user accounts by manipulating the checkcode, username, password, and email parameters in the retrieve function of apps/home/controller/MemberController.php. The recovery mechanism fails to adequately validate or protect the verification token, enabling bypass of the intended authentication challenge during the password reset flow. A public proof-of-concept exploit explicitly titled 'Account-Takeover' is available on GitHub, elevating the realistic risk beyond the conservative base score of 6.9.

Technical ContextAI

PbootCMS is a PHP-based content management system. The vulnerable component is the retrieve function inside apps/home/controller/MemberController.php, which is responsible for handling forgotten-password recovery requests. CWE-640 (Weak Password Recovery Mechanism for Forgotten Password) identifies the root cause class: the recovery flow does not sufficiently secure the checkcode verification token - a flaw that typically manifests as a short or predictable code, absence of rate limiting, or improper server-side validation of the submitted token alongside user-supplied username, email, and password parameters. The CPE cpe:2.3:a:n/a:pbootcms:*:*:*:*:*:*:*:* covers all PbootCMS versions up to 3.2.12. The CVSS 4.0 vector AV:N/AC:L/AT:N/PR:N/UI:N confirms the flaw is network-reachable, requires no special attack conditions, and demands no privileges or user interaction.

RemediationAI

No vendor-released patch with a confirmed fixed version number has been identified at time of analysis. Organizations should monitor https://github.com/pbootcmspro/PbootCMS/issues/38 and the VulDB advisory at https://vuldb.com/vuln/370561 for a patched release and apply it immediately upon availability. As compensating controls: disable the public-facing password recovery endpoint entirely if member self-service password reset is not operationally required - this eliminates the attack surface but prevents legitimate users from self-service resets, requiring administrator intervention. If the feature must remain enabled, implement per-IP and per-account rate limiting on the /retrieve endpoint to prevent brute-force enumeration of verification codes; absence of rate limiting is the likely core enabler. Replace short numeric checkcodes with cryptographically random, sufficiently long (minimum 128-bit entropy), time-limited tokens. Add CAPTCHA to the recovery flow to prevent automated submission. Monitor web server and application logs for high-frequency recovery requests targeting the same account or originating from the same source IP as an indicator of active exploitation attempts.