iWebShop-5 CVE-2026-112033

Exploitation requires that a victim holds an active, authenticated iWebShop-5 administrator session AND is induced to load attacker-controlled content (UI:P) that triggers a forged request to the admin_repwd_act function in controllers/system.php. The specific limiting factors are: (1) the target must be a logged-in admin - without a live session the forged request fails; (2) the application must lack anti-CSRF tokens on the password-change form (the root cause); and (3) the attacker gains no direct access themselves - the outcome is a password change executed in the victim's context, not server takeover. No fixed version is available since the vendor has not responded.

This is a genuinely low-to-moderate priority issue despite being a 'MEDIUM' CVSS 5.3. The signals are internally consistent and point to limited real-world risk. The CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:P) correctly reflects a CSRF weakness (CWE-352): the attack is network-reachable and low-complexity, but hinges on tricking an already-authenticated administrator into performing an action (UI:P / Passive user interaction), and the impact is confined to a single low-integrity effect (VI:L) with no confidentiality or availability loss (VC:N/VA:N) and no scope change (SC/SI/SA:N). A public exploit exists (referenced as the GitHub issue report), and the vendor embargo status is poor - the project was notified but has not responded, so no patch is available. However, the embedded exploit-maturity metric is E:P (Proof-of-Concept), NOT active exploitation. There is no CISA KEV listing and no EPSS score in the provided data, so there is no evidence of in-the-wild or automated exploitation. The required precondition - a logged-in admin being socially engineered into visiting a malicious page - combined with the product's obscurity sharply limits practical attacker value. Note a conflict worth flagging: PR:N (unauthenticated attacker) is technically correct for CSRF because the ATTACKER needs no credentials, but exploitation nonetheless depends entirely on a VICTIM who holds an authenticated admin session; this is a classic CSRF nuance, not an unauthenticated server compromise.

An attacker hosts a malicious web page (or sends a link/email) containing an auto-submitting form targeting the admin_repwd_act endpoint of controllers/system.php. When a currently-authenticated iWebShop-5 administrator visits that page, their browser silently submits the forged password/repassword change request using their valid session, altering the account password without consent. A public proof-of-concept for this vector has been released.