cURL error 2: easy handle already used in multi handle

Hi @dchesbro,

version 1.8.1 and 1.9.0 of our plugin are using the same version of Guzzle: 6.4.1.

Only in 2.0.0 (released on Monday), the Guzzle is updated to the latest version: 6.5.3.

So I don’t know why that would resolve your issue. This is getting stranger and stranger…

So you updated your modified plugin v1.9.0 to v2.0.0, uninstalled it, installed v1.8.1 and it works without the curl issues?

Take care!

@capuderg That is correct.

I began experiencing this issue while using version 1.9.0 and modified the copy of CurlFactory.php included with that versions distribution of Guzzle as a temporary fix.

I then updated to version 2.0.0 when is became available, but still saw curl error 2. I implemented the same modifications used for version 1.9.0 as a temporary fix again.

Yesterday I tried reverting to version 1.8.1 and I am no longer seeing the curl error 2 or any other errors. As of this message I’ve reverted to this version of the plugin for all of our live websites and they appear to be operating as expected.

I’m continuing to examine the issue in our development environment to see if I can figure out why this started happening in the first place, and what might resolve it. I’ve collected the following details that might be helpful to anyone trying to do the same here:

Server Details
Server OS: CentOS 6.10
WHM/cPanel: 86.0.18
OS curl: 7.69.1
OS libcurl: 7.69.1
OS OpenSSL: 1.0.1e
PHP: 7.3.17
PHP curl: 7.69.1
PHP OpenSSL: 1.1.1g
WordPress: 5.4

Plugin Email Test Results
WP Mail SMTP 1.8.1: No error messages, test email received
WP Mail SMTP 2.0.0: Error message: “There was a problem while sending the test email”, no test email received

Versions:
WordPress: 5.4
WordPress MS: No
PHP: 7.3.17
WP Mail SMTP: 2.0.0

Params:
Mailer: gmail
Constants: No
Client ID/Secret: Yes
Auth Code: Yes
Access Token: Yes

Server:
OpenSSL: OpenSSL 1.1.1g 21 Apr 2020
PHP.allow_url_fopen: Yes
PHP.stream_socket_client(): Yes
PHP.fsockopen(): Yes
PHP.curl_version(): 7.69.1

Debug:
Mailer: Gmail
cURL error 2: easy handle already used in multi handle (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)

It’s an especially confusing issue, I agree. I’ll continue to post here with anything I uncover, and check in to see if anyone else has found anything helpful. Good luck!

Edit: I can also confirm that an unmodified version 1.9.0 continues to produce the same error as version 2.0.0 above.

• This reply was modified 4 years, 7 months ago by dchesbro.

I would like to add that I’m also experiencing the same issue, and it looks like I have the same centos version

Hi,

Each update still has the error. Here’s the output:

Versions:
WordPress: 5.4.1
WordPress MS: Yes
PHP: 7.3.17
WP Mail SMTP: 2.0.1

Params:
Mailer: gmail
Constants: No
Client ID/Secret: Yes
Auth Code: Yes
Access Token: Yes

Server:
OpenSSL: OpenSSL 1.1.1g 21 Apr 2020
PHP.allow_url_fopen: No
PHP.stream_socket_client(): Yes
PHP.fsockopen(): Yes
PHP.curl_version(): 7.69.1

Debug:
Mailer: Gmail
cURL error 2: easy handle already used in multi handle (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)

Update: After more research than I like to admit, chasing down the solution to this problem, I think I may have the answer.

I have 6 VPS servers that I manage, 3 are GoDaddy servers and 3 are InMotion Hosting servers. The site’s that had the problem where on GoDaddy VPS servers, I found I was also getting the cURL error 2 message with the GiveWP plugin on those servers.

I tried moving one of the site’s to one of the InMotion Hosting servers with a full site transfer. I found that once I did, the problem went away.

I then reached out to GoDaddy to find out what happened to my servers. I got someone who was helpful and informed me that they had a major backend issue that started on/around the 16th/17th of April but didn’t affect any front end functionality. He also told me it took them a week but they had it fixed. I explained that whatever that was seems to be the problem I’m still dealing with. He escalated me to a higher level support.

When I reached the higher level of support they all but refused to believe they meessed something up. I ended up getting nowhere with them.

So I took this opportunity and purchased a new GoDaddy VPS server and started moving accounts over to it. The new server worked just fine.

I’m curious if everyone who is having trouble with this is using GoDaddy servers, They could be purchased directly through GoDaddy or through a reseller. I, for example, resell GoDaddy services and these were one’s I purchased from myself.

I think this is a problem that GoDaddy created and hasn’t taken ownership of yet.

Hi, @insightdezign

Same scenario for me. I have a reseller account through GoDaddy and bought my VPS through there. That’s where I’m seeing this issue.

Hi @insightdezign,

thank you very much for sharing these findings with us!

Now I wonder if all of you that are seeing these issues are using GoDaddy specifically or is it just a server configuration issue…

@dchesbro, @guytimes, @thomas-popp, @cgmedya, @pascalgenest are you maybe using GoDaddy as your hosting?

Take care!

@insightdezign @capuderg I am also using GoDaddy as my hosting provider, though with dedicated servers and not VPS.

I also reached out to GoDaddy while troubleshooting this problem and was basically told I was on my own.

The error report says I’m running cURL version 7.69.1, but I just ran /usr/bin/curl -V on my GoDaddy VPS and it says the curl version is 7.19.7, which is ten years old.

I’m thinking this is the issue.

I can confirm my client is also having this issue on a GoDaddy hosted site.
As Abland mentioned, the curl version is 7.19.7 on the cPanel however it looks like the one running for plugins on WordPress is 7.69.1.

I am currently firefighting by implementing the fix here every time the plugin automatically updates however this is not sustainable.

Our e-commerce websites hosted on GoDaddy were both hacked on 4/17. By a miracle, we discovered a modified PHP file within about an hour that was sending credit card information to a site in Russia. We removed the code and contacted the 8 customers affected. Unfortunately, that wasn’t the only thing changed — on 5/4 we received word from 2 separate customers that their cards had been hacked a few days after 4/17. As suspected, all 1,500 customers during that 20 day period were affected – about half having fraudulent activity on their cards already.
We discovered via reviewing tcpdump logs that any time a cURL request was sent during our checkout process to our credit card processor, the actual cURL request was being duplicated on the server (not in the PHP file) and sent to a different site in Russia (we guess based on the URL). The security service couldn’t find the issue and we used a PHP stream wrapper as a work-around to avoid the malicious cURL.
We just learned today that libcurl had been automatically updated from 7.69 to 7.79 on the afternoon of 4/16. When the GoDaddy representative rolled us back to 7.69, I tried the old cURL checkout method again and it fully fixed the issue (did not send the second, malicious request).

We have no evidence as to whether the libcurl version 7.79 was corrupted from the beginning, or if our server happened to get hacked within a day of it being auto-updated and then the hacker modified the binary on our server. I’m just posting this in case it helps anyone else uncover an issue.

Follow-up: apparently, 7.79 isn’t supposed to exist (7.70 is the current version), so it seems like there was a hack released a compromised libcurl to a subset (or all) of GoDaddy’s servers. Rolling back fixed our issue and, as of 5/15, 7.79 was no longer ‘available’.

N E W S ?

• This reply was modified 4 years, 4 months ago by ofmarconi.

Hi @ofmarconi,

there are no exact steps on how to resolve it as well as what is causing it…

It looks to be related to some centOS versions and upgrading might resolve the issue: https://github.com/stripe/stripe-php/issues/918#issuecomment-630430860

I’m sorry, but we don’t have any additional info.