Code execution when a directory in sites/ is writeable and could potentially have an attacker install Drupal to it

Updated Issue Description

Problem Statement:

The issue pertains to a security vulnerability in Drupal Core, where it is possible to create a settings.php file in an unintended directory, especially when the web server has write permissions to the sites directory. This is particularly risky if you're running a multisite setup where requests for multiple (especially wildcard) domains/subdomains would be handled by Drupal.

Context:

This issue was initially flagged on security.drupal.org, but the link is inaccessible, giving an "access denied" message. It was later publicized through PSA-2015-001 → . The PSA is still marked as critical and suggests that the risk is higher if the Drupal installation has not gone past the database configuration phase, meaning install.php is still accessible.

Current Mitigation:

The Security Review module can warn about this issue but is not part of Drupal Core. Therefore, new users may not be aware of this mitigation step.

Old Patches:

The patches from the private issue along with the full discussion of feedback on them are in comment #3 on this public issue.

How to Replicate:

To find yourself in this situation, you would go through the initial steps of setting up a Drupal site. You might think that completing the drush site-install command or reaching the "finished" page of install.php means you're safe. However, if you've left the sites directory writable by the web server, you're still at risk for this relatively uncommon scenario.

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment 9 months ago →
🇦🇺Australia thursday_bw
update issue and add recommendations with questions for the security team.
Comment 9 months ago →
🇺🇸United States greggles Denver, Colorado, USA
Questions:

Clarification Needed: Could we get clarification on where the suggestion to use hook_requirements() originated?

Security Team Update: Given the critical nature of this issue, could the security team provide an update on why this hasn't been addressed?

Action Plan: Considering that the Security Review module is not a guaranteed fix, this issue should remain open until a more concrete solution is implemented in the core.

Answers, in order:

All the context for it is in comment #4.

The Security Team determined this could be fixed in public. It's up to the community of people who care about issues like this to work on a fix for it.

IMO it would also be fair to close the issue since the consequences appear to be not that significant. This issue has not been identified to the security team as a root cause of a site takeover.

I've removed these recommendations from the summary - they feel more appropriate to exist in a comment to me at this point.
Comment 9 months ago →
🇺🇸United States greggles Denver, Colorado, USA
Comment 9 months ago →
🇦🇺Australia thursday_bw
"IMO it would also be fair to close the issue since the consequences appear to be not that significant. This issue has not been identified to the security team as a root cause of a site takeover." seems fair to me.
Should we just do it?