Execution Risks
Execution Risks
PHP Execution in Uploads
What This Means
This finding indicates that PHP files can be executed within upload or storage directories.
These directories are typically intended for file storage, not code execution.
Why It Matters
Upload directories (such as /wp-content/uploads/) are commonly writable by the application.
If PHP execution is allowed in these locations, attackers may:
- upload malicious scripts
- execute code through vulnerable upload points
- gain unauthorized access or control
This is a common method used in real-world WordPress attacks.
How Steel Security Detects This
Steel Security checks whether PHP files placed in upload directories can be executed.
If execution is possible, the directory is flagged as a risk.
How to Fix It
To resolve this issue:
- disable PHP execution in upload and storage directories
- apply server-level rules to prevent script execution
- use Steel Security hardening controls related to execution restrictions
What to Expect After Fixing
After applying protections:
- PHP files in upload directories will not execute
- uploaded scripts will be treated as files, not code
- your site will be significantly more resistant to upload-based attacks
How to Verify
To verify the fix:
- upload or place a test PHP file in an upload directory
- attempt to access it via browser
- confirm that execution is blocked
Expected results include:
- file download instead of execution
- or a blocked request (e.g., 403 Forbidden)
Common Causes
- default server configuration allowing execution
- missing directory-level restrictions
- insecure file upload handling
Best Practices
- never allow PHP execution in upload directories
- treat storage locations as non-executable
- regularly review upload behavior and permissions
- combine with other execution and file protection controls
Related
Direct PHP Access Allowed
What This Means
This finding indicates that certain PHP files on your site can be accessed directly via a browser.
These files may not be intended to be executed outside of normal WordPress workflows.
Why It Matters
Many PHP files are designed to be included internally, not accessed directly.
If these files are accessible, attackers may:
- execute scripts in unintended ways
- bypass application logic
- probe for vulnerabilities
- trigger unintended behavior
Restricting direct access reduces these risks.
How Steel Security Detects This
Steel Security identifies PHP files that should not be directly accessible and checks whether they can be executed via a browser.
If direct access is possible, the file is flagged.
How to Fix It
To resolve this issue:
- restrict direct access to sensitive PHP files using server rules
- ensure scripts are only executed through WordPress entry points
- apply Steel Security hardening controls related to PHP access restrictions
What to Expect After Fixing
After applying protections:
- direct requests to restricted PHP files will be blocked
- unauthorized execution attempts will fail
- normal site functionality should remain unchanged
How to Verify
To verify the fix:
- attempt to access a flagged PHP file directly via its URL
- confirm that access is denied (e.g., 403 Forbidden)
Ensure that:
- restricted files are not accessible directly
- legitimate site functionality continues to work
Common Causes
- plugin or theme files exposed without access restrictions
- custom scripts placed in public directories
- missing or incomplete server rules
Best Practices
- avoid exposing internal PHP files directly
- route execution through WordPress where possible
- review custom scripts and endpoints carefully
- combine with other execution controls