Hello @mbabker ! I wish to contribute but I am unable to setup the project. I am stuck on the step where I have to run npm ci.
Also I had to add --ignore-platform-reqs when I had to run composer install.

This issue is not specific to 4.0 and should only be addressed on that branch only if fixing it requires B/C breaks (3.x does not require you to run Composer or NPM).

@mbabker From which branch should I clone? And where can I find the setup instructions for contributing?

@mbabker can you please answer the Question?

This really needs to be addressed with some urgency, if you don't believe me build a "src" library extension that installs files in the "libraries/src" directory and see how long it takes you to FUBAR a Joomla installation. Or, ya know, just ignore a huge concern in the system architecture that allows users and developers to too easily break Joomla; wouldn't be the first time architectural concerns I've raised have been ignored (most likely because I'm the one raising them).

Given the JSST elected to not treat this as a security issue, I am now publicly posting the detailed writeup as to why this should have been considered one, as emailed to the JSST on November 8.

Why is this a security issue? Through the Joomla extension installer, a properly crafted package can be installed that can replace the core files in the following directories:

• libraries/cms
• libraries/legacy
• libraries/php-encryption
• libraries/src
• libraries/vendor

The Joomla architecture expects that only Joomla library extensions are contained within the libraries directory, adding new folders to this path without creating library extensions is therefore discouraged.

A proper fix for this issue would be to move all code that is not a library extension to another path (the cms, legacy, src, and vendor directories at a minimum). Considering that would either force a new root directory and would probably create upgrade issues trying to remove/replace such a large number of files, two other acceptable alternatives are available:

1. Register library extensions for all core paths within the Joomla application database
2. Introduce a blacklist in the library extension installer to prohibit installing a library extension matching the name of a protected core directory

The JSST considered this to not be a security issue because a default installation of Joomla only authorizes super users access to com_installer. However, this is not adequate enough of a security mechanism as the root issue lies within the Installer library API which can be extended and directly implemented by extensions which may or may not make as strict of ACL checks as core does. Therefore, relying on com_installer as the sole security mechanism is not acceptable.

A proof of concept package can be downloaded from https://www.babdev.com/downloads/destructor.zip

A blacklist sounds like a simple and effective way to deal with the issue. Or is there some downside I don't see to having a blacklist for library names?

A blacklist is the simplest and probably most maintainable solution given the limited number of reserved directories inside the libraries folder.

Please test #27300
Closing as we have a PR.