Anytime any plugin does anything, the submission of that "anything" into the Drupal subsystem proceeds to pass that plugin's payload to every single plugin in the system so they can make modifications. What those modifications are, you do not know, they are just applied and then your modified payload is accepted into the subsystem to modify whatever it modifies.
If you are installing rogue code then you will have a bad time.
Modules/themes on drupal.org which show "Stable releases for this project are covered by the security advisory policy" are written by trusted users. There is no other protection from rogue code because they are inherently able to access the database. It utterly doesn't matter what extension points the code supports and how because of that. In very broad strokes, if you are using any CMS which a) accesses a database b) allows installing additional code and it runs that in the same process as the CMS code accessing the database -- then you are vulnerable to rogue code. Like, a headless CMS where the frontend only talks to it via an API is protected from rogue code in the frontend part but that's about it.
This means the Drupal ecosystem is vulnerable to a supply chain attack, yes but ... um ... that doesn't make Drupal design insecure, does it?
Consider that often, far too often, a hierarchically senior non-tech individual mandates that various plugins be installed, without security checks or plugins that fail security checks, but that manager/c-suite individual demands the change. Far too often.
Most of the time they will go from drupal.org luckily there's very little else
And once again, what does rogue code has to do with Drupal? Nothing. The same would happen with almost any system. Name any CMS which is actually used in the wild and doesn't get compromised if you install rogue code right into the codebase.
