Vulnerabilidad crítica PHP: qué es y cómo parchearla
Una vulnerabilidad crítica de PHP es un fallo que permite a un atacante ejecutar código en tu servidor sin usuario ni contraseña. En este caso se publicaron dos fallos de ejecución remota de código (RCE) con una puntuación de 9.2 sobre 10 en el sistema CVSS, y ya existen versiones de PHP que los corrigen. Si tu sitio corre sobre PHP, la acción es revisar la versión y actualizar cuanto antes.
No es un tema menor: PHP mueve WordPress, Laravel, Drupal, PrestaShop y una parte enorme de la web. Cuando un fallo así se hace público, no afecta a un plugin concreto ni a una mala configuración: afecta al propio lenguaje y, por tanto, a casi cualquier página que atienda peticiones web.
Qué pasó: el aviso que no es habitual
El equipo de seguridad de PHP hizo algo poco común: avisar con antelación de que publicaría un parche crítico. Ese gesto, que en apariencia es solo cortesía, es en realidad una señal de alarma. Cuando un proyecto de la magnitud de PHP avisa un día antes para que todo el mundo se prepare, es porque el problema es serio.
Los rumores circularon primero por redes y apuntaban a versiones muy antiguas, hasta PHP 5. Finalmente, los parches se publicaron y las versiones que corrigen el problema son:
PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35
Como PHP 8.1 ya no tiene soporte oficial, el equipo publicó parches excepcionales para PHP 7.4, 8.0 y 8.1. Si tu servidor corre una versión anterior, no habrá parche para ti: te verás forzado a subir a una de estas versiones o tu servidor quedará vulnerable.
Las dos vulnerabilidades explicadas sin jerga
Ambos fallos tienen el mismo origen: cómo gestiona PHP la memoria por dentro mientras atiende una petición. Entenderlo ayuda a dimensionar el riesgo, aunque no necesites ser técnico para actuar.
Ejecución remota por corrupción al quedarse sin memoria
Cuando llega una petición, PHP va preparando sus datos internos: variables, parámetros, estado. El problema aparece si a mitad de ese proceso se queda sin memoria. PHP interrumpe con los datos a medio armar y, al limpiar, trata esos datos incompletos como si fueran válidos.
Es como si un camarero estuviera montando tu mesa, lo llamaran a mitad y el siguiente camarero diera por hecho que la mesa ya está completa. Un atacante que sepa provocar ese «me quedé sin memoria» en el momento justo puede aprovechar los datos corruptos para ejecutar su propio código.
Ejecución remota por estado global obsoleto
En PHP, un mismo proceso trabajador puede atender muchas peticiones seguidas. Parte del estado interno de una petición puede sobrevivir después de que su memoria se haya liberado. La siguiente petición que entra en ese mismo proceso puede usar ese estado fantasma antes de que PHP lo reinicie.
El atacante controla qué queda en esa memoria que ya no es suya y, con ello, qué se ejecuta. Es más retorcido que el anterior, pero igual de peligroso.
Por qué es tan grave: no hace falta autenticarse
La gravedad no está solo en poder ejecutar código remoto. Está en que no necesitas login, ni un formulario vulnerable, ni una sesión iniciada. Basta con enviar la petición adecuada. Eso amplía el universo de afectados a prácticamente cualquier sitio que atienda peticiones web sobre PHP: WordPress, Laravel, Symfony, PrestaShop, un hosting compartido o un servidor propio.
Si tienes un servidor con PHP, este aviso te aplica. La pregunta no es si te afecta, sino qué versión estás ejecutando ahora mismo.
Qué hacer hoy: pasos para parchear tu servidor
El orden importa. Actualizar sin reiniciar el proceso no sirve de nada, y no saber qué versión tienes instalada es empezar con el pie izquierdo.
Averigua qué versión ejecuta tu servidor. Puedes usar php -v o phpinfo. En WordPress, por ejemplo, puedes entrar en Herramientas → Salud del sitio → Información → Servidor.
Actualiza desde el sistema operativo. En Ubuntu o Debian, con sudo apt update y sudo apt upgrade, o el gestor que corresponda.
Verifica que la versión instalada es la corregida. No basta con lanzar la actualización: confirma el número.
Reinicia el proceso que sirve tu sitio. Si dejas el proceso antiguo abierto, seguirás sirviendo peticiones con la versión vulnerable.
Si usas Docker, reconstruye las imágenes y vuelve a desplegar.
Si estás en hosting compartido, pregunta a tu proveedor. Muchos aplicaron el parche automáticamente, pero conviene confirmarlo y no dejarlo al azar.
Qué hacer si todavía no puedes actualizar
Hay dos medidas que no resuelven el problema, pero pueden darte tiempo. La primera es poner delante un WAF o un proxy que filtre los ataques: la vulnerabilidad sigue ahí, pero actúa como escudo hacia fuera. La segunda es tocar la configuración de php.ini para desactivar o limitar ciertos parámetros.
El propio equipo de PHP advierte que esto no arregla nada: solo complica un poco las cosas al atacante. El parche real es la actualización. Cualquier otra cosa es ganar tiempo.
Cómo se encontraron: la sorpresa del hallazgo
Al publicarse los parches, se conoció que una iniciativa de OpenAI orientada a encontrar y corregir vulnerabilidades críticas colaboró en el descubrimiento, apoyándose en modelos de inteligencia artificial de frontera junto a investigadores de ciberseguridad. No fue un modelo encontrándolo solo y a ciegas: hubo un equipo liderando una coalición de mantenedores, investigadores y proveedores de seguridad.
Una empresa de ciberseguridad descubrió y reportó de forma independiente los dos fallos. La inteligencia artificial fue un apoyo, no el protagonista único. Aun así, el episodio deja una idea clara: la IA ya se usa para encontrar y corregir fallos críticos, lo que probablemente acelerará el ritmo al que aparecen y se parchean.
Cómo abordamos este tipo de riesgos en Zempercodes
En Zempercodes trabajamos con la idea de que un sistema no está terminado cuando funciona, sino cuando puede operar, mantenerse y evolucionar sin sobresaltos. Por eso, cuando diseñamos plataformas, APIs o integraciones para empresas, el mantenimiento y la continuidad forman parte de la conversación desde el inicio, no como un añadido posterior. La seguridad de lo que ya está en producción es parte del sistema, igual que los datos o las reglas del negocio.
Un fallo como este demuestra por qué conviene acompañarse de método y no solo de una herramienta. Tener un sitio publicado no equivale a tenerlo bajo control: hace falta saber qué versión corre, quién la actualiza, cómo se reinicia el proceso y quién responde cuando aparece un aviso crítico. Sin responsables y sin procedimiento, la actualización se convierte en una lotería que depende de que alguien se entere a tiempo.
En Zempercodes podemos ayudarte a ordenar esa capa: entender qué tienes en producción, qué depende de qué y cómo se sostiene en el tiempo. No se trata de prometer que nada fallará, sino de que cuando algo falle, el negocio sepa qué hacer. Si tu operación depende de sistemas que nadie está mirando de cerca, es un buen momento para revisarlo con calma.
Preguntas frecuentes
¿Mi sitio está afectado si uso WordPress?
Sí, si WordPress corre sobre una versión de PHP afectada. La vulnerabilidad está en el propio lenguaje, no en WordPress, así que la solución pasa por actualizar PHP en el servidor. Revisa la versión desde Herramientas → Salud del sitio → Información → Servidor.
¿Basta con actualizar o tengo que reiniciar algo?
No basta con instalar la nueva versión. Si el proceso que sirve tu sitio sigue abierto con la versión antigua, seguirás atendiendo peticiones vulnerables. Reinicia el proceso o vuelve a desplegar para que la versión corregida sea la que responde.
¿Qué pasa si mi versión de PHP ya no tiene soporte?
Si estás en PHP 7.4, 8.0 u 8.1 hay parches excepcionales disponibles. Si tu versión es anterior, no habrá parche: tendrás que subir a una de las versiones corregidas o tu servidor quedará expuesto.
¿Un WAF me protege del todo?
No. Un WAF o un proxy puede filtrar intentos de ataque y darte margen, pero la vulnerabilidad sigue presente en el servidor. Es una medida temporal, no un sustituto de la actualización.
¿Necesito autenticarme para que me ataquen?
No. Estas vulnerabilidades permiten ejecución remota de código sin usuario ni contraseña, y sin depender de un formulario vulnerable. Basta con enviar la petición adecuada, lo que las hace especialmente peligrosas.
Conclusión: revisa hoy, no mañana
Estamos ante una vulnerabilidad histórica de PHP: dos fallos de ejecución remota de código, sin autenticación, en el lenguaje que sostiene buena parte de la web. La buena noticia es que ya existen versiones corregidas y que el equipo de PHP avisó con antelación para que los equipos se prepararan. La mala es que la ventana para actuar se mide en horas, no en semanas.
Si no sabes qué versión corre en tu servidor, si nadie en tu equipo tiene claro quién actualiza o si tienes un sitio olvidado que nadie toca, ese es el primer punto a resolver. Escríbenos por el chat que aparece en la esquina inferior derecha de esta página y cuéntanos cómo está montada tu operación: te ayudamos a entender qué revisar y por dónde empezar.