Situación actual: PHP2Shell. Dos vulnerabilidades críticas de PHP (CVSS 9.2) permiten ejecutar código malicioso sin autenticación. Parches desde el 21/10/2026.Qué hacer ahora →

Emergencia informática: contrate ya a un proveedor para su servidor web

¿Emergencia informática en su servidor web y sin ningún experto a mano? Entramos en remoto, aseguramos los rastros, cerramos la vulnerabilidad y documentamos el incidente.

Actualizado 5 min de lecturaAyuda inmediata

En resumen: ¿le afecta? Llame. Le ayudamos. Si tiene una emergencia informática en su servidor web y ningún experto a mano, contrátenos con un mensaje: nos hacemos cargo desde el primer mensaje, trabajamos en remoto sin desplazamientos y lo dejamos todo por escrito hasta que el incidente quede cerrado y documentado.

Actuar de inmediato

No borre nada ahora y no reinstale nada. Tampoco como preparación para el proveedor. El estado del sistema es la prueba más importante. Comunique la emergencia y aclararemos juntos los accesos y las funciones.

¿Le afecta? Cuándo hace falta un proveedor de emergencias

No toda avería es un incidente de seguridad. Un proveedor para emergencias tiene sentido si se da al menos uno de estos puntos:

  • Su servidor web se comporta de forma anómala y nadie en la empresa sabe identificar la causa.
  • Hay sospecha de código malicioso, de una intrusión o de datos filtrados.
  • El proveedor de hosting ha bloqueado el servicio o exige una limpieza.
  • Su versión de PHP es antigua o no está clara, y no sabe si se han explotado las vulnerabilidades de PHP2Shell.
  • El departamento de TI propio o la agencia no está localizable o no tiene experiencia con incidentes.

Basta con la sospecha. Si puede avanzar usted mismo o necesita apoyo se puede valorar con la página ¿Resolverlo uno mismo o recurrir a un proveedor?.

Qué hacer ahora mismo

  1. Congelar el estado. Ningún cambio en el servidor, ninguna operación de limpieza, ninguna actualización a ciegas.
  2. Hacer una lista de accesos. ¿Qué accesos al panel, por SSH, al CMS y a la base de datos existen y quién los gestiona?
  3. Informar al proveedor de hosting. Pídale que conserve registros e instantáneas. No omita nada que deba saber.
  4. Fijar quién decide. ¿Quién en la empresa autoriza apagados, reinicios y cambios de contraseña?
  5. Aclarar los datos. ¿Hay en el sistema datos personales, datos de pago o secretos empresariales?
  6. Informar a los implicados. Al delegado de protección de datos y, si lo hay, al asegurador de ciberriesgos.
  7. Contratar al proveedor. Llame o escriba por WhatsApp. Nos hacemos cargo desde el primer mensaje.

Cómo se desarrolla la contratación

Una emergencia no admite un proceso contractual largo, pero tampoco admite lagunas en responsabilidad y protección de datos. Por eso procedemos en este orden:

  1. Primera conversación: escuchamos la situación y hacemos las pocas preguntas necesarias para una primera valoración.
  2. Acordar el marco: aclaramos juntos qué sistemas podemos revisar, quién decide y cómo nos comunicamos.
  3. Regular la protección de datos: si accedemos a sistemas con datos personales, hablamos del acuerdo de encargo del tratamiento necesario. Los fundamentos los explica la página Encargo del tratamiento en el acceso a servidores.
  4. Configurar el acceso: usted nos da solo los permisos necesarios para el encargo. Al terminar, los accesos se retiran de nuevo.
  5. Trabajo e informes: le informamos con estados intermedios y dejamos los resultados por escrito.

Cómo comparar proveedores en general se explica en Elegir un proveedor de seguridad informática: 12 preguntas. Las obligaciones contractuales en materia de seguridad se tratan en Contratos con proveedores: regular con claridad las obligaciones de seguridad.

¿Cómo ayuda PHP SOS en concreto?

  1. Evaluar la situación: ¿qué ha pasado, qué servidores están en funcionamiento, qué versiones de PHP y qué modo de ejecución (PHP-FPM, mod_php, LiteSpeed) se utilizan?
  2. Asegurar y cerrar: aseguramos registros, archivos y base de datos. Después resolvemos la causa: parche, configuración o bloqueo de accesos, con reinicio de todos los procesos de PHP.
  3. Revisar y limpiar: buscamos webshells, puertas traseras, tareas cron y accesos ajenos y los eliminamos, o reconstruimos a partir de fuentes limpias.
  4. Reforzar e informar: recibe un informe con cronología, hallazgos y recomendaciones. En incidentes mayores pasamos a una respuesta a incidentes.

Si por ahora se trata solo de la vulnerabilidad de PHP y de la prueba del parche, encaja la ayuda urgente PHP2Shell para empresas. Si hay código malicioso, el punto de partida adecuado es la eliminación de malware.

Cómo reconocer a un proveedor de emergencias fiable

En una emergencia muchos recurren al primer proveedor que encuentran. Tres preguntas ayudan a poner orden en minutos. Primera: ¿se asegura primero y solo después se modifica? Quien «ordena» de inmediato dificulta el esclarecimiento posterior. Segunda: ¿se deja constancia por escrito de lo encontrado y de lo hecho? Sin documentación, ni la aseguradora ni los delegados de protección de datos pueden hacer nada con ello. Tercera: ¿se mencionan los límites? Hay que tratar con cautela a un proveedor que declara que todo es factible antes de haber visto el sistema.

Compruebe también si el proveedor entiende su modo de ejecución. PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed se comportan de forma distinta al parchear, y tras la actualización hay que reiniciar todos los procesos; si no, el estado antiguo sigue ejecutándose en memoria.

Lo que un proveedor de emergencias no puede hacer

Conviene conocer los límites de antemano. Ningún proveedor puede generar retroactivamente registros que nunca se escribieron o que ya se sobrescribieron. Si faltan rastros, mencionamos las lagunas abiertamente. Tampoco nadie puede asegurar que un sistema limpiado no vuelva a ser atacado nunca. Y el asesoramiento jurídico no forma parte de nuestro encargo: las cuestiones sobre obligaciones de notificación, responsabilidad y seguros corresponden al delegado de protección de datos, al abogado y a la aseguradora; nosotros les facilitamos los hechos técnicos.

Qué debería enviarnos

  • breve descripción del incidente y del momento en que se detectó
  • dominios y servidores afectados y, si se conoce, la versión de PHP
  • nombre del proveedor de hosting y tipo de contrato (hosting compartido, VPS, servidor dedicado, servidor gestionado)
  • una persona de contacto con capacidad de decisión
  • copias de seguridad existentes y su estado

Por qué PHP SOS

Trabajamos Made in Germany y llevamos más de 25 años especializados en seguridad informática junto con nuestra red de socios, profesionales de la ciberseguridad. Usted habla con un interlocutor fijo, trabajamos en remoto en toda Europa y documentamos cada paso. Decimos con franqueza qué está demostrado y qué no, y no hacemos promesas que ningún proveedor serio pueda dar. Nuestro orden es siempre el mismo: primero asegurar, después modificar, después informar.

¿Le afecta? Llame. Le ayudamos.

No siga buscando al proveedor adecuado mientras el incidente está en curso. Llame o escriba por WhatsApp; nos hacemos cargo desde el primer mensaje. Comunicar la emergencia ahora.

Preguntas frecuentes

¿Cómo reconozco a un buen proveedor para emergencias informáticas?

Asegura los rastros antes de cambiar nada, separa con franqueza lo demostrado de lo supuesto, documenta cada paso y no promete milagros. Debe desconfiar de afirmaciones como «garantizado totalmente limpio», porque nadie puede asegurarlo con seriedad.

¿Qué accesos necesita un proveedor en una emergencia informática?

Por lo general, acceso por SSH o al panel del servidor, acceso al backend del CMS y a la base de datos, o su autorización para hablar con el proveedor de hosting. Dé solo lo necesario y anote quién recibió qué acceso y cuándo.

¿Necesito un contrato de encargo del tratamiento para el acceso remoto?

Si un proveedor accede a sistemas con datos personales, normalmente hace falta una regulación del encargo del tratamiento. La valoración corresponde a los delegados de protección de datos o a los abogados. Lo aclaramos con usted desde el principio.

¿Cuál es la diferencia entre respuesta a incidentes y eliminación de malware?

La eliminación de malware limpia un sistema infectado. La respuesta a incidentes tiene un alcance mayor: abarca la visión de la situación, la contención, la limpieza, la comunicación y el seguimiento posterior, a menudo en varios sistemas.

¿Hay que implicar a mi proveedor de hosting?

A menudo sí, por ejemplo para instantáneas, registros o el levantamiento de bloqueos. Nos coordinamos con su proveedor de hosting si usted lo autoriza. Lo que puede revisarse depende de los permisos que recibamos.

Fuentes

Contacto inmediato

Cada hora cuenta. Escríbanos ahora.

Describa brevemente el sistema, la versión de PHP y lo que ha observado. Nos pondremos en contacto, aclararemos la situación y trabajaremos en remoto hasta que el incidente quede cerrado y documentado.

Ayuda inmediata