You're right, deliberate injection isn't common in the open source world, in part because the process makes it expensive, but mostly because it's not necessary.
Most open source projects that gain traction have users who exercise lots of use cases and need careful custodians who respond to problems and know their committers, so arbitrary pull requests from new developers go through a vetting process, and in order to get their code in, participants have to be invested in growing a reputation and building trust. This all makes deliberate injection of vulnerabilities difficult.
And it's not necessary because software is vulnerable by default. From an attacker's perspective, there is no reason to go through a trust charade to inject vulnerabilities, because there are already going to be some in any codebase, you just have to look for them. And because the code is open, you can look for them without anyone knowing you are looking for them.
In the closed source/commercial world, injection is much more common, for instance:
For those attackers at that scale it makes sense to build and then sacrifice trust, though that is a very expensive exercise. The infamous case of Dual_EC_DRBG is instructive, because it was an injection in a world that resembled open source in terms of dynamics, with the result that a previously trusted actor (NSA) working in a previously unblemished open process (NIST) has forever sacrificed their own and the process' credibility. Check wikipedia for details.
The model you suggest- third parties utilizing a process that does not require trust to inject attacks or vulnerabilities- accurately describes the delivery model for web malware.