SAN FRANCISCO — July 6, 2026. More than 100,000 iOS applications depend on CocoaPods, the dependency manager that has quietly become the connective tissue of Apple's app ecosystem since its 2011 launch. That scale is exactly why a string of disclosures over the past two years — from a trio of critical CVEs in the CocoaPods trunk server to a malicious ad SDK that sat undetected in the App Store for seven years — has forced security teams to treat "iOS SDK" and "supply chain risk" as synonyms rather than separate categories. The pattern is consistent: a single compromised pod, SDK, or build server can silently ride into millions of end-user devices through apps that never triggered a single App Store red flag.
This report examines the two defining incidents that shaped how the industry now thinks about malicious iOS SDKs and pods — the 2024 CocoaPods trunk server vulnerabilities and the SourMint ad-fraud SDK — and what they collectively reveal about the exposure facing mobile engineering teams today.
The CocoaPods Trunk Server Vulnerabilities
In April 2024, researchers at EVA Information Security disclosed three vulnerabilities in the CocoaPods "trunk" server — the central authority that verifies ownership and publishes new pod versions to the roughly 100,000-package registry that underpins the majority of iOS and macOS apps built with CocoaPods.
- CVE-2024-38368 — An authentication flaw meant thousands of pods migrated during a 2018 infrastructure switch to a new trunk server were left in an "orphaned" ownership state. Anyone could claim ownership of these packages simply by requesting a session against an unclaimed pod's metadata, then push a new malicious version under the original package name. EVA's researchers found this affected an estimated 1,866 pods that were still being actively pulled into production apps.
- CVE-2024-38366 — A remote code execution flaw in the trunk server itself, triggered by a crafted email-verification request. Successful exploitation could have handed an attacker control of the server responsible for validating and distributing every pod in the registry — a single point of compromise for the entire CocoaPods supply chain.
- CVE-2024-38367 — A verification-bypass issue in which the email-confirmation link sent for new pod ownership claims did not strictly validate the session token, allowing attackers to intercept or forge the confirmation flow and seize control of a package without the legitimate owner's consent.
None of the three vulnerabilities required the victim developer to do anything unusual — no phishing click, no fake package name, no typosquat. A pod already sitting in a Podfile.lock for years could simply change hands and start shipping different code on its next routine pod update. EVA's disclosure noted that some of the affected pods had over 100 million cumulative downloads, and that verification for the underlying trunk service had effectively been broken since the 2018 migration — meaning the exposure window was measured in years, not days. CocoaPods maintainers patched the flaws following coordinated disclosure, but the incident is a durable case study in how a dependency manager's infrastructure, not just its package contents, is now squarely inside the attack surface.
SourMint: Seven Years Inside the App Store
If the CocoaPods CVEs illustrate infrastructure risk, the SourMint SDK disclosure illustrates the risk of the SDKs themselves. In August 2020, researchers publicly detailed an advertising SDK distributed by Mintegral, embedded in more than 1,200 iOS applications with a combined download count estimated in the hundreds of millions. Analysis showed the SDK was logging and exfiltrating URLs from clicked ads — including deep-linking data that could expose which other apps a user had installed — and was engaging in ad-fraud behavior by spoofing attribution data to steal credit for ad clicks it never legitimately drove.
What made SourMint notable wasn't just its behavior; it was persistence. The SDK had reportedly been present in the App Store since at least 2013, passing through Apple's App Review process repeatedly, embedded inside apps built by developers who had no visibility into what the third-party monetization SDK they'd integrated was actually doing at runtime. App Review evaluates the compiled app binary as a whole — it was never designed to attribute a specific data-exfiltration behavior to a specific bundled SDK buried three dependencies deep.
Why iOS SDKs and Pods Are a Distinctly Attractive Target
Three structural properties of the iOS SDK ecosystem make it a persistently attractive target for attackers, and they explain why these incidents recur rather than remaining isolated events:
- Opaque binary distribution. Many commercial iOS SDKs — ad networks, analytics, crash reporting, attribution — ship as closed-source binary frameworks rather than auditable source. A development team integrating the SDK has no practical way to diff behavior between versions without binary analysis tooling most app teams don't run as a matter of course.
- Trust concentration in package infrastructure. CocoaPods, Swift Package Manager, and Carthage each represent a centralized trust root. Compromising the registry, the trunk server, or a widely-used maintainer account has a multiplying effect far beyond any single package's own code quality — as the orphaned-pod CVE demonstrated at scale.
- Downstream blast radius invisible to the app developer. A pod maintainer's account takeover, or a monetization SDK's silent behavior change, propagates through every app that has that dependency pinned — often without triggering a version bump that would prompt a manual review. Teams frequently don't know precisely which SDKs, at which versions, are compiled into their shipping binary at any given moment.
The Present-Day Exposure Window
Neither of these incident classes has fully closed. CocoaPods' own maintainers have acknowledged that trust in the ecosystem's historical package provenance cannot be retroactively verified for every pod migrated in 2018 — meaning apps still holding old lockfile references carry residual risk regardless of the CVE patch. Meanwhile, the SDK-behavior problem generalized by SourMint has only expanded as mobile apps have added more third-party SDKs for monetization, attribution, analytics, and fraud detection — each one a new binary dependency running with the same permissions as the host app, and each one a candidate for the same class of undisclosed data-collection behavior that took seven years to surface in Mintegral's case.
For security and engineering leaders, the takeaway from both incidents is the same: dependency trust cannot be a one-time decision made at integration time. It has to be continuously verified — at the registry level, at the SDK-behavior level, and at the point where a vulnerable or malicious component would actually be reachable and exploitable inside your specific app.
How Safeguard Helps
Safeguard is built for exactly this class of problem. Our platform generates and ingests SBOMs across iOS, Android, and backend codebases so security teams have a continuously updated, ground-truth inventory of every pod, SDK, and transitive dependency actually compiled into a shipping build — not just what's declared in a Podfile. Reachability analysis then determines whether a flagged CVE, like the CocoaPods trunk-server vulnerabilities, or a known malicious SDK actually executes in a code path your app can reach, cutting through alert noise so teams fix what matters instead of triaging every advisory equally. Griffin AI, Safeguard's security reasoning engine, correlates package provenance signals — maintainer changes, ownership transfers, anomalous version bumps — against threat intelligence to flag supply chain tampering before it ships to production, the same pattern that let orphaned CocoaPods sit unclaimed for years. When a fix is available, Safeguard opens auto-fix pull requests that bump the affected dependency to a patched, verified version, closing the gap between disclosure and remediation from weeks to hours. Together, these capabilities give mobile security teams the continuous, evidence-based visibility that App Review and manual dependency audits were never designed to provide.