Noticias de seguridad

Más de 100 extensiones maliciosas en la Chrome Web Store oficial intentan robar tokens Bearer de Google OAuth2, desplegar puertas traseras y cometer fraude publicitario. Investigadores de la empresa de seguridad de aplicaciones Socket descubrieron que estas extensiones forman parte de una campaña coordinada que utiliza la misma infraestructura de comando y control (C2). El atacante publicó las extensiones bajo cinco identidades de editor distintas en diversas categorías: clientes para la barra lateral de Telegram, juegos de tragamonedas keno, optimizadores para YouTube y TikTok, una herramienta de traducción de texto y utilidades. Según los investigadores, la campaña utiliza un servidor central alojado en un VPS de Contabo, con múltiples subdominios que gestionan el secuestro de sesiones, la recopilación de identidades, la ejecución de comandos y las operaciones de monetización. Socket ha encontrado indicios de una operación rusa de malware como servicio (MaaS), basándose en comentarios en el código relacionados con la autenticación y el robo de sesiones. Recopilación de datos y secuestro de cuentas El grupo más grande, compuesto por 78 extensiones, inyecta código HTML controlado por el atacante en la interfaz de usuario mediante la propiedad innerHTML. El segundo grupo más grande, con 54 extensiones, utiliza chrome.identity.getAuthToken para recopilar el correo electrónico, el nombre, la foto de perfil y el ID de la cuenta de Google de la víctima. También roban el token de acceso OAuth2 de Google, un token de acceso temporal que permite a las aplicaciones acceder a los datos del usuario o actuar en su nombre.Un tercer lote de 45 extensiones incluye una función oculta que se ejecuta al iniciar el navegador, actuando como una puerta trasera que obtiene comandos del servidor C2 (cloudapi[.]stream) y puede abrir URL arbitrarias. Esta función no requiere la interacción del usuario con la extensión.Una extensión, destacada por Socket como "la más peligrosa", roba sesiones de Telegram Web cada 15 segundos, extrae los datos de sesión del almacenamiento local (localStorage) y el token de sesión de Telegram Web, y envía la información al servidor C2; esto permite al atacante tomar control de la cuenta sin necesidad de credenciales ni MFA. "La extensión también gestiona un mensaje entrante (set_session_changed) que realiza la operación inversa: borra el almacenamiento local de la víctima, lo sobrescribe con datos de sesión proporcionados por el atacante y fuerza la recarga de Telegram. "Esto permite al atacante cambiar el navegador de cualquier víctima a una cuenta de Telegram diferente sin que esta lo sepa". Los investigadores también encontraron tres extensiones que eliminan los encabezados de seguridad e insertan anuncios en YouTube y TikTok, una que redirige las solicitudes de traducción a través de un servidor malicioso y una extensión inactiva para el robo de sesiones de Telegram que utiliza infraestructura simulada. Socket ha notificado a Google sobre la campaña, pero advierte que todas las extensiones maliciosas siguen disponibles en la Chrome Web Store al momento de publicar su informe. BleepingComputer ha confirmado que muchas de las extensiones mencionadas en el informe de Socket aún están disponibles al momento de la publicación. Se recomienda a los usuarios que busquen las extensiones instaladas con los identificadores publicados por Socket y desinstalen inmediatamente cualquier coincidencia. Fuente: Socket

El martes parches de abril de 2026 de Microsoft ha dejado actualizaciones de seguridad para 169 vulnerabilidades, incluyendo 2 Zero-Days. Este Patch Tuesday también aborda ocho vulnerabilidades "críticas", 7 de las cuales son vulnerabilidades de ejecución remota de código y la otra es una vulnerabilidad de denegación de servicio. El número de errores en cada categoría de vulnerabilidad se detalla a continuación: 93 vulnerabilidades de elevación de privilegios 13 vulnerabilidades de omisión de funciones de seguridad 20 vulnerabilidades de ejecución remota de código 21 vulnerabilidades de divulgación de información 10 vulnerabilidades de denegación de servicio 9 vulnerabilidades de suplantación de identidad Entre las 169 vulnerabilidades también se incluyen cuatro CVE no emitidas por Microsoft que afectan a AMD (CVE-2023-20585), Node.js (CVE-2026-21637), Windows Secure Boot (CVE-2026-25250) y Git para Windows (CVE-2026-32631). Estas actualizaciones se suman a las 78 vulnerabilidades que se han corregido en su navegador Edge basado en Chromium desde la actualización lanzada el mes pasado. Para obtener más información sobre las actualizaciones no relacionadas con la seguridad publicadas hoy, puede consultar nuestros artículos específicos sobre las actualizaciones acumulativas the Windows 11 KB5083769 & KB5082052 y la actualizaciuón extendida de Windows 10 KB5082200. Dos vulnerabilidades de día cero y fallos en Microsoft Office Esta actualización corrige dos vulnerabilidades de día cero: una divulgada públicamente y la otra explotada activamente en ataques. La vulnerabilidad de día cero explotada activamente es: CVE-2026-32201 (CVSS 6.5). Vulnerabilidad de suplantación de identidad en Microsoft SharePoint Server, que fue explotada en ataques. "Una validación de entrada incorrecta en Microsoft Office SharePoint permite a un atacante no autorizado suplantar identidades en una red", explica Microsoft. La explotación activa de la vulnerabilidad CVE-2026-32201 ha llevado a la CISA añadirla al catálogo de Vulnerabilidades Explotadas Conocidas (KEV). La vulnerabilidad de día cero divulgada públicamente es: CVE-2026-33825 (CVSS 8.5). Vulnerabilidad de elevación de privilegios en Microsoft Defender que otorgaba privilegios de SYSTEM y se conoció públicamente com BlueHammer. La compañía ha solucionado la vulnerabilidad en la actualización 4.18.26050.3011 de la plataforma antimalware Microsoft Defender, que se descargará automáticamente en los sistemas. Microsoft reconoce el descubrimiento de esta vulnerabilidad por parte de Zen Dodd y Yuanpei XU (HUST) de Diffract. Ejecución remota de código en Microsoft Office Microsoft también ha corregido varios errores de ejecución remota de código en Microsoft Office (Word y Excel) que podían ejecutarse a través del panel de vista previa o al abrir documentos maliciosos. Por lo tanto, se recomienda a los usuarios que actualicen Microsoft Office lo antes posible, especialmente si suelen recibir archivos adjuntos. Vulnerabilidad en IKE (IPSec / VPN) Una de las vulnerabilidades más graves es la ejecución remota de código que afecta a las extensiones del servicio de intercambio de claves de Internet (IKE) de Windows. Identificada como CVE-2026-33824, esta vulnerabilidad tiene una puntuación CVSS de 9.8. "Para explotarla, un atacante debe enviar paquetes especialmente diseñados a un equipo Windows con IKE v2 habilitado, lo que podría permitir la ejecución remota de código", declaró Adam Barnett, ingeniero jefe de software de Rapid7. "Las vulnerabilidades que permiten la ejecución remota de código sin autenticación en sistemas Windows modernos son relativamente raras; de lo contrario, veríamos más vulnerabilidades que se propagan por internet. Sin embargo, dado que IKE proporciona servicios seguros de negociación de túneles, por ejemplo, para VPN, está necesariamente expuesto a redes no confiables y es accesible en un contexto de preautorización". Un atacante no autenticado puede enviar paquetes especialmente diseñados a una máquina Windows con IKE versión 2 habilitado para potencialmente permitir la ejecución remota de código. Entre las medidas de mitigación adicionales se incluye el bloqueo del tráfico entrante en los puertos UDP 500 y 4500 si IKE no está en uso. Walters señaló que esta vulnerabilidad representa una seria amenaza para los entornos empresariales, especialmente para aquellos que dependen de VPN o IPsec para comunicaciones seguras. La explotación exitosa de esta vulnerabilidad podría comprometer completamente el sistema, permitiendo a atacantes robar datos confidenciales, interrumpir operaciones o moverse lateralmente por la red. La falta de interacción del usuario hace que esto sea especialmente peligroso para los sistemas conectados a internet. Su baja complejidad de ataque y su impacto total en el sistema lo convierten en un objetivo ideal para su rápida utilización como arma. Los sistemas conectados a internet que ejecutan servicios IKEv2 corren un riesgo particular, y retrasar la implementación del parche aumenta la exposición a posibles ataques generalizados. Vulnerabilidad de BitLocker Microsoft publicó oficialmente actualizaciones de seguridad para solucionar una importante vulnerabilidad en Windows BitLocker. Esta vulnerabilidad, identificada como CVE-2026-27913 (CVSS 7.7), fue descubierta por el investigador de seguridad Alon Leviev en colaboración con el equipo STORM de Microsoft. El fallo representa un riesgo considerable para las arquitecturas de seguridad de los dispositivos empresariales. Sin embargo, actualmente no hay evidencia de explotación activa ni código de explotación disponible públicamente. La causa principal de CVE-2026-27913 reside en la forma en que el componente Windows BitLocker procesa y gestiona ciertos datos de entrada. Según el aviso de seguridad integral de Microsoft, la vulnerabilidad se deriva directamente de una validación de entrada incorrecta, clasificada como debilidad CWE-20. El exploit requiere acceso local a la máquina objetivo, lo que significa que el atacante debe estar físicamente cerca o tener acceso local al sistema. Esta debilidad sistémica permite a un atacante no autorizado eludir fácilmente las protecciones críticas del sistema y eludir completamente el Arranque Seguro (Secure Boot). La ejecución del exploit tiene una baja complejidad y no requiere interacción del usuario ni privilegios elevados para tener éxito. La documentación de Microsoft confirma que la vulnerabilidad afecta a un amplio espectro de entornos Windows Server actualmente en uso. Las plataformas afectadas incluyen Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019 y Windows Server 2022. Además, la vulnerabilidad está presente tanto en instalaciones estándar completas de escritorio como en instalaciones optimizadas de Server Core en todas estas versiones. Actualizaciones para otras compañías Adobe security updates, incluye un Zero- Day explotado activamente en Reader/Acrobat. CVE-2026-34621 (CVSS 8.6). Apache corrige un RCE, una vulnerabilidad de 13 años de antiguedad. Apple iOS 18 security updates, que protege contra DarkSword exploit kit. Cisco security updates para muchos productos, incluyendo un Integrated Management Controller (IMC) authentication bypass que permite ganar acceso de Admin. Fortinet security updates para numerosos productos, incluyendo uno para FortiClient Enterprise Management Server (EMS) vulnerability, CVE-2026-35616, que está siendo activamente explotado. Google Android's April security bulletin y fixed a Google Chrome zero-day que está siendo explotado. Nuevo GPUBreach rowhammer attack. Marimo security update. SAP lanza April security updates para muchos productos, incluyendo un SQL Injection en SAP Business Planning y Consolidation and SAP Business Warehouse. CVE-2026-27681 (CVSS 9.9). wolfSSL SSL/TLS library publica security update que permite manipular certificados digitales.

La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE.UU. (CISA) añadió las vulnerabilidades CVE-2026-35616 (control de acceso inadecuado) y CVE-2026-21643 (Inyección SQL) debido a su explotación activa. Además, hoy Fortinet ha corregido una nueva vulnerabilidad identificada como CVE-2026-39808 - FG-IR-26-100 (CVSS 9.1), una inyección de comandos del sistema operativo en FortiSandbox que podría permitir a un atacante no autenticado ejecutar código o comandos no autorizados a través de solicitudes HTTP diseñadas. CVE-2026-35616 (CVSS de 9.1) es una vulnerabilidad de gravedad crítica basada en CWE-284 (Control de Acceso Inadecuado). La vulnerabilidad afecta específicamente a las versiones 7.4.5 y 7.4.6 de FortiClient EMS, mientras que la versión 7.2 no se ve afectada. La vulnerabilidad permite eludir el acceso a la API sin autenticación previa, posibilitando el escalamiento de privilegios sin credenciales válidas. Según el aviso oficial de Fortinet (FG-IR-26-099) y FG-IR-25-1142 la vulnerabilidad permite a un atacante no autenticado eludir las protecciones de autenticación y autorización de la API y ejecutar código o comandos maliciosos mediante solicitudes HTTP especialmente diseñadas. Esto otorga a los ciberdelincuentes una primitiva de ejecución remota de código (RCE) sin autenticación contra implementaciones de EMS expuestas. Una explotación exitosa permite a un atacante: Eludir los controles de autenticación y autorización de la API sin credenciales. Ejecutar código o comandos no autorizados de forma remota mediante solicitudes manipuladas. Obtener acceso inicial a la red objetivo, lo que permite el movimiento lateral o la implementación de malware. Escalar privilegios dentro del entorno EMS, comprometiendo a los clientes de punto final conectados. La explotación activa de esta vulnerabilidad Zero-Day se registró por primera vez el 31 de marzo de 2026, cuando watchTowr detectó intentos de explotación contra sus honeypots. Los investigadores de seguridad Simo Kohonen, de Defused Cyber, y Nguyen Duc Anh fueron reconocidos por descubrir y reportar responsablemente la falla. Fortinet confirmó la explotación en la práctica en su aviso de emergencia del fin de semana, indicando que "insta a los clientes vulnerables a instalar el parche para FortiClient EMS 7.4.5 y 7.4.6". La rápida confirmación de Fortinet tras la divulgación pública de Defused Cyber ​​subraya la gravedad e inmediatez de la amenaza. Esta es la segunda vulnerabilidad crítica de EMS explotada en cuestión de semanas, lo que genera preocupación sobre la superficie de ataque expuesta por las implementaciones de FortiClient EMS con acceso a internet. La Fundación Shadowserver ha emitido una advertencia urgente a los administradores de FortiClient Enterprise Management Server (EMS). Han identificado más de 2.000 instancias accesibles públicamente en todo el mundo, y se ha confirmado que dos de ellas están siendo explotadas activamente debido a vulnerabilidades críticas de ejecución remota de código (RCE) sin autenticación. Este script permite detectar la vulnerabilidad. Por su parte CVE-2026-21643 (CVSS de 9.1) es una falla de Fortinet FortiClient EMS y ha sido objeto de explotación activa en estado salvaje a partir del 24 de marzo de 2026. La vulnerabilidad en cuestión es una inyección SQL crítica que podría permitir a un atacante no autenticado ejecutar código o comandos no autorizados a través de solicitudes HTTP específicamente diseñadas. La vulnerabilidad afecta solo FortiClientEMS 7.4.4 y se corrige en 7.4.5. La adición al catálogo se produce después de que Defused Cyber dijera que detectó intentos de explotación dirigidos a la falla desde el 24 de marzo de 2026. Otras vulnerabilidades agregadas al catalogo KEV CVE-2020-9715 (CVSS: 7,8): una vulnerabilidad de uso después de la liberación en Adobe Acrobat Reader que podría provocar la ejecución remota de código. CVE-2023-36424 (CVSS: 7,8): una vulnerabilidad de lectura fuera de límites en el controlador del sistema de archivos de registro común de Microsoft Windows que podría provocar una escalada de privilegios. CVE-2023-21529 (CVSS: 8,8): una deserialización de datos que no son de confianza en Microsoft Exchange Server que podría permitir a un atacante autenticado lograr la ejecución remota de código. La semana pasada, Microsoft reveló que un actor de amenazas al que rastrea como Storm-1175 ha estado utilizando CVE-2023-21529 como arma en ataques para entregar ransomware Medusa. CVE-2025-60710 (CVSS: 7,8): una resolución de enlace incorrecta antes de la vulnerabilidad de acceso a archivos en el proceso de host para tareas de Windows que podría permitir a un atacante autorizado elevar los privilegios localmente. CVE-2012-1854 (CVSS: 7,8): una vulnerabilidad de carga de biblioteca insegura en Microsoft Visual Basic para Aplicaciones (VBA) que podría provocar la ejecución remota de código. Fuente: CyberSecurityNews

Una nueva investigación de seguridad revela qué categorías de vulnerabilidades se solucionan rápidamente, cuáles no y qué marca la diferencia.La mayoría de los equipos de seguridad de aplicaciones (AppSec) conocen OWASP Top 10, la lista estándar de la industria de los riesgos de seguridad de software más críticos. Son menos los que saben cuál de esas categorías realmente corrige su organización.En conversaciones con los equipos de seguridad, escucho la misma historia: "Damos prioridad a los aspectos críticos, para que se manejen las cosas importantes". Los datos cuentan una historia diferente. Las tasas de reparación varían drásticamente según la clase de vulnerabilidad de OWASP y no de la manera que la mayoría de los equipos esperan.Los datos provienen del informe Remediación a escala de Semgrep, que analizó patrones de remediación anónimos en más de 50.000 repositorios y cientos de organizaciones durante 2025. La metodología es sencilla: agrupar las organizaciones en dos cohortes por tasa fija (el 15% superior como "Líderes", el 85% restante como "Campo"), luego comparar lo que cada grupo realmente hace de manera diferente.La brecha entre los Líderes y el Campo no tiene que ver con la calidad de la detección o los marcos de priorización. Ambos grupos aplican los mismos filtros de gravedad y presentan los mismos hallazgos críticos. Lo que difiere es la ejecución. Una organización Líder corrige el 63% de sus hallazgos críticos; el otro grupo sólo el 13%. Mismas herramientas. Mismas alertas. Diferentes enfoques.Las brechas de tipos fijos de las que nadie hablaCuando se dividen las tasas de corrección de las pruebas de seguridad de aplicaciones estáticas (SAST) por categoría OWASP, las mayores brechas entre los equipos de alto rendimiento y todos los demás no están en las categorías que se esperarían.Los fallos de autenticación (A07) muestran la brecha más grande en el conjunto de datos: una diferencia de 48 puntos porcentuales entre los Líderes y el Campo. Los líderes se sitúan en casi el 60%, mientras que el resto se sitúa en aproximadamente el 12%. Las fallas criptográficas (A02) tienen una diferencia de 38 puntos.Estas dos categorías comparten un rasgo que puede ser menos evidente solo con la etiqueta OWASP: arreglarlas requiere comprensión arquitectónica, no reemplazo de patrones.Considere cómo se ve realmente una solución de autenticación. Por lo general, no solo se soluciona un ticket ni se agrega una "verificación la línea 47". Se debe rastrear la gestión de sesiones en todo el middleware, comprendiendo el ciclo de vida de los tokens, auditando la aplicación de múltiples factores y descubriendo cómo funciona el almacenamiento de credenciales en las capas de servicio.Una solución criptográfica puede significar migrar de un algoritmo obsoleto a uno moderno en todos los sistemas que leen los datos cifrados. Por lo general, se trata de proyectos complicados, no de tickets rápidos.La SSRF (A10) es una de las únicas categorías donde el Campo supera a los Líderes, mostrando una brecha ligeramente negativa. Las correcciones de SSRF resisten patrones simples porque las listas permitidas se pueden omitir mediante la vinculación de DNS, la codificación de IP y los puntos finales de metadatos en la nube. Ambas cohortes los abordan con un esfuerzo especializado similar, aplanando la brecha observada en otros lugares.La inyección (A03) se encuentra en el medio con una separación de 23 puntos. La solución en sí (consultas parametrizadas en lugar de concatenación de cadenas) es conceptualmente simple. El desafío es encontrar cada punto de inyección en una base de código grande, particularmente cuando la entrada que no es confiable fluye a través de múltiples archivos antes de llegar a un sumidero peligroso.Los desgloses más detallados en el informe reflejan esto: cuando un escáner confirma un hallazgo rastreando el flujo de datos entre archivos (análisis entre archivos), los Líderes corrigen esos hallazgos en un 69% frente al 43% para los hallazgos de un solo archivo. Esto significa que cuando los equipos ven el camino completo desde la entrada del usuario hasta el sumidero peligroso, tienden a tratarlo como un trabajo real, mientras que los hallazgos sin evidencia clara del flujo de datos se posponen.El precipicio de los 90 días: cuando las vulnerabilidades se vuelven permanentesLos datos también revelan algo que, especialmente para aquellos que gestionan grandes retrasos, debería replantear su forma de pensar sobre los hallazgos de seguridad del código antiguo.Es poco probable que los hallazgos abiertos durante más de 90 días se solucionen alguna vez. Entre los equipos de alto rendimiento, solo el 9% de las remediaciones de SAST provienen de un trabajo pendiente de más de 90 días. Para el Campo, es el 16%.Como anécdota, muchos equipos siguen de cerca estos hallazgos trimestre tras trimestre, esperando un buen momento para abordarlos, y ese momento nunca llega. Si una vulnerabilidad ha estado acumulada durante tres meses, la trayectoria predeterminada es que permanezca allí. Trate los 90 días como un punto de escalada, no como una fecha límite sino como una función forzosa. En ese momento, todo hallazgo abierto necesita una de tres disposiciones:remediarlo con tiempo dedicadoaceptar formalmente el riesgo con justificación documentadasilenciarlo como un falso positivo confirmadoDejar que los hallazgos permanezcan indefinidamente sin tomar una decisión no es gestión de riesgos.Qué hacen de manera diferente los equipos de alto rendimientoLos patrones que separan a los Líderes del Campo generalmente implican algún tipo de configuración del flujo de trabajo, no solo la selección de herramientas.Si separamos las vulnerabilidades del código mediante vulnerabilidades de código propio (SAST) y vulnerabilidades introducidas por paquetes y dependencias (SCA), podemos ver que hay una serie de ideas interesantes:El escaneo a nivel de relaciones públicas acelera la corrección 9 veces, pero solo si el flujo de trabajo lo admite. El 96% de los Líderes y el 95% de las organizaciones de Campo ya ejecutan escaneos SAST y SCA en solicitudes de extracción (el código revisa que los desarrolladores abren antes de fusionar los cambios).La adopción del escaneo en los Pull Request (PR) no es el diferenciador. Lo que difiere es si los hallazgos son procesables en el momento de la solicitud para incorporar el código. Los Líderes resuelven los hallazgos SAST detectados en los PR en un promedio de 4,8 días; el mismo tipo de hallazgo en una exploración completa tarda 43 días.Entre las organizaciones Líderes, el 63 % de las correcciones detectadas en PR ocurren el mismo día. Esto tiene sentido cuando se piensa en la experiencia del desarrollador: ya están en el código, el contexto es nuevo y la solución se envía en el mismo PR sin necesidad de ticket ni reasignación.Las reglas de bloqueo generan el mayor aumento de correcciones en el conjunto de datos. Las organizaciones que configuran reglas específicas de alta confianza para bloquear fusiones de código, ven resultados mensurables: los Líderes obtienen una mejora de 12 puntos porcentuales en la tasa de corrección de SAST y SCA; el Campo gana 5 puntos.¿A qué se debe tal disparidad? La diferencia es que los Líderes han creado el flujo de trabajo posterior para respaldar una fusión bloqueada: el desarrollador sabe qué arreglar, la ruta de solución es inequívoca y el bloqueo no se trata como ruido para anular. Restringen el bloqueo a reglas en las que eso es cierto (secretos codificados, inyección de SQL mediante concatenación de cadenas, falta de autenticación en puntos finales sensibles) y evitan el bloqueo de reglas con altas tasas de falsos positivos.El análisis de accesibilidad transforma la priorización de SCA. El conjunto de datos no solo incluye hallazgos de SAST, sino que también incluye hallazgos relacionados con paquetes de terceros gracias a Semgrep Supply Chain.Para las vulnerabilidades de dependencia, saber que un paquete contiene un exploit versus saber si su código base realmente llama a la función vulnerable dentro del paquete cambia el comportamiento. Los Líderes fijan los hallazgos alcanzables de SCA en un 92% frente al 67% de los hallazgos no alcanzables. Esta señal elimina la fatiga de las alertas de dependencia al separar lo que está técnicamente presente de lo que realmente es explotable.Por donde empezarSi está intentando comparar su propio programa, el informe ofrece un diagnóstico simple: observe su tasa de corrección SAST crítica. Si está por debajo del 50%, es probable que el problema no sea la calidad de la detección. Algo entre la detección y la remediación está roto. En mi experiencia, suele ser una de tres cosas: los hallazgos no llegan a los desarrolladores con suficiente contexto; no hay un propietario claro para cada hallazgo o; no hay una ruta de escalamiento para los problemas antiguos.El informe completo de Remediación a escala de Semgrep incluye un análisis de tasa de corrección realizado por CWE (Common Weakness Enumeration, una clasificación más detallada que OWASP), datos específicos del ecosistema en varios administradores de paquetes y un conjunto priorizado de recomendaciones organizadas por cronograma de implementación.Fuente: THN

La inteligencia artificial ya forma parte del día a día de muchos programadores. Es de gran ayuda, actúa en muchas ocasiones como una mano derecha, pero, en otras, se convierte en la mano ejecutora de tareas que deberían ser revisadas por humanos. Esto es algo a lo que Linus Torvalds ha querido poner freno en el marco del lanzamiento de Linux 7.0. Este ha sido directo, como suele, y no es que haya prohibido su uso, pero ha dejado muy claro que no le vale con enviar código sin control. Su idea es que la IA sea una herramienta más, como cualquier otra. Con el lanzamiento de la nueva versión parece que algo ha cambiado. No es una actualización cualquiera; es un cambio de dígito que arrastra consigo años de debates, peleas en foros y una nueva visión. Linux impone normas sobre el código generado por IA, da el visto bueno a Copilot, rechaza la programación chapucera de la IA y responsabiliza a los humanos de los errores; tras meses de intenso debate, Torvalds y los mantenedores llegan a un acuerdo. La prolongada crisis de identidad de la comunidad de código abierto en torno a la inteligencia artificial ha recibido una dosis muy necesaria de pragmatismo. Esta semana, el proyecto del kernel de Linux finalmente estableció una política formal para todo el proyecto que permite explícitamente las contribuciones de código asistido por IA, siempre que los desarrolladores cumplan con nuevas y estrictas normas de divulgación. Las nuevas directrices exigen que los agentes de IA no puedan usar la etiqueta legalmente vinculante "Signed-off-by", sino que requieran una nueva etiqueta "Assisted-by" para mayor transparencia. En definitiva, la política vincula legalmente cada línea de código generado por IA, así como cualquier error o fallo de seguridad resultante, a la persona que lo envía. Esta medida llega tras unos meses caóticos en el mundo del código abierto, poniendo fin a un intenso debate que alcanzó su punto álgido en enero, cuando Dave Hansen de Intel y Lorenzo Stoakes de Oracle se enfrentaron sobre la rigurosidad con la que el kernel debería controlar las herramientas de IA. Linus Torvalds, con su franqueza característica, zanjó definitivamente la discusión, calificando el debate sobre las prohibiciones totales de "una postura inútil". La postura de Torvalds, que constituye la base filosófica de esta nueva política, es sorprendentemente directa: la IA es simplemente otra herramienta. Quienes envían código basura no van a leer la documentación, así que el kernel debería centrarse en responsabilizar a los desarrolladores humanos en lugar de intentar controlar el software que ejecutan en sus ordenadores. Es un enfoque muy razonable y pragmático, sobre todo si se compara con el pánico que se ha apoderado de otros sectores del ecosistema de código abierto. Hasta ahora, los principales proyectos han adoptado enfoques muy diferentes respecto a la IA. En los últimos dos años, distribuciones de Linux prominentes como Gentoo, así como la venerable distribución Unix NetBSD, optaron por prohibir directamente las contribuciones generadas por IA. Los responsables de NetBSD describieron las salidas de los modelos de aprendizaje automático (LLM) como legalmente "contaminadas" debido a la ambigua situación de los derechos de autor de los datos de entrenamiento de los modelos. El origen de esta preocupación radica en el Certificado de Origen del Desarrollador (DCO). Como señaló Red Hat en un análisis exhaustivo a finales del año pasado, el DCO exige que los desarrolladores certifiquen legalmente que tienen derecho a enviar su código. Dado que los LLM se entrenan con conjuntos de datos masivos de código abierto que a menudo tienen licencias restrictivas como la Licencia Pública General de GNU, los desarrolladores que utilizan Copilot o ChatGPT no pueden garantizar con certeza la procedencia de lo que envían. Red Hat advirtió que esto podría infringir inadvertidamente las licencias de código abierto y desmantelar por completo el marco del DCO. Además de los problemas legales, los responsables de los proyectos también se han enfrentado a una batalla perdida contra el enorme volumen de solicitudes. El mundo del código abierto se encuentra actualmente inundado de lo que la comunidad ha denominado "código basura generado por IA" (Slop IA). El creador de cURL tuvo que suspender las recompensas por detección de errores tras verse inundado de código generado por IA; la herramienta de pizarra digital tldraw comenzó a cerrar automáticamente las solicitudes de extracción externas como medida de protección; y proyectos como Node.js y OCaml han visto cómo parches masivos de más de 10.000 líneas generados por IA desataban debates existenciales entre sus mantenedores. La fricción cultural en torno al código de IA no divulgado ha sido aún más volátil. A finales del año pasado, el ingeniero de NVIDIA y mantenedor del kernel, Sasha Levin, se enfrentó a una fuerte reacción negativa de la comunidad tras revelarse que había enviado un parche al kernel 6.15 escrito íntegramente por un LLM sin divulgarlo, ni siquiera el registro de cambios. Si bien el código era funcional, presentaba una regresión de rendimiento a pesar de haber sido revisado y probado. La comunidad se opuso firmemente a la idea de que los desarrolladores pusieran sus nombres en código complejo que en realidad no habían escrito, e incluso Torvalds admitió que el parche no se revisó adecuadamente, en parte porque no estaba etiquetado como generado por IA. El kernel de Linux no es la única comunidad que lidia con las consecuencias del uso no divulgado de IA. En el mundo de los videojuegos, la legendaria (y aún muy activa) comunidad de modding de Doom se dividió el año pasado cuando Christoph "Graf Zahl" Oelckers, el desarrollador principal del popularísimo GZDoom, fue descubierto utilizando parches generados por IA sin su consentimiento. Cuando los miembros de la comunidad lo confrontaron por la falta de transparencia, Oelckers adoptó una actitud sorprendentemente despreocupada, diciéndoles básicamente a sus críticos que "siéntanse libres de bifurcar el proyecto". La comunidad no se dejó intimidar, lo que dio lugar al nacimiento del nuevo UZDoom, ya que la gran mayoría de los colaboradores de GZDoom se unieron a la nueva bifurcación. El incidente de GZDoom y la reacción negativa contra Sasha Levin ponen de manifiesto la importancia de la nueva política del kernel de Linux. La mayor parte de la comunidad de desarrolladores está menos enfadada por el uso de la IA y más frustrada por la falta de honestidad que la rodea. Al exigir una etiqueta de "Asistido por" e imponer una estricta responsabilidad humana, el kernel de Linux intenta despojar al debate de la carga emocional. Torvalds y los mantenedores reconocen la realidad: los desarrolladores usarán herramientas de IA para programar más rápido, e intentar prohibirlas es como intentar prohibir una marca específica de teclado. En resumen, si el código es bueno, es bueno. Si se trata de un código de IA defectuoso que daña el kernel, quien hizo clic en "enviar" será quien tenga que rendir cuentas ante Linus Torvalds. En el mundo del código abierto, esa es una de las medidas disuasorias más efectivas que existen. Fuente: Toms Hardware