“Disable PHP in uploads” blocks everything from uploads

This feature works as intended and will not be modified. It protects your website from attacks that exploit the most common breach in plugins and themes nowadays. Having PHP code in the uploads folder is a mess. I mean code must reside in code folders, media files in the uploads folder. In other words, plugin code must be in the plugin’s folder, theme code in the theme’s folder. Developing stuff that put executable code in the uploads folder is reckless. It poses a real risk to a website. Millions of websites have been hacking by uploading malware code to the uploads folder. But who cares?

Also, on top of that, you have an issue with images. All static files (like images) in the media/uploads folder must be served by a frontend server like NGINX or by a CDN, not PHP scripts like you seemingly have. Serving static files via PHP scripts is absurd. But it’s not your fault, it’s the fault of the developer of one of your plugins.

P.S. Be a demanding and aware customer, do not trust people that tell you that having executable code in the uploads folder is safe.

@gioni Agreed!

Tim

@wfsupport Look who’s here ??

??

Thanks for replies, but that’s not what I meant. I have no .php files in uploads folder. Enabling this function gave 404’s on *.jpg, *.png and *.webm files. With “Include static files” *.css and *.js gets 404’s too. It’s not the expected behaviour, so I reported it. But I’m not sure if it’s a problem on webserver, this plugin or conflicts with other plugins. I’d like to keep this function on just in case – I’m just administrating website from time to time, so I’m not sure what other users would do.

Could you please check the Live Traffic log for related errors? Go to the Traffic Inspector, click the “Errors” button. Probably you have a rewrite rule in the .htaccess file that invokes a PHP script to handle those static files.

Sadly, there is no info other than 404 errors in Live Traffic. No other PHP script intercept the request. No plugins seem to conflict. .htaccess created in Uploads looks OK to me.
I have WP-Cerber on other sites, ones with similar and others with different configuration, but only this one makes trouble. It’s also on different hosting provider. Could it be problem with Apache version and .htaccess content? Maybe my server doesn’t support something?

Do you see 404 errors on Live Traffic log for static files? That’s not good. What URL is being logged for those 404 requests? Do you use some kind of a membership or a content restriction plugin?

Yes, traffic log shows 404 errors. Logged URL is actual file URL. If I enable JetPack CDN function, it still shows site URL, not a CDN one. Also, when I try to access them directly, I get WordPress 404 page (not a default server 404, so it intercepts traffic). I don’t think any other plugin could cause a problem, here’s list of them (I always try to keep latest versions):

Accelerated Mobile Pages 0.9.97.42
All-in-One WP Migration 6.86
Activity Log 2.5.2
Clean Image Filenames 1.2.1
Document Gallery 4.4.3
Docxpresso 2.3
Embed Any Document 2.4.1
EWWW Image Optimizer 4.6.3
Flexible Posts Widget 3.5.0
Glue for Yoast SEO & AMP 0.4.3
Imsanity 2.4.2
Jetpack by WordPress.com 7.1.1
Media Cleaner 5.1.3
Menu Items Visibility Control 0.3.7
Photo Gallery 1.5.18
Require Featured Image 1.4.0
Restrict Author Posting 2.1.5
Shortcodes Ultimate 5.3.0
Page Builder by SiteOrigin 2.10.2
SiteOrigin Widgets Bundle 1.15.3
Yoast SEO 9.7
WP Cerber Security 8.1

• This reply was modified 5 years, 8 months ago by saulens22.

Your issue may be caused by a conflict with one of these plugins (I suspect Jetpack):

Document Gallery 4.4.3
EWWW Image Optimizer 4.6.3
Jetpack by WordPress.com 7.1.1
Photo Gallery 1.5.18

Found the problem! I tried running with only WP Cerber enabled, and as it didn’t work out, I checked Apache error log. Here’s the error:

[Wed Mar 13 11:37:49.592942 2019] [core:alert] [pid 27382:tid 140320891184896] [client xx.xx.xx.xx:2747] /home/*webuser*/domains/*website*/public_html/wp-content/uploads/.htaccess: Option ExecCGI not allowed here

So it’s definitely a problem with my server. So the only suggestion is maybe to add a check in PHP / if block in .htaccess, so no one else runs into the same problem.

Thanks for your replies ??