In May 2024, researchers at EVA Information Security disclosed three vulnerabilities in the trunk server that powers CocoaPods — the dependency manager behind the majority of iOS and macOS apps built with Swift and Objective-C — that had gone unpatched for roughly a decade. The flaws, tracked as CVE-2024-38366, CVE-2024-38367, and CVE-2024-38368, gave attackers a path to remote code execution on CocoaPods' own infrastructure and, separately, a way to seize control of at least 1,866 "orphaned" pods left ownerless since a January 2014 migration. CocoaPods hosts more than 100,000 libraries and sits upstream of an enormous share of consumer and enterprise mobile software, meaning a successful takeover of even a handful of widely used pods could have propagated malicious code into thousands of downstream apps before anyone noticed.
CocoaPods' maintainers patched the trunk server in October 2023, several months before the public write-up went live — a gap that gave the ecosystem time to update tooling but also meant the vulnerable window had already existed, undetected, for nearly ten years. The episode has become one of the reference case studies security teams point to when arguing that package registries deserve the same scrutiny as production infrastructure.
What Happened, and When
CocoaPods launched its centralized "trunk" service in 2014 to replace a looser, GitHub-based publishing model. During that migration, ownership records for a subset of pods were never properly re-associated with their original maintainers' accounts. Those packages sat in a lurking state: technically live and installable by any developer running pod install, but with no verified owner able to push updates through the normal authenticated flow. EVA's researchers found that this orphaned state was itself exploitable — an attacker could claim ownership of any of the 1,866 affected pods without ever proving they controlled the associated email address, because the verification logic trusted client-supplied session data rather than independently confirming identity.
A second flaw sat in the trunk server's handling of pod publishing itself. By crafting a malicious podspec, researchers demonstrated arbitrary code execution on the server that processes and distributes pods to the broader network — not just a way to poison a single package, but a foothold on the infrastructure responsible for validating and serving all of them. A third issue compounded the authentication weaknesses, allowing session and verification data to be manipulated so that new "owners" could be attached to pods without ever completing the email confirmation step CocoaPods' own security model depended on.
Taken together, the three bugs meant an attacker didn't need to compromise a single maintainer's credentials or laptop — the trust model of the registry itself could be bypassed. CocoaPods disclosed the fixes with CVSS scores as high as 10.0, the maximum severity rating, reflecting how directly the flaws could translate into unauthenticated remote code execution and package takeover.
The Scale Problem: Why CocoaPods' Blast Radius Is Enormous
CocoaPods isn't a niche tool. Independent estimates cited alongside the disclosure put CocoaPods in use across a large majority of the top apps in the Apple App Store, spanning consumer social apps, banking apps, and enterprise mobile software. Once a pod is pulled into a Podfile.lock, its code compiles directly into the shipped binary — there is no runtime sandbox, no network boundary, and often no automated re-scanning once an app has passed App Store review. A malicious update pushed into a popular pod doesn't need a user to click anything; it rides along with the next routine pod update a mobile engineering team runs.
This is precisely the mechanism that has made open-source registries the preferred entry point for supply chain attacks over the last several years, from the event-stream npm backdoor to the xz-utils compromise embedded deep in Linux build tooling. What made the CocoaPods case distinct is that the weakness wasn't a socially-engineered maintainer handoff — it was structural, sitting in the registry's own account-recovery and publishing logic, unpatched since the infrastructure was built.
A Pattern, Not an Anomaly
Package registries across ecosystems have repeatedly struggled with the same category of problem: verifying that the entity pushing a new version of a widely-depended-upon library is who they claim to be. npm has dealt with maintainer account takeovers via credential stuffing and expired-domain email hijacks. PyPI has seen typosquatting campaigns exploit weak namespace controls. RubyGems has faced its own orphaned-gem reclamation issues. CocoaPods' orphaned-pod count — nearly 1,900 packages sitting in a claimable, unverified state for a decade — is a concrete illustration of a risk every registry maintainer now has to model explicitly: abandoned or loosely-owned packages accumulate quietly, and each one is a latent supply chain entry point that doesn't require breaching anyone's laptop, only understanding the registry's own account logic well enough to abuse it.
For mobile-focused organizations specifically, this incident is a reminder that dependency risk isn't confined to the server-side stacks most application security programs are built around. iOS and macOS build pipelines pull in CocoaPods, Swift Package Manager, and (on the Android side) Gradle and Maven dependencies that rarely get the same SBOM discipline, reachability review, or CI gating that backend services receive. Mobile app security has historically leaned on static analysis of the compiled binary and App Store review, neither of which is designed to catch a registry-level takeover of a transitive dependency.
What Security Teams Should Do Now
Even with the CocoaPods trunk server patched, the incident leaves several practical follow-ups for any team shipping iOS or macOS software:
- Audit
Podfile.lockhistory for any pods that were orphaned prior to the fix, and re-verify the maintainer identity and recent commit activity of pods your build depends on, particularly ones that haven't been updated in years. - Pin exact versions and hashes rather than loose version ranges, so a compromised or takeover-published release can't silently enter a build.
- Monitor for ownership and maintainer changes on dependencies on an ongoing basis — not just at initial adoption — since registry-level account takeovers are, by definition, invisible to a one-time dependency review.
- Extend SBOM and dependency inventory practices to mobile build pipelines, treating CocoaPods, SPM, and Gradle dependency graphs with the same rigor applied to backend package managers.
None of these steps require heroics, but they do require dependency management to be treated as a continuous security control rather than a one-time approval gate — which is exactly where most mobile engineering organizations still fall short today.
How Safeguard Helps
Safeguard is built for exactly this class of problem: dependencies that look clean at import time but carry registry-level or maintainer-level risk that only surfaces later. Safeguard's SBOM generation and ingest capabilities give teams a continuously updated inventory of every CocoaPods, SPM, npm, and backend dependency in use, so an incident like the CocoaPods trunk disclosure can be answered in minutes rather than days of manual Podfile.lock archaeology. Reachability analysis then narrows that inventory down to the dependencies whose vulnerable or attacker-controlled code paths are actually exercised by your application, cutting through alert noise so teams aren't chasing every orphaned pod in the ecosystem — only the ones that matter to them. Griffin AI, Safeguard's reasoning engine, correlates ownership changes, disclosure timing, and package behavior to flag suspicious dependency updates before they ship, and Safeguard's auto-fix PRs let engineering teams pin, upgrade, or replace risky pods directly in their existing pull request workflow without manual triage. Together, these capabilities turn a supply chain incident that once required a decade to surface into something detectable, explainable, and fixable in a single sprint.