Recently, I discovered a dylib injection vulnerability in the Spotify desktop client.
Before proceeding with a full disclosure, I decided to check HackerOne to verify whether this issue fell within Spotify’s responsible disclosure scope.
As shown in the screenshot below, the vulnerability type is indeed listed as in-scope on their HackerOne program page.
What Is a Dylib Injection and Why Is It Dangerous?
Dylib injection (short for dynamic library injection) is a technique that allows an attacker to load a malicious dynamic library (dylib) into the memory space of another application typically without the user’s knowledge or the app’s consent. This technique is primarily seen on macOS systems, where applications frequently rely on dynamically linked libraries at runtime.
In a dylib injection attack, the injected library can intercept or modify the app’s behavior, monitor user activity, steal sensitive data, or even introduce a persistent backdoor. Depending on how the target app is structured, an attacker may be able to bypass integrity checks, hijack functionality, or escalate privileges.
POC
The following code is a simple reverse shell implementation, which we’ll use as the payload within our malicious dylib.
Once injected into the target application, this code will initiate a connection back to our listener, allowing remote command execution.
clang -dynamiclib -framework Cocoa -o reverse.dylib reverse.m
After compiling our malicious dylib containing the reverse shell, we need to inject it into the target binary.
To automate this step, I wrote a simple bash script that uses the tool insert_dylib.
Of course, there are many other utilities available that can achieve the same result, but this one is lightweight and effective for our proof of concept.
The next step is to set up Netcat in listening mode, and then launch the Spotify application.
As shown in the screenshot, Spotify runs normally here’s no visible crash or abnormal behavior.
Meanwhile, we successfully obtain a reverse shell, without the victim noticing anything unusual.
This demonstrates how stealthy and effective a dylib injection attack can be when integrated into a legitimate-looking process.
Final Thoughts
After reporting this issue to HackerOne, I received a response stating that the vulnerability was classified as informational and therefore not eligible for a reward
I was genuinely surprised by their response.
According to HackerOne’s reasoning, a vulnerability is only considered valid if it’s remotely triggerable. This dismisses the entire class of local or post-exploitation attack vectors even though the desktop application is explicitly listed as in-scope on their program page.
To better understand if this was an isolated case, I did some research and found that many other security researchers share the same concerns. Several have reported similar experiences, where impactful local vulnerabilities were downplayed or outright ignored due to overly narrow triage criteria.
Here are a few links that reflect this wider frustration within the security community:
Here are a few links that reflect this wider frustration within the security community:
Researchers criticize HackerOne over triage, mediation woes
A TechTarget article reports on widespread concerns around slow triage, poor communications, and unfair mediation especially when researchers disagree with severity assessments. One expert said:
https://news.ycombinator.com/item?id=22404022
Hackerone triagers are really a triager?
https://www.reddit.com/r/bugbounty/comments/1kgu9gh/hackerone_triagers_are_really_a_triager/?utm_source=chatgpt.com
A quick search online reveals a significant underlying issue with how vulnerability triage is handled on platforms like HackerOne. Many researchers report being dismissed without clear explanations or proper justification.
This blog is not intended as an attack on HackerOne, but rather as a shared reflection on the use of such services and whether companies should rely entirely on these platforms. While they are undoubtedly valuable tools, in my opinion, those responsible for vulnerability triage should receive thorough training. This process is both serious and delicate and should never be underestimated.