Supply Chain Insecurity: Exposing Vulnerabilities in iOS Dependency Management Systems

Dependency management systems are a critical component in software development, enabling projects to incorporate existing functionality efficiently. However, misconfigurations and malicious actors in these systems pose severe security risks, leading to supply chain attacks. Despite the widespread use of smartphone apps, the security of dependency management systems in the iOS software supply chain has received limited attention. In this paper, we focus on CocoaPods, one of the most widely used dependency management systems for iOS app development, but also examine the security of Carthage and Swift Package Manager (SwiftPM). We demonstrate that iOS apps expose internal package names and versions. Attackers can exploit this leakage to register previously unclaimed dependencies in CocoaPods, enabling remote code execution (RCE) on developer machines and build servers. Additionally, we show that attackers can compromise dependencies by reclaiming abandoned domains and GitHub URLs. Analyzing a dataset of 9,212 apps, we quantify how many apps are susceptible to these vulnerabilities. Further, we inspect the use of vulnerable dependencies within public GitHub repositories. Our findings reveal that popular apps disclose internal dependency information, enabling dependency confusion attacks. Furthermore, we show that hijacking a single CocoaPod library through an abandoned domain could compromise 63 iOS apps, affecting millions of users. Finally, we compare iOS dependency management systems with Cargo, Go modules, Maven, npm, and pip to discuss mitigation strategies for the identified threats.

💡 Research Summary

This paper presents the first systematic study of supply‑chain security risks in the iOS software ecosystem, focusing on the three most widely used dependency managers: CocoaPods, Carthage, and Swift Package Manager (SwiftPM). The authors first characterize dependency managers along two dimensions—where dependencies are hosted (centralized vs. decentralized) and how ownership is determined (central authority vs. URL‑based control). These properties define the attack surface for two classes of supply‑chain attacks: dependency‑confusion and package‑hijacking.

CocoaPods, the dominant iOS manager with a central repository, also allows developers to add private spec repositories. When the order of source declarations in a Podfile is not carefully managed, the manager may resolve a dependency from the public repository even though a private version exists. Because CocoaPods supports arbitrary shell commands during installation (e.g., the prepare_command hook), an attacker who registers a malicious package with the same name and version as a private one can achieve remote code execution (RCE) on developer workstations or CI/CD build servers simply by running pod update.

A key observation of the study is that iOS applications leak internal dependency names and versions directly in the compiled bundle. Each CocoaPod is built as a separate framework placed in the app’s Frameworks directory, and the accompanying Info.plist contains CFBundleVersion (the library version) and a CFBundleIdentifier that often includes the org.cocoapods prefix. Consequently, an attacker can reverse‑engineer an app, extract a complete bill of materials, and craft a matching malicious package without needing any external source‑code leaks.

The paper also explores hijacking attacks that target the URL‑based ownership model used by decentralized managers and by CocoaPods when dependencies are fetched from GitHub or custom domains. GitHub’s namespace redirection allows a renamed or deleted account to keep old URLs functional, but once a namespace becomes “abandoned” (e.g., after a user deletes the account and the name is later re‑registered), the same username/repo path can point to an attacker‑controlled repository. Similarly, if a custom domain used in a Package.swift or Podfile expires and is re‑registered, the attacker gains control over the code fetched from that URL. Both scenarios enable silent injection of malicious code into the build process.

Empirical analysis was performed on a dataset of 9,212 iOS applications obtained from the App Store. The authors found that 162 apps (1.76 %) expose sufficient dependency information to be vulnerable to the described attacks. A single hijacked domain could affect 63 distinct apps, potentially reaching millions of end users. The authors responsibly disclosed the findings to nine companies, who confirmed the issues and applied mitigations such as reordering source declarations or explicitly pinning internal sources.

To assess the generality of the problem, the study compares iOS managers with five other ecosystems: Cargo, Go modules, Maven, npm, and pip. All centralized systems (npm, pip, Maven) are susceptible to dependency‑confusion when private and public namespaces collide. Decentralized systems that rely on URL ownership (Go modules, Cargo, SwiftPM) inherit the same hijacking risks when domains or GitHub namespaces are abandoned. The authors note that Go and npm share particularly similar weaknesses in version‑resolution policies.

Finally, the paper proposes concrete mitigation strategies: (1) always declare private sources before public ones or use explicit source URLs for each dependency; (2) enforce lock‑file‑only installations and avoid update unless a deliberate audit is performed; (3) restrict or sandbox any install‑time script execution hooks; (4) monitor GitHub namespace changes and domain expiration, and encourage repository hosts to retire abandoned names more aggressively; (5) redesign resolution algorithms to prefer explicitly specified sources over implicit defaults. These recommendations are applicable not only to iOS but to any language ecosystem that mixes private and public dependency sources.