Una semana dura para ser defensor: PwnEscape, eMudhra, SafePay y el parche de PHP

Actualización, 21 de octubre, 16:30 hora de París: PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 hacia las 15:35 hora de París, un poco antes de las 14:00 UTC anunciadas, corrigiendo ambos fallos críticos, además de backports de código fuente para la 7.4, la 8.0 y la 8.1. La sección sobre PHP de más abajo ha sido actualizada.

Si trabajas en seguridad, administración de sistemas o hosting, los siete días que terminan hoy fueron de los que la gente del oficio describe de forma plana, con un rango de fechas, porque los adjetivos parecen poco profesionales. Un escape crítico de máquina virtual en Linux el jueves. Una autoridad de certificación cuyas claves privadas resultaron ser recuperables por cualquiera con un portátil, durante el fin de semana. Un aviso gubernamental conjunto el martes sobre un ransomware que restablece de fábrica los dispositivos de copia de seguridad, más una caída de nube que dejó de hacer funcionar tarjetas bancarias, más el aviso del proyecto PHP de que dos correcciones críticas llegarían al día siguiente. Ese día siguiente es hoy. Las correcciones estaban anunciadas para las 14:00 UTC y llegaron un poco antes, hacia las 15:35 hora de París.

Hay una corrección que importa más que cualquier titular aislado. Puede que hayas leído que «muchos proveedores de hosting fueron hackeados» a través del escape de VM, apodado PwnEscape. A las 13:30 hora de París del 21 de octubre, eso es un temor, no algo confirmado. No se ha reportado explotación activa en ningún sitio. El temor tiene una base racional, que explicaremos, pero debe etiquetarse como temor. El resto de este artículo recorre la semana en orden, separa lo confirmado de lo pronosticado y termina con la breve lista de cosas que un lector corriente o el dueño de un sitio pequeño debería hacer de verdad.

¿Por qué están tan agotados los equipos de seguridad?

Empecemos por las personas, porque todos los acontecimientos de esta semana cayeron sobre las mismas mesas. El estudio de fuerza laboral en ciberseguridad ISC2 2025, publicado en diciembre de 2025 a partir de un trabajo de campo realizado en julio y agosto de 2025 con 16.029 encuestados, halló que el 48% de los profesionales de seguridad se siente agotado intentando mantenerse al día de amenazas y tecnologías, el 47% se siente a menudo desbordado por su carga de trabajo y el 32% se siente sobrecargado por la falta de personal. El dinero no lo suaviza mucho: el 20% no recibió ningún aumento de salario en el último año, y la paga insuficiente fue una fuente frecuente de insatisfacción para el 31%.

El hallazgo más punzante tiene que ver con el liderazgo. Solo el 32% de los encuestados dice que su organización trata la ciberseguridad como una función crítica del negocio, y el 23% señala esa brecha como causa de insatisfacción. El trabajo de seguridad es estructuralmente invisible: un trimestre tranquilo parece, desde el consejo de administración, exactamente igual que un gasto innecesario, y la persona que evitó diez incidentes figura en el presupuesto junto a la que cerró diez ventas. El mismo estudio de ISC2 halló que el 36% de las organizaciones recortó presupuestos de seguridad en 2025 y el 24% reportó despidos en seguridad, mientras que el 72% de los profesionales está de acuerdo en que recortar personal de seguridad aumenta significativamente el riesgo de brechas.

Los datos europeos no son más amables. En el State of Cybersecurity 2026 de ISACA (trabajo de campo en mayo de 2026; 494 encuestados europeos de un total de 1.888 globales), el 72% dijo que el trabajo es más estresante que hace cinco años, con el complejo panorama de amenazas (72%) y las expectativas poco realistas combinadas con demasiado trabajo (57%) como causas principales. Más de la mitad de las organizaciones europeas dijeron estar faltas de personal (56%) y de financiación (55%), y el 21% de las empresas no toma ninguna medida contra el agotamiento. Ten presentes esas cifras mientras se despliega la semana.

¿Qué es PwnEscape y de verdad hackearon a proveedores de hosting a través de él?

El jueves 15 de octubre, el proyecto del kernel de Linux publicó CVE-2026-99999, rápidamente apodado PwnEscape: un fallo en el manejo de sumas de verificación IPv4 del kernel, puntuado 9,3 Crítico por la CNA del kernel (Red Hat lo puntúa como Importante). El escenario: una micro-VM maliciosa envía metadatos de suma de verificación virtio-net manipulados a la interfaz TAP del anfitrión. Un escape de invitado a anfitrión es el momento en que una máquina virtual alquilada deja de ser inquilina y se convierte en casera: el código dentro de la VM de un cliente obtiene influencia sobre el servidor físico que ejecuta las de todos los demás. Por eso un 9,3 en anfitriones de tipo KVM hizo que el personal de hosting fuera a por el café.

Esto es lo que está realmente establecido. El fallo fue hallado por investigadores de pwn.ai durante el desafío Sandbox de Vercel, reportado al kernel el 4 de septiembre y corregido en la rama principal el 14 de octubre, con siete ramas estables parcheadas. La fuga de memoria del anfitrión se demostró contra los sandboxes de producción del anfitrión del desafío, como confirma el propio relato de Vercel sobre el desafío; el mismo artículo dice que ningún informe mostró a nadie accediendo a datos de clientes en Vercel Sandbox. Los fallos del anfitrión y el root en el anfitrión se mostraron solo en las máquinas de los propios investigadores, y pwn.ai afirma que su trabajo no es una afirmación de ejecución de comandos como root en el entorno de producción de ningún proveedor. El patrón de código vulnerable se remonta aproximadamente a 2008, según el análisis de TuxCare.

¿Y la explotación? El enriquecimiento del registro CVE por parte de CISA lo dice sin rodeos: explotación, ninguna. El fallo no está en el catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA en el feed del 20 de octubre. Ningún medio de los que lo siguen ha reportado un ataque activo confirmado. Investigadores citados por CSO y heise esperan exploits funcionales contra configuraciones más débiles en cuestión de semanas, lo cual es un pronóstico, no una observación.

Entonces, ¿por qué el pavor? Tres razones, todas legítimas. Primera, no hay indicadores de compromiso publicados para este fallo, ni hashes maliciosos ni infraestructura de atacantes que buscar; SOC Prime señala que la detección depende de la telemetría del anfitrión, la monitorización de la virtualización y el análisis de fallos, cosas que muchos hosts pequeños sencillamente no recopilan. Eso dificulta la detección. No hace que el fallo sea indetectable: ninguna fuente que hayamos encontrado dice que la explotación no deje rastro. Segunda, la corrección requiere parchear y reiniciar el kernel del anfitrión; actualizar tu propia VM no sirve de nada, así que cada proveedor afectado afronta una campaña de reinicios por toda su flota. Tercera, la incertidumbre ya está causando daño comercial: un proveedor de hosting japonés congeló los nuevos registros en su VPS, hosting compartido y dedicado el 16 de octubre como precaución, sin que se haya reportado brecha alguna, y un host alemán lleva reiniciando sus servidores de virtualización desde el fin de semana. Para los clientes, el consejo de heise sigue vigente: no necesitas actuar, más allá de comprobar que tu VM volvió a arrancar tras el reinicio de tu host.

¿Qué pasó con los certificados de eMudhra?

El sábado llegó la historia de los certificados, y la palabra «secuestrados» empezó a circular. La realidad, documentada en el informe de error de Mozilla, es distinta y en algunos aspectos más extraña: ocho certificados de CA intermedios pertenecientes a eMudhra, una autoridad de certificación india, tenían claves privadas P-384 tan débiles que eran trivialmente recuperables. El propio personal de Mozilla recuperó las claves en cuestión de horas tras el informe del 17 de octubre. eMudhra atribuye la debilidad a un script de generación de claves defectuoso usado en una ceremonia de claves de abril de 2025, citando errores humanos en múltiples pasos.

Lo que siguió fue el ecosistema de confianza funcionando a toda velocidad. Según BleepingComputer, Firefox lanzó un bloqueo mediante OneCRL el 17 de octubre, con las actualizaciones de Firefox 158.0.1 y ESR llegando el 20 de octubre para los usuarios cuyas configuraciones habían bloqueado la actualización anterior; Chrome bloqueó los seis intermedios con capacidad TLS también el 17 de octubre, y Apple hizo lo propio el 19 de octubre; eMudhra revocó los ocho certificados el 18 de octubre. Mozilla anunció después la retirada de emergencia de la confianza en la raíz madre emSign ECC Root CA - G3, con Chrome comprometiéndose a un camino similar; eMudhra estima que habrá que migrar unos 30.000 certificados, según su propio comentario en el informe de error de Mozilla.

Dos matices honestos apuntan en direcciones opuestas. Tranquilizador: no hay pruebas de que las claves débiles fueran jamás utilizadas de forma abusiva, y eMudhra dice que no se emitieron certificados de entidad final a partir de las series afectadas. Menos tranquilizador: una de las claves privadas fue publicada en GitHub por un investigador, y el software que lleva su propio almacén de confianza o se salta las comprobaciones de revocación (el seguimiento del incidente de Mozilla, según reporta BleepingComputer, da como ejemplo el curl integrado en macOS) puede seguir confiando en los certificados hasta que se actualice. Para un lector, toda la acción cabe en una línea: actualiza tu navegador y tu sistema operativo. Los problemas de certificados son exactamente la categoría en la que una VPN no cambia nada, aunque conviene recordar que los certificados falsificados o indebidamente confiables importan sobre todo a un atacante que ya puede interceptar tu tráfico, que es una de las razones por las que cifrar tu conexión en el Wi-Fi público (en inglés) sigue siendo una higiene sensata.

¿Por qué importó tanto la publicación de PHP de hoy?

El martes por la tarde, el proyecto PHP publicó un aviso inusual en php.net: una publicación de seguridad programada para el miércoles 21 de octubre a las 14:00 UTC, que aborda dos vulnerabilidades críticas, con los detalles completos por publicar junto con el lanzamiento. Preanunciar una corrección crítica es un compromiso deliberado: da a los defensores un día para programar ventanas de mantenimiento, a costa de decirles a los atacantes que algo valioso está en camino. El lanzamiento llegó luego un poco antes de lo previsto: los avisos de GitHub llevan la marca de las 13:34 UTC, las 15:34 en París, y el anuncio de PHP, titulado «Vulnerabilidades críticas de ejecución remota de código, actualiza ya», nombra como versiones corregidas PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Corrigen CVE-2026-109618 y CVE-2026-109619, «dos vulnerabilidades críticas que pueden permitir la ejecución remota de código sin autenticación», ambas puntuadas con CVSS v4.0 de 9,2.

Los dos fallos son fáciles de enunciar. CVE-2026-109618, «RCE por corrupción OOM»: la gestión de falta de memoria puede interrumpir PHP mientras los datos internos de la petición están solo parcialmente inicializados, y la limpieza de la petición puede entonces tratar los datos inválidos como válidos. CVE-2026-109619, «RCE por estado global obsoleto»: el estado interno propio de una petición puede sobrevivir después de que su memoria haya sido liberada, y una petición posterior gestionada por el mismo worker puede usarlo, un use after free. Quién está en riesgo, según PHP: «todas las instalaciones de PHP que sirven peticiones web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed». El riesgo es máximo para mod_php, «con un exploit demostrado en el que una petición sin autenticar puede desencadenar el ataque antes de que se ejecute ningún código de la aplicación». Un exploit demostrado no es lo mismo que explotación activa; el aviso de PHP no reporta ataques en circulación.

El embargo se había filtrado de todos modos. Los análisis de firmas de seguridad, incluido el de SecureLayer7, seguían los fallos como CVE-2026-109618 y CVE-2026-109619 y reportaron que una prueba de concepto apodada «PHP2Shell» apareció antes de la publicación; el proyecto PHP no la ha verificado, aunque SecureLayer7 reporta que al menos una firma de seguridad dice haber reproducido uno de los fallos. Los avisos de PHP del 21 de octubre reportan que no hay explotación activa.

Luego está todo el que sigue en una rama antigua. «PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto PHP», señala el anuncio, aunque algunas distribuciones y proveedores LTS ofrecen correcciones retroportadas. «Dada la gravedad», el equipo de seguridad de PHP publicó además backports mínimos de código fuente para PHP 7.4, 8.0 y 8.1, dirigidos a quienes compilan desde el código fuente o no tienen un proveedor LTS; son parches que aplicar, no versiones listas para usar. El proyecto no publicó backports para PHP 7.3 ni anteriores, incluido PHP 5. Las distribuciones de Linux y los proveedores LTS recibieron los parches por adelantado, y la propia PHP 8.2 llega al final de su vida útil el 31 de diciembre de 2026. El aviso de PHP enumera medidas provisionales para quienes no pueden actualizar de inmediato, como poner memory_limit a -1, reducir post_max_size o desactivar el progreso de subida de sesión, pero dice que «reducen la exposición a rutas de ataque concretas pero no hacen segura una instalación»; según las notas de la versión, «actualizar es la única opción segura».

La escala es la clave. Según W3Techs, PHP funciona en el 69,3% de los sitios web con un lenguaje de servidor conocido y, de esos sitios PHP, el 27,0% aún ejecuta la versión 7 y el 7,7% la versión 5, ramas que llegaron al final de su vida útil hace años. Los sitios con la versión 7 incluyen PHP 7.4, que ahora al menos cuenta con un backport a nivel de código fuente; los sitios con PHP 5, y con las versiones de la 7.0 a la 7.3, no reciben ningún backport del proyecto. El aviso 2026-018 de CERT-EU advirtió de que las vulnerabilidades podrían afectar a todas las versiones de PHP desde PHP 5 en adelante; esa advertencia se mantiene como tal, mientras que los avisos de GitHub enumeran como afectadas solo las ramas soportadas, por debajo de 8.2.35, 8.3.36, 8.4.27 y 8.5.12, y no detallan las versiones al final de su vida útil. Para los administradores de sistemas de la primera sección, eso es el trabajo de esta noche y el proyecto de migración del próximo trimestre, anunciado el mismo martes que todo lo demás.

¿Qué más cayó esta semana en la mesa de los defensores?

El lunes y el martes siguieron sumando. El aviso conjunto AA26-293A de CISA y el FBI (20 de octubre) detalla SafePay, una operación de ransomware que ha atacado al menos a 600 organizaciones desde agosto de 2024. Para impedir que las víctimas se recuperen, dice el aviso, SafePay detiene el servicio Volume Shadow Copy y restablece a los ajustes de fábrica el almacenamiento de copias de seguridad conectado a la red, en algunos casos eliminando todas las copias de seguridad en red. El consejo central del aviso es sabiduría antigua con urgencia nueva: las copias de seguridad deben estar fuera de línea, ser inmutables y estar realmente probadas, porque las copias accesibles por red son exactamente lo que esta banda destruye.

El catálogo de vulnerabilidades explotadas conocidas de CISA también tuvo una semana cargada: el 20 de octubre se añadieron cuatro fallos de Plex Media Server que pueden encadenarse, lo cual importa porque Plex es esa rara entrada del KEV que vive en los salones de las casas y no en los centros de datos. Antes esa semana llegaron BeyondTrust Remote Support y Fortinet (16 de octubre), Atlassian Data Center (15 de octubre) y Palo Alto PAN-OS, Cisco Secure Email Gateway y Ahsay (14 de octubre). Cada entrada tiene pruebas de explotación activa.

Otros dos elementos enmarcaron la semana. Una exclusiva de Reuters del 19 de octubre describió a un único hacker que usó agentes de IA autónomos para intentar intrusiones en más de 1.200 sitios y penetrar en los sitios de más de 100 empresas, a un coste de unos 50 dólares por intrusión, según un investigador de NorForge; Reuters no pudo establecer qué datos fueron sustraídos. Sea cual sea el recuento final, la economía es la noticia: si una intrusión cuesta unos 50 dólares, los recortes de presupuesto de los datos de ISC2 parecen aún más difíciles de justificar. Y el martes, una caída de Google Cloud en su región de Londres coincidió con el rechazo de las tarjetas de Revolut por toda Europa; la propia Revolut confirmó la causa la noche del 20 de octubre, anunciando a las 19:39 hora de París que el problema había sido corregido y los servicios restablecidos y señalando una caída de Google Cloud como causa; Google atribuye su caída a un incidente eléctrico en una zona de su región de Londres, y nada la vincula a PwnEscape. Lo cubrimos por separado en nuestro artículo sobre la caída de Revolut.

¿Cómo se ve la semana entera en conjunto?

¿Qué deberías hacer realmente esta semana?

Para la mayoría de los lectores, la respuesta honesta es corta. Actualiza tu navegador y tu sistema operativo, lo que resuelve discretamente la historia de los certificados. Si usas Plex Media Server en casa, actualízalo hoy; esos fallos se están explotando, no solo teorizando. Y espera phishing que tome prestados los titulares de esta semana, el típico «tu cuenta quedó expuesta en la brecha de PHP»; un filtro DNS que bloquea los dominios de phishing conocidos antes de que carguen, como Threat Protection de Le VPN, ayuda en eso, y si un correo afirma que tu email apareció en una brecha, compruébalo tú mismo contra las brechas conocidas en vez de hacer clic en el enlace. Nuestro centro de seguridad online cubre el resto de lo básico.

Si eres dueño de un sitio web: averigua esta noche qué rama de PHP ejecutas. De la 8.2 a la 8.5, la actualización ya está disponible: aplica 8.2.35, 8.3.36, 8.4.27 u 8.5.12 ahora, o pregunta a tu host si ya está aplicada, puesto que las distribuciones de Linux y los proveedores LTS recibieron los parches por adelantado. En la 7.4, la 8.0 o la 8.1, las opciones son los backports mínimos de código fuente del equipo de seguridad de PHP o la corrección retroportada de un proveedor. En la 7.3 o anteriores, incluido PHP 5, toma esto como el detonante de la migración que llevas aplazando y, mientras tanto, considera la sugerencia de CERT-EU de aislar cualquier cosa expuesta a Internet que no pueda parchearse. Si tu sitio vive en un VPS, es justo hacerle a tu proveedor dos preguntas: si los kernels de los anfitriones han sido parcheados contra CVE-2026-99999 y cuándo es la ventana de reinicio. Y comprueba que tus copias de seguridad existen en algún lugar al que el ransomware no pueda llegar: SafePay restablece o elimina las copias conectadas a la red precisamente porque las víctimas cuentan con ellas.

Si gestionas a las personas que hacen este trabajo, las cifras de encuestas del inicio de este artículo no son una curiosidad de recursos humanos; son un indicador de riesgo. El Voice of the CISO 2026 de Proofpoint halló que el 77% de los CISO dice que se depositan expectativas excesivas sobre ellos, y la investigación de IANS/Artico sobre la implicación de los consejos halló que solo el 29% de los consejeros califica de muy eficaces los informes cibernéticos que recibe. Un equipo que pasó esta semana parcheando anfitriones, rotando certificados y leyendo filtraciones de embargos a medianoche volverá a hacerlo el mes que viene. Que lo haga bien, o mientras actualiza su currículum, es en parte una línea de presupuesto.

Un párrafo más de honestidad. Una VPN no habría evitado ni un solo acontecimiento de esta lista. No parchea servidores, no corrige fallos del kernel o de PHP en los sitios que visitas, no detiene caídas de nube ni sustituye las actualizaciones del navegador que bloquearon los certificados defectuosos. Lo que hace es más estrecho y sigue siendo útil: cifra el tráfico entre tu dispositivo y el servidor VPN, de modo que alguien en el mismo Wi-Fi de la cafetería no pueda interceptar lo que envías. Saber con precisión lo que hace una herramienta, y decirlo, nos pareció la forma correcta de cerrar una semana que funcionó a base de miedo a lo no confirmado.

Las correcciones llegaron esta tarde, hora de París. En algún lugar, un administrador cansado tiene una terminal abierta y una ventana de mantenimiento reservada, y para el jueves nadie fuera del equipo recordará que ocurrió. Así es la seguridad cuando funciona: nada, visiblemente, en absoluto.