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.