Linux arrastra fama de ser el sistema más seguro que Windows, y buena parte de esa reputación se atribuye a su reducida cuota de mercado. Esa explicación, sin embargo, se queda corta: el motivo real tiene que ver con cómo gestiona los permisos y los paquetes, algo que no sustituye a un antivirus, sino que lo complementa, como demuestran el ataque al repositorio AUR y una prueba práctica con ClamAV que os contamos a continuación.
El argumento de la cuota de mercado explica por qué los atacantes prefieren Windows, pero ignora un factor decisivo: el diseño de permisos de Linux obliga a cualquier script descargado a pedir autorización explícita antes de ejecutarse. A eso se suma que el ataque sufrido por el AUR en junio de 2026 no buscó llegar a una base de usuarios masiva, sino explotar la confianza que depositan los usuarios en los paquetes de la comunidad. Vamos a repasar cómo funciona esa barrera de permisos y qué papel juega realmente un antivirus como ClamAV en este sistema.
La cuota de mercado explica solo la mitad de la historia
La cuota de mercado inferior a la de Windows reduce el interés de los atacantes en desarrollar malware masivo para Linux, y esa es la explicación que circula con más frecuencia entre los usuarios. El motivo real va más allá de los números: el sistema de permisos impide que un archivo se ejecute solo porque se ha descargado, algo que Windows no exige con la misma rigidez en sus configuraciones por defecto.
Linux no deja que un script se ejecute porque sí. Hace falta que alguien conceda permiso de ejecución explícito, un paso que en Windows no siempre resulta tan exigente, donde ejecutar un archivo puede ser mucho más inmediato. Esa barrera obliga a los atacantes a dar un paso más: no basta con que la víctima descargue el archivo, también tiene que autorizarlo de forma consciente. Esta arquitectura, más que la ausencia de malware dirigido, es la que sostiene buena parte de la fama de seguridad de Linux frente a Windows, y explica por qué muchos usuarios conviven sin antivirus instalado durante años sin sufrir incidentes graves.
El ataque al AUR de junio de 2026 fue por la confianza
En junio de 2026, el Arch User Repository (AUR) sufrió un ataque que desmontó la idea de que nadie se molesta en atacar Linux. Los hackers inyectaron malware en más de 400 paquetes adoptando repositorios abandonados y modificando sus instrucciones de compilación. Sonatype elevó después la cifra a unos 1.500 paquetes afectados en todo el AUR, una magnitud que sorprendió a buena parte de la comunidad.
El mecanismo era sencillo pero efectivo: al instalar los paquetes comprometidos, el sistema arrastraba también un paquete npm llamado atomic-lockfile, que desplegaba malware con comportamiento de rootkit para robar credenciales. El objetivo no era alcanzar al mayor número de máquinas posible, sino aprovechar la confianza que los usuarios depositan en un repositorio gestionado por la propia comunidad. La irrupción de la inteligencia artificial ha facilitado además que personas con conocimientos de programación limitados puedan montar este tipo de campañas dirigidas al robo de credenciales, lo que amplía el abanico de actores capaces de intentarlo.
Así frenan los permisos de Linux un script sin permiso
Una prueba en un entorno Ubuntu sobre WSL deja claro cómo funciona esta barrera en la práctica. Al intentar lanzar un script de una sola línea descargado de internet, el sistema lo rechazó de inmediato por falta de permisos, y lo mismo ocurrió al intentar crear un archivo directamente en una carpeta protegida del sistema.
Hay un matiz importante: la cuenta usada en la prueba pertenecía al grupo sudo, así que la seguridad final seguía dependiendo de las decisiones de quien administra el equipo. Precisamente ahí fallaron las víctimas del ataque al AUR, que instalaron paquetes comprometidos sin revisar qué había cambiado en sus instrucciones de compilación, concediendo sin saberlo el permiso que el malware necesitaba para actuar. Cuidar los hábitos en la terminal, sobre todo cuando trabajamos como administradores o recurrimos a sudo, marca la diferencia entre que un ataque fracase o acabe colándose en el sistema.
ClamAV detecta lo conocido, no decide en quién confiar
ClamAV es la referencia gratuita y de código abierto para quien quiera instalar antivirus en Linux. Tras instalarlo en un entorno Ubuntu y descargar su base de datos, con unos 3,6 millones de entradas, creamos un archivo EICAR para comprobar su funcionamiento de primera mano.
El archivo EICAR es un fichero de prueba inofensivo, de entre 68 y 128 bytes, desarrollado por el European Institute for Computer Antivirus Research junto con la Computer Antivirus Research Organization para validar antivirus sin necesidad de recurrir a malware real. ClamAV lo detectó al instante y devolvió el aviso «EICAR-signature FOUND» nada más lanzar el escaneo. El problema aparece con amenazas que no están en su base de firmas: un malware nuevo, poco evidente o camuflado dentro de un ejecutable legítimo puede pasar desapercibido sin que el antivirus llegue a detectarlo. Tener antivirus instalado ayuda, pero no garantiza estar a salvo de todo tipo de amenazas.
Si el antivirus solo cubre una parte del problema, la protección real depende de combinar el diseño del sistema con unas rutinas básicas que podemos aplicar sin mucho esfuerzo. Evitar que archivos o carpetas tengan permisos totales sin necesidad y asegurarnos de que los paquetes proceden de fuentes de confianza reduce buena parte del riesgo desde el primer momento.