What you’re describing is a supply chain attack, where validator nodes in the sync committee are somehow corrupted by third-party software dependencies. However this isn’t a problem unique to the ethereum ALC, or even blockchains.
Its simply not the case Its highly improbable that a majority of beacon chain validators in the ALC can be corrupted by MEV middleware, given the current level of ethereum’s client diversity (different validator implementations)
For example, with the Lighthouse and Lodestar implementations, the MEV middleware can only interact with the validator process via a well-defined and constrained Builder API. The MEV middleware can only pass execution layer payloads (normal eth1 blocks) to the validators.
Malicious MEV middleware cannot cause honest validators to sign fraudulent sync committee attestations. Honest validators still have a duty to participate in consensus, which in turn ensures that the execution payloads provided by MEV middleware are valid according to majority of validators. This constrains the kinds of attacks that MEV middleware are able to orchestrate.
That said, Robert is correct in that MEV middleware can be used as a secretive coordination layer for dishonest validators. However, in that case, we’re back to the honesty arguments which myself and @petscheit have described.