PHP2Shell: dos fallas críticas en PHP obligan a actualizar Moodle y cualquier sitio PHP hoy

Qué pasó el 21 de octubre

El equipo de seguridad de PHP publicó un aviso de seguridad junto con cuatro versiones de emergencia: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las cuatro corrigen dos vulnerabilidades críticas, puntuadas 9.2 en CVSS 4.0, que la prensa especializada agrupa bajo el nombre PHP2Shell:

• CVE-2026-109618: un agotamiento de memoria interrumpe a PHP mientras los datos de la petición están a medio inicializar; la limpieza posterior trata esos datos corruptos como válidos y abre la puerta a ejecutar código.
• CVE-2026-109619: el estado interno de una petición sobrevive después de liberar su memoria, y la siguiente petición atendida por el mismo proceso puede usar ese estado obsoleto antes de que se reinicie.

El propio aviso lo resume sin rodeos: «no hay mitigaciones completas; actualizar es la única opción segura». Los detalles se filtraron el 20 de octubre, un día antes de la publicación coordinada, y Amazon, watchTowr y Cloudflare ya reportan intentos de explotación en la red.

¿A quién afecta PHP2Shell?

A cualquier servidor que atienda peticiones web con PHP: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El escenario más expuesto es Apache con mod_php, donde una petición sin autenticar dispara la falla antes de que corra una sola línea de la aplicación. Investigadores confirmaron ejecución remota de código sin iniciar sesión en instalaciones de WordPress, Drupal, Joomla y Magento; las estimaciones recogidas por Tenable hablan de más de 1.3 millones de hosts expuestos en internet.

Moodle no aparece en los avisos. Eso no es un alivio: Moodle es una aplicación PHP y la vulnerabilidad vive en el intérprete, no en la aplicación. Una plataforma de capacitación expuesta a internet con PHP sin parchear está en la misma situación que una tienda en línea o un blog.

Por qué Moodle merece prioridad

Un LMS corporativo guarda más de lo que parece: nombres, correos y puestos de toda la plantilla, calificaciones, constancias DC-3 y la evidencia de capacitación que la STPS o un auditor ISO pueden pedir. Un atacante con control del servidor puede extraer esos datos, alterar registros o usar el servidor para atacar a otros sistemas de la empresa. Además, muchas instalaciones de Moodle corren en hosting compartido o en servidores que nadie ha tocado desde la implementación, justo el perfil que tarda más en recibir el parche.

¿Qué versión de PHP necesita tu Moodle?

La buena noticia: toda rama de Moodle con soporte tiene una versión de PHP parcheada dentro de su rango admitido. La tabla usa los rangos oficiales de la documentación de Moodle.

Dos avisos que salen de la tabla. Primero: PHP 8.1 y anteriores ya no reciben parches del proyecto; el equipo de seguridad publicó solo «backports mínimos» de código fuente para 7.4, 8.0 y 8.1 que cada quien tendría que compilar. Si tu Moodle es 4.1 o más viejo, el parche de PHP no te alcanza: la salida es migrar Moodle. Segundo: PHP 8.2 llega a su fin de vida el 31 de diciembre de 2026; parchear a 8.2.35 hoy resuelve la urgencia, pero conviene planear el salto a 8.3 u 8.4 antes de fin de año.

¿Qué hacer hoy? Seis pasos en orden

1. Inventario. Lista cada servidor que ejecute PHP, empezando por los expuestos a internet: Moodle, el sitio corporativo, intranets, APIs. En Moodle la versión de PHP aparece en Administración del sitio → Servidor → Entorno.
2. Actualiza PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 según el rango de tu Moodle. Las distribuciones Linux recibieron los parches con antelación: revisa el changelog del paquete de tu proveedor. Si usas hosting compartido, pide por escrito la versión exacta instalada.
3. Reinicia PHP-FPM, Apache o el servicio que corresponda. Mientras no se reinicie, el proceso vulnerable sigue en memoria aunque el paquete ya esté actualizado.
4. Si no puedes actualizar en las próximas horas, aplica las mitigaciones que publicó PHP, sabiendo que son parciales: memory_limit = -1 fijado con php_admin_value para que la aplicación no lo pueda cambiar, post_max_size de 8 MB (32 MB si Moodle necesita subir archivos), session.upload_progress.enabled = 0 en php.ini o en el pool de FPM, y en PHP 8.5 fatal_error_backtraces = 0. Evita límites RLIMIT_AS o RLIMIT_DATA: provocan justo la falla de memoria que explota el ataque. Un WAF o proxy inverso delante de PHP ayuda, pero solo cubre el tráfico que pasa por él.
5. Busca señales de compromiso: envíos de formularios inusualmente grandes, errores de memoria agotada durante la inicialización de peticiones en los logs de PHP y procesos de shell que no deberían existir en el servidor.
6. Verifica los plugins. Si el parche te obliga a subir de rama de PHP (por ejemplo de 8.1 a 8.3), confirma antes que tus plugins de Moodle tienen versión compatible; es la causa más común de que una actualización urgente se posponga. Si quien administra la plataforma necesita soltura con estas tareas, el curso de Moodle para administradores cubre entorno, actualización y respaldos.

Lo que estamos haciendo con los Moodle que administramos

Desde la madrugada del 22 de octubre estamos aplicando el parche de PHP y reiniciando los procesos en las plataformas bajo mantenimiento de Geedle, con respaldo previo y verificación de entorno en cada una. Si administras tu Moodle por tu cuenta y necesitas una segunda mano para hacerlo sin tirar la plataforma, o si tu instalación está en una versión que ya no admite un PHP parcheado, los servicios de abajo son el camino: una revisión de hoy cuesta mucho menos que un incidente la próxima semana.

Transparencia: Geedle vende servicios de mantenimiento de LMS. Los hechos de esta nota salen de las fuentes enlazadas, no de nuestra oferta comercial; si detectas un error, escríbenos a [email protected] y lo corregimos con fecha.

Fuentes

• PHP Group: aviso de seguridad y versiones 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (21 de octubre de 2026)
• Tenable: preguntas frecuentes sobre php2shell
• CERT-EU: aviso 2026-018
• MoodleDocs: versiones de PHP admitidas por cada Moodle y calendario de soporte de Moodle