En resumen: contratar a un proveedor de seguridad TI compensa cuando hay indicios de una intrusión, funcionan versiones antiguas de PHP sin actualización oficial, internamente faltan tiempo o conocimientos, o hay cuestiones jurídicas afectadas. Si su sitio web está en un proveedor de alojamiento que confirma por escrito el parche y el reinicio, o si su propia TI puede actualizar y comprobar por sí misma una versión compatible de PHP, a menudo no necesita ayuda externa para PHP2Shell.
La pregunta que muchos se plantean ahora
En la semana posterior al 21 de octubre de 2026, muchas empresas miraron por primera vez con más detalle quién atiende en realidad sus servidores web. El resultado fue a menudo desalentador: la agencia se ocupa de los contenidos, el proveedor de alojamiento del hardware, y la versión de PHP del viejo vServer no la conoce nadie con exactitud.
Al mismo tiempo vale esto: no toda empresa necesita en esta situación un proveedor de seguridad. Quien comprueba con honestidad lo que es posible internamente ahorra dinero y conserva el control. Quien se sobrevalora corre el riesgo de que una intrusión pase inadvertida. Este artículo ayuda a situarse, sin querer venderle nada que no necesite.
Resolverlo uno mismo o contratar a un proveedor de seguridad TI: los criterios
| Criterio | Resolverlo uno mismo | Contratar a un proveedor |
|---|---|---|
| Modelo de alojamiento | Alojamiento compartido o gestionado con parche confirmado | Servidor propio sin atención, responsabilidad poco clara |
| Versión de PHP | 8.2 a 8.5, actualización oficial o backport de la distribución disponible | 8.1 o anterior, solo backports de código fuente o fuentes de terceros |
| Número de sistemas | Uno o pocos sitios web, bien documentados | Muchos servidores, entornos mixtos, contenedores |
| Competencia interna | Administrador con derechos de servidor, experiencia en gestión de paquetes y reinicios | Nadie con acceso o experiencia disponible |
| Indicios de intrusión | Sin anomalías tras la revisión | Archivos, procesos, cuentas o conexiones desconocidos |
| Datos personales | Sin datos sensibles en el sistema | Datos de clientes, de salud o de pago |
| Seguro y obligaciones de notificación | Sin afectación | Hay que implicar a la aseguradora o a protección de datos |
| Necesidad de prueba documental | Basta una nota interna | Hace falta un informe para la dirección, una auditoría o la aseguradora |
Si en su situación se cumplen varias filas de la columna derecha, hay mucho a favor de la ayuda externa. Si solo se cumple la columna derecha en «necesidad de prueba documental», a menudo basta un apoyo dirigido en la documentación.
Un autotest en siete preguntas
Responda las preguntas con sí o no. Cada no es una indicación de dónde podría necesitar ayuda.
- ¿Sabe para cada sitio web en qué servidor y con qué versión de PHP se ejecuta?
- ¿Puede acreditar que este estado está corregido frente a CVE-2026-109618 y CVE-2026-109619, por ejemplo mediante el registro de cambios del paquete? La guía está en Comprobar correctamente la versión de PHP y el estado del parche.
- ¿Tiene alguien en casa los derechos y los conocimientos para actualizar PHP y reiniciar todos los workers?
- ¿Tiene para los sitios web en el proveedor de alojamiento una confirmación por escrito del parche y del reinicio? Una plantilla la ofrece Cómo preguntar a su proveedor de alojamiento por el estado del parche.
- ¿Ha buscado alguien anomalías desde el 17 de octubre de 2026, como nuevos archivos PHP en carpetas de subida o tareas cron desconocidas?
- ¿Están asegurados los registros del servidor desde el 20 de octubre de 2026?
- ¿Hay una persona que pueda decidir sobre una desconexión temporal y que sea localizable?
Siete síes significan: está bien posicionado. Uno o dos noes suelen poder recuperarse internamente. Con tres o más noes, sobre todo en las preguntas 2 y 5, el apoyo externo es una consideración seria.
Cuándo expresamente no necesita un proveedor de servicios
Hay situaciones en las que nosotros mismos desaconsejaríamos gastar dinero en ayuda externa. Un sitio web corporativo sencillo en un gran proveedor de alojamiento que ha confirmado el parche, sin formularios con datos sensibles y sin anomalías, es una de ellas. También lo es un servidor propio con PHP 8.3 u 8.4 cuyo administrador ha instalado el backport de la distribución, ha reiniciado todos los procesos y ha revisado brevemente los registros.
En estos casos lo más importante es una breve nota escrita: ¿qué se comprobó, cuándo y con qué resultado? Ayuda ante consultas y en la próxima situación.
Siendo honestos, forma parte de ello no subestimar los propios límites. Instalar una actualización es rutina para muchos administradores. Valorar correctamente un archivo sospechoso sin borrar rastros normalmente no lo es. Quien al parchear encuentre algo llamativo debería detenerse en ese punto, no borrar nada y decidir de nuevo si sigue solo.
Aunque lo haga todo usted mismo: establezca hoy a quién llamaría si de todos modos algo llama la atención. En una emergencia, buscar a un proveedor es tiempo perdido.
El término medio: repartir en lugar de ceder
Entre «todo por mi cuenta» y «cederlo todo» está la variante que mejor funciona en muchas empresas. El propio equipo asume lo que conoce: actualizaciones, reinicios, contacto con el proveedor de alojamiento. Un proveedor asume lo que requiere conocimientos especializados o una mirada independiente, por ejemplo la búsqueda de rastros, la valoración de una sospecha o el informe para la aseguradora.
Para que funcione, deben estar regulados los accesos, las responsabilidades y la protección de datos. Si un proveedor accede a servidores con datos personales, por lo general hace falta un contrato de encargo de tratamiento; encontrará indicaciones en Encargo de tratamiento cuando los proveedores acceden al servidor. Cómo encontrar un proveedor adecuado lo describe Elegir un proveedor de seguridad TI.
¿Cómo ayuda PHP SOS en concreto?
- Empezamos con un breve inventario y decimos abiertamente si no nos necesita.
- Asumimos de forma dirigida las partes que faltan internamente, como la búsqueda de rastros, los sistemas antiguos o la prueba documental, y dejamos el resto en su equipo.
- Trabajamos de forma remota con los accesos que usted autorice y documentamos cada paso.
- En caso de necesidad aguda asumimos por completo, con la ayuda inmediata PHP2Shell, el inventario, el parche, el reinicio y la búsqueda de rastros.
Conclusión
La respuesta correcta a «¿por mi cuenta o con un proveedor?» rara vez es blanca o negra. Quien conoce sus sistemas, opera versiones de PHP compatibles y puede acreditar que se ha parcheado y reiniciado, a menudo supera PHP2Shell por sí solo. Quien tiene sistemas antiguos, estados poco claros o indicios de una intrusión no debería dudar en buscar ayuda.
Preguntas frecuentes
¿Cuándo debería contratar a un proveedor de seguridad TI?
Sobre todo si hay indicios de una intrusión, si funcionan versiones antiguas de PHP sin actualización oficial, si internamente no hay nadie disponible con derechos de servidor y experiencia, o si están afectados datos personales y cuestiones de seguros.
¿No puede encargarse sencillamente mi proveedor de alojamiento?
En el alojamiento compartido y en muchas tarifas gestionadas, el proveedor parchea PHP por sí mismo. Pida que le confirmen por escrito el estado del parche y el reinicio. Para su aplicación, los plugins y una búsqueda de rastros, el proveedor de alojamiento normalmente no es responsable.
¿Qué debería preparar antes de llamar a un proveedor de servicios?
Una lista de los sitios web y servidores afectados, las vías de acceso, interlocutores con capacidad de decisión y una breve descripción de lo que le ha llamado la atención. Hasta entonces, no borre ni modifique nada que pueda contener rastros.
¿Existe un término medio entre hacerlo uno mismo y cederlo todo?
Sí. A menudo el propio equipo asume la rutina, como actualizaciones y reinicios, mientras que un proveedor se encarga de la búsqueda de rastros, la valoración o la documentación. Es importante un reparto claro de quién hace qué.