No es nuestro fallo, pero sí nuestro problema

Por qué el mundo .NET / Umbraco debe tomarse en serio la vulnerabilidad PHP2Shell

Dos fallos críticos de PHP pusieron en riesgo esta semana a millones de sitios WordPress y otros sitios PHP. Los sitios Umbraco no están afectados, pero en la era de la IA ninguna plataforma puede bajar la guardia. Te explicamos por qué .NET está mejor posicionado y qué debería hacer ya cualquier responsable de un sitio web.

Umbraco · Seguridad

Parchear. Proteger. Prepararse.

El 20 de octubre, el proyecto PHP advirtió de dos fallos críticos en el propio PHP: CVE-2026-109618 y CVE-2026-109619. Los detalles se filtraron antes de que la corrección estuviera lista. Los parches llegaron el 21 de octubre en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y ya se estaba informando de tráfico de ataque. Ambos fallos pueden permitir que un atacante ejecute su propio código en un servidor web sin iniciar sesión.

Si tu sitio web funciona con Umbraco, no estás afectado. Umbraco está construido sobre Microsoft .NET y no usa PHP. Aun así, no es motivo para relajarse. Este artículo explica por qué los sitios .NET y Umbraco están mejor posicionados y por qué todas las plataformas deben reforzar su seguridad ahora que los atacantes también usan IA.

Puntos clave

Umbraco no está afectadoLos fallos están en el intérprete de PHP. Umbraco funciona con .NET, así que esta vez no hay nada que parchear.

La escala atrae a los atacantesPHP hace funcionar la mayor parte de la web, y WordPress es la razón principal. Un solo fallo abre millones de puertas.

Quién es el dueño importaMicrosoft es dueño de .NET y lo corrige con un calendario mensual fijo. Umbraco le sigue de cerca.

La IA acorta los plazosLos atacantes pueden convertir una corrección publicada en un exploit funcional mucho más rápido que antes, en cualquier plataforma.

Pon un escudo delanteUn firewall de aplicaciones web como Cloudflare te protege entre el anuncio de un fallo y la instalación de tu parche.

Qué pasó

Ambos fallos están en el núcleo de PHP, en cómo limpia después de que una petición se queda sin memoria o sufre un error fatal. En determinadas circunstancias, los datos que quedan de una petición pueden usarse para tomar el control del servidor. Cualquier instalación de PHP que sirva páginas web está en riesgo, sea cual sea el servidor web que use. Palo Alto Networks contabilizó más de 22 millones de servidores expuestos, y las versiones antiguas de PHP que ya no tienen soporte no recibirán ninguna corrección.

Por qué WordPress convierte a PHP en un objetivo mayor

Alrededor del 70 % de los sitios web usan alguna versión de PHP, y WordPress representa una gran parte de ellos. Cuando una sola plataforma hace funcionar tanta parte de la web, vale la pena automatizar el ataque a un único fallo. Los atacantes rastrean todo internet en horas. No necesitan saber quién eres, solo qué usas.

El ecosistema de plugins aumenta el riesgo. Un sitio WordPress típico depende de decenas de plugins de distintos autores, cada uno con su propia forma de gestionar las actualizaciones. Muchos sitios se configuran una vez y se dejan en un hosting compartido, con la versión de PHP que el proveedor eligió hace años.

Por qué .NET está en una posición más sólida

.NET es propiedad de Microsoft, que se encarga de su mantenimiento. Las correcciones de seguridad pasan por el Microsoft Security Response Center y se publican con un calendario mensual fijo, el Patch Tuesday, con versiones de emergencia cuando hace falta. En servidores Windows, las actualizaciones de .NET pueden llegar por Microsoft Update junto con las del propio sistema operativo.

Soporte predecibleCada versión de .NET tiene una fecha de fin de soporte publicada. Las versiones de soporte a largo plazo reciben tres años de correcciones, así que siempre sabes a qué atenerte.

Código compiladoEl código de la aplicación se compila antes de desplegarse. Un archivo subido al servidor no puede ejecutarse sin más como código, lo que cierra una de las vías más habituales para tomar el control de sitios PHP.

Un solo dueñoEl runtime, el framework y el servidor web de Windows vienen de una sola empresa, con uno de los mayores equipos de seguridad del mundo y mucho que perder.

Eso no hace a .NET inmune. En octubre de 2025, Microsoft corrigió un fallo crítico en el servidor web de ASP.NET Core. La diferencia está en lo rápido que llegó la corrección, lo claro que se comunicó y lo fácil que resultó aplicarla.

Cómo se mantiene al día Umbraco

Umbraco sigue de cerca a .NET. Sus versiones de soporte a largo plazo coinciden con las de .NET, así que Umbraco 17 funciona con .NET 10. Umbraco HQ publica sus avisos de seguridad abiertamente en GitHub y lanza las correcciones como versiones de parche, que normalmente se aplican en minutos sin una actualización completa.

Si usas una versión antigua que ya no recibe correcciones, lee Tu actualización de Umbraco, planificada en cinco pasos.

Por qué ser más pequeño ayuda

Umbraco hace funcionar muchos menos sitios web que WordPress. Eso no garantiza la seguridad, pero cambia la economía de un ataque. Los ataques automatizados van a donde están los números. Además, los sitios Umbraco suelen crearlos agencias y equipos de desarrollo internos, usan un conjunto más reducido de paquetes bien mantenidos y normalmente se gestionan con un contrato de soporte. Menos sitios, menos plugins y más gente vigilando hacen un objetivo más pequeño.

En la era de la IA, todas las plataformas están expuestas

Las herramientas de IA ya ayudan a los atacantes a leer un parche de seguridad, entender qué corrige y escribir un exploit funcional, a veces en cuestión de horas. Los fallos de PHP siguieron ese patrón: los detalles se filtraron antes de la corrección y poco después circulaban ejemplos funcionales. El margen entre la publicación de una corrección y el inicio de los ataques se ha reducido casi a cero, y eso vale tanto para .NET y Umbraco como para cualquier otra plataforma.

Da por hecho que toda vulnerabilidad se explotará el mismo día en que se anuncie, uses la plataforma que uses.

Lo que hacemos nosotros y lo que puedes hacer tú

Pon Cloudflare delanteUn firewall de aplicaciones web filtra los ataques antes de que lleguen a tu servidor. Cloudflare ya detectaba y filtraba tráfico de ataque contra estos fallos de PHP, y actualiza sus reglas gestionadas rápidamente tras los anuncios importantes.

Cierra la puerta lateralCon Cloudflare en marcha, bloquea el tráfico directo a la dirección IP de tu servidor para que los atacantes no puedan rodearlo.

Parchea con un calendarioAplica las actualizaciones de .NET y Windows cada mes, y las versiones de parche de Umbraco en cuanto salgan. No las acumules para la siguiente actualización.

Usa versiones con soporteLas versiones de .NET y Umbraco sin soporte no reciben correcciones. Planifica las actualizaciones antes de que termine el soporte, no después.

Usa menos paquetesCada paquete es código en el que tienes que confiar. Elimina lo que ya no uses.

Protege el back officeUsa autenticación de dos factores para todos los editores y restringe el acceso al back office de Umbraco por dirección IP o con Cloudflare Access cuando sea posible.

Vigila y haz copias de seguridadSupervisa la actividad inusual y guarda copias de seguridad probadas fuera del servidor, para poder recuperarte rápido si algo se cuela.

Si usas WordPress u otros sitios PHP

Actualiza PHP ya a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o pide a tu proveedor de hosting que confirme que lo ha hecho. Si tu sitio usa una versión antigua de PHP que ya no tiene soporte, no hay corrección y es momento de planificar una migración.

Si quieres una revisión de seguridad de tu sitio Umbraco, ayuda para poner Cloudflare delante o asesoría para migrar desde una plataforma sin soporte, escríbenos.