En resumen: en la web de una consulta médica se trata de la seguridad de datos de salud, no solo de una tarjeta de visita en Internet. Compruebe qué formularios guardan datos o los envían por correo, pida que le confirmen por escrito el estado del parche de PHP del servidor y, ante cualquier sospecha, conserve de inmediato los registros.
Qué sistemas PHP funcionan en consultas y MVZ
La mayoría de las webs de consultas se basan en un CMS PHP, a menudo WordPress y, más raramente, TYPO3 o Joomla. Lo delicado son las funciones adicionales: formularios para solicitar recetas y volantes, cuestionarios de anamnesis para descargar o subir, inscripciones al recordatorio de revisiones, ofertas de empleo con carga de candidaturas y reserva de citas en línea.
La reserva de citas suele ser un servicio externo que solo se integra en la página. En ese caso, los datos de las citas están en el proveedor. Pero algunas consultas usan plugins de reserva que guardan las citas, con su motivo, en la base de datos de la propia web. Conviene conocer justo esa diferencia antes de valorar el riesgo.
Datos de salud: por qué la web es más sensible de lo que parece
Una frase como «Necesito de nuevo mi medicación para la tensión» en el formulario de contacto es un dato de salud. Estas indicaciones pertenecen a las categorías especiales de datos personales del art. 9 del RGPD. Para los médicos rige además el secreto profesional, cuya vulneración puede ser punible según el § 203 del Código Penal alemán (StGB).
Para la web esto significa: las entradas de formularios que permanecen en la base de datos, las copias en los plugins de formularios, los registros de correo del servidor y los documentos subidos quedan al alcance en un ataque. Quien ejecuta código en el servidor suele leerlos también.
Haga que comprueben si su plugin de formularios guarda además las entradas en la base de datos. Muchos lo hacen por defecto. Lo que no se almacena tampoco puede filtrarse.
Qué supone para la consulta una caída o una fuga de datos
Si la web se cae, los pacientes llaman, y el teléfono de la consulta ya está saturado. Es molesto, pero manejable. Pesa más un ataque que pasa desapercibido: redirecciones a páginas fraudulentas con el nombre de la consulta, formularios falsificados o solicitudes con referencia a enfermedades capturadas.
Un incidente así puede desencadenar obligaciones de notificación a la autoridad de protección de datos y, según el riesgo, también la comunicación a los afectados. El plazo de 72 horas del RGPD empieza en cuanto usted tiene conocimiento de la violación. Aclare la valoración con su delegado de protección de datos.
Web de la consulta y seguridad: el hueco habitual de responsabilidades
En las consultas suele haber tres partes implicadas, y cada una se siente responsable de una parte:
| Parte implicada | De qué se ocupa por lo general | Qué suele quedar fuera de su vista |
|---|---|---|
| Proveedor informático de la consulta | Sistema de gestión (PVS), red, conector, puestos de trabajo | Servidor de la web en el proveedor de hosting |
| Agencia web | Diseño, contenidos, plugins | Versión de PHP y reinicio del servidor |
| Proveedor de hosting | Operación del servidor | Datos de formularios y plugins de la consulta |
En PHP2Shell, la vulnerabilidad está justo entre estos papeles: en PHP del servidor web. En el hosting compartido suele ser responsable el proveedor, pero la confirmación del estado del paquete debe solicitarla usted mismo. En los MVZ (centros médicos de atención ambulatoria) con varias sedes, a menudo interviene además la entidad titular, que fija sus propias normas.
¿Hay un puente entre la web y la red de la consulta?
Lo habitual es que la web de la consulta funcione en el proveedor de hosting y no tenga conexión directa con el sistema de gestión de la consulta. Pero hay excepciones que conviene conocer: formularios que transfieren datos automáticamente al PVS, un servidor web en el propio centro de datos del MVZ o credenciales que se usan a la vez para la web, las cuentas de correo y el mantenimiento remoto.
En estos casos, un servidor web comprometido no es solo un problema de la web. Pida a su proveedor informático de la consulta y a quien mantiene el sitio que comprueben juntos qué conexiones existen y qué contraseñas se reutilizan. Para la informática de la consulta rigen además las directrices de la Kassenärztliche Bundesvereinigung (KBV, asociación federal alemana de médicos del seguro de enfermedad) sobre seguridad informática. En qué medida afectan a la web debe aclararlo con su delegado de protección de datos.
Las primeras horas tras un aviso
- Preguntar al proveedor de hosting si PHP está en 8.5.12, 8.4.27, 8.3.36 u 8.2.35 o si se ha aplicado un backport, y si se reiniciaron todos los procesos de PHP.
- Si no está confirmado: desactivar temporalmente el sitio web o sustituirlo por una página informativa estática con el horario de atención telefónica, como recomienda el BSI (Oficina Federal alemana para la Seguridad de la Información) para servidores que no pueden parchearse.
- Conservar los registros del servidor y de acceso desde el 20/10/2026.
- Estar atento a los indicios de compromiso: archivos desconocidos, cuentas de administrador nuevas, redirecciones modificadas.
- Implicar pronto al delegado de protección de datos, no solo después de la limpieza.
¿Cómo ayuda PHP SOS en concreto?
- Aclaramos con el proveedor de hosting y la agencia quién parchea y reinicia PHP, y recabamos la confirmación con el estado del paquete.
- Comprobamos dónde se encuentran en el servidor web los datos de formularios, las cargas y las copias de correo, y si existen conexiones con la red de la consulta.
- Ante una sospecha, conservamos los rastros, buscamos webshells y limpiamos el servidor en el marco de nuestra ayuda de emergencia para webs hackeadas.
- Documentamos el incidente de modo que su delegado de protección de datos pueda valorar la obligación de notificar.
- A continuación reducimos los datos almacenados y reforzamos el servidor, para que la próxima vez haya menos en juego.
Preguntas frecuentes
¿Afecta PHP2Shell al software de mi consulta?
El sistema de gestión de la consulta y el acceso a la infraestructura telemática suelen funcionar separados del sitio web. Los afectados son los servidores web con PHP, es decir, normalmente la web de la consulta y los formularios o portales conectados a ella. Si existen conexiones entre el sitio web y la red de la consulta, debería comprobarlo su proveedor de servicios informáticos.
¿Son datos de salud los del formulario de contacto?
A menudo sí. Ya la petición de una receta de continuación o una solicitud de cita por determinadas dolencias permite sacar conclusiones sobre la salud. Estos datos pertenecen a las categorías especiales del art. 9 del RGPD. La clasificación exacta debe aclararla con su delegado de protección de datos.
¿Debo informar a los pacientes si la web ha sido hackeada?
Depende de si hay datos personales afectados y de lo alto que sea el riesgo para los pacientes. En el caso de los datos de salud, el riesgo suele ser alto. La decisión la toma usted con su delegado de protección de datos y, si es necesario, con asesoramiento jurídico.
¿Quién es responsable de las actualizaciones de PHP en la web de la consulta?
Consta en el contrato de hosting o de mantenimiento. En el hosting compartido y en el gestionado suele parchear el proveedor de hosting; en un servidor propio, el prestador de servicios contratado. Si falta una regulación clara, conviene dejarla por escrito ahora.