Webkul Aureus ERP EUVD-2026-104479

The specific precondition is that the user-creation/edit password field defined in plugins/webkul/security/src/Filament/Resources/UserResource/Schemas/UserForm.php does not enforce sufficient password-strength/complexity requirements, permitting weak passwords to be set for accounts. Exploitation is therefore gated by behavioral and difficulty factors rather than a single crafted request: an account must actually use a weak password, and the attacker must perform an online guessing/brute-force effort - consistent with the CVSS AC:H ('rather high' complexity) rating and VulDB's 'difficult' exploitability note. Direct impact is limited to low confidentiality (VC:L) with no integrity or availability effect, so the realistic risk is account compromise facilitated by poor credential hygiene, not immediate system takeover.

This is a low-priority, low-real-risk issue despite its network attack vector. The provided CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:N/UI:N/VC:L) yields a base score of only 2.9 (Low), driven by high attack complexity (AC:H) and a confidentiality-only impact rated Low (VC:L), with no integrity or availability impact. The weakness is CWE-521 (Insufficiently Strong Password Requirements) - a design/policy weakness, not a directly exploitable memory or injection flaw. Signals are largely consistent and point to low urgency: there is publicly available exploit code (a GitHub write-up), but the CVE is NOT in CISA KEV, and no EPSS score was provided in the input. VulDB's own language ('complexity of an attack is rather high', 'exploitability is considered difficult') aligns with the AC:H metric. The 'exploit' reference is a readme describing the weak-password-policy finding rather than a weaponized tool, so POC availability should not be conflated with active exploitation. Note a tension worth flagging: PR:N labels this 'unauthenticated,' but the weakness only materializes once a user sets a weak password and an attacker then attempts to guess/brute-force it, so real-world exploitation depends on account behavior, not solely on reaching the product over the network - verify intended attacker model with the vendor. EPSS is missing, so widespread automated exploitation probability cannot be independently assessed.

An attacker targeting an internet-reachable Aureus ERP instance leverages the application's failure to enforce strong password complexity: because users (including administrators) can register or set trivially weak passwords, the attacker mounts an online guessing or brute-force campaign against the login endpoint to compromise an account. A public write-up (POC) documenting the weak password policy exists, but success still hinges on an account actually using a weak credential and on overcoming the high attack complexity.