Cada pocas semanas aparece una vulnerabilidad crítica con nombre propio y medio internet en vilo. La última se llama PHP2Shell: ejecución remota de código sin autenticación en el propio intérprete de PHP, exploits públicos a las pocas horas y sin mitigación posible más que actualizar.

Si lo que necesitas es saber si te afecta y qué hacer ya con lo de PHP y Node.js, empieza por el artículo de Pedro: Vulnerabilidades PHP y Node.js: cómo saber si te afecta y qué hacer ya.

Este artículo va de otra cosa: del patrón que hay detrás y de por qué la seguridad en el código sigue fallando por los mismos sitios.

Quince años del mismo guion

Lo de PHP no es un caso aislado, ni mucho menos. Llevamos quince años viendo la misma película con actores distintos.

En 2008, Heartland caía por una inyección SQL. En 2016, Uber exponía credenciales en un repositorio de GitHub. En 2017, WannaCry paralizaba medio mundo con un fallo para el que el parche llevaba meses publicado. En 2021, Log4Shell descubría que una librería que casi nadie sabía que usaba estaba en todas partes. En 2023, MOVEit volvía a lo de siempre: inyección SQL. En 2024, xz-utils puso a punto de llegar a las distribuciones estables una puerta trasera en pleno open source. En 2025, Shai-Hulud demostró que un gusano podía propagarse por npm. Y en 2026, PHP2Shell: esta vez, el propio runtime.

Inyección, secretos expuestos, parches tardíos y dependencias de terceros. Los mismos cuatro problemas, cada vez con menos margen para reaccionar: los exploits públicos ya aparecen en cuestión de horas, no de días.

Y el fondo no deja de crecer. Solo en España, el INCIBE gestionó 122.223 incidentes en 2025, un 26% más que el año anterior, y detectó 237.028 sistemas con vulnerabilidades relevantes. La técnica dominante sigue siendo la de siempre: el phishing. (Fuente: INCIBE, Balance de Ciberseguridad 2025.)

Hay además una cifra que duele a cualquier equipo con código en producción: corregir un defecto en fase de diseño cuesta 1; en implementación, 6,5; en pruebas, 15; y en producción, hasta 100. Las cifras son orientativas (se atribuyen habitualmente al IBM Systems Sciences Institute y su origen exacto está discutido), pero la tendencia es la que importa: cada semana que un problema vive dentro de tu código, la factura sube.

Seguridad en el código: menos pánico, más blindaje

Ante este panorama hay dos tentaciones. Una es el pánico: vivir pendiente de cada alerta, apagar fuegos a ciegas y parchear sin criterio. La otra es el conformismo: no tocar nada porque funciona, que es como acaban la mayoría de los incidentes que luego salen en las noticias.

Ninguna de las dos funciona. Lo que funciona es el blindaje: saber qué tienes en producción, decidir por dónde empezar y convertir la seguridad en un hábito del día a día del equipo, no en una fase final del proyecto. Y eso no se improvisa el día que salta la alarma: se construye antes.

Para saber por dónde estás, seis preguntas incómodas.

Seis preguntas incómodas

1. ¿Cuántos de tus servidores ejecutan PHP? ¿En qué versión está cada uno? ¿Quién se encarga de actualizarlos, y en cuánto tiempo? Si no puedes responder en cinco minutos, nadie puede.
2. ¿Tu pipeline se defiende solo en cada commit, o depende de que alguien se acuerde de pasar el escáner?
3. ¿El mayor riesgo está en tu código, o en lo que tu código importa? ¿Sabes qué arrastra detrás cada dependencia, cada imagen, cada extensión?
4. Tu asistente de IA es un agente, y tiene tus permisos. ¿Sabes qué paquetes instala y qué ejecuta en tu nombre?
5. ¿Podría cualquiera suplantar el correo de tu dominio? ¿Qué puertos de tus contenedores están abiertos a internet sin que lo sepas?
6. Y cuando pase, porque pasará: ¿quién hace qué? ¿Está escrito y probado, o se decidirá en pleno ataque?

Si las respuestas te salen solas, enhorabuena: estás en la minoría. Si alguna te ha hecho dudar, el 17 de noviembre tienes dónde escuchar las nuestras.

Lo contamos en persona

El martes 17 de noviembre a las 18:30, en La harinera, VGC (Valencia), celebramos el Sugarfree #5: Menos pánico, más blindaje. Mángel contará, sin humo, cómo nos defendemos en el día a día: cómo se cuelan este tipo de vulnerabilidades por debajo del radar, qué hacemos para que la seguridad esté desde el minuto cero y qué hemos visto en servidores reales. Después, casos sobre la mesa para analizarlos en directo: los nuestros y los que traigáis. Y para cerrar, picoteo, cerveza y networking. Invita Secture.

Si cada semana aparece una vulnerabilidad nueva en tu feed y no sabes por dónde empezar, saldrás con criterio para decidir qué hacer. Sin humo.

Reserva tu entrada aquí.

Todo es hackeable, pero nos ocupamos de que sea extremadamente difícil hacerlo.