This blog post is part of an ongoing series exploring how AI related tools aimed at developers can be exploited to compromise their machines. As these tools increasingly integrate deep system access, they also expand the attack surface available to threat actors.
In our first post, we outlined a remote code execution vulnerability in Cursor. With this second entry, we turn our attention to Ollama.
What is Ollama?
Ollama is an open-source tool for running large language models locally, with over 143k GitHub stars. It topped Runa Capital’s 2024 ROSS Index as the hottest open-source startup.
It offers an easy‑to‑use CLI and access to a library of popular models like Llama, Deepseek, or Mistral. By keeping everything on your machine, it gives you full control over your data and enhances privacy.
The Bug
As mentioned before, Ollama is open-source and therefore I was able to review its code. Like many cross-platform applications it uses Electron, which is a way to write desktop applications using web technologies like JavaScript, HTML, and CSS.
I started by looking at the macos/src/app.tsx which is what gets rendered when you install the Ollama application. It shows an install button that, when clicked, attempts to create a symlink at the /usr/local/bin/ollama which requires administrator privileges. Here is the code responsible for it:
The interesting part of this code is the “ollama” variable, which is inserted into the shell command. This introduces a command injection vulnerability if an attacker can control the Ollama executable path.
While trying to exploit this, I encountered an alert that prompts the user to move the executable to the Applications folder. This makes exploitation more difficult, as the user would have to click the “Do Not Move” button, which is less likely.
I wanted to see how Ollama checked whether it was launched from the Applications folder. I found that it uses an Electron API called isInApplicationsFolder.
It claims to check whether the application is running from the systems Application folder, however, looking at the implementation we find this:
Interestingly, in addition to checking if the application was launched from the system applications directory, the function also checks if the path contains the string “Applications” to support cases where the user has another Applications directory, which is great for us because it means we can make the Ollama installer skip the “Move to Applications” dialog.
Putting it all together
To turn Ollama into a dropper, I created the following folder structure that abuses both a command injection vulnerability and a logic flaw in how the app verifies its install location.
At the core of the attack is a malicious symlink named Ollama, which points to a nested path that includes an injected shell command. This symlink is critical: not only does it allow us to inject our payload into the shell command Ollama uses to install its CLI tool, but it also helps us avoid raising suspicion by preserving the expected folder structure and launching the real, signed Ollama app.
Importantly, the entire payload can be delivered as a ZIP file. That matches Ollama’s distribution format: a plain ZIP archive holding the signed binary.
Because the Electron’s app.isInApplicationsFolder() merely looks for the substring “Applications” anywhere in the path and my bogus tree contains that word, the “Move to Applications?” dialog never appears. When the victim double-clicks the symlink, macOS launches the notarised Ollama binary as usual, Gatekeeper is satisfied, and the user is soon prompted (legitimately) to authorise the CLI install. At that moment the installer expands the symlink, the injected $( … ) runs, and the demo payload (open /System/Applications/Calculator.app) fires. An attacker could, of course, swap in any command, turning a trusted, signed installer into a stealthy dropper.
Why Apple’s Process Matters for Attackers
Developing software for Apple’s ecosystem involves navigating strict requirements, from enrolling in the Developer Program to verifying your identity and obtaining Apple-issued certificates. Once your app is ready, it must pass Apple’s rigorous review process, ensuring functionality and compliance with their guidelines before being made available to users.
While these steps can feel tedious, they serve a critical purpose. Apple’s strict policies create significant hurdles for malware developers. By requiring verified developer accounts and certificates, Apple ties app distribution directly to accountable sources. This means malicious software can only be distributed through the exploitation of a Gatekeeper bypass vulnerability or use a valid developer account, which leaves a clear trail for authorities to trace.
In this case, Ollama’s flawed installer logic effectively gives attackers a signed and notarized tool they can exploit to execute malicious code.
Responsible Disclosure
We followed standard responsible disclosure practices and made multiple attempts to contact the Ollama team via email, starting in late 2024. After receiving no response through official channels, I reached out directly to one of the Ollama maintainers on December 16, 2024, and was told that a fix was in progress.
However, more than six months have passed since that conversation, and as of the time of writing, the latest version of Ollama remains vulnerable to this issue. While Ollama is an open-source project, its growing popularity and the fact that it distributes signed and notarized binaries to end users make this vulnerability particularly concerning. We are publishing this research in the interest of transparency and to help raise awareness about this risk.
The post Hijacking Ollama’s Signed Installer for Code Execution appeared first on Blog.
