CocoaPods Trunk Server Email Verification Bypass Enabling...

CocoaPods, the dependency manager that underpins package distribution for a huge share of the iOS and macOS developer ecosystem, disclosed a set of critical vulnerabilities in its trunk server in mid-2024. Among them, CVE-2024-38367 describes an email verification bypass in the CocoaPods trunk server that could let an attacker take over the account tied to virtually any pod, without ever proving they controlled the associated email address. Because trunk.cocoapods.org is the single authoritative registry that resolves pod install and pod update requests across the ecosystem, a successful account takeover here meant an attacker could push malicious code into a library consumed by any app that depended on it — a textbook software supply chain compromise.

CVE-2024-38367 did not exist in isolation. It was disclosed alongside two sibling CVEs (CVE-2024-38366 and CVE-2024-38368) as part of the same research effort into the trunk server's authentication and ownership model. Together they illustrate how a decade-old migration decision quietly left a hole in the trust model of one of the world's largest mobile package ecosystems.

What Is CVE-2024-38367?

CocoaPods authenticates publishers through a session-based email verification flow: when a developer registers as (or claims) the owner of a pod, the trunk server emails a verification link containing a session token. Clicking that link is supposed to prove the requester actually controls the claimed email address before trunk grants them publishing rights over the associated pods.

The flaw underlying CVE-2024-38367 was that the verification session was not strictly bound to the specific email address it was issued for. By manipulating the verification request, an attacker could substitute an arbitrary target email into an active verification flow and have the trunk server treat it as confirmed, effectively completing an email verification bypass without ever receiving or clicking a link sent to that address. Since pod ownership on trunk.cocoapods.org is keyed to verified email identity, this let an attacker walk straight into account takeover of any pod owner account they chose to target — including accounts tied to popular, widely-depended-upon libraries.

From there, the attacker would hold legitimate publishing credentials for the pod. They could push a new version containing malicious code, and every project that pulled in that dependency on its next pod install would happily fetch the tampered release. Researchers estimated the CocoaPods ecosystem hosted publishing rights over roughly a million pods used across an estimated 3 million-plus apps, giving a sense of the blast radius a single successful exploitation chain could reach.

Affected Versions and Components

Unlike a typical library CVE with a patched version number, CVE-2024-38367 lived entirely in server-side infrastructure — the trunk.cocoapods.org registry and session-verification service, not the cocoapods gem or client CLI that developers install locally. There is no "upgrade to version X" fix for end users because the vulnerable logic never shipped as installable code; it ran only on CocoaPods' own servers.

That said, the practical blast radius touched everyone downstream:

• CocoaPods trunk server — the account and ownership-verification subsystem was the vulnerable component.
• Pod maintainers — anyone with a claimed or claimable pod on trunk was a potential account-takeover target.
• Downstream iOS/macOS developers — any project with a Podfile referencing an affected pod was exposed to receiving a malicious update if an attacker exploited the bug against that pod's owner.

Researchers also flagged a related structural weakness that compounded the risk: when CocoaPods migrated from a static, Git-based specs repository to the trunk server model back in 2014, thousands of existing pods were left without a verified owner in the new system. Those "orphaned" pods sat unclaimed for roughly a decade — a long window during which the ownership and verification logic, including the flaw behind CVE-2024-38367, could have been abused with no owner around to notice.

CVSS, EPSS, and KEV Context

The three CocoaPods CVEs from this disclosure were all rated in the critical-to-high range, reflecting how directly they translated into remote, unauthenticated compromise of the software supply chain:

• CVE-2024-38366 (remote code execution in trunk) was rated CVSS 10.0, critical.
• CVE-2024-38367 (email verification bypass / account takeover, the subject of this post) was rated CVSS 9.3, critical.
• CVE-2024-38368 (insecure ownership/authorization handling) was rated CVSS 9.1, critical.

At the time of writing, CVE-2024-38367 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and there is no public evidence of confirmed in-the-wild exploitation. That is a meaningfully different risk posture than an actively weaponized bug, but it should not be read as low risk: the vulnerability lived in shared registry infrastructure for years, publishing malicious code through it would look like a routine version bump, and supply chain compromises of this shape are notoriously hard to detect after the fact. Treat the absence from KEV as "not yet observed," not "not exploitable."

Timeline

• Discovery — Security researchers investigating the CocoaPods trunk server's authentication model identified the email verification bypass along with the related RCE and ownership-authorization issues.
• Responsible disclosure — Findings were reported privately to the CocoaPods maintainers ahead of public release, giving the project time to remediate server-side before details went public.
• Remediation — The CocoaPods team patched the trunk server's verification and session logic directly, since the fix lived entirely in server infrastructure rather than a client release. Orphaned-pod handling was also tightened as part of the response.
• Public disclosure (2024) — CVE-2024-38366, CVE-2024-38367, and CVE-2024-38368 were published with details of the vulnerabilities, their scale of impact, and the CocoaPods project's fixes.

Remediation Steps

Because the vulnerable code lived on CocoaPods' own servers, there is no client-side patch for developers to install for CVE-2024-38367 itself — the trunk server has already been remediated by the CocoaPods maintainers. Your remediation work is about verifying you weren't affected and hardening how you consume the ecosystem going forward:

1. Audit your dependency tree. Review your Podfile.lock for every pod you depend on, directly and transitively, and check for unexpected version bumps or ownership changes around the disclosure window.
2. Verify pod provenance. Cross-check that pod owners and publish history look consistent with the project's known maintainers; be suspicious of pods that changed hands or had their first release in years right before or after the disclosure.
3. Pin and vendor critical dependencies. Where feasible, pin exact versions and consider vendoring high-trust dependencies rather than resolving them dynamically from trunk on every build.
4. Rotate CocoaPods trunk credentials. If you own pods on trunk.cocoapods.org, re-verify your account, rotate any session tokens, and confirm your registered email is current and under your control.
5. Generate and monitor an SBOM. Maintain a software bill of materials for your iOS/macOS builds so you can quickly answer "are we exposed" the next time a registry-level vulnerability surfaces in the iOS supply chain.
6. Add anomaly monitoring for CI/CD pulls. Alert on unexpected changes to dependency checksums, unexpected new maintainers, or version releases that don't match a project's normal cadence.

How Safeguard Helps

CVE-2024-38367 is a clean illustration of a pattern Safeguard is built to catch: the vulnerability wasn't in your code, it was in the trust chain your code depends on. A single compromised registry account, undetected, becomes every downstream app's problem the moment CI pulls the next build.

Safeguard's software supply chain security platform is designed to close exactly this gap:

• Continuous SBOM generation and monitoring across your iOS, macOS, and cross-platform dependency graphs — including CocoaPods, Swift Package Manager, and mixed-ecosystem builds — so you always know which pods, versions, and maintainers you're trusting.
• Provenance and ownership-change detection that flags when a dependency's publisher, signing identity, or ownership record shifts unexpectedly, the exact signal that would have surfaced account takeover activity stemming from an email verification bypass like CVE-2024-38367.
• Policy-driven CI/CD gating that blocks builds from pulling dependency versions that fail provenance or integrity checks, rather than discovering a compromised pod after it's already shipped to production.
• Vulnerability intelligence correlation that maps disclosures like CVE-2024-38366, CVE-2024-38367, and CVE-2024-38368 directly against your actual dependency inventory, so security teams aren't manually cross-referencing CVE feeds against every Podfile.lock in the org.
• Alerting and remediation workflows that give AppSec and platform teams a fast path from "a registry-level vulnerability was disclosed" to "here is our exact exposure and what to fix," instead of a scramble across every repository.

Registry-level trust failures like the one behind CVE-2024-38367 are a reminder that supply chain security can't stop at scanning your own repositories — it has to extend to the infrastructure and identity model of every package ecosystem you build on. Safeguard exists to give teams that visibility before an account takeover in a dependency's registry becomes an account takeover in your production app.