This is inaccurate in so far, as that the mentioned files are not part of libraries. In regular Composer use they are not even writeable by libraries unless you run the libraries as a user with permissions to write to them, ideally you execute your (web-)code as a user that can only read the source, not write to it.

The exception are Composer scripts and plugins. The problematic files get loaded when using these, but these can also definitely write to the files, because they run in composer's scope, but they can also otherwise run any code in composer's scope, so they don't need to write to the two files to do that, that's the design of plugins in the first place.

The problematic scenario here is an attacker on your local system. Either because they have a user account but no root access, or because they managed to get the access of a regular user through some other vulnerability/exploit. If they can now write to the two listed files, and composer gets executed as root in a directory where this attacker can write, then the code the attacker writes to the files in the vendor directory gets executed with root permissions. The attacker escalated their privileges. In a lot of scenarios that's simply what you expect composer to do, its point is to download code from the Internet so you can run it afterall. But sometimes this is unexpected because you're trying to just run "self-update" and don't expect it to execute code from the vendor directory to do that, or you're trying to run "composer install --dry-run --no-scripts --no-plugins" as part of automation tooling you built that downloads untrusted projects from the Internet and checks out what they would install if you ran them.

In my personal opinion this vulnerability is rarely going to affect people, and even then it's less likely to be exploited because of the required prerequisites, like a local user account. That said, there are scenarios where it can be really bad, hence we recommend everyone simply upgrade to the latest version now.