Ya estamos oficialmente libres de PHP. Esto es lo que octubre nos enseñó (por ahora)

La semana del 19 al 24 de octubre de 2026, de lunes a sábado, trajo una sucesión constante de noticias graves de seguridad en todo el sector. Si te la perdiste, nuestro repaso de esa semana cubre los detalles. La versión corta: en varios casos, los atacantes se movieron antes que las correcciones.

Una semana así no nos manda de vuelta a la mesa de diseño, pero sí afila las líneas que ya están trazadas en ella. Una cosa es sostener un principio y otra observar, caso por caso, qué ocurre allí donde ese principio falta. Por eso, en lugar de enumerar pasos técnicos, queremos explicar los principios con los que trabajamos, porque para ti como cliente el enfoque importa más que cualquier actualización concreta. Uno de esos principios acaba de alcanzar su hito: ya estamos oficialmente libres de PHP.

¿Por qué parchear después del hecho es una carrera perdida?

Durante años, el consejo estándar era simple: parchea rápido y estarás a salvo. La tendencia ya iba en contra de ese consejo. El equipo Mandiant de Google midió el tiempo medio entre que una vulnerabilidad se hace conocida y su explotación: 63 días en 2018 a 2019, 32 días a lo largo de 2021 y 2022, y cinco días en 2023, promediado tras eliminar los valores atípicos.

Cinco días es la cifra de 2023, antes de que las herramientas de IA pasaran a formar parte del trabajo cotidiano con software. Este mes nos dio una medición fresca de la carrera, tomada desde tres puntos de observación distintos en torno a la divulgación de PHP2Shell del 21 de octubre de 2026.

El equipo de inteligencia de amenazas de Amazon vio un intento de explotación de PHP2Shell el 17 de octubre, cuatro días antes de la divulgación pública, y afirma que, una vez levantado el embargo y publicado el parche, aparecieron más exploits de prueba de concepto en cuestión de horas. F5 Labs vio los primeros escaneos de PHP2Shell más de cinco horas antes de que se publicaran los dos CVE, y a las pocas horas de la divulgación sus sensores registraban miles de intentos de explotación. El CEO de Cloudflare, Matthew Prince, dijo el 22 de octubre que Cloudflare vio miles de intentos antes del anuncio, decenas de miles en los 45 minutos posteriores, cientos de miles en dos horas y millones para cuando publicó su mensaje. Eran intentos, no intrusiones confirmadas, pero muestran con qué rapidez se estaban probando las puertas: la ventana ahora se mide en minutos y horas, y para algunos se cerró antes incluso de que existiera el parche.

La explotación antes de que exista corrección alguna tampoco es una rareza. En 2023, el 70% de las vulnerabilidades explotadas que Mandiant rastreó, 97 de 138, se explotaron como días cero, es decir, antes de que existiera corrección alguna.

Si la explotación puede empezar antes de que haya un parche disponible, y llegar en masa a los pocos minutos de haberlo, entonces parchear, por disciplinado que sea, no puede ser todo el plan. Un defensor que depende solo de eso ha entrado en una carrera que a menudo se decide antes de empezar. Así que asumimos que la carrera a veces se perderá, y diseñamos para la derrota. Esa suposición se convierte en tres preguntas. Mientras un fallo está abierto, ¿cuánto de nuestros sistemas puede ser golpeado? Si algo es golpeado, ¿cuánto se puede perder? Y una vez que existe una corrección, ¿con qué rapidez podemos recuperarnos y cerrar la brecha? Cada principio que sostenemos responde a una de esas preguntas, y todo lo que sigue está organizado en torno a ellas.

¿Por qué eliminamos software en lugar de parchear a su alrededor?

Empecemos por la primera pregunta, cuánto puede ser golpeado. Toda organización acumula software que ha envejecido mal: herramientas cuyos mantenedores se han ido, componentes atascados en versiones viejas porque algo más depende de ellos, código que nadie quiere tocar. La respuesta habitual es envolver ese software en soluciones provisionales y reglas de cortafuegos, y esperar lo mejor.

Nosotros lo vemos de otra manera. El software que no se puede mantener actualizado se elimina, no se parchea a su alrededor. No lo mantenemos vivo con arreglos temporales, porque un arreglo temporal sobre código sin mantenimiento es una promesa que acabará rompiéndose. O un componente puede actualizarse durante todo el tiempo que lo ejecutemos, o no se ejecuta en absoluto.

¿Por qué fallan las soluciones provisionales? Porque una solución provisional solo bloquea los fallos que ya se conocen. El software sin mantenimiento no deja de tener debilidades el día en que sus mantenedores se marchan. Los investigadores y los atacantes siguen encontrando otras nuevas, año tras año, y ya no queda nadie para escribir las correcciones. Cada descubrimiento obliga a otra regla, otro filtro, otra capa atornillada sobre la anterior, y la pila se vuelve más frágil con cada añadido. Tarde o temprano aparece un fallo que ninguna capa externa puede filtrar, o dos capas interfieren entre sí, y la protección cede en silencio. Una solución provisional compra tiempo, y en código abandonado no hay nada útil en lo que gastar ese tiempo, porque el problema de fondo nunca va a arreglarse.

Vuelve a pensar en la carrera de antes, que ahora se corre en minutos y horas. Contra software mantenido, la carrera es brutalmente corta, pero al menos se puede correr. Contra software abandonado, no hay carrera alguna, porque la corrección que debería ponerle fin nunca llegará. Esto suena obvio por escrito. En la práctica es el camino más difícil, ya que eliminar algo suele significar reconstruir lo que dependía de ello. Creemos que ese coste merece la pena. Un atacante no puede explotar una debilidad en un sistema que ya no existe.

¿Cómo es en realidad una superficie de ataque pequeña?

La eliminación es la forma más contundente de reducir lo que puede ser golpeado. El hábito más amplio que hay detrás tiene nombre técnico: mantener pequeña la superficie de ataque. La superficie de ataque es una idea sencilla, la suma de cada lugar donde un atacante podría probar una llave en una cerradura. Cada servicio expuesto, cada biblioteca de terceros, cada plugin es una cerradura más que defender. Nuestra definición de buena seguridad empieza aquí: el código más fuerte es el que no ejecutas, y los datos más seguros son los que nunca almacenaste.

Piensa en lo que es realmente una biblioteca o un plugin de terceros. Cuando un desarrollador lo incorpora, está confiando en un desconocido, a menudo un voluntario sin paga, para mantener ese código seguro durante todo el tiempo que se ejecute. La biblioteca necesita sus propias actualizaciones, sus propias correcciones de seguridad, su propio mantenedor prestando atención. Si ese mantenedor pierde el interés, cambia de trabajo o simplemente deja de responder, el código sigue funcionando, pero ya nadie lo vigila. Un fallo encontrado a partir de ese momento queda abierto para siempre, que es el problema del abandono de la sección anterior entrando por una puerta lateral. Multiplica esto por los muchos componentes de los que depende una aplicación típica y el panorama queda claro. Cada dependencia es una pequeña promesa hecha por alguien a quien nunca has conocido, y algunas de esas promesas caducan en silencio. Ejecutar menos significa deber tu seguridad a menos desconocidos.

Los sistemas en los que inicias sesión, a través de los que pagas y con los que hablan nuestras aplicaciones están escritos en Go. PHP ha desaparecido, y con él la larga cola de bibliotecas, plugins y dependencias que las aplicaciones PHP tienden a arrastrar.

Elegimos Go para nuestros sistemas más críticos porque responde al problema de las dependencias en el propio lenguaje. Go es seguro en memoria: el lenguaje gestiona la memoria por el programador, lo que descarta toda una clase de errores como los desbordamientos de búfer, y la CISA (la agencia de ciberseguridad de Estados Unidos) incluye a Go entre los lenguajes seguros en memoria en The Case for Memory Safe Roadmaps. Esa clase es mayor de lo que parece: el proyecto Chromium encuentra que alrededor del 70% de sus errores graves de seguridad son problemas de seguridad de memoria. La biblioteca estándar de Go cubre buena parte de lo que necesita un servicio web, incluida la criptografía, así que un servicio en Go necesita menos paquetes de terceros, lo que significa menos de esas promesas de desconocidos. La criptografía se toma tan en serio que el propio módulo de criptografía de Go está validado bajo el estándar FIPS 140-3 del gobierno de Estados Unidos, certificado CMVP n.º 5247. Y cuando un fallo sí aparece en el ecosistema más amplio, el equipo de seguridad de Go mantiene una base de datos de vulnerabilidades, y su herramienta govulncheck informa solo de las vulnerabilidades en el código que un programa realmente llama, lo que mantiene las alertas con poco ruido y accionables.

Eso importa por lo extendidas, y lo antiguas, que son las instalaciones de PHP. W3Techs informa de que PHP se usa en el 69,2% de todos los sitios web cuyo lenguaje de servidor conoce, con un 26,6% de los sitios PHP todavía en PHP 7 y un 7,7% en PHP 5, medido el 27 de octubre de 2026. El propio proyecto PHP da soporte a cada rama de versiones durante dos años de correcciones de errores y de seguridad, y luego dos años más solo de correcciones de seguridad críticas. PHP 7 y PHP 5 están más allá de todo eso. Una gran parte de la web funciona sobre código que sus propios creadores ya no protegen, que es la carrera perdida de la primera sección, pero entrando en ella voluntariamente.

Nuestro sitio web son páginas estáticas construidas de antemano, sin código de servidor que las genere cuando lo visitas. Una página que es solo un archivo tiene muy poco que atacar. A la pregunta de cuánto puede ser golpeado, esta es nuestra respuesta: lo menos que podamos conseguir.

¿Qué datos guardamos sobre ti?

Una superficie pequeña limita cómo podría entrar un atacante. La segunda pregunta plantea qué encontraría si, algún día, uno de ellos entrara de todos modos. Nuestra respuesta es hacer que el hallazgo sea lo más aburrido posible: menos datos, guardados durante menos tiempo.

Solo pedimos lo necesario para gestionar una cuenta. Nuestra política de privacidad lo enumera con claridad: un nombre de usuario, una dirección de correo electrónico, una contraseña cifrada y la dirección IP usada al registrarse. Los pagos pasan por procesadores de pago externos, así que los datos de tu tarjeta viven con especialistas cuyo negocio entero consiste en protegerlos, no con nosotros.

También estamos endureciendo lo que ocurre con el tiempo. Las cuentas antiguas sin uso se eliminarán automáticamente. Los datos que no existen no pueden filtrarse, no pueden robarse y no pueden exigirse. Una cuenta que abandonaste hace años no debería quedarse por ahí como un riesgo con tu nombre encima. Si la carrera alguna vez se pierde en nuestro lado de la valla, el premio sobre la mesa debería ser lo más pequeño que podamos hacerlo.

La misma lógica se aplica más allá de nosotros, porque otras empresas también pierden carreras. Muchas de las filtraciones que sufre la gente ocurren en tiendas, foros y servicios en los que se registraron hace mucho. Por eso ofrecemos alertas de filtraciones de datos: nuestro Data Breach Scanner comprueba las filtraciones de datos conocidas en busca de tu dirección de correo y te avisa por email si aparece, para que puedas cambiar las contraseñas antes de que la filtración se use de forma abusiva.

¿Qué pasa si algo se rompe de todos modos?

La tercera pregunta tiene dos mitades: recuperarse y cerrar la brecha. Primero, la recuperación. Una buena planificación de seguridad asume los malos días. El hardware falla, los proveedores cambian y a veces lo correcto es sencillamente alejarse de una pieza de infraestructura.

Nuestros sistemas están construidos para poder recrearse o trasladarse a otro lugar si hace falta. Para ti, esto significa que un fallo, o una ubicación que ya no cumple nuestros estándares, no tiene por qué convertirse en una interrupción larga, porque el sistema afectado puede reconstruirse o moverse. Si alguna vez concluimos que un entorno ya no es lo bastante bueno, podemos abandonarlo en lugar de negociar con él.

La resiliencia no es una cualidad dramática. Se manifiesta sobre todo en que las cosas siguen funcionando, y en este marco es lo que evita que una ronda perdida se convierta en una temporada perdida.

¿Con qué rapidez llegan las correcciones a nuestros sistemas?

La otra mitad de la tercera pregunta es la velocidad. Nada de lo anterior elimina la necesidad de parchear; cambia lo que el parcheo tiene que cargar. Con una superficie pequeña y software actualizado, aplicar una corrección es rutina y no un proyecto.

Nuestra regla es simple: las actualizaciones salen en cuanto existen las correcciones. Las mediciones de octubre explican por qué. Cuando los intentos de explotación llegan a los pocos minutos y horas de publicarse una corrección, y a veces antes de que exista, una corrección que espera guardada no protege a nadie. Tratamos un parche publicado como un pistoletazo de salida. El tramo entre que una corrección existe y que una corrección se aplica es la única parte de la carrera que un defensor controla por completo, así que es la parte que nos negamos a ceder.

Y como nuestra pila es pequeña, sencillamente hay menos que parchear, que es donde se encuentran las tres preguntas: cuanto menos hay que golpear, más rápido se cierra la brecha.

Puestas una junto a otra, las preguntas y los principios que las responden quedan así:

¿Qué significa todo esto para ti?

Significa que las tres preguntas tienen respuestas que puedes notar. Hay menos código entre tú y tu cuenta, así que hay menos lugares donde algo puede salir mal. Existen menos datos tuyos, así que incluso el peor caso expone poco. Y nuestros sistemas pueden reconstruirse, así que un mal día para nosotros no tiene por qué convertirse en una interrupción larga para ti.

Seremos honestos sobre el límite de todo esto. La carrera con la que empezamos no se puede ganar de forma fiable, ni nosotros ni nadie, porque a veces los fallos se explotan antes de que nadie sepa que existen, y ninguna arquitectura cambia eso. Ningún proveedor puede prometer riesgo cero, y quien lo haga está vendiendo confianza en lugar de seguridad. Lo que sí podemos prometer es la forma de una pérdida: pocas vías de entrada, poco que llevarse y un camino rápido de vuelta. No podemos garantizar que ganaremos cada ronda de la carrera. Hemos construido para que perder una te cueste lo menos posible, y creemos que esa promesa, cumplida con constancia, vale más que una audaz que no puede cumplirse.

La seguridad también es un esfuerzo compartido. La configuración más fuerte que podamos construir sigue beneficiándose de buenos hábitos por tu parte, así que si quieres pasos prácticos, empieza por nuestra guía sobre cómo aumentar tu seguridad online. Y si estás eligiendo una VPN, con nosotros o con cualquier otro, pregunta al proveedor cómo piensa, no solo qué vende. La respuesta te dice mucho sobre cómo irán tus semanas tranquilas, y las ruidosas.