10 year old vulnerabilities in widely used dev tool include a CVSS  10.0 remote code execution  bug.

Tim Looks Grim

What’s the craic? Nate Nelson broke the story: Apple CocoaPods Bugs Expose Millions of Apps to Code Injection

“CVE-2024-38366”
CocoaPods is a platform that developers in Apple’s ecosystem use to add and manage external libraries. [It’s] used by more than three million apps, including the most popular ones in the world, [such as] Instagram, X, Slack, AirBnB, Tinder, and Uber, to name just a few. This makes the pods prime targets for hackers.
…
CVE-2024-38366 [is] a remote code execution (RCE) opportunity, … assigned a critical 10 out of 10 CVSS rating. … The type of malicious code such an attacker could silently add to a pod would be limitless. … CVE-2024-38368 earned a critical 9.3, and … CVE-2024-38367 [is] 8.2.

Which devices are vulnerable? As John Leonard explains, Almost every Apple device vulnerable

“Potential impact is enormous”
So ubiquitous is CocoaPods that, by exploiting these vulnerabilities, an attacker could potentially infect almost every Apple device. … CocoaPods is a dependency manager for Swift and Objective-C projects.
…
The vulnerabilities in CocoaPods stem from a migration in 2014 to a new “Trunk” server, which left thousands of packages “orphaned,” with their original owners unidentified. The public API endpoint for claiming pods was still open nine years later, meaning that anyone could claim these orphaned pods without any verification. In addition, an insecure email verification process and a vulnerable Ruby package could have allowed attackers to execute arbitrary code on the Trunk server and manipulate or replace the packages.
…
The potential impact of these vulnerabilities is enormous.

Horse’s mouth? EVA’s Reef Spektor and Eran Vaknin: Major risk of supply chain attacks

“Absence of evidence is not evidence of absence”
An attack … could infect almost every Apple device, leaving thousands of organizations vulnerable to catastrophic financial and reputational damage. … Developers and DevOps teams that have used CocoaPods in recent years should verify the integrity of open source dependencies used in their application code … (including iOS, macOS, and other Apple device software). … Special attention needs to be paid to software that relies on orphaned CocoaPods packages.
…
In recent years, many … software supply chain attacks … have occurred (Log4Shell is probably the most famous example). … Dependency managers, such as CocoaPods … NPM, Maven, and PyPI, play a critical role in … software supply chains. … They allow developers to verify the integrity and authenticity of the components. … Compromise of the dependency manager itself poses a severe threat.
…
While there is no direct evidence of any of these vulnerabilities being exploited in the wild, absence of evidence is not evidence of absence. Potential code changes could affect millions of Apple devices around the world, across iPhone, Mac, AppleTV, and AppleWatch.

Good riddance? TimeWinder thinks so:

Honestly, CocoaPods can’t go away soon enough to make me happy. They’ve always been a clumsy glue-on mechanism posing as a package manager, with a bunch of manual steps and such. If I never have to type “pod install” only to have it tell me I need to “pod update” and then “pod install” again … it’ll be too soon. Swift Packages is a decade newer, easier to use, better integrated, and hopefully more secure.
…
It’s also not a bad thing if developers just stop using third party libraries for simple stuff. I’ve seen code where someone decided they needed a third-party library to draw a border on a control, or to parse comma-separated strings. Every library you add is a potential problem downstream, even not counting malware injection.

Concerning. Certainly, isodev seems concerned:

Could the researchers have done anything differently? Roland6 has an idea:

I know it’s borderline blackmail, [but] EVA could have proved the … orphaned pod reclaim process was flawed and done the community a favour by [claiming] all orphaned CocoaPods.

I think you ought to know storagedude is feeling very depressed:

This seems like one of those software supply chain bugs that’s going to take a very long time to eradicate.

Is the lesson that you should audit your dependencies? No way, thinks Martin Blank:

How do you reasonably do that? … The dependency stacks are so tall these days that trying to audit the dozen libraries you call on (for a small project) means auditing the dozens they rely on—and the hundreds that layer relies on. If you have a project with thousands of dependencies, it becomes impossible to vet them all, and it is impossible to recreate the functionality in anything resembling an economically viable fashion without a high risk of introducing your own vulnerabilities.
…
This is an extraordinarily difficult problem: Use someone else’s code and hope that you can patch your stuff when someone else using it gets whacked, or write your own stuff and hope that you don’t create code that will have very few outside eyes on it.

Meanwhile, Bill Neal sounds slightly sarcastic:

Apple already prevented any malware security issues long ago by forcing people to code in Objective C. Remember? Their apps are the most secure. /s

And Finally:

Plant timelapse supercut

Hat tip: My Name

Previously in And Finally

You have been reading SB  Blogwatch by Richi  Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites—so you don’t have to. Hate mail may be directed to  @RiCHi, @richij, @[email protected], @richi.bsky.social or [email protected]. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.

Image sauce: European Union, 2023 (cc:by; leveled and cropped)