Millions of Apple apps have been unknowingly exposed to severe security vulnerabilities for years, thanks to issues in a popular dependency manager called CocoaPods.
This platform, used widely by developers to integrate external libraries (or “pods”) into their apps, has harbored critical flaws that could have allowed hackers to inject malicious code into countless applications.
CocoaPods is a cornerstone in the Apple development ecosystem, supporting over 100,000 libraries and used by more than three million apps, including major names like Instagram, Slack, Tinder, and Uber. This wide adoption makes it a prime target for attackers, and the recent discovery of several significant vulnerabilities by E.V.A Information Security underscores the immense risk.
The Uncovering of CocoaPods Vulnerabilities
On Monday, E.V.A Information Security revealed that CocoaPods had been hiding a trio of serious vulnerabilities. The most severe, identified as CVE-2024-38366, is a remote code execution (RCE) flaw that received a critical rating of 10 out of 10 on the CVSS scale. Other bugs include a critical issue related to orphaned pods (CVE-2024-38368) with a 9.3 severity rating, and a session verification-hijacking bug (CVE-2024-38367) rated at 8.2.
According to Alon Boxiner, CEO and co-founder of E.V.A, the impact of these vulnerabilities is “enormous” and difficult to fully quantify due to the widespread use of CocoaPods.
A Decade-Long Issue
CocoaPods was launched in 2011, but the roots of these issues trace back to 2014, when the platform shifted from a GitHub-based authentication system to a new “Trunk” server. This server became the centralized hub for repository management and distribution but brought along some significant security flaws.
One of the most glaring issues was that ownership of all pods was reset during this transition. Developers had to reclaim their pods by authenticating via their GitHub accounts, but many failed to do so. As a result, thousands of pods were left “orphaned” and without an active maintainer—a situation that persists today.
Shockingly, the public API endpoint that allowed developers to claim these pods remained accessible for nearly a decade. This meant that, from 2014 to 2023, anyone with knowledge of this vulnerability could have taken control of these orphaned pods, modified them, and pushed malicious updates to any apps that depended on them.
This oversight left even high-profile apps vulnerable, with evidence of orphaned pods found in the documentation of major apps like Facebook, Safari, Microsoft Teams, TikTok, and Snapchat.
The Most Severe Vulnerability: Max-Severity RCE
Ironically, the worst vulnerability within CocoaPods stemmed from an open-source component used for validating user email addresses. This component, a RubyGem package known as rfc-22, had vulnerable methods that could be exploited by attackers to inject malicious code during the Trunk account validation process.
With this exploit, an attacker could gain complete control over the Trunk service, allowing them to alter pod specifications, inject malicious code, or even hijack entire pods. This level of access would enable attackers to execute a wide range of harmful actions, all without detection.
A Needle in a Haystack
While there is no clear evidence that these vulnerabilities have been exploited in the wild, the nature of these supply chain bugs makes detection extremely difficult. The vast number of pods at risk, combined with the ease with which these vulnerabilities could be concealed, creates a scenario where finding an exploit would be like searching for a needle in a haystack.
Given the potential risks, E.V.A recommends that developers who have used CocoaPods in their apps before the vulnerabilities were patched in October 2023 should take immediate steps to mitigate the risks. This includes checking for orphaned pods, thoroughly reviewing third-party code dependencies, and ensuring all components are up to date.
E.V.A’s findings highlight the importance of addressing supply chain risks in software development. As Boxiner pointed out, “It’s not only about how you develop what you develop, but also about the dependencies you rely on—which can be significant blind spots.”