Cuando publicamos esta guía en septiembre de 2014, Shellshock acababa de detonar en internet. Apenas 48 horas después de la divulgación pública del fallo el 24 de septiembre, escáneres automatizados ya barrían medio internet buscando servidores vulnerables. Doce años después, el bug catalogado como CVE-2014-6271 sigue siendo material de manual de seguridad: afectaba a cualquier sistema que ejecutara Bash en su versión 1.14 a 4.3, lo que en 2014 significaba prácticamente todo Linux y todo macOS. Esta actualización repasa qué fue Shellshock, cómo se detectaba en su día con la prueba de una sola línea de Bash que muchos administradores recordamos de memoria, y por qué en 2026 sigue apareciendo en escaneos de seguridad sobre routers domésticos e IoT abandonados. Si te interesa el contexto más amplio, en Wwwhatsnew tenemos un análisis sobre por qué las vulnerabilidades en código abierto se han duplicado en los últimos años.

Qué fue Shellshock y por qué fue tan grave

Shellshock no era un bug elegante: era una herida abierta. El fallo, descubierto el 12 de septiembre de 2014 por Stéphane Chazelas y mantenido en secreto durante doce días para preparar parches coordinados, permitía ejecutar código arbitrario en cualquier sistema cuya versión de Bash procesara variables de entorno con definiciones de función especialmente preparadas. Bastaba una cadena con la forma de una función vacía seguida de comandos para que el intérprete los ejecutara con los permisos del proceso anfitrión. En servidores web con CGI antiguos, eso significaba ejecución remota como root con apenas una petición HTTP.

El alcance real del problema es lo que lo hizo histórico. Bash estaba (y está) en cualquier servidor Linux con interfaz CGI, en clientes DHCP que invocan scripts de configuración, en sistemas de impresión, en electrodomésticos conectados con firmware Linux y en macOS. Shellshock encadenaba un identificador CVE principal, CVE-2014-6271, con cinco más descubiertos en los días siguientes: CVE-2014-7169, 7186, 7187, 6277 y 6278. Cada uno cubría un fallo lateral en el mismo subsistema.

Cómo se detectaba y mitigaba en 2014

La prueba que circuló en todos los foros de administración de sistemas era brutalmente simple. Bastaba escribir en una terminal Bash una variable de entorno con definición de función vacía seguida de un comando inocuo, ejecutar bash -c «echo hola» y ver si el sistema imprimía la palabra que solo aparecería si la variable se procesaba. Quien obtenía la palabra inocua, vulnerable. Quien obtenía un mensaje de aviso de Bash, parcheado.

La solución dependía del sistema. Las distribuciones Linux mayoritarias (Debian, Ubuntu, CentOS, Red Hat, SUSE, Arch) publicaron actualizaciones del paquete bash en menos de 48 horas, distribuidas vía apt-get o yum según la familia. Apple tardó cinco días en sacar un parche oficial para macOS Mavericks, Mountain Lion y Lion, lanzado el 29 de septiembre de 2014. Quien no quería esperar al parche oficial podía recompilar Bash desde el código fuente del proyecto GNU, una opción cómoda solo si dominabas la línea de comandos. Para entender mejor las órdenes que se usaban en aquellos parches, herramientas como explainshell, una web para aprender las órdenes del shell de Linux, siguen siendo un recurso útil para descifrar comandos heredados.

Por qué Shellshock sigue importando en 2026

La gracia macabra de Shellshock es que doce años después seguimos viéndolo en informes de pentesting. Las distribuciones modernas y macOS están parcheadas desde finales de 2014, pero el fallo sigue activo en dos territorios concretos: routers domésticos antiguos con firmware no mantenido, donde la base Linux nunca recibió actualización del paquete bash; y dispositivos IoT industriales con vida útil de quince años cuyo proveedor desapareció antes de publicar parche. Honeypots como los que mantiene la SANS Internet Storm Center registran cada mes intentos de explotación que prueban variantes de Shellshock contra puertos 80 y 8080.

El otro motivo por el que conviene recordarlo es didáctico. Shellshock es el ejemplo de manual del riesgo asociado a las dependencias invisibles del software libre: durante 25 años, todo Unix ejecutó Bash sin que casi nadie revisara la lógica de procesado de variables de entorno. La conversación contemporánea sobre los tipos de malware que pueden infectar dispositivos hoy sigue arrastrando ese mismo patrón estructural.

Actualización a 26 de abril de 2026

El fallo en sí está resuelto desde 2014 en cualquier sistema con mantenimiento activo, pero el ruido de fondo no ha desaparecido. Los datos públicos de Shadowserver Foundation mostraban a comienzos de 2026 que aún se detectan unas 8.500 IPs únicas vulnerables a CVE-2014-6271 al mes, casi todas en routers de consumo y cámaras IP de marcas que ya no existen. CISA, la agencia federal estadounidense de ciberseguridad, mantiene Shellshock en su Known Exploited Vulnerabilities Catalog desde 2021 con plazo de remediación obligatorio para entidades federales. La recomendación práctica para 2026: si administras un parque de máquinas heredadas, lanza un escaneo trimestral con herramientas tipo Nessus o OpenVAS, que mantienen plugins específicos para Shellshock. Y si eres usuario doméstico con un router de hace una década, considera renovarlo: doce años es bastante más de lo que cualquier fabricante recomienda.

Mi valoración

Llevo cubriendo seguridad informática en Wwwhatsnew desde 2008 y Shellshock fue, junto con Heartbleed seis meses antes, uno de esos episodios que reordenan tu manera de ver el software libre. La narrativa popular de aquellos meses fue: open source también tiene fallos, pero al menos los podemos auditar. La realidad menos cómoda es: los podemos auditar, pero llevábamos décadas sin hacerlo. Bash había procesado mal esas variables de entorno desde 1989 y nadie se había parado a revisarlo.

Tras parchear personalmente unos 40 servidores entre el 24 y el 26 de septiembre de 2014, lo que recuerdo es la sensación de inevitabilidad. En mi setup desde 2024 mantengo escaneos automáticos diarios de mis máquinas con un script propio basado en oscap que avisa por Telegram en cuanto aparece un CVE crítico aplicable. Esa rutina nació de Shellshock: la lección es que cualquier capa de software invisible puede ser, mañana, el vector de un fallo trivial de explotar. Para un repaso al panorama actual, en Wwwhatsnew analizamos por qué una antigua vulnerabilidad afectó a varias distribuciones de Linux en 2022 reproduciendo el patrón de Shellshock siete años después.

Preguntas frecuentes

¿Mi Linux o Mac actual sigue siendo vulnerable a Shellshock?

Casi con toda seguridad no. Cualquier distribución Linux con soporte activo y cualquier macOS desde la versión 10.10 Yosemite incluyen versiones de Bash superiores a la 4.3 con todos los parches contra CVE-2014-6271 y derivados aplicados de fábrica. Para verificarlo, abre una terminal y consulta la versión de Bash con bash –version: si ves 4.3 patch 30 o superior, o cualquier rama 5.x, estás cubierto. El riesgo real está en routers domésticos de antes de 2014, NAS olvidados y dispositivos IoT industriales sin mantenimiento.

¿Cómo puedo escanear mi red en busca de equipos vulnerables a Shellshock?

Las opciones más fiables en 2026 son Nessus Essentials (gratuito hasta 16 IPs, después en torno a 3.290 euros al año), OpenVAS en su versión Community y Nuclei con la plantilla CVE-2014-6271. Cualquiera de los tres devuelve un informe con la dirección IP, el puerto vulnerable y el comando de explotación de prueba. Para un usuario doméstico con un único router, basta con consultar el panel de administración del fabricante y comprobar la fecha del firmware: si es anterior a finales de 2014 y el modelo ya no recibe actualizaciones, asume que es vulnerable y reemplázalo.

¿Por qué un fallo de 2014 sigue apareciendo en estadísticas de exploits en 2026?

Por la longevidad del hardware barato. Los routers domésticos tienen una vida media efectiva de ocho a doce años en muchas casas, y los dispositivos IoT industriales con base Linux pueden seguir conectados hasta veinte años. Mientras existan equipos sin parche y con un servidor web embebido, los escáneres automáticos seguirán probando Shellshock como primer vector porque su explotación es trivial y devuelve ejecución remota directa. Es el mismo motivo por el que Heartbleed o EternalBlue siguen vivos en honeypots: internet no olvida, solo acumula.