Cualquier lector despistado que abra terminal2shell.com estos días encuentra un aviso con mayúsculas rojas: explotación activa, unos dos mil millones de dispositivos afectados y ningún parche disponible. Debajo, una lista de sistemas vulnerables que incluye macOS, todas las distribuciones de Linux, Windows, FreeBSD, el VT100 de 1978 y el puerto de consola del router. Y una excepción: Microsoft Paint no está afectado.
No hay ninguna vulnerabilidad CVE-2026 detrás de esa página. Lo que hay es una sátira bien construida sobre cómo el sector nombra, documenta y vende los fallos de seguridad, y funciona porque el lector reconoce el formato antes de leer el chiste. La página lo admite en la sección de cronología: en 2026 los investigadores avisaron a todos los fabricantes y «los fabricantes respondieron que eso es lo que hace una terminal».
El texto describe la «vulnerabilidad» con precisión burocrática: al abrirse una terminal, se lanza un proceso de shell conectado directamente al teclado, y desde ahí el atacante puede enviar comandos con los privilegios del usuario. Los pasos de explotación son dos, y el segundo no existe: abrir una terminal es todo el exploit, y el teclado del atacante es el mismo que el de la víctima. El resto de la página mantiene el registro con una seriedad que hace el chiste más eficaz.
Un simple chiste, para golpear el ecosistema
El humor se sostiene en un detalle real del ecosistema. La familia de fallos bautizada con el sufijo *2Shell (Node2Shell, PHP2Shell, Plex2Shell, Able2Shell) tiene una característica común que casi nadie subraya: todas las pruebas de concepto publicadas empiezan con alguien abriendo una terminal y tecleando un comando. Los casos de la semana lo confirman: SSHole en OpenSSH, Plex2Shell en NAS de QNAP y PHP2Shell con Fragnesia.
terminal2shell convierte esa coincidencia en premisa. Si todos los exploits de la familia dependen de que el investigador tenga un shell, entonces el shell es el fallo, y los demás son variaciones de la misma condición previa. La página lo dice con la cara seria de un informe de impacto: «es la vulnerabilidad debajo de las vulnerabilidades y la única que viene con un shell gratis antes de que empiece el ataque».
La cronología de la broma recorre la historia de Unix para entregar el remate. En 1971 el código vulnerable viaja en la versión 1 con el shell de Thompson. En 1979 llega el shell de Bourne y conserva el problema por compatibilidad. En 1989 aparece Bash y el nombre, dice la página, confirma que el ataque es intencionado.
Las mitigaciones que no existen
La sección de controles compensatorios es lo más afilado del sitio. No abrir terminales es la más eficaz, aunque advierte de que muchos desarrolladores abren terminales «por trabajo», algo que los equipos de seguridad deberían considerar una señal de alarma. Cerrar la terminal justo después de abrirla es una mitigación parcial: reabrirla reintroduce la vulnerabilidad, y la página lo reconoce con la misma seriedad fingida que el resto.
Las demás siguen el mismo registro. Escribir más despacio reduce los comandos por minuto y, por tanto, el caudal del ataque. Quitar el teclado es efectivo, pero el teclado en pantalla es un bypass conocido. Poner `SHELL=/bin/false` remedia el problema por completo y también la capacidad de usar el ordenador.
Esa última línea es la que explica por qué el texto funciona como crítica y no solo como broma. La seguridad de manual que exige desactivar la funcionalidad para eliminar el riesgo produce recomendaciones absurdas cuando el riesgo es el propio funcionamiento del sistema.
Un sector que está abarrotado de problemas
La sátira acierta porque el terreno está abonado. En 2026 se publicaron tantos fallos críticos con nombre propio y logotipo que la marca dejó de distinguir lo grave de lo rutinario: un dominio nuevo, un logo y un nombre terminado en número y sustantivo ya no comunican urgencia, comunican campaña.
El formato de divulgación se ha convertido en un ejercicio de marketing. Un investigador que registra un dominio antes de notificar a los fabricantes consigue cobertura, y una empresa que publica su propio *2Shell consigue que la conversación gire en torno a su producto. La página se ríe de eso con una frase que resume el mecanismo: «todo cero-día serio necesita un logo, un dominio y un nombre terminado en un número seguido de un sustantivo».
También hay una lectura menos cómoda. La broma funciona porque el lector, técnico o no, ya sabe que muchos de esos avisos exageran el impacto real para conseguir atención, y porque el volumen de parches generado por la detección automática de fallos ha vuelto difícil distinguir un hallazgo relevante de un ruido bien presentado.
Así que el mensaje es claro: si todos los fallos *2Shell, detectados hasta ahora empieza en la shell/terminal, quizás sea hora de dejar de usarla, aunque si le dices eso a tu jefe, seguramente termines en el paro, o peor, con una IA haciendo tu trabajo, y manteniendo el canal abierto para nuevas vulnerabilidades en el futuro.
