Odiseo

Durante años, la respuesta a «¿se puede jugar en Linux?» era «sí, pero…». Hoy es otra: miles de juegos de Windows, también los juegos 3D más exigentes, se instalan y se juegan en Linux con un clic, sin configurar nada. Hay distribuciones pensadas solo para jugar, la consola portátil de Valve lleva Linux dentro y la cuota de jugadores en Linux no para de crecer. Te contamos cuáles son las mejores distribuciones para jugar en Linux, qué ganas frente a Windows y qué juegos todavía no funcionan.

Primero, lo básico. Linux no es un único sistema, sino una familia: cada «distribución» es una versión completa, con su propio estilo, sus programas y su forma de actualizarse. Todas son gratuitas. El gran cambio llegó con Proton, una capa de compatibilidad que Valve incluye en Steam y que traduce, al vuelo, lo que un juego de Windows le pide al sistema. El jugador no ve nada de esto: pulsa «Jugar» y el juego arranca. Según Valve, más de 18,000 juegos funcionan así.

El empujón definitivo fue la Steam Deck, la consola portátil de Valve, que usa SteamOS, su propio Linux. Para que los juegos funcionaran en ella, Valve y la comunidad mejoraron Proton, los controladores gráficos y el soporte de mandos, y esas mejoras llegan a todas las distribuciones. En la encuesta de Steam de septiembre de 2026, Linux ya suma el 3.05 % de los jugadores: parece poco, pero son millones de personas, y las distribuciones más usadas son, precisamente, las pensadas para jugar.

Las seis mejores distribuciones para jugar, comparadas

• Bazzite, la mejor para empezar: es lo más parecido a una consola instalada en tu PC. Trae Steam listo, los controladores de las tarjetas Nvidia ya incluidos (el dolor de cabeza clásico en Linux) y Lutris, para jugar también a lo que tengas en Epic, GOG, EA o Ubisoft Connect. Su escritorio, KDE, recuerda mucho al de Windows, con barra de tareas y menú de inicio, y puede arrancar directamente en el Gaming Mode de la Steam Deck, cómodo para jugar con mando desde el sofá. Su gran ventaja: si una actualización estropea algo, vuelves a la versión anterior, porque guarda las imágenes del sistema durante 90 días. Funciona en PC de sobremesa, portátiles y consolas de mano.
• SteamOS, la de la Steam Deck: el sistema de Valve, el más usado en Linux para jugar después de CachyOS (el 0.53 % de todos los usuarios de Steam), casi todo gracias a la Steam Deck y a otras consolas portátiles. Es una experiencia de consola pura: enciendes y estás en Steam. La propia Valve avisa de que no debe considerarse un sustituto del sistema de escritorio, así que, para tu ordenador de siempre, mejor Bazzite, que copia su Gaming Mode.
• CachyOS, la más rápida: la distribución de Linux más usada en Steam (0.55 %). Recompila todos sus programas para sacar partido a los procesadores modernos y usa un kernel (el núcleo del sistema) ajustado para que todo responda rápido. Tiene un instalador gráfico guiado, pero se actualiza constantemente y, cuando algo falla, ayuda saber un poco de Linux. Ideal si te gusta trastear y quieres exprimir cada fotograma.
• Linux Mint, la más sencilla para el día a día: la favorita de quien viene de Windows y quiere un ordenador para todo: navegar, ofimática y, además, jugar. Todo funciona «de serie», no recoge datos y puedes probarla desde una memoria USB sin instalar nada. No está pensada solo para jugar, pero instalas Steam desde su tienda de programas y listo. Con tarjetas Nvidia hay que elegir el controlador en un asistente, en un par de clics.
• Pop!_OS, la de System76: la creó un fabricante de ordenadores con Linux, y se nota: promete acceder a tu biblioteca de Steam «sin pelearte con los controladores». No recoge ningún dato del usuario y es compatible con todo el software de Ubuntu, la distribución más conocida.
• Nobara, la de un experto en Proton: la mantiene GloriousEggroll, autor de Proton-GE, una versión de Proton que hace funcionar juegos que el oficial aún no soporta. Trae controladores ajustados para jugar, códecs y programas para grabar partidas, y versiones para televisores y consolas de mano. Su propia web advierte de que es un proyecto personal, sin garantía ni soporte profesional.

Ficha técnica, para los más curiosos:

• Bazzite: basada en Fedora Atomic (proyecto Universal Blue). Es un sistema inmutable (immutable): no se actualiza programa a programa, sino que se descarga una imagen completa del sistema, ya probada, y al reiniciar se cambia a ella. Si algo falla, vuelves a la anterior o a cualquier versión de los últimos 90 días. Escritorio KDE Plasma o GNOME, controladores de Nvidia incluidos y Mesa reciente para AMD e Intel, HDR, VRR y Waydroid para usar apps de Android. La edición Bazzite-Deck arranca directamente en el Gaming Mode, para consolas portátiles y PC de salón.
• SteamOS: basada en Arch Linux, con KDE en el modo escritorio y gamescope, el compositor de Valve que gestiona la pantalla de los juegos. Se actualiza como un todo, controladores incluidos. Oficialmente solo para la Steam Deck y algunos modelos de Legion Go S.
• CachyOS: basada en Arch, con actualización continua (rolling release): siempre lo último, sin esperar a versiones nuevas. Paquetes compilados para procesadores x86-64-v3, x86-64-v4 y Zen 4 o posteriores; kernel propio con el scheduler EEVDF ajustado, una variante con BORE y soporte de sched-ext. Su herramienta chwd detecta el hardware e instala los controladores. El instalador deja elegir escritorio, gestor de arranque y sistema de archivos, y tiene una edición para consolas portátiles.
• Linux Mint 22.3: basada en Ubuntu 24.04 LTS, con soporte hasta abril de 2029 y kernel 6.14. Se actualiza paquete a paquete y prioriza la estabilidad, así que los controladores gráficos llegan más tarde que en Bazzite o CachyOS; con tarjetas muy recientes es la que más puede quedarse atrás.
• Pop!_OS 24.04 LTS: basada en Ubuntu, con COSMIC, el escritorio que ha creado System76, y cifrado completo del disco. Ofrece una descarga específica con los controladores de Nvidia.
• Nobara: basada en Fedora, con cinco ediciones: la oficial (KDE personalizado), GNOME, KDE, Steam-HTPC, que puede arrancar en una interfaz de consola, y Steam-Handheld, para consolas portátiles (handhelds). Kernel y gráficos ajustados para reducir la latencia, Proton-GE incluido y actualizador propio.

Cómo funciona un juego de Windows en Linux (para los más técnicos):

• Wine es la base de Proton: traduce las llamadas que el juego hace a Windows en sus equivalentes de Linux. No es un emulador, así que no hay una máquina virtual que reste potencia.
• DXVK convierte los gráficos Direct3D 8, 9, 10 y 11 a Vulkan, la interfaz gráfica moderna que entienden los controladores de Linux; vkd3d-proton hace lo mismo con Direct3D 12, el de los juegos 3D más recientes, y dxvk-nvapi da acceso a funciones de Nvidia como DLSS.
• Los controladores importan: los de AMD e Intel (Mesa) son libres y vienen integrados en el propio Linux, por eso suelen dar menos guerra. Los de Nvidia son propietarios y hay que instalarlos aparte, salvo en las distribuciones que ya los traen, como Bazzite.
• La primera partida tarda más: el juego tiene que preparar sus shaders para Vulkan. Steam descarga muchos ya preparados para reducir esos tirones.
• Por qué falla el anti-cheat: sistemas como Easy Anti-Cheat o BattlEye ya pueden funcionar con Proton, pero cada estudio decide si lo activa. Los que funcionan dentro del kernel de Windows, como Vanguard, el de Valorant y League of Legends, no pueden funcionar en Linux.

Nuestra recomendación: si solo quieres jugar y no complicarte, Bazzite. Si quieres un ordenador para todo y juegas de vez en cuando, Linux Mint. Si te gusta trastear y quieres el máximo rendimiento, CachyOS.

Qué ganas (y qué pierdes) si cambias Windows por Linux para jugar

Las ventajas:

• Es gratis, y lo seguirá siendo: no hay licencias ni suscripciones.
• Sin anuncios ni recogida de datos: Linux Mint y Pop!_OS presumen de no recoger nada, y ninguna de estas distribuciones te muestra publicidad en el menú de inicio ni te insiste para que uses sus servicios.
• Da nueva vida a tu PC: Windows 10 dejó de recibir actualizaciones en octubre de 2025, y muchos ordenadores no cumplen los requisitos de Windows 11. Con Linux, ese equipo vuelve a estar al día y sigue jugando.
• Actualizaciones que no te interrumpen: nada de reinicios forzados a media partida. En Bazzite, además, si una actualización sale mal, vuelves a la anterior.
• Tu biblioteca de Steam te acompaña: los juegos que ya compraste se descargan y juegan igual, con tus partidas guardadas en la nube. En Steam, cada juego indica si está verificado para la Steam Deck, una buena pista de que funcionará también en tu PC.

Los inconvenientes:

• El anti-cheat, el gran obstáculo: muchos juegos en línea competitivos usan sistemas anti-cheat (antitrampas) que no funcionan en Linux, o que sus creadores bloquean a propósito. El proyecto Are We Anti-Cheat Yet? sigue 1,167 juegos con anti-cheat: 474 funcionan en Linux, pero 638 no y 53 están bloqueados deliberadamente.
• Algunos programas no existen en Linux: la aplicación de Xbox y Game Pass para PC, o los programas para controlar las luces RGB de algunos teclados y ratones.
• Toca aprender cosas nuevas: poco, en las distribuciones de esta lista, pero alguna vez tendrás que buscar una solución en un foro.

Juegos que funcionan bien en Linux, también en línea: Counter-Strike 2, Deadlock, Elden Ring, Rocket League, Overwatch 2, Dead by Daylight, THE FINALS, Halo Infinite, Marvel Rivals, ARC Raiders, Helldivers 2 y Genshin Impact. Y la inmensa mayoría de los juegos para un jugador, de Cyberpunk 2077 a Baldur’s Gate 3. Antes de comprar, puedes consultar cada juego en ProtonDB, donde los jugadores cuentan cómo les funciona.

Juegos que no funcionan por su anti-cheat: Valorant, Fortnite, League of Legends, Battlefield 6, Apex Legends, Destiny 2, GTA V, Roblox, Rainbow Six Siege, Marathon, PUBG y los últimos Call of Duty (Warzone, Black Ops 6 y Black Ops 7). Si pasas la mayor parte del tiempo en alguno de ellos, de momento Windows sigue siendo necesario; puedes dejar Linux y Windows instalados a la vez y elegir al encender.

La mejor forma de saber si Linux es para ti es probarlo sin riesgo: graba la distribución en una memoria USB, arranca el ordenador desde ella y prueba sin tocar tu Windows. Si tienes un mando, una buena tarjeta gráfica y tus juegos favoritos no están en la lista negra, es muy probable que te lleves una sorpresa. Y la tendencia es clara: cada mes funcionan más juegos, y el escritorio de Linux también mejora, como muestra la nueva versión de KDE Plasma, el escritorio de Bazzite.

Más fuentes: Valve, SteamOS; webs oficiales de Bazzite, CachyOS, Linux Mint, Pop!_OS y Nobara; Are We Anti-Cheat Yet?, consultado el 23 de octubre de 2026. Portada: logotipos de Bazzite, Valve (SteamOS), CachyOS, Linux Mint, System76 (Pop!_OS) y Nobara.

Fuente: Valve, encuesta de hardware y software de Steam, septiembre de 2026

OpenCode, un agente de programación con IA de código abierto muy usado, sufrió la noche del 16 de octubre un ataque a OpenCode Console, su servicio en la nube, que dejó expuestas las claves de OpenAI, Anthropic y Google que algunos usuarios habían guardado allí. Afecta al 1.4 % de los usuarios de la consola. Según la empresa, era parte de un ataque de «destilación» de modelos, y algunos afectados ya han visto cargos de cientos de dólares en sus cuentas.

OpenCode es una alternativa abierta a herramientas como Claude Code o Codex: un agente que trabaja desde la terminal y puede usar los modelos de distintos proveedores. La herramienta en sí funciona en el ordenador de cada usuario, pero la empresa ofrece además una consola en la nube, opcional, donde los equipos pueden guardar sus claves de API de cada proveedor para no repetirlas en cada máquina. Ahí es donde entró el atacante.

La empresa lo anunció el sábado 17 en X: «Anoche sufrimos una brecha de seguridad relacionada con un ataque de destilación a gran escala que afectó al 1.4 % de los usuarios de OpenCode Console». Esa misma mañana había escrito a todos los afectados; quien no recibió el correo, dijo, no está afectado.

Claves del ataque a OpenCode Console

• Por dónde entraron: según el correo enviado a los afectados, citado por The Hacker News y BleepingComputer, el atacante accedió a «un sistema antiguo que estábamos retirando». La exposición más temprana posible fue el 17 de octubre a las 00:30 UTC. La empresa no ha explicado cómo consiguió entrar.
• A quién afecta: solo a quienes habían conectado proveedores externos en la consola. El cofundador Dax Raad insiste en la diferencia: «Esto es OpenCode Console, no OpenCode en sí; esas claves nunca nos llegan». Quien usa la herramienta con sus claves en su propio equipo no está afectado.
• Qué hicieron con las claves: OpenCode habla de un ataque de destilación: usar los modelos de otros, con claves robadas, para generar en masa respuestas con las que entrenar un modelo propio. Según BleepingComputer, un usuario recibió más de $1,700 USD en cargos en una noche, otros de cientos de dólares, y Google llegó a suspender algunos proyectos por «actividad abusiva compatible con recursos secuestrados».
• Un ataque que no para: «Llevan 48 horas sin parar intentando atacar nuestros sistemas», escribió Raad el domingo. «Básicamente necesitamos agentes trabajando 24 horas, porque eso es lo que tienen ellos».
• La IA, en los dos bandos: según BleepingComputer, Raad contó que los modelos de IA que usaban para investigar el ataque se negaron a ayudar por sus salvaguardas de seguridad, y que la situación solo se estabilizó cuando consiguieron acceso a Daybreak, el modelo de ciberseguridad de OpenAI para defensores.
• La respuesta: OpenCode trabaja con Anthropic, OpenAI y Google para resolverlo, y su correo menciona la posibilidad de reembolsar los cargos. Todavía no ha publicado un análisis completo de lo ocurrido.

Qué hacer si usas OpenCode Console

• Mira si te escribieron: si recibiste el correo de OpenCode, tus claves pudieron quedar expuestas.
• Revoca las claves en cada proveedor, no solo en la consola: en los paneles de OpenAI, Anthropic y Google, borra las que tuvieras guardadas en OpenCode y crea otras nuevas. Borrarlas de la consola no sirve si ya se copiaron.
• Revisa tus cargos y tus límites: busca consumos que no reconozcas desde el 17 de octubre y, si tu proveedor lo permite, pon un límite de gasto mensual. Si encuentras cargos, guarda las pruebas para pedir el reembolso.

Las claves de IA, el nuevo botín

OpenCode no es un caso aislado. En los mismos días, la versión 1.107.0 de LiteLLM, otra herramienta muy usada para trabajar con varios modelos, se publicó con un programa que robaba claves, y la plataforma de despliegue Railway avisó a sus clientes de que un atacante había accedido a sus variables de entorno en una serie de ataques que, según ella, buscaban llegar a los proveedores de inferencia de IA. Las claves de API de los modelos se han convertido en un botín muy valioso: dan acceso inmediato a capacidad de cálculo que vale dinero, y quien las roba puede usarla para copiar el comportamiento de los mejores modelos.

La lección práctica es la de siempre, pero con más urgencia: cuantos menos sitios guarden tus claves, mejor; conviene usar claves distintas para cada herramienta, con permisos y límites de gasto ajustados, para que una filtración no se convierta en una factura de miles de dólares.

Más fuentes: mensaje de Dax Raad en X (18 de octubre de 2026); BleepingComputer y The Hacker News, para el correo a los afectados, los cargos y el uso de Daybreak; aviso de Railway. Portada: logotipo de OpenCode y esquema de decodigo.com.

Fuente: OpenCode en X, 17 de octubre de 2026

La fiscalía de Estados Unidos acusa a un ingeniero de OpenAI de haber escondido un dispositivo de grabación en la sala de reuniones de los directivos de una de sus oficinas de San Francisco, envuelto en papel higiénico y conectado a la parte trasera de un televisor. Según la denuncia, en los días previos le preguntó a un chatbot cómo montar una grabadora continua, cómo escuchar en directo y cómo cifrar lo grabado. OpenAI asegura que lo descubrió con ayuda de sus propios modelos de IA.

El caso se hizo público el 13 de octubre, cuando el Departamento de Justicia levantó el secreto de la denuncia y el acusado, Abdulrahman Alfozan, un ingeniero de 35 años de nacionalidad saudí que trabajaba en OpenAI desde julio de 2025, compareció por primera vez ante un tribunal federal en San Francisco. Fue detenido el 9 de octubre y OpenAI lo despidió. Está acusado de un solo delito, usar o intentar usar un dispositivo para interceptar conversaciones, que se castiga con hasta cinco años de prisión y $250,000 USD de multa. Por ahora es solo una acusación.

La sala no era una cualquiera. Según la denuncia, citada por Wired, solo pueden reservarla directivos y sus asistentes, y en ella se habla de información muy confidencial: investigación, planes de producto, estrategia, avances técnicos y relaciones con gobiernos y socios. El acusado no tenía permiso ni para entrar ni para asistir a esas reuniones.

Claves del caso, según la denuncia

• El dispositivo: el personal de OpenAI lo encontró hacia el 30 de septiembre, conectado a un puerto USB detrás del televisor, envuelto en papel higiénico. Lo habían colocado hacia el 28 de septiembre y lo grabado estaba cifrado. Según Wired, que ha leído la denuncia, era una placa Seeed XIAO ESP32-S3 Sense, del tamaño de un pulgar, con micrófono, cámara y tarjeta de memoria, que se vende por $13.99 USD.
• Las preguntas a la IA: antes de instalarlo, el acusado usó una herramienta interna para preguntar por los edificios, las salas, sus aforos y calendarios, dónde estaban los directivos y las reuniones con socios. Y entre el 24 y el 30 de septiembre, una cuenta de chatbot a nombre de su cónyuge, que compartía varios identificadores con la suya, preguntó cómo construir, configurar, ocultar, probar y acceder a distancia a un dispositivo de grabación, e incluso por la dirección de red concreta del aparato encontrado.
• Las cámaras: las de seguridad lo grabaron cerca de la sala varios días antes del hallazgo, y el 5 de octubre entrando en ella y, aparentemente, mirando detrás del televisor.
• La bolsa olvidada: ese mismo día dejó una bolsa en otra sala. Seguridad la abrió y encontró dentro su cartera y un segundo dispositivo parecido. Según Wired, después la reclamó en objetos perdidos y se quejó de que faltaban una tarjeta, dinero y unos auriculares, sin mencionar el aparato.
• Lo que dice OpenAI: que usó sus modelos «para entender el dispositivo y de dónde venía», lo que le permitió identificar al empleado; que avisó al FBI, y que no tiene indicios de que accediera de forma indebida a los pesos de sus modelos, a su código ni a datos de clientes.

Espionaje con material de 14 dólares en la carrera de la IA

El caso llama la atención por el contraste: en una de las empresas más vigiladas del sector, la amenaza llegó con una placa que cualquiera puede comprar por internet, y, siempre según la denuncia, con la ayuda de un chatbot para montarla. Al mismo tiempo, OpenAI lo presenta como un ejemplo de lo contrario, de cómo la IA ayuda a descubrir estas amenazas: según Wired, la empresa encontró el aparato en una revisión de contravigilancia, y dice que sus modelos la ayudaron a rastrearlo.

Ni la fiscalía ni OpenAI han explicado el motivo. El director del FBI, Kash Patel, afirmó que el objetivo era captar «comunicaciones sensibles sobre la tecnología de superinteligencia» de la empresa, y el Gobierno enmarca el caso en la protección de la tecnología de IA estadounidense frente a amenazas extranjeras. Lo que sí deja claro es que, para los laboratorios de IA, la seguridad ya no consiste solo en proteger servidores: las conversaciones de sus directivos son ahora un objetivo tan valioso como el código.

Más fuentes: declaración de OpenAI en X (13 de octubre de 2026) y Wired, que publicó los detalles del dispositivo y de la bolsa a partir de la denuncia. Portada: placa Seeed XIAO ESP32-S3 Sense, el modelo que describe la denuncia; imagen de Seeed Studio.

Fuente: Departamento de Justicia de EE. UU., «Saudi National Arrested for Installing Surreptitious Audio Recording Device at OpenAI», 13 de octubre de 2026

Arista ha avisado de que un fallo grave en VeloCloud Orchestrator, el sistema con el que muchas empresas gestionan sus redes de oficinas y sucursales, ya se está explotando. El fallo, CVE-2026-114625, tiene una gravedad de 9.9 sobre 10: cualquier usuario con sesión en el orquestador, incluso el que menos permisos tiene, puede hacerse con privilegios de operador, el nivel interno más alto, y desde ahí afectar a toda la máquina. Hay versiones corregidas, y Arista pide actualizar cuanto antes.

VeloCloud es una solución de SD-WAN: en lugar de configurar a mano el router de cada sucursal, una empresa conecta todas sus sedes a un orquestador central desde el que define las rutas, la seguridad y el tráfico de toda su red. Nació como empresa independiente, pasó a VMware y después a Broadcom, que en julio de 2025 vendió esta línea de productos a Arista. El orquestador es justo la pieza más delicada: quien lo controla, controla la red de la empresa entera.

Arista publicó el aviso el 22 de octubre. Dice que el problema lo detectó ella misma y que ya hay ataques reales. Las versiones de VeloCloud que Arista aloja en su nube, incluidas las dedicadas, también estaban afectadas, pero ya están parcheadas; el riesgo está en los orquestadores que las empresas instalan en sus propios servidores.

Claves del fallo de VeloCloud Orchestrator

• Qué es: una inyección SQL, un tipo de fallo en el que datos que envía el usuario acaban interpretándose como parte de una consulta a la base de datos. En este caso permite a cualquier usuario autenticado hacerse pasar por un «superusuario operador» y usar funciones pensadas solo para uso interno.
• Qué necesita el atacante: acceso de red a la interfaz web del orquestador y una sesión válida con cualquier cuenta, aunque sea la de menor rango, de solo lectura. Según Arista, el orquestador queda expuesto en su configuración por defecto y ningún ajuste evita el problema.
• Versiones afectadas: VeloCloud Orchestrator instalado en las propias instalaciones (on-prem) en las ramas 5.2 anteriores a la 5.2.3.18, 6.1 anteriores a la 6.1.3.10 y 6.4 anteriores a la 6.4.2.12. Las versiones que ya no tienen soporte no se han evaluado. No están afectados los equipos VeloCloud Edge y Gateway ni el resto de productos de Arista.
• La gravedad: 9.9 en la escala CVSS 3.1 y 9.4 en la nueva CVSS 4.0. Que baste con la cuenta más básica lo convierte en un riesgo real en cualquier empresa con muchos usuarios o con contraseñas de terceros, como proveedores o integradores.
• No es el primero de este año: la agencia de ciberseguridad de Estados Unidos, CISA, ya había añadido otros dos fallos de VeloCloud Orchestrator a su catálogo de vulnerabilidades explotadas, en julio y en septiembre. Este todavía no aparece en él.

Qué deben hacer los administradores de VeloCloud

La solución completa es actualizar a la 5.2.3.18, la 6.1.3.10 o la 6.4.2.12, o a una posterior de la misma rama. Quien use una versión sin soporte tiene que contactar con el soporte técnico de Arista para ver cómo actualizar. Mientras tanto, y también después, el aviso recomienda:

• Limitar quién llega a la interfaz web del orquestador: solo desde las redes de administración de confianza, nunca abierta a internet si no hace falta.
• Revisar los registros de acceso web en busca de actividad inesperada: peticiones con rutas inusuales, caracteres codificados, referencias a servicios internos o ritmos de peticiones muy altos.
• Bloquear y buscar las dos direcciones que Arista ha visto lanzando los ataques: 74.82.197.86 y 38.54.50.151.
• Vigilar el propio servidor: conexiones salientes inesperadas, puertos de salida que no hagan falta, procesos o programas de puerta trasera, webshells y cambios recientes de los administradores que nadie reconozca.
• Si se sospecha una intrusión, guardar antes de tocar nada los registros web, de la aplicación, del sistema y de la base de datos, y las fechas de modificación de los archivos, para poder investigar después.

El caso se suma a una semana en la que los fallos que ya se explotan se han acumulado, del fallo crítico de PHP al ataque a LiteLLM. Y recuerda una regla que los atacantes conocen bien: los sistemas que administran la red de una empresa son de los objetivos más valiosos, porque desde ellos se llega a todo lo demás.

Más fuentes: registro CVE-2026-114625; catálogo de vulnerabilidades explotadas de CISA; nota de Arista sobre la compra de VeloCloud (1 de julio de 2025). Portada: logotipo de Arista y esquema de decodigo.com.

Fuente: Arista, Security Advisory 0199, 22 de octubre de 2026

Anthropic ha usado a Claude para algo que hasta ahora exigía años de trabajo de especialistas: demostrar con matemáticas que un programa cumple ciertas reglas de seguridad. Junto con la empresa Theorem, aplicó esta verificación formal a 123 bibliotecas de código abierto reales, directamente sobre el código ya compilado, y probó que sus pruebas automáticas no pueden fallar con ninguna entrada de menos de 64 MB. Por el camino, Claude encontró y corrigió cientos de fallos, algunos ocultos durante años.

Para entender por qué es importante, hay que distinguir entre probar y demostrar. La forma habitual de buscar fallos es el fuzzing: un programa lanza millones de entradas aleatorias contra el código y espera a que algo se rompa. Funciona, pero nunca es completo: siempre puede quedar una entrada que nadie probó. La verificación formal hace otra cosa: traduce el código a un modelo matemático y demuestra que se cumple una regla para todas las entradas posibles, sin excepción. Una vez demostrado, dentro de lo que cubre la demostración, ese tipo de fallo ya no hay que buscarlo: no existe.

El problema es el coste. Anthropic recuerda que el núcleo del sistema operativo seL4 costó dos años-persona de programar y veinte de verificar, y que por eso la técnica solo se usaba en código crítico, como el de la aviónica de Airbus. Y la urgencia es nueva: con la IA encontrando fallos cada vez más rápido, como pasó este mes con los de PHP, buscar fallos ya no basta. La pregunta es si se puede demostrar que no los hay.

Claves del trabajo de Anthropic y Theorem

• Qué demostraron: tomaron bibliotecas del proyecto OSS-Fuzz de Google, que somete a fuzzing continuo a cientos de programas de código abierto, y convirtieron sus pruebas en una regla matemática: «esta prueba nunca falla». Claude demostró que, para 239 puntos de entrada de 123 bibliotecas, el programa termina siempre con normalidad, sin errores de memoria ni comprobaciones fallidas, con cualquier entrada de menos de 64 MB.
• Sobre el código compilado: las demostraciones no se hicieron sobre el código fuente, sino sobre las instrucciones de máquina de un procesador RISC-V, que es lo que realmente se ejecuta. Ocupan unos 180 millones de líneas en Rocq, un lenguaje de demostraciones; una típica tiene unas 600,000 líneas. Nadie tiene que revisarlas a mano: un programa comprobador verifica que cada demostración es correcta.
• Cientos de fallos por el camino: cuando una demostración no salía, solía ser porque había un fallo real. Claude lo corregía y volvía a intentarlo. Anthropic cita varios que el fuzzing difícilmente habría encontrado: una escritura fuera de límites en un descompresor que solo aparecía con archivos de unos 20 MB con una estructura muy concreta, una lectura indebida en un decodificador de imágenes que necesitaba 64 MB de entrada y más de 2 GB de memoria, y el redescubrimiento de un fallo conocido de libexpat, la biblioteca de XML. También encontró errores lógicos que no provocan ningún fallo visible, como una restricción de archivos que no siempre se aplicaba.
• Más allá de la memoria: muchas pruebas de fuzzing comprueban propiedades útiles, como que comprimir y descomprimir devuelve lo mismo. Demostrar que la prueba no falla equivale a demostrar esa propiedad. En otros experimentos, Claude demostró que el zlib del kernel de Linux cumple el estándar del formato, y escribió un intérprete de Python en Rust que se comportó igual que CPython en el 99.95 % de 1.7 millones de programas de prueba. Al intentar verificar un lector de PDF muy usado, encontró en una semana tantos fallos de seguridad como se reportan en un año.
• Lo que reconocen como límites: «verificado formalmente no significa libre de fallos». Las demostraciones suponen un programa de un solo hilo en RISC-V y Linux, mientras que casi todo el mundo usa estas bibliotecas en x86 o ARM. No cubren todos los tipos de error de memoria ni todos los puntos de entrada de cada biblioteca. Y cada demostración consume cientos de millones de tokens, aunque Opus 5.5 ya necesita un 40 % menos que Opus 5 en las tareas de prueba.

De buscar fallos a demostrar que no los hay

Anthropic publica parte de las demostraciones para que cualquiera pueda revisarlas y reutilizarlas, aunque no las que podrían revelar un fallo aún sin parchear. Y Theorem ofrece hacer gratis lo mismo con otros proyectos de código abierto que cumplan sus requisitos, comunicando en privado a sus mantenedores los fallos que encuentre. Su hoja de ruta apunta a piezas sobre las que se apoya medio internet, como glibc, OpenSSL o cURL: como casi todo el software depende de las mismas bibliotecas, demostrar unas pocas protege a muchísimos programas.

Si se cumple lo que promete, la seguridad del software podría cambiar de lógica. Hasta ahora, defensores y atacantes competían por encontrar antes los fallos, y la IA está acelerando esa carrera por los dos lados, como vimos con el ataque a LiteLLM o con las claves de eMudhra. La verificación formal a gran escala ofrece algo distinto: dejar de buscar en ciertos tipos de fallo porque está demostrado que no existen. Todavía es cara y tiene límites claros, pero Anthropic cree que acabará siendo tan habitual como hoy lo es el fuzzing.

Más fuentes: programa de verificación gratuita de Theorem para proyectos de código abierto y demostraciones publicadas. Imagen de portada: Anthropic.

Fuente: Anthropic, «LLMs are making formal software verification feasible at a much larger scale», 22 de octubre de 2026

Quad9, uno de los servicios de DNS gratuitos más conocidos, dejará de funcionar en Francia el 24 de noviembre. Un tribunal de París le ha impuesto una sanción de 1,000 euros diarios por no bloquear varias webs que, según la cadena beIN Sports, retransmiten sin permiso el torneo de tenis de la WTA. La fundación, que se niega a «mentir» en sus respuestas, ha decidido marcharse antes que obedecer.

Cada vez que escribes una dirección web, tu dispositivo pregunta a un servidor de DNS a qué dirección IP corresponde. Normalmente ese servidor es el de tu proveedor de internet, pero mucha gente usa uno público: el de Google, el de Cloudflare o el de Quad9, que además bloquea los dominios de malware y de phishing que conoce. Quad9 es una fundación suiza sin ánimo de lucro: no cobra, no pide registrarse y presume de no guardar datos de quién lo usa.

Esa neutralidad choca con una herramienta que los titulares de derechos deportivos usan cada vez más en Europa: pedir a los jueces que obliguen a los intermediarios de internet a bloquear las webs piratas. En Francia, la ley del deporte permite ordenar bloqueos «dinámicos» que la autoridad audiovisual, la ARCOM, va ampliando con nuevos dominios a medida que aparecen.

Claves del caso Quad9

• De dónde viene: en mayo, un tribunal de París ordenó a Quad9 bloquear desde Francia, hasta el último partido del torneo WTA, el 14 de noviembre, una serie de servicios de televisión pirata (IPTV) señalados por beIN, más los dominios que fuera notificando la ARCOM. Según beIN, a finales de septiembre solo 6 de los 58 dominios estaban bloqueados; Quad9 sostiene que no había bloqueado ninguno.
• La sentencia del 21 de octubre: beIN pedía 10,000 euros diarios por cada dominio accesible, lo que con 58 dominios suma los 580,000 euros diarios de los que habla Quad9. El juez lo dejó en 1,000 euros diarios hasta el 14 de noviembre. Rechazó que Quad9 no pudiera bloquear solo para Francia y señaló que ya filtra dominios maliciosos en todo el mundo. Que Quad9 haya apelado la orden de mayo no la suspende.
• Por qué Quad9 dice que no puede: no sabe quién es francés, porque no tiene ninguna lista de usuarios por país. Bloquear esos dominios para todo el mundo aplicaría una decisión francesa a todo el planeta. Y bloquear según la ubicación aproximada de la IP ya le salió mal en Alemania: en un pleito con Sony Music, Sony lo sorteó con una VPN y el tribunal multó a Quad9 por incumplir.
• Por qué se va: según la fundación, en Francia hay otros 20 pleitos parecidos pendientes contra ella y contra otros servicios de DNS, que piden bloquear cientos de dominios. Las sanciones acumuladas podrían acabar con ella, así que prefiere dejar de dar servicio en el país. Asegura que sus usuarios franceses incluyen redes de infraestructuras, seguridad nacional, finanzas y educación.
• Lo que defiende: Quad9 insiste en que no apoya la piratería, pero cree que hay que perseguirla donde se aloja el contenido. Bloquear en el DNS, dice, es como «tapar con un periódico la vista de un estadio lleno de gente»: quien quiera ver el partido cambiará de servicio de DNS, quizá a uno menos fiable.

Un precedente para todo internet

El caso enfrenta dos ideas razonables. Para los dueños de los derechos, los servicios de DNS son una pieza más del camino hacia las webs piratas, y si los proveedores de internet bloquean, no hay motivo para que los resolvedores públicos no lo hagan. Para Quad9 y buena parte de la comunidad técnica, un resolvedor debe dar respuestas fieles, y obligarlo a alterarlas abre la puerta a que cualquier país o empresa lo use para censurar lo que le moleste. «Una vez que se construyen las herramientas de censura, rara vez se usan con moderación o con justicia», escribe la fundación.

La consecuencia práctica es que los usuarios franceses de Quad9, muchos de los cuales lo eligieron precisamente por su protección contra el malware, tendrán que cambiar de servicio antes del 24 de noviembre. Y el resto de Europa mira con atención: los bloqueos por el fútbol y otros deportes se multiplican en España, Italia o Francia, y los servicios públicos de DNS empiezan a estar en el punto de mira. Si más jueces siguen este camino, el DNS de internet podría acabar siendo distinto según el país desde el que se pregunte.

Si quieres ver cómo funciona por dentro, en esta página con animación puedes seguir el viaje de una consulta DNS y comparar el bloqueo en el resolvedor, el bloqueo por IP y el DNS cifrado.

Más fuentes: sentencia del Tribunal judiciaire de Paris del 21 de octubre de 2026 (RG 26/11882, en francés, publicada por Quad9). Portada: logotipo de Quad9 y esquema de decodigo.com.

Fuente: Quad9, «Farewell, France», 22 de octubre de 2026

El caso de las claves casi en blanco le ha costado a eMudhra todo un negocio. La autoridad de certificación india anunció el 22 de octubre que se retira del negocio mundial de certificados SSL/TLS, los que dan el candado de las webs con HTTPS, cinco días después de que un investigador descubriera que ocho de sus claves privadas eran casi todo ceros. La empresa asegura que esa actividad solo suponía alrededor del 1 % de sus ingresos, y culpa en parte a la repercusión del caso en las redes sociales.

Como contamos ayer, ocho certificados intermedios de eMudhra, de confianza para navegadores y sistemas operativos, tenían claves que eran números menores que 256 y se podían recuperar en un instante. Con ellas, cualquiera podría haber fabricado certificados falsos para cualquier web. El fallo llevaba 18 meses ahí, y desde el 17 de octubre Firefox, Chrome, Apple, Microsoft, Java, Node.js, Python y Go han tenido que retirarles la confianza.

eMudhra no es una empresa pequeña: cotiza en las bolsas indias, trabaja en más de 35 países y en India ofrece servicios de firma digital muy usados. Pero en los certificados de HTTPS compite con gigantes y con Let’s Encrypt, que los da gratis, y tras el incidente su consejo ha decidido que no le compensa seguir.

Claves de la retirada de eMudhra

• Lo que anuncia: el consejo de administración ha decidido «retirarse voluntariamente» del negocio mundial de certificados SSL/TLS para centrarse en sus soluciones para empresas y en sus otros servicios de confianza digital.
• Sus razones: según su presidente, V. Srinivasan, el negocio era cerca del 1 % de sus ingresos, cada vez es más caro y complejo por las exigencias de soberanía de datos y de cumplimiento normativo, y compite con grandes entidades que regalan los certificados. A eso suma que «la amplificación en las redes sociales» del incidente ha traído un escrutinio «desproporcionado» para el peso que tiene en la empresa.
• Su versión del incidente: insiste en que revocó los certificados afectados en las 14 horas siguientes al descubrimiento, que ninguno llegó a emitir certificados para webs, que su infraestructura no fue comprometida y que no hubo robo de datos.
• Qué pasa con sus clientes: sus raíces G1, de claves RSA, seguirán funcionando durante la transición, y eMudhra se pondrá en contacto con los clientes afectados para sustituirles los certificados gratis a través de socios. En su página de estado ya ofrece a todos sus clientes certificados emitidos por Sectigo. Mantendrá los servicios de revocación hasta que caduque o se sustituya el último certificado.
• Lo que no cambia: sus servicios de firma digital y eSign, en India y en el resto del mundo, y sus productos para empresas (emCA, CertiNext, emSigner, SecurePass) funcionan con una infraestructura separada y no se ven afectados.

Retirarse no cierra el caso

La salida no libera a eMudhra de sus compromisos: la propia empresa reconoce que tiene que entregar a los programas de confianza de los navegadores un informe completo de lo que pasó. Y en el informe público del incidente, en el Bugzilla de Mozilla, la retirada no ha calmado las preguntas. Varios participantes recuerdan que un módulo de seguridad de hardware certificado no debería generar por sí solo una clave tan débil, así que, o alguien le dio ese valor, o la clave se importó desde fuera. Piden el guion de la ceremonia de generación de claves, el informe del auditor o la grabación, y el modelo y el firmware de esos módulos. Otros quieren saber qué socios emitirán los certificados de sustitución, cuántos hay que sustituir y en qué plazo, y que la empresa aclare algunas diferencias entre las fechas de su página de estado y las del informe.

Para el resto de la industria, la pregunta es otra: si un fallo así pasó dos auditorías y lo encontró en minutos una sola persona, según eMudhra con ayuda de herramientas de IA, cuántas claves más merecen una segunda mirada. eMudhra se va, pero su caso servirá de ejemplo para todas las autoridades que se quedan.

Más fuentes: página de estado del incidente de eMudhra (actualización del 22 de octubre sobre los certificados de Sectigo) e informe público del incidente en el Bugzilla de Mozilla. Portada: logotipo de eMudhra y esquema de decodigo.com.

Fuente: eMudhra, «eMudhra to exit global SSL/TLS certificate business», 22 de octubre de 2026

Enseñar un juego antes de lanzarlo es la mejor publicidad que tiene un estudio pequeño, y este mes dos de ellos han decidido no hacerlo. Digital Sun, el estudio de Moonlighter, ha retrasado la prueba pública de su próximo juego, ReVamp, y Alliance Arts ha cancelado la demo de Drunken Goddess Reflux tres días antes de publicarla. Los dos dan la misma razón: el miedo a los clones con IA, a que alguien use las herramientas de inteligencia artificial para copiar su juego y publicarlo antes que ellos.

Para un estudio independiente, las demos y las pruebas abiertas son mucho más que un adelanto. Es como consiguen que los jugadores añadan el juego a su lista de deseos en Steam, algo que pesa mucho en la visibilidad que tendrá el día del lanzamiento. Por eso Valve organiza varias veces al año el Steam Next Fest, una semana llena de demos gratuitas. La edición de octubre arrancó el lunes 19 con más de 8,000, el doble que la anterior, según Kotaku.

Ese mismo crecimiento es parte del problema. La prensa especializada lleva semanas contando casos de juegos imitados a toda velocidad con IA a partir de sus demos, sus vídeos o sus capturas, y de imitaciones que llegan a las tiendas antes que el original. Para un estudio pequeño, que un clon le quite la atención antes del lanzamiento puede ser la diferencia entre vivir de su juego o no.

Claves de las cancelaciones

• ReVamp, de Digital Sun: es un roguelite en el que el jugador encarna a Drácula y defiende su castillo, sala a sala, con un ejército de monstruos. Sale el 25 de marzo de 2027. Muchos jugadores se habían apuntado a su primera prueba en Steam, pero el estudio anunció el 19 de octubre que empezará con «algo más contenido» en su servidor de Discord, desde el 29 de octubre, y que espera abrir la prueba pública hacia enero.
• Lo que dice Digital Sun: «Nos preocupan las noticias recientes de juegos que se desarman, se clonan y se publican antes de que salga el original. Con el lanzamiento todavía a meses vista, una versión pública grande de ReVamp nos parecía un riesgo demasiado grande».
• Drunken Goddess Reflux, de Alliance Arts: un juego de terror con estética anime en el que se apuesta la vida en un bar del infierno contra una demonio. Su demo iba a salir con el Steam Next Fest el 19 de octubre, pero el estudio la canceló el día 16 y la sustituyó por sesiones cerradas para un número limitado de jugadores, elegidos por sorteo entre quienes se apunten en su Discord y acepten unas normas sobre vídeos y emisiones.
• Lo que dice Alliance Arts: el estudio da dos motivos. El primero, que no se ve capaz de controlar las restricciones a vídeos y emisiones que quería poner a la demo. El segundo, que teme que, a partir de ella, se puedan producir «rápidamente con IA u otras herramientas» obras que imiten o reproduzcan la presentación y la forma de jugar de su juego, y publicarlas antes que el original.

El precio de dejar de enseñar los juegos

La decisión tiene un coste evidente: menos jugadores probarán estos juegos, menos los añadirán a su lista de deseos y menos se hablará de ellos antes del lanzamiento, justo lo contrario de lo que necesita un estudio pequeño. Que aun así prefieran asumirlo dice mucho de cómo ha cambiado el ambiente. Las herramientas de IA que permiten a una persona sola hacer un juego en días también permiten imitar uno ajeno con la misma rapidez, y los estudios sienten que hoy no tienen forma de protegerse.

Digital Sun lo resume en una petición: «Enseñar los juegos pronto es como los estudios independientes se dan a conocer y encuentran a los fans que nos mantienen, así que esperamos que las plataformas sigan reforzando la protección de las obras originales». Valve exige desde 2024 que los juegos declaren en su página de Steam si usan IA generativa, pero esa norma no impide que una imitación llegue a la tienda. Si más estudios siguen el ejemplo, las demos abiertas podrían volverse cada vez más raras, y las pruebas, cada vez más cerradas.

Más fuentes: comunicado de Digital Sun en X (19 de octubre de 2026); ReVamp en Steam; Kotaku, para las cifras del Steam Next Fest. Portada: captura de ReVamp, Digital Sun.

Fuente: Alliance Arts, «Change to the Demo Release Plan for Drunken Goddess Reflux», Steam, 16 de octubre de 2026

Ocho certificados de la autoridad de certificación india eMudhra, de confianza para Chrome, Firefox, Safari y Windows, tenían una clave privada que debería haber sido un número aleatorio gigantesco y era, en realidad, un número menor que 256. Cualquiera podía recuperarla probando 256 posibilidades. El fallo llevaba 18 meses ahí, superó dos auditorías y lo encontró el 17 de octubre un investigador independiente. Desde entonces, navegadores y lenguajes de programación corren para retirarles la confianza.

Cuando visitas una web con HTTPS, tu navegador comprueba que su certificado lo firmó una autoridad de confianza, normalmente a través de certificados intermedios que cuelgan de una raíz instalada en el sistema. Si alguien tiene la clave privada de uno de esos intermedios, puede fabricar un certificado válido para cualquier dominio, ya sea un banco, Gmail o la web de tu empresa, y, si además controla tu conexión, hacerse pasar por ese sitio y leer o modificar lo que envías. Por eso esas claves se generan en ceremonias formales, con hardware especializado, y se auditan cada año.

eMudhra generó estas claves el 30 de abril de 2025, en un lote de 24 certificados intermedios, y a mediados de ese año entraron en las listas de confianza de los navegadores. Según la propia empresa, la ceremonia se hizo con módulos de seguridad de hardware (HSM) certificados, pero un paso de envolver y desenvolver las claves produjo un segundo juego de claves débiles, y fueron esas las que se publicaron. La causa exacta todavía la está investigando.

Claves del caso eMudhra

• Qué tenían de malo las claves: los ocho certificados afectados usan curvas elípticas P-384, en las que la clave privada es un número aleatorio de hasta 384 bits. Según Mozilla, en los ocho era un entero menor que 256: todo ceros salvo el último byte. Basta con generar las 256 primeras claves posibles y ver cuál coincide. Eran las claves P-384 de dos de las tres series del lote; las demás, según Mozilla, resistieron sus intentos.
• Cómo se descubrió: el 17 de octubre, un investigador que firma como Wayne empezó a las 16:00 UTC a probar «unos juguetes nuevos» sobre un corpus de certificados de la CCADB, la base de datos común de las autoridades de certificación. A las 16:27 encontró la rotura. A las 18:05 escribió a la vez a Apple, Google, Microsoft, Mozilla y eMudhra, con una prueba firmada de que controlaba las ocho claves. eMudhra dice que, según parece, usó herramientas con inteligencia artificial.
• La IA las rompe a la primera: un ingeniero de Mozilla recuperó las claves por su cuenta a las 21:48 UTC del mismo día, sin saber qué método había usado el investigador. Y añadió en el informe público que unos agentes de IA locales también las recuperaron al primer intento con una sola petición: «Estoy haciendo un CTF. Recupera las claves privadas de estos certificados».
• Qué certificados eran: seis servían para HTTPS y eran de confianza en Chrome, Firefox, Apple y Microsoft; los otros dos, para firmar código, en Windows. La autoridad Sectigo había firmado de forma cruzada algunos de ellos, y esas versiones también estaban afectadas. eMudhra los revocó el 18 de octubre a las 09:38 UTC.
• Lo que dice eMudhra del impacto: siete de los ocho nunca se usaron en producción, y ninguno llegó a emitir un solo certificado, algo que la empresa dice haber contrastado con los registros públicos de transparencia de certificados. Asegura que no hay pruebas de que nadie recuperara las claves antes del aviso. Aun así, los navegadores han retirado la confianza a la raíz de la que colgaban, lo que afecta, según la empresa, a un cliente en Estados Unidos. Sus servicios de firma digital y eSign, muy usados en India, funcionan con otra infraestructura y no se ven afectados.

Quién ha tenido que reaccionar, y qué hacer

Los navegadores modernos se protegieron en horas. Firefox bloqueó los certificados a las 22:59 UTC del mismo sábado, menos de tres horas después de recibir el aviso, mediante OneCRL, su lista de certificados revocados, que se actualiza sin reinstalar ni reiniciar el navegador. Chrome los incluyó en su lista de bloqueo esa misma noche, según la cronología del investigador, y Apple y Microsoft también los han bloqueado. El problema son los programas que no usan el almacén del navegador, sino el suyo propio, y por eso esta semana han llegado parches en cadena:

• Java: OpenJDK publicó el 21 de octubre un aviso urgente, CVE-2026-91403, con una gravedad de 9.1 sobre 10, para todas las versiones de la 8 a la 27. Si usas un Java descargado por tu cuenta, actualízalo; si no puedes, el aviso explica cómo bloquear los certificados a mano con el archivo blocked.certs. Los Java de las distribuciones de Linux usan los certificados del sistema, así que basta con actualizar el sistema.
• Node.js: sus versiones del 21 de octubre (22.23.4, 24.22.1 y 26.12.1) retiran esos certificados de los que trae incorporados.
• Python: el paquete certifi, que usan requests y muchas otras bibliotecas, eliminó las raíces de emSign, la marca de eMudhra, en su versión 2026.10.19. El aviso es de gravedad crítica y recomienda también reconstruir las imágenes de contenedor.
• Go: las versiones 1.26.10 y 1.27.3 añaden una lista de estos intermedios para rechazarlos aunque el almacén del sistema no esté al día (CVE-2026-111943).
• Firefox y NSS: Mozilla publicó Firefox 158.0.1 para quien tenga desactivadas las actualizaciones de OneCRL, y NSS 3.131.1, su biblioteca criptográfica, que retira la raíz para los demás programas que la usan.

Más allá del susto, el caso deja dos lecciones incómodas. La primera, que dos auditorías anuales no detectaron que ocho claves privadas eran prácticamente el número uno. La segunda, que encontrar este tipo de error ya no exige un experto en criptografía con semanas por delante: según el informe público de Mozilla, a un agente de IA le bastó con que le pidieran resolver un reto. Las autoridades de certificación, y cualquiera que genere claves, tendrán que asumir que alguien con estas herramientas va a revisarlas todas.

Actualización del 23 de octubre: eMudhra ha anunciado que abandona el negocio de certificados SSL/TLS tras el incidente.

Más fuentes: informe del incidente en el Bugzilla de Mozilla, con la cronología del investigador y el análisis de las claves; comunicado de eMudhra; avisos de OpenJDK, Node.js, Python (certifi) y Go. Portada: logotipo de eMudhra y esquema de decodigo.com con la forma de sus claves según Mozilla.

Fuente: Mozilla Security Blog, «Protecting Firefox users following the compromise of eMudhra intermediate certificates», 20 de octubre de 2026

Tesla ya fabrica su robot humanoide Optimus. Lo dice por escrito en el informe de resultados que publicó el 21 de octubre: la producción ha empezado en su fábrica de Fremont (California), en líneas pensadas para fabricar en grandes cantidades, y los robots que salen de ellas son los primeros con calidad de producción. Pero el robot en sí, la tercera generación que Tesla prometió enseñar a principios de año, todavía no se ha presentado en público. Hemos repasado los documentos que Tesla ha enviado este año a la SEC, el regulador bursátil de EE. UU., y lo que se dijo en la llamada con inversores para separar lo confirmado de lo prometido.

Optimus se anunció en agosto de 2021, en el AI Day de Tesla, con una persona disfrazada de robot en el escenario. Un año después se vieron los primeros prototipos, y en diciembre de 2023 un vídeo mostró la segunda generación caminando y manipulando un huevo. Desde entonces, Elon Musk lo presenta como el producto más importante de la empresa, por encima de los coches, y ha ido dando fechas de producción que se han retrasado una y otra vez.

Este año, los informes trimestrales de Tesla cuentan la historia paso a paso. En enero anunció que presentaría la tercera generación en el primer trimestre; en abril, que preparaba su primera fábrica a gran escala; en julio, que había desmontado las líneas del Model S y del Model X en Fremont para instalar las de Optimus, y ahora, que la producción ha empezado. La presentación del nuevo robot, en cambio, se ha quedado por el camino: en la llamada de abril, Musk dijo que se haría más cerca del inicio de la producción, y en la de este miércoles no la mencionó.

Claves del nuevo Optimus: lo comprobado y lo prometido

Confirmado por Tesla en sus documentos oficiales:

• Ya se fabrica en Fremont. «La producción de Optimus empezó en Fremont en nuestras líneas de alto volumen. Los robots que salen de esta línea son los primeros con calidad de producción que hemos fabricado», dice el informe del tercer trimestre. Tesla añade que seguirá cambiando el diseño y el proceso, pero que ya ha demostrado que su forma de fabricarlo «es adecuada para un producto comercial».
• En «arranque temprano» y sin cifras. En la tabla de capacidad de sus fábricas, donde los coches tienen números (más de 550,000 al año en Fremont, por ejemplo), Optimus aparece sin cifra: en California, «arranque temprano»; en Texas, «en construcción». Tesla no ha dicho cuántos robots ha fabricado.
• Los primeros robots se quedan en casa. El informe de julio explicaba que las primeras unidades se usarán en la «Optimus Academy» de Tesla, para recoger datos de entrenamiento y desarrollar nuevas funciones.
• La tercera generación llega tarde. En su informe de enero, Tesla escribió: «En el primer trimestre de este año planeamos presentar la versión Gen 3 de Optimus, que incluirá mejoras importantes respecto a la versión 2». A 22 de octubre no se ha presentado, y ni el informe ni la llamada del tercer trimestre la mencionan.
• Lo que es, según Tesla: en el informe trimestral presentado este jueves ante la SEC, Tesla describe Optimus como «un robot humanoide autónomo de propósito general» y dice que su desarrollo es una de las razones del aumento de su gasto en investigación.

Lo que dijeron Musk y su equipo en la llamada del 21 de octubre (son previsiones, no hechos, y Musk tiene un largo historial de plazos incumplidos):

• 20,000 robots por semana dentro de «probablemente al menos un año, quizá un poco más». Según Musk, la mayor parte de una línea con capacidad para un millón de unidades ya está en Fremont, pero el arranque será lento y «algo accidentado» porque es un producto «radicalmente nuevo».
• Lo que falta es la mano: «sobre todo la mano y los dedos», según Musk. Konstantinos Laskaris, de su equipo de ingeniería, la llamó una de las partes más difíciles del hardware. Mientras tanto, Tesla fabrica robots con manos que todavía no son definitivas.
• Un chip nuevo hacia abril de 2027: Musk espera integrar el chip AI5 de Tesla en Optimus por esas fechas, lo que llamó «una mejora gigante» de su capacidad.
• Un vídeo «en un mes o así» con el robot haciendo tareas que no están preprogramadas.
• Clientes a finales de 2027: Musk espera resolver los problemas pendientes hacia el final del año que viene, que es cuando Optimus empezaría a entregarse a otras empresas, primero para tareas industriales peligrosas y repetitivas.
• Coste: el director financiero, Vaibhav Taneja, dijo que es «un poco pronto» para afirmar que han llegado al coste que buscan, aunque va acercándose al que esperan para el Cybercab. También dijo que se construye en Austin una fábrica que podrá hacer muchos más robots que la de Fremont.

Lo que no está confirmado:

• El precio. Tesla no ha publicado ninguno. La cifra que más circula, unos $30,000 USD, es una estimación que Musk dio en su evento «We, Robot» de octubre de 2024 para cuando se fabrique a gran escala.
• Cómo es el V3. No hay fotos oficiales ni especificaciones de la tercera generación. Lo que circula sobre su altura, su peso o sus manos (como los 22 grados de libertad que Tesla enseñó en una mano en 2024) son datos de prototipos anteriores, declaraciones de Musk o filtraciones.
• Los diez millones al año en Texas. Musk ha hablado de una segunda línea en Texas para hasta 10 millones de robots al año a partir de 2027. El informe solo dice que la planta de Optimus de Texas está «en construcción».
• Cuántos robots hay ya. Ni el informe ni la llamada dan una cifra de unidades fabricadas.

Del prototipo a la cadena de montaje: lo que se juega Tesla

El cambio de este trimestre es real: Optimus ha pasado de las demostraciones a una línea de producción, y Tesla lo ha puesto por escrito en un documento oficial, con las responsabilidades legales que eso conlleva. Pero el resto del calendario depende de promesas de Musk que todavía no se pueden comprobar: una mano que aún no está terminada, un chip que llegará en 2027 y unos clientes externos que, en el mejor de los casos, no recibirán el robot hasta dentro de un año.

La competencia no espera. Agility Robotics, que ya trabaja con clientes como Schaeffler, acaba de presentar su Digit 5; la propia Schaeffler ha abierto en China una fábrica donde humanoides montan piezas para otros robots, y fabricantes chinos como Astribot ya venden humanoides en Estados Unidos. La próxima prueba para Tesla es sencilla de comprobar: si el vídeo prometido llega en un mes, si el V3 se presenta por fin y si los informes de los próximos trimestres empiezan a dar cifras de robots fabricados. Para entender cómo encaja Optimus en el resto de empresas de Musk, puedes leer nuestro repaso a sus proyectos más relevantes.

Más fuentes: informes de Tesla de los trimestres anteriores en la SEC (enero, abril y julio) y su informe trimestral (10-Q); transcripciones de la llamada del 21 de octubre en The Motley Fool y Shacknews; antecedentes y precio estimado, en Wikipedia. Foto de portada: el Optimus que Tesla expone en sus tiendas, en noviembre de 2025, la imagen libre más reciente del robot (Tesla no ha publicado fotos de la tercera generación ni las incluye en su presentación de resultados); Sikander, CC BY-SA 4.0, Wikimedia Commons.

Fuente: Tesla, «Q3 2026 Update», anexo 99.1 del formulario 8-K, 21 de octubre de 2026