What potential exists for AppImage abuse to inject malware?


We’ve recently transitioned to using Linux Mint in our workplace and one of the things I appreciated about Linux over Windows is the requirement to enter a superuser password in order to install and run executable files. This level of security by itself prevents the possibility of drive-by downloads or malware infection by malicious email attachments and negates the need for expensive resource-consuming antivirus software.

We recently downloaded an AppImage of Scribus for our art department and I noted that all that was needed to execute it was to chmod it and run it, no password needed. This to me represents an apparent potential security hazard analogous to using freely executable files on Windows.

Now given that Linux is currently not in widespread use in a desktop context compared to Windows, malware authors have devoted little time to exploiting it; but given the invasive nature of Windows 10 resulting in our company and quite a number of others transitioning to Linux, it is only a matter of time before criminals start creating malware for Linux in order to target this growing market. When they do, easy and convenient solutions such as AppImage are likely to become targets for abuse as a delivery platform.

So my question is, has any research been done into the potential for this ease of execution as a means for criminals to create and inject malware? In particular I’d like to know:

  1. Is it possible for a malicious website to use Javascript to automatically download, chmod and execute an AppImage file without user consent, awareness or intervention?

  2. Is is possible to ‘pre-chmod’ an AppImage file as executable and attach it to an email, such that a user opening the attachment would cause the file to execute without further action being required on the part of the user?

  3. What privileges do AppImage files run with; that is, are they intrinsically sandboxed, do they run only with current user privileges or can they potentially gain superuser privileges?

  4. In the event that AppImage files are found to pose a security risk, what measures can be taken to prevent them from being downloaded and executed?

  5. What security measures are in place at AppImage (for example required presence of source code) to prevent malware being encoded as AppImage files and distributed through the platform?

While convenience is certainly a positive trait of the AppImage project, my experience is that convenience all too often comes at the expense of security. I would therefore appreciate other peoples’ thoughts on this as well as any studies or research that has been conducted in this area.


Hello, the questions you pose are are about how executables are handled on Linux in general, not about AppImage in particular. Linux does not require the user to enter a root password to set the executable bit. If you don’t want your users to be able to do this, you could mount the home partition with the ‘noexec’ mount option, although clever users will still find ways around this.
I am not aware of a way to mark a file as executable by default without any user intervention, apart from putting it into e.g., a .tar.gz or .tar.bz2 archive.

AppImage does not improve or worsen the Linux security model in this regard. There is sandboxing available for AppImage, but it is entirely optional.

  1. I don’t think this is possible
  2. Only inside an archive as far as I know (but most users will just unpack a .tar.gz or.tbz2 without thinking much about it)
  3. Normal user privileges. Superuser only if the user explicitly runs them e.g., with sudo, or the AppImage requests root rights through mechanisms like gksu. No enforced sandboxing
  4. Like with any other binary
  5. No such requirements to produce an AppImage. So trust must be established regarding where users download AppImages from. GPG signatures (as .asc files) strongly recommended. Signatures embedded inside the AppImage planned


Thank you for your response, your assistance is much appreciated. I will look into setting the noexec mount option; I’m not overly concerned with “clever” users finding their way around it as our staff are aware of company policy in regard to IT security including the consequences of intentional breaches. I’m mainly concerned with preventing accidental or unintentional execution of files, which your response has clarified adequately. Thanks again for your help.