Add security measures to block PHP execution in storage directory #641
+23
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
In July 2025, there was a 9.2 CVE disclosed for Laravel Livewire that allowed unauthenticated attackers to achieve remote command execution in specific scenarios.
How this exploit was used in the wild
One of our community members (@xaimes) noticed in some scenarios, attackers were using the vulnerability to preform further code execution by executing PHP scripts from the Laravel
/storagedirectory.How this applies to serversideup/php
Although the exploit was not from the serversideup/php image itself, we're using this as an opportunity to further harden our images to protect the community.
What this PR does
This PR prevents any
.phpfile from being executed that is found in the/storage/*path.For example, if someone visits:
A
403 Forbiddenmessage will be returned.Note
This rule applies regardless if you're using Laravel or not. We felt this is a general enough of a directory name it is safe to apply to all PHP application types.
Variations this affects
This rule applies to: