CocoaPods Orphaned Pod Takeover Vulnerability (CVE-2024-3...

CVE-2024-38368 is a critical vulnerability in CocoaPods, the dependency manager used by the vast majority of iOS and macOS projects, that stems from a decade-old migration decision: thousands of pods left in an "orphaned" state on the CocoaPods Trunk server could be silently claimed by anyone, handing an attacker the ability to push malicious code into any app that still depended on them. Because CocoaPods sits at the center of the Apple developer supply chain, the vulnerability's blast radius wasn't a handful of test projects — researchers estimated that pods flagged as orphaned were pulled into the build of well over three million applications, making CVE-2024-38368 one of the more consequential open source supply chain disclosures of 2024.

What CVE-2024-38368 actually is

CocoaPods runs on a central registry called Trunk, which replaced the old GitHub-based Specs repository in October 2014. When that migration happened, CocoaPods had no reliable way to verify who actually owned each existing pod, so it marked a large number of them — publicly reported as more than 1,800 — as "orphaned." An orphaned pod had no verified owner attached to it in Trunk, even though the pod itself remained a live, resolvable dependency that developers could keep pulling into their Podfile.

To let legitimate maintainers reclaim their work, CocoaPods exposed an ownership-claiming workflow. The problem researchers at security firm EVA Information Security found is that this claiming process didn't actually confirm the claimant was the original author. In many cases the email address on record for an orphaned pod pointed to a domain that had since expired or lapsed, or the claim flow itself could be triggered without adequate verification of identity. An attacker who registered that lapsed domain, or who otherwise abused the weak claim logic, could take ownership of the orphaned package and publish a new version under the existing pod name — a textbook pod takeover. Any project that still referenced that pod, directly or transitively, would then pull the attacker's code on its next pod install or pod update, with no signal to the developer that anything had changed hands.

This is the same class of risk security teams have watched play out repeatedly across npm, PyPI, and RubyGems: an orphaned package or an expired maintainer identity becomes the softest possible entry point into thousands of downstream codebases, because trust was established once, long ago, and never re-verified.

Affected versions and components

CVE-2024-38368 is not a bug in a specific version of the cocoapods gem that developers install locally — it's a server-side trust and authorization flaw in the CocoaPods Trunk service that CocoaPods' own team had to remediate on their infrastructure. That distinction matters for triage:

• Directly affected: The CocoaPods Trunk ownership-claim mechanism, and by extension every pod that was carried over from the pre-2014 Specs-repo era without an owner ever being formally verified in Trunk.
• Indirectly affected: Any iOS or macOS application, SDK, or library that declares a dependency — including transitive dependencies — on one of the orphaned pods. Because CocoaPods dependency graphs are often several layers deep, teams frequently had no idea an orphaned pod was even in their build.
• Not affected in the traditional sense: Pods actively maintained by owners who had already claimed them in Trunk were not exposed to this specific takeover path, though the broader disclosure (which also covered CVE-2024-38366 and CVE-2024-38367) touched other parts of the Trunk authentication flow.

Because the flaw lives in shared registry infrastructure rather than a client library, there is no single "upgrade to version X" fix for consuming applications. Remediation instead depends on CocoaPods' server-side hardening plus downstream teams auditing their own dependency trees for exposure — which is exactly the kind of gap that's easy to miss without dependency-level visibility.

CVSS, EPSS, and KEV context

CVE-2024-38368 was disclosed alongside two related CocoaPods CVEs (CVE-2024-38366 and CVE-2024-38367) as part of the same research effort, and it was rated in the critical range given that successful exploitation requires no authentication from the victim's perspective and results in arbitrary code being pulled directly into downstream builds — effectively a remote code execution path delivered through the software supply chain rather than a network service. As with most registry-trust vulnerabilities, exploitation likelihood hinges less on technical difficulty and more on an attacker's willingness to invest in reconnaissance: identifying which orphaned pods are still widely depended upon, and reclaiming the lapsed identity attached to them.

At the time of writing, CVE-2024-38368 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and there are no public reports of confirmed in-the-wild pod takeovers tied to this specific disclosure — the issue was identified and reported by researchers before it appears to have been abused. That said, KEV and EPSS scores are lagging, population-level signals; they say little about whether your application depends on one of the affected orphaned pods today. A dependency that was orphaned in 2014 and never claimed by an attacker doesn't stop being orphaned just because no exploitation has been reported yet.

Timeline

• October 2014: CocoaPods migrates from the GitHub-hosted Specs repository to the centralized Trunk registry. Pods without a verified owner in the new system are marked orphaned rather than being deleted, preserving them as live, installable dependencies.
• 2023: Researchers at EVA Information Security begin auditing the CocoaPods Trunk infrastructure and identify the orphaned-pod claiming flaw alongside two other Trunk vulnerabilities.
• Prior to public disclosure: Findings are reported to the CocoaPods maintainers, who work with the researchers to remediate the Trunk-side claiming and verification logic.
• June 2024: CocoaPods and EVA Information Security jointly disclose all three vulnerabilities — CVE-2024-38366, CVE-2024-38367, and CVE-2024-38368 — publicly, alongside guidance for maintainers to re-verify ownership of their pods.

Remediation steps

Because the root cause lives in shared registry infrastructure, remediation is a shared responsibility between CocoaPods and every team consuming its ecosystem:

1. Update CocoaPods tooling. Ensure your build environment uses a current, patched CocoaPods release rather than a pinned legacy version, so you benefit from the Trunk-side fixes and any client-side hardening shipped alongside the disclosure.
2. Audit your Podfile.lock for orphaned or unclaimed pods. Cross-reference direct and transitive dependencies against pods that were part of the pre-2014 migration and confirm they have a verified, actively maintained owner on Trunk.
3. Pin dependencies and verify checksums. Avoid loose version constraints that silently pull in new pod releases; pin to known-good versions and validate integrity before promoting a dependency bump through CI/CD.
4. Re-verify maintainer identity for anything your organization publishes. If your team owns pods that predate Trunk, confirm your claim is current and that the contact email tied to your account uses a domain you still control.
5. Monitor for unexpected ownership or release changes. Set up alerting for new versions published to pods you depend on, especially ones with long gaps between releases — a sudden update after years of dormancy is a classic pod-takeover signal.
6. Treat this as a broader iOS/macOS dependency hygiene exercise. CVE-2024-38368 is a CocoaPods-specific instance of a general problem — orphaned package takeover — that also shows up in npm, PyPI, RubyGems, and other registries. A one-time cleanup isn't enough; ownership and provenance need continuous verification.

How Safeguard Helps

CVE-2024-38368 is a reminder that supply chain risk often hides in dependencies nobody has looked at in years — pods, packages, and libraries that were pulled in once and never revisited. Safeguard is built to close exactly that visibility gap for iOS, macOS, and every other stack in your software supply chain.

Safeguard continuously inventories your full dependency graph, including transitive CocoaPods dependencies, and flags packages that show risk signals consistent with orphaned-package or pod-takeover exposure: stale or unverified ownership, dormant packages that suddenly publish new versions, and mismatches between a maintainer's historical identity and current release activity. When a CVE like CVE-2024-38368 is disclosed, Safeguard maps it directly against your live software bill of materials so your team knows within minutes — not weeks — whether any application in your portfolio actually depends on an affected pod, rather than relying on a manual grep through Podfile.lock files across every repo.

Beyond point-in-time CVE matching, Safeguard's provenance and integrity monitoring is designed specifically to catch the pattern behind this disclosure: a trusted package identity changing hands without your team's knowledge. By tracking ownership and publishing behavior over time across your dependency tree, Safeguard can surface anomalous pod takeover activity before it reaches a production build, giving security and mobile engineering teams the same continuous verification for their iOS/macOS dependencies that they'd expect for any other production system.