billbordallo

Hey guys,

I have written to [email protected], as advised when you find a security issue in a plugin, and here is what they have replied:

We would need to see the report that leads to this message. However, “CSV injection” is not a real attack vector for a website.

The basic idea is that any code which exports a CSV file could include data that is dangerous when you import the CSV file to Excel, or something similar.

Fundamentally, this is not a real issue, because it is entirely possible that you want that data in that format. After all, a CSV file is just a text file. CSV stands for comma separated values. So anything that creates such a text file could include things like hyperlinks or whatever. And then programs such as Microsoft Excel can interpret those in possibly unexpected ways.

However, this is not a threat against a website, nor could it be used to directly attack a website. If the plugin has a CSV export feature, then this sort of report gets made simply because it contains that feature. We’ve had several such similar reports in the past, for other plugins, and pretty much all of them have been invalid.

We did a search and cannot find such a report, so we cannot validate it. So I would say to treat such a report as suspect, until more information is available.

WordPress Plugin Review Team

So, I think it is just a false-flag from WHM.

Ok, @eskapism. It could be a false warning.

I will let you know if I have any news.

Thanks for the reply!

@pca2014

I don’t think that’s the problem. It may have something to do with the use of “nonces”, which the CF7 author mentioned on their support forums. The problem with using “nonces” to enhance security is that the page will have to be re-chached every 12hours or so; I read that in my WP-Rocket documentation. Obviously that will heavily degrade the value of caching and the CF APO, which I am also using.

FYI: Mine also broke after 12-hours because this, so I’m rolling back now. It’s not worth the performance burn.

Thanks for the information. I hope that the CF7 plugin developer fixes this issue soon.

Hi,
I am having similar issues with W3-Total-Cache and CloudFlare (with Automatic Platform Optimization for WordPress enabled).

In my case, the forms stop to sending emails and the temporary solution is to clean all caches (page cache in W3TC and purge cache in CloudFlare). Then, the forms work again.

However, after a few hours the forms stop again. I am assuming the js scripts cannot be cached in version 5.4.

After downgrade to version 5.3.2, the forms are working again.

Any advice to prevent this issue would be very appreciated.

Hi,

@nicolaskulka thanks for the reply!

I think I have found the cause of the issue: the plugin W3 Total Cache.

The custom login page was only working when disabling W3 Total Cache.

After struggling a little bit with W3TC settings, I have put the URI of my custom login page into the “404 exception list” and everything went back to normal.

For those who are under the same issue, the path for the “404 exception list” is Performance -> Browser Cache -> General -> 404 exception list, in the WordPress admin menu (W3 Total Cache must be enabled). Insert the URI of your custom login page (i.e.: my-custom-login), the hit Save Settings and Purge Caches.

Currently I am just ignoring CLS errors and warnings on Google Search Console until I find a solution (nothing found so far).

Good to know, @vanyukov!

Thank you!

Hi @jlongbrake

I have disabled the Gutenberg support under the integrations tab and the error is no longer showing. Thanks for the tip!

I hope this issue gets resolved in a future update.

@danielkolbo the installation method can change depending on your environment. Maybe you could contact your hosting provider and ask then to install the curl extension. They will probably help you with some instructions or the installation itself.

@westonruter I got the same error in a localhost installation. As you said, curl extension was not being loaded. So, I fixed that on the local server and the error has gone.

Thank you!

Just adding an information: the log.txt file show the following error:

[ERROR][2019-01-28 10:47:15] - An error occur, here is the detail information
 [ERROR][SEVERITY]    - 4096
 [ERROR][MESSAGE]     - Object of class stcr\wp_subscribe_reloaded could not be converted to string
 [ERROR][FILENAME]    - C:\path-to\wp-content\plugins\subscribe-to-comments-reloaded\wp_subscribe_reloaded.php
 [ERROR][LINE NUMBER] - 1226

• This reply was modified 5 years, 10 months ago by billbordallo.

Hey Guys!
I think I have found the cause of the problem and therefore the solution. Thanks to this thread.

My .htaccess has a rule to force a trailing slash after all URLs. The rule is:

# Force trailing slash
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ https://mysite.com.br/$1/ [L,R=301]

So, as @mikele3 explained in the thread linked above, this redirection was forcing all URLs to have a “/” in the end, including the wp-json path, which is used by Contact Form 7 after the 4.8 upgrade.

I just have to add an exception in .htaccess to not redirect the /wp-json path. The final snippet is:

# Force trailing slash
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteCond %{REQUEST_URI} !^/wp-json
RewriteRule ^(.*)$ https://mysite.com.br/$1/ [L,R=301]

Now I have the version 4.9.1 and all the forms are sending through ajax without any issue.

I hope this could help others with the same problem.

• This reply was modified 7 years ago by billbordallo.

Still not working for me. The console shows the error:
https://mydomain/wp-json/contact-form-7/v1/contact-forms/70/feedback/ 404 (not found)
Only works when I disable ajax sending (see my previous comment).

• This reply was modified 7 years ago by billbordallo.

I only got the plugin sending emails after disable ajax to the contact form 7 plugin. I am using v4.9 and the contact form is working, but without ajax. It is not the perfect scenario, but it is working after all.
To disable ajax, put this in the functions.php:

add_filter( 'wpcf7_load_js', '__return_false' );

More information here: https://contactform7.com/loading-javascript-and-stylesheet-only-when-it-is-necessary/

I went back to the 4.7 version of the plugin and it worked again.