En resumen: si su servidor PHP da problemas y quiere hablar directamente con un experto, llame o escriba por WhatsApp. ¿Le afecta? Llame. Le ayudamos. Aclaramos en remoto si detrás hay una caída, un error de configuración o un ataque, y nos hacemos cargo desde el primer mensaje hasta que el incidente quede cerrado y documentado.
No borre nada ahora y no reinstale nada. Incluso un reinicio o una reversión puede borrar rastros. Cuéntenos primero lo que ve. Comunique la emergencia y después fijaremos el siguiente paso.
¿Le afecta? Estas averías son un caso para nosotros
No toda avería es un ataque, pero en estos días merece la pena echar un vistazo. Póngase en contacto si en su sistema PHP ocurre algo de lo siguiente:
- Los procesos de PHP o el servidor web se interrumpen, se reinician una y otra vez o los termina el sistema (estado de salida 137).
- La carga sube sin motivo aparente o la memoria se llena.
- Las páginas devuelven respuestas vacías, errores 500 o mensajes de error que antes no existían.
- Bajo el servidor web o PHP-FPM se ejecutan procesos que inician una shell.
- En la carpeta de subida o de caché hay archivos PHP que usted no conoce.
- Tras una actualización de PHP, una aplicación deja de funcionar.
- Su proveedor de hosting ha bloqueado el acceso o ha desconectado el sitio.
La diferencia entre una caída y un ataque suele verse solo en los registros. Las primeras pistas sobre qué importa las describe el artículo El servidor web inicia una shell.
Qué hacer ahora mismo
- Observar antes de intervenir. Anote la hora, los mensajes de error y lo último que se cambió (actualización, plugin, configuración).
- Asegurar los registros. Copie los registros del servidor web, de PHP y del sistema antes de que roten. La prensa especializada aconseja conservar los registros desde el 20/10/2026.
- No reiniciar a ciegas. Un reinicio resuelve alguna caída, pero destruye rastros volátiles. Reinicie si la operación lo exige y anote lo que ha hecho.
- Valorar la disponibilidad. Si sospecha un ataque, aislar o desconectar suele ser lo correcto. El BSI (Oficina Federal alemana de Seguridad de la Información) lo aconseja cuando la actualización no es posible de inmediato.
- Determinar la versión de PHP.
php -vmuestra la versión, pero no siempre la del entorno de ejecución del servidor web. - Llamar o escribir. Cuanto más exactamente pueda describir la situación, antes llegamos al fondo.
¿Cómo ayuda PHP SOS en concreto?
Trabajamos en remoto, sin desplazamientos, en toda Europa.
- Evaluar la situación: en la primera conversación escuchamos y preguntamos con precisión: sistemas, modo de ejecución de PHP, momento, últimos cambios. Después sabrá si vemos una caída o una sospecha de ataque.
- Asegurar y cerrar: aseguramos el estado, resolvemos la causa y, si es necesario, cerramos la vulnerabilidad con actualización, reinicio y medidas provisionales.
- Revisar y limpiar: si se muestra una intrusión, eliminamos el código malicioso y revisamos accesos y secretos. Si no, documentamos la causa y dejamos la operación funcionando limpia.
- Reforzar e informar: recibe un informe breve y recomendaciones para que la avería no se repita.
Si hay algo más detrás, pasamos a la ayuda de emergencia para sitios hackeados o a la respuesta a incidentes estructurada.
Memoria, interrupciones y el nuevo límite
Desde las versiones de seguridad del 21/10/2026 (8.5.12, 8.4.27, 8.3.36, 8.2.35) existe la directiva memory_hard_limit_percent. Desde entonces memory_limit es un límite blando. Sin un ajuste propio, el límite estricto es el doble de memory_limit hasta 1G y, por encima, memory_limit más 1G. Si se supera, el proceso termina de inmediato con el estado de salida 137. Una operación que antes de la actualización iba justa de límite puede mostrar por ello interrupciones repentinas. No es un ataque, sino una consecuencia de la corrección, y la solución es ajustar bien la aplicación o el límite, no revertir la actualización.
A la inversa: quien ve procesos caídos y todavía no ha parcheado no debería descartarlo como casualidad, porque la vulnerabilidad CVE-2026-109618 está relacionada con un estado de falta de memoria. Si eso influye en su caso lo muestran los registros. Encontrará antecedentes sobre la gestión de memoria en Falta de memoria en PHP y posibles señales de intrusión en Procesos sospechosos en Linux.
Cuando interviene el proveedor de hosting
Algunos proveedores bloquean cuentas o ponen sitios fuera de línea como medida preventiva. Eso no significa automáticamente que le hayan hackeado, pero puede ser consecuencia de anomalías. Pregunte por el motivo y el momento, pida los registros y anote lo que exige el proveedor. Nos coordinamos con su proveedor de hosting si usted lo desea. Conviene aclarar de antemano quién puede tomar decisiones en el proveedor y si allí hay registros del servidor que usted mismo no puede consultar. Esos datos, por ejemplo los accesos a nivel de red, pueden ser decisivos más adelante cuando se trate de acotar el momento de una posible intrusión.
Qué debería enviarnos
- breve descripción: ¿qué ha fallado o llama la atención, desde cuándo?
- tipo de sistema (servidor propio, paquete de hosting, contenedor) y proveedor de hosting
- salida de
php -v, modo de ejecución y servidor web, en la medida en que se conozcan - mensajes de error o extractos de los registros
- momento de la última actualización de PHP y de los últimos cambios
- persona de contacto con capacidad de decisión para los reinicios
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 en lugar de con un sistema de tickets. Trabajamos en remoto, documentamos lo que vemos y hacemos, y decimos con franqueza qué está demostrado y qué no. Para los casos agudos relacionados con la vulnerabilidad existe además la ayuda urgente PHP2Shell.
¿Le afecta? Llame. Le ayudamos.
Si su servidor PHP da problemas, no espere a la próxima caída. Llame o escriba por WhatsApp. Nos hacemos cargo desde el primer mensaje. Comunicar la emergencia ahora.
Preguntas frecuentes
Mi servidor PHP de pronto va lento o se cae: ¿es un ataque?
No necesariamente. Las caídas suelen tener causas banales, como falta de memoria, una actualización defectuosa o una sobrecarga. Solo una mirada a los registros y a los procesos muestra si es un ataque; son señales de alerta, por ejemplo, los procesos de shell bajo el servidor web o archivos PHP nuevos desconocidos.
¿Qué significa el estado de salida 137 en los procesos de PHP?
El estado 137 corresponde a un proceso terminado de forma inmediata. Según el manual de PHP, un proceso termina con 137 cuando supera el límite estricto de memoria de la nueva directiva memory_hard_limit_percent; pero también puede haber sido terminado por el sistema por falta de memoria. La causa la aclara una mirada a los registros.
¿Puedo hablar por teléfono con un experto antes de cambiar nada?
Sí, para eso está precisamente la ayuda de emergencia. Llame o escriba por WhatsApp y describa lo que observa. Le diremos qué debe dejar como está y qué puede hacer sin riesgo.
¿Debo reiniciar sin más el servicio PHP?
Un reinicio puede resolver una caída, pero borra pistas en la memoria. Si es posible que haya habido una intrusión, asegure antes los registros y pida asesoramiento. Tras una actualización de PHP, en cambio, el reinicio es obligatorio.
¿Trabajan también si mi servidor está en un proveedor de hosting?
Sí, trabajamos en remoto con el acceso que usted tenga y, si hace falta, nos coordinamos con su proveedor de hosting. Qué revisiones son posibles depende de sus permisos.