CVE-2024-4577 en PHP: cómo funciona el fallo crítico de PHP-CGI en Windows
Publicado el 2026-10-27 por frfrand
Qué es CVE-2024-4577, quién lo descubrió, cuándo afecta a PHP en Windows, cómo se aprovecha y cómo proteger tu web o servidor.
¿Qué pasó con PHP y por qué importa?
Imaginá que tu web funciona normalmente, pero el servidor interpreta parte de una petición HTTP como instrucciones para el programa que ejecuta PHP. Eso es lo que hizo especialmente peligrosa a CVE-2024-4577, publicada en junio de 2024: bajo condiciones específicas, un atacante remoto sin iniciar sesión podía hacer que PHP-CGI recibiera opciones que nunca deberían venir del visitante. El resultado podía ser la ejecución de código o la exposición de información sensible.
¿Quién descubrió la vulnerabilidad y cómo se reportó?
La investigación se atribuye a Orange Tsai, de DEVCORE. El hallazgo se comunicó por los canales de seguridad y el PHP Group publicó correcciones. Identificar un fallo así exige revisar cómo una capa entrega datos a otra: aquí el punto inesperado estaba en la conversión de caracteres de Windows y cómo PHP-CGI interpretaba el resultado.
¿Qué sistemas y versiones estaban afectados?
El registro de PHP Group señala las ramas 8.1 anteriores a 8.1.29, 8.2 anteriores a 8.2.20 y 8.3 anteriores a 8.3.8, en escenarios con Apache, PHP-CGI en Windows y ciertas páginas de códigos. Una instalación de PHP en Linux no queda automáticamente afectada por este fallo específico; tampoco basta con ver «PHP 8» para afirmar que un sitio es vulnerable. El modo de ejecución y la configuración importan mucho.
¿Cómo se explotaba?
A nivel conceptual, el atacante enviaba una solicitud web manipulada para aprovechar una conversión de caracteres conocida como Best-Fit. Esa transformación podía hacer que una entrada tratada como dato terminara interpretándose como opción de la línea de comandos de PHP. No hacía falta conocer la contraseña del administrador si la configuración vulnerable era alcanzable. No es correcto asumir que cualquier formulario PHP provoca este efecto: el origen del fallo está en la integración PHP-CGI/Windows.
¿Por qué se considera tan grave?
Una ejecución de código remota puede permitir leer archivos de configuración, comprometer credenciales, alterar el sitio o instalar componentes maliciosos con los permisos del servicio web. La ficha CVE asigna gravedad crítica. Además, organismos de respuesta reportaron explotación real; por eso no bastaba con pensar que era una prueba académica.
¿Cómo saber si tu sitio corre riesgo?
Primero averiguá dónde se ejecuta PHP: Windows o Linux. Después comprobá cómo: PHP-CGI, FastCGI, módulo de Apache u otro modo. Revisá el número exacto de versión y el boletín aplicable. Si usás Windows con PHP-CGI expuesto, priorizá la revisión; si la distribución mantiene parches retroportados, cotejá el paquete concreto con su aviso de seguridad.
¿Cómo se soluciona?
La solución es actualizar a una versión corregida y actualmente mantenida de PHP, siguiendo las instrucciones del fabricante o proveedor de hosting. Las versiones 8.1.29, 8.2.20 y 8.3.8 corrigieron este CVE en sus respectivas ramas históricas; no son una recomendación para instalar versiones viejas en 2026. Si administrás Apache en Windows, revisá si realmente necesitás exponer PHP-CGI y eliminá esa superficie de ataque cuando no sea necesaria. Probá en un entorno de staging, conservá backup y supervisá logs tras la actualización.
Preguntas rápidas
¿También afecta a WordPress? Un WordPress ejecutado en una configuración PHP-CGI vulnerable podía quedar expuesto, aunque el fallo es de PHP, no del núcleo de WordPress.
¿Un firewall sustituye el parche? No. Puede reducir exposición, pero la corrección principal es actualizar y revisar la configuración.
¿Qué hago si sospecho explotación? Preservá registros, restringí acceso, revisá integridad del sistema y credenciales, y tratá el incidente como potencial compromiso del servidor.
Fuentes verificables: CVE oficial del PHP Group · PHP ChangeLog · CERT-EU.
¿Dónde seguir las alertas y pedir soporte?
En ArduMaker explicamos nuevas vulnerabilidades y compartimos orientación sobre revisión de versiones, actualizaciones y medidas de contención. Podés consultar la página de CVE y soporte de ArduMaker. Si tu sistema no usa WordPress, indicá igualmente la tecnología, versión y configuración al describir el caso para evaluar qué corresponde revisar. Una alerta publicada no significa que todos los servidores de esa tecnología estén afectados, ni que una actualización pendiente implique una intrusión confirmada.
Actualización editorial: octubre de 2026. Revisá siempre el aviso oficial por posibles cambios de versiones y mitigaciones.
Ejemplo práctico: una web PHP en Windows
Situación: una tienda WordPress funciona sobre Windows con Apache y PHP-CGI. El administrador recibe una alerta sobre CVE-2024-4577. No alcanza con mirar la versión de WordPress: el problema está en cómo Windows, Apache y PHP-CGI interpretan la petición.
Comprobación sin atacar la web: en el propio servidor, ejecutá PowerShell y verificá el binario PHP utilizado por Apache:
& "C:\php\php.exe" -vComprobá luego en la configuración de Apache que ese sea el PHP realmente vinculado. Compará rama y versión con el aviso oficial; evitá publicar una página phpinfo() en Internet solo para investigar.
Antes: PHP-CGI vulnerable y públicamente alcanzable. Después: runtime actualizado, procesos reiniciados y una petición normal de prueba que confirma que login, pagos y formularios siguen funcionando. Un backup permite volver atrás si una extensión antigua deja de ser compatible.
¿Qué no prueba el comando? Que tu web fue atacada. Solo ayuda a inventariar el intérprete; el riesgo exige revisar configuración y registros.