Potential Information Disclosure in Core Paths: /core/install.php and /update.php Reveal Internal System Details

I am moving this issue to normal priority because there is a workaround—a site owner may delete these file in production deployments.

There are many ways for a sophisticated attacker to determine whether a site is Drupal.

The issue here is not determine that the site is on Drupal but specific error message handling as per https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Shee...

What does "Drupal core paths are accessible" mean in this bug report?

We have hardened these pages recently to prevent stack traces and error messages that disclose site specific information from being shown. Additionally as @cilefen mentions you can delete these files or use the vendor hardening plugin to delete them for you, this is documented at https://www.drupal.org/node/3424527 →

Can you give a precise example of any error messages that still disclose information? It is trivial to tell whether a site is running on Drupal even if install.php and update.php are removed, so hiding the existence of Drupal from these pages is not relevant or useful.

Hi @longwave,

The message that disclose information is that eg. on /update.php

Access denied: You do not have permission to access the update script.

In this way an attacker know that the update script is here, more hover i see was removed the message with variable of settings php that is good.

The old one show more information:

In order to run update.php you need to either have "Administer software updates" permission or have set $settings['update_free_access'] in your settings.php.

The issue isn't about to hide that a site leverage on Drupal CMS (that would also be a bad accessibility practice), but to not provide specific information with 4XX pages to potential attackers as per OWASP Error handling guidilnes: https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Shee...

There is also more or less same issue for. lot of ajax request in the BE that if spoofed provide lot of useful information to an attacker, eg. if we request with curl an admin page we have this in the HTML response "currentPathIsAdmin":true so that is a relevant information for attackers that are trying to understand modules installed on Drupal instance.

Please let me know if still something unclear or that need more detailed examples and description

BR
Alberto

Morehover, i know that i should delete or protect with a VPN that pages but this should not be very well documented and disclaimed on d.org? also yestarday i was checking use cases on d.org and no one has removed this files, maybe they just don't know that!

The problem with doing any of these things

• A generic 403 or 404 page.
• A redirection to the homepage or login page.
• No visible Drupal branding or technical guidance.

is that it reduces usability; a site owner who is following documentation to visit update.php, but is not logged in, will be confused and not know what to do next if they don't receive an informative message. Security and usability is always a tradeoff and we believe we have the right balance here.

not provide specific information with 4XX pages to potential attackers

How does "Access denied: You do not have permission to access the update script." provide any useful information to potential attackers? It provides enough information to a site owner to tell them what the problem is, but doesn't reveal anything else (for example why they don't have permission), and it's widely documented that Drupal has an update script at update.php, so hiding its existence further is not necessary.

Ok that is why we protect some internal path with VPN for production websites.

The fact is that this 403 page is providing an explicit message to the attackers (mostly scripts not human) that is in contrast with OWASP guidelines.

Usability can still be preserved after authentication. Once logged in as an admin, the user can receive a detailed and helpful message, that’s the right place for technical explanations.

Many CMS platforms, including Adobe Experience Manager, WordPress and Joomla, also follow this model: deny access to system paths unless authenticated, and provide details only to trusted users.

This isn’t about hiding Drupal or update.php — it’s about not helping attackers identify or confirm behaviors and configurations, even unintentionally. Security headers, generic messages, and authenticated-only technical guidance are well-known best practices in hardening production systems.

We can preserve usability without exposing technical details. For instance:
The behaviour like in AEM could be that the user is redirected to login page with generic message like:

Access Denied
You are not authorized to access this resource.

I think that the Admin that have to update a CMS database should know that it is not accessible with specific permissions.

Best regards

I still don't see how that is any more secure than what we're doing right now. Drupal is open source, anyone can look at it to figure out how it works anyway - therefore it is better for usability to provide helpful messages instead of being vague.

Thank you for your feedback. I appreciate the usability concerns, and I understand the need to support legitimate administrators who might land on the page without being logged in.

However, my intention with this issue is simply to point out that Drupal's current behavior does not fully align with OWASP guidelines, specifically regarding information disclosure in unauthenticated contexts

As I’ve already mentioned, attackers are not only humans. Automated tools can easily extract relevant information from messages like:
"You do not have permission to access the update script."
This reveals both the existence of a sensitive script and its function, which should ideally be avoided.

These small pieces of information, when aggregated with others (e.g. exposed file paths like /core/install.php , identifiable assets, or HTTP headers), contribute to attack surface mapping, particularly when automated scanners are involved. This is exactly the kind of incremental information OWASP advises to avoid disclosing to unauthenticated users.

A more generic message would better align with OWASP's recommendations to minimize information disclosure in unauthenticated contexts.

That said, if the project’s position is that the current message is the right trade-off between security and usability, I respect that decision. I just wanted to raise the concern and ensure the discussion was on record.

BR

Just to be clear, I am not against some adjustments here. In the case of install.php I think it should do nothing whatsoever after install. But I think this issue needs to be better scoped—perhaps split—because install.php and update.php are a bit different in the codebase.

However, my intention with this issue is simply to point out that Drupal's current behavior does not fully align with OWASP guidelines, specifically regarding information disclosure in unauthenticated contexts

You keep asserting this, but you haven't demonstrated it.

e.g. OWASP says:

In the implementation, ensure that the site is built to gracefully handle all possible errors. When errors occur, the site should respond with a specifically designed result that is helpful to the user without revealing unnecessary internal details.

https://owasp.org/www-community/Improper_Error_Handling

That exactly describes the message on update.php - it gives the minimum information in order to be useful, without revealing unnecessary internal details.

as already explained my point of view (not only mine) is that even if disclaim that the update script is located to /update.php is a relevant information for attackers. It is more reasonable to give that information only to authenticated users, for not authenticated users the message should be more generic and redirect to the login maybe with destination in the session so after logged in the user will be redirected to update page (to me this seems also a correct UX).

Side note: The "update.module" component is for the Update Status module. The update.php script is part of the "database update system". However, since this ticket is also talking about install.php, moving to "base system" as a more appropriate spot.

That said, I'm -1 to this being a "bug" that needs fixing. As has been repeatedly explained by release managers, the error messages on these pages are not disclosing any information that's not trivial for attackers to already know - that the site is a Drupal installation at a given path and that anonymous users don't have permission to access the administrative paths. There's no additional information being disclosed. Furthermore, most attacks are using automated scanning to directly attempt numerous exploits, mostly for vulnerabilities in entirely other CMS platforms. My production site logs are regularly full of requests for wp-admin paths, etc, used only by WordPress. Security by obscurity is not security at all. There's nothing to gain from the security perspective, and a lot to lose from the usability one, to try to further obfuscate these pages.

+1 to closing this with "works as designed".

That’s fine for me, we’ll continue to protect sensitive paths like install.php and update.php via VPN, not just relying on Drupal’s default access control. The same goes for log access; in our case, that's managed through WAF rules.

I also regularly observe a large number of automated requests targeting Drupal login pages and RSS feeds. This confirms that automated scripts exist and many of them attempt requests across all known CMS platforms, not just Drupal.

As I’ve already explained, I believe the information currently exposed to unauthenticated users (e.g. explicit mentions of the "update script") is still relevant from a security standpoint and could be avoided. I remain concerned about optimizing the UX for an admin user who is not even logged in, at the expense of security best practices.

That said, I understand this is not something the Drupal core team considers a priority to address, so I’ll go ahead and close the issue.

Thanks for the discussion.

As mentioned in comment #5 above, you may completely remove these files as documented at https://www.drupal.org/node/3424527 → .

Documentation cover only install.php, update.php should not be removed.

Why not? drush updatedb exists.

i was thinking it uses update.php; So if we have to use drush to update DB no need of the message to public users on update.php, just joking eheh :)

In case clients raise concerns about open source cms security usually we put VPN in front of certain paths plus remove the not needed paths like install.php, install.readme etc. We still have update.php present but under VPN so in case of needs admin can run update from the browser and if someone try to access to the update.php without login WAF rules point to the generic server 403 page, same for user/login.