CVE-2024-38366 is a critical remote code execution (RCE) vulnerability in the CocoaPods Trunk server, the infrastructure that powers pod trunk push and every other publishing action for the CocoaPods ecosystem. CocoaPods is the dominant dependency manager for iOS and macOS development, and the Trunk server is its single point of truth for who owns a pod and what code ships when a version is published. A flaw that lets an attacker execute arbitrary code on that server isn't just a bug in one project's infrastructure — it's a potential foothold into the build pipeline of a huge share of the mobile apps running on iPhones today.
The vulnerability was one of three CocoaPods issues disclosed together by researchers at EVA Information Security, who found that a series of misconfigurations dating back to 2018 had quietly weakened the security of the Trunk publishing workflow for years without anyone noticing. CVE-2024-38366 was the most severe of the three because it moved beyond account takeover and pod-ownership abuse into full server-side code execution — the kind of access that could be used to tamper with the pod-publishing pipeline itself.
What Is CVE-2024-38366?
CocoaPods migrated away from a single centralized specs repository toward the Trunk service model to let individual maintainers publish pod versions directly, authenticated through an email-based ownership and session-verification flow. CVE-2024-38366 concerns the CocoaPods Trunk server's handling of that publishing path: a component of the server processed maintainer-supplied input in a way that could be manipulated to execute operating system commands on the underlying host. Because the Trunk server sits at the center of the CocoaPods supply chain — validating specs, storing pod metadata, and serving the source-of-truth index that the pod install and pod update commands rely on — remote code execution there is effectively a worst-case scenario for a package registry. An attacker with that level of access could, in theory, tamper with pod metadata, redirect legitimate pod names to malicious sources, or otherwise interfere with the integrity of packages downloaded by iOS and macOS developers around the world.
It's important to be precise about what was affected: this was not a vulnerability in the CocoaPods CLI gem that developers install locally, nor in a specific pod version that teams need to bump in their Podfile. It was a defect in CocoaPods' own server-side publishing infrastructure at trunk.cocoapods.org. That distinction matters for remediation — there is no local patch to gem install your way out of, because the fix had to happen on CocoaPods' infrastructure itself.
Affected Versions and Components
CVE-2024-38366 affected the CocoaPods Trunk server infrastructure rather than a specific released version of the CocoaPods client. The issue existed in the server-side code responsible for handling pod publishing and had been present since the Trunk service's session and verification mechanisms were reconfigured back in 2018. Any pod published through the Trunk server during the affected window was, in principle, exposed to the surrounding weaknesses in the publishing pipeline, which is why the CocoaPods maintainers treated remediation as an infrastructure-wide event rather than a simple version bump. Because CocoaPods underpins dependency resolution for a large fraction of iOS apps, the practical blast radius extended to any project pulling pods through the standard trunk-based publishing flow — which, for most modern CocoaPods users, is effectively all of them.
CVSS, EPSS, and KEV Context
The National Vulnerability Database rated CVE-2024-38366 at the top of the severity scale — a CVSS v3.1 base score of 10.0, reflecting a network-exploitable vulnerability requiring no authentication or user interaction, with the potential for complete impact on confidentiality, integrity, and availability of the affected server. A maximum CVSS score for a registry-level RCE is not surprising given what an attacker could theoretically reach: the trust root for a major open-source dependency ecosystem.
As of this writing, CVE-2024-38366 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and no confirmed reports of in-the-wild exploitation have surfaced publicly. EPSS scoring has likewise stayed modest, consistent with a vulnerability that was privately reported, fixed at the infrastructure level before public disclosure, and never had a working exploit released. That said, EPSS and KEV status reflect observed exploitation activity, not theoretical risk — a critical flaw in centralized package infrastructure remains a high-value target for supply chain attackers regardless of whether exploitation has been publicly confirmed, and organizations should weigh the CVSS score and the nature of the affected component more heavily than the absence of KEV listing.
Timeline
The story behind CVE-2024-38366 is as notable as the vulnerability itself. According to EVA Information Security's public write-up, the underlying weaknesses trace back to 2018, when changes to the Trunk server's verification and session-handling configuration silently degraded the security of the pod-ownership and publishing workflow. That degradation went undetected for roughly four years — earning the disclosure the title "Four Years of Silence" in the researchers' own report.
EVA's researchers identified the issues, including the RCE condition later assigned CVE-2024-38366, and reported them privately to the CocoaPods maintainers. CocoaPods — with the involvement of the broader open-source infrastructure stewards supporting the project — worked to remediate the Trunk server issues, which included invalidating existing sessions, closing off the exploitable code path, and requiring maintainers to re-verify ownership of pods that had been left in an ambiguous or unclaimed state. The three related CVEs (CVE-2024-38366, CVE-2024-38367, and CVE-2024-38368) were publicly disclosed together in mid-2024, once the server-side fixes were in place.
Remediation Steps
Because the vulnerable component was server-side infrastructure, most of the direct remediation happened on CocoaPods' end rather than in individual codebases. Even so, teams that rely on CocoaPods for iOS dependency management should take the following steps:
- Re-verify pod ownership if you're a maintainer. If your organization publishes pods, confirm your Trunk account sessions and ownership records are current, and re-authenticate if CocoaPods flagged your session for re-verification during the remediation.
- Audit your Podfile.lock for unexpected changes. Review pinned pod versions, checksums, and source URLs for anything that doesn't match your own release history, particularly for pods your team doesn't actively maintain.
- Treat unclaimed or "orphaned" pods with caution. Part of the broader CocoaPods disclosure involved pods that had no verified owner. Avoid adding new dependencies on pods with unclear maintenance status, and consider forking or vendoring critical unmaintained dependencies.
- Keep the CocoaPods CLI current. Running an up-to-date CocoaPods client ensures you benefit from any client-side hardening that accompanied the server-side fix.
- Strengthen CI/CD isolation. Ensure build pipelines that run
pod installdon't have broader access to production secrets or signing credentials than necessary, so that a compromised dependency can't pivot into more sensitive systems. - Add CocoaPods to your dependency monitoring and SBOM practice. Many teams generate software bills of materials for backend services but overlook mobile dependency managers like CocoaPods, Swift Package Manager, and Carthage. Given that CVE-2024-38366 targeted the trunk server itself, visibility into what pods you consume — and when their metadata or maintainers change — is essential.
How Safeguard Helps
CVE-2024-38366 is a reminder that software supply chain risk doesn't stop at the packages you directly install — it extends to the registries and trunk servers that distribute them. Safeguard is built to close exactly that visibility gap for teams shipping software that depends on open-source ecosystems like CocoaPods.
Safeguard continuously maps your iOS dependency tree and generates accurate, mobile-aware SBOMs that include CocoaPods, Swift Package Manager, and other package sources many scanning tools miss. When a pod you depend on changes ownership, gets republished unexpectedly, or shows signs consistent with the kind of trunk-server abuse seen in the CocoaPods disclosures, Safeguard surfaces that anomaly before it reaches your build pipeline. Our platform correlates CVE intelligence — including registry- and infrastructure-level vulnerabilities like CVE-2024-38366 — against your actual dependency graph, so security teams aren't left guessing whether a headline vulnerability actually touches their apps.
Beyond detection, Safeguard helps enforce provenance and integrity checks in CI/CD, flagging dependencies pulled from unverified or recently reassigned sources before they're compiled into a shipping build. For organizations that rely on the open-source ecosystem underpinning iOS development, that combination of dependency visibility, CVE correlation, and pipeline enforcement is what turns incidents like the CocoaPods trunk server compromise from a scramble into a non-event.