CocoaPods, an open-source dependency manager used in over three million apps coded in Swift and Objective-C, has left thousands of packages exposed and ready for ingestion for nearly a decade — thereby creating opportunities for supply chain attacks of iOS and macOS apps, according to security researchers.
Israeli firm EVA Information Security announced the discovery in a blog post on Monday. EVA claims that CocoaPods in 2014 migrated all “Pods” – a file describing project dependencies – to a new “Trunk server” on GitHub. In this migration, the authorship of all Pods was reset and the authors requested to restore their work.
Some didn’t, and at the time of writing, 1,870 Pods remained unclaimed by their owners, leaving them orphaned – and available.
This mess is now known as CVE-2024-38368, which EVA told us has a CVSS score of 9.3. The issue earned this rating because all orphaned Pods were associated with a default email address and a public API for requesting unclaimed Pods was available until the end of 2023 – without the need to provide any ownership verification.
To request a Pod, all an attacker has to do is pass a specific CURL request and ready – would be free to modify the Pod and insert malicious code.
The EVA researchers wrote that they saw no evidence that this mess was used. But given the billion-plus iOS devices in use — and the fact that apps from Meta, Apple, Microsoft, TikTok, Amazon and others have been found to be using vulnerable Pods — it’s entirely possible that “thousands to millions” of apps were exposed to exploitation by the vulnerability.
The fact that we’re even aware of this fustercluck is also somewhat coincidental: the researchers discovered them when they were running a red team exercise for a client, not through deliberate research on CocoaPods.
If the EVA team could find them, so could someone else.
Have a lot of fun: Breach CocoaPods, everyone
A second vulnerability—CVE-2024-38366, CVSS 10.0—allows remote code execution on the Trunk server by inspecting mail exchanges using a vulnerable RFC822 Ruby packet. By exploiting the fact that the aforementioned package executes host commands against a provided email address without proper validation, a command can be injected at the end of bash to dump session tokens, poison client traffic, or even trigger a server shutdown .
Third, there is a vulnerability in the Trunk server’s own source code – CVE-2024-38367, CVSS 8.2 – that has an interesting exploit chain relying on standard email scanning software functionality to steal session validation tokens without the need for user interaction.
CocoaPods authenticates new devices using an email sent to users who request a session, the researchers note — but the authentication relies on nothing more than a client confirming their email address by clicking a link.
“We found that the server would accept a fake XFH header and use it explicitly to create a URL sent to the client for session verification,” the researchers complained. Clicking on the link generated by the fake XFH header passes a session token straight to the spoofer.
Here’s where zero-click comes in: As email scanning services check links to compare them to known phishing patterns, researchers note that automated tools eventually follow the link and transmit the session token on behalf of the targeted user. oops
“We discovered that almost every Pod owner is registered with their organizational email on the Trunk server, making them vulnerable to our zero-click ingestion vulnerability,” the EVA team warned. “It was pretty easy to take over almost any organizational account on Pod [a target] system because their email security solutions actively scan every link sent to their inboxes.”
The researchers noted that they actually used the method “to take over the accounts of the owners of some of the most popular CocoaPods,” which “we could use … for highly damaging supply chain attacks that could affect the entire ecosystem of Apple’.
As noted above, the CocoaPods team fixed the issues – and appears to have done so months ago – although the details were not widely known until EVA published its research today.
“The worst-case scenario is that an attacker could have used this technique to gain access to our core database,” Horta Terox, a volunteer with the CocoaPods project, wrote in October. “We delete all session keys, which ensures that no one other than those with access to their emails can post updates to these Pods.”
The supporting CocoaPods they connect to The register did not respond to questions prior to publication.
Another open source security caveat
“The vulnerabilities found in CocoaPods serve as an important reminder of the risks associated with relying on open source code and third-party dependencies,” the researchers wrote, a message we’ve heard often in recent years.
As a supply chain attack, this CocoaPods vulnerability could have found itself in the illustrious company of such malicious exploits as Log4Shell, the recent failure of Polyfill, SolarWinds, and others. Fortunately, that doesn’t seem to be the case – but it’s impossible to know for sure.
“While there is no direct evidence that any of these vulnerabilities are being exploited in the wild,” the EVA researchers note, lack of evidence is not evidence of absence.
The researchers recommend that everyone using CocoaPods review their dependencies for orphaned Pods, perform checksum checks on all code downloaded from the CocoaPods Trunk server, review all third-party code, update their CocoaPods installations, and as generally be more alert to open source software supply chain risks.
With roughly 97 percent of all commercial codebases believed to be using open source components, this advice applies to almost everyone—CocoaPods user or not. ®
