WordPress.org

Make WordPress Core

#37700 closed defect (bug) (fixed)

Warning: curl_exec() has been disabled for security reasons

Reported by: Ipstenu Owned by: dd32
Milestone: 4.6.1 Priority: normal
Severity: normal Version: 4.6
Component: External Libraries Keywords: fixed-major
Focuses: Cc:

Description

Some installs now use cURL when they didn't before following 4.6

https://wordpress.org/support/topic/warning-curl_exec-has-been-disabled-for-security-reasons?replies=13

As Otto said:

Additionally, the new Requests_Transport_cURL class does indeed check for function_exists('curl_exec') before attempting to use it, so it seems likely that your host is using suhosin or some other means of disabling functions which doesn't cause PHP to properly report that function as disabled.

Also some Jetpack folks have reported it and it doesn't seem that they rolled back.

I don't know if there's a better check we can do for this.

Attachments (1)

37700.patch (1.0 KB) - added by pross 15 months ago.

Download all attachments as: .zip

Change History (13)

#1 @pross
15 months ago

Maybe after a function_exists() it should try a curl_init() and check the response to make sure it will actually work. Just a thought.

#2 @dd32
15 months ago

  • Component changed from HTTP API to External Libraries
  • Milestone changed from Awaiting Review to 4.6.1

Looks like there's a logic slip in Requests where it only bails from using cURL if BOTH curl_init() AND curl_exec() are unavailable. WordPress previously bailed when EITHER were unavailable.

Created a PR upstream: https://github.com/rmccue/Requests/pull/230

@pross
15 months ago

#3 @Otto42
15 months ago

Filter looks okay for back-compat.

#4 @dd32
15 months ago

  • Owner set to dd32
  • Resolution set to fixed
  • Status changed from new to closed

In 38274:

Requests: Update to Requests master (fb5b517) which corrects a logic inversion in the cURL transport checks.

Previously if a host had only disabled one of curl_init() or curl_exec() it wouldn't get detected correctly by Requests, which caused cURL warnings for users on an affecte dhost.

Fixes #37700 for trunk.

#5 @dd32
15 months ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Re-opening for 4.6 merging.

#6 @SergeyBiryukov
15 months ago

#37715 was marked as a duplicate.

#7 @Whitegoodshelp
15 months ago

I also had an issue with 4.6 update stopping Akismet from working and removing curl_exec from my php.ini file fixed the problem.

However, my tech support at my hosting company looked into this for me and successfully re-disabled curl_exec without the Wordpress issue recurring by simply adding the disable function curl_exec to all the php.ini files on the server. It seems Wordpress wasn't looking at the php.ini file I edited and looked at a different one.

Here's what they said in case it helps -

"I believe that due to the different php.ini files in use on the server, exactly where the call is being made by
WordPress has caused confusion. The /etc/php.ini file is the global PHP settings on the server. The php.ini files in the /opt/plesk/php/ directories are the php.ini files for each specific version of PHP that Plesk uses. The php.ini file in the document root is the WordPress specific php.ini file. It looks as though WordPress checks the global php.ini settings and not just its own specific php.ini settings for this check."

Andy

#8 @Ipstenu
15 months ago

Andy, that's not really how PHP works as far as I know. WordPress doesn't know the difference, it just knows what PHP tells it. You can check by making a phpinfo file, and see what that reports. It will be the same as what WP sees.

You may need to tell your host "WordPress is just a PHP app, so if PHP is reporting back the wrong information, then this is more likely due to a server configuration not prioritizing my local php.ini, or that my local php.ini is actually not correct. PHP isn't THAT smart :) "

Last edited 15 months ago by Ipstenu (previous) (diff)

#9 @Whitegoodshelp
15 months ago

Thanks Ipstenu. That makes sense. It's just that each time I added curl_exec to the disable functions in php.ini (via Plesk) Akismet stopped working and couldn't connect to its server, but when my tech support said they added it also to the 2 other php.ini files the issue was resolved which is why I thought the experience might help someone else in the same position. It remains a mystery but it fixed my issue with updating to 4.6 :)

#10 @adam1920
15 months ago

This is the solution!
In file wp-includes/Requests/Transport/cURL.php
change row 527

if (!function_exists('curl_init') && !function_exists('curl_exec')) {

to

if (!function_exists('curl_init') || !function_exists('curl_exec')) {

This ticket was mentioned in Slack in #core by jeremyfelt. View the logs.


15 months ago

#12 @swissspidy
15 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 38338:

Requests: Update to Requests master (fb5b517) which corrects a logic inversion in the cURL transport checks.

Previously if a host had only disabled one of curl_init() or curl_exec() it wouldn't get detected correctly by Requests, which caused cURL warnings for users on an affected host.

Merge of [38274] to the 4.6 branch.

Fixes #37700.

Note: See TracTickets for help on using tickets.