rawrly

How it is currently designed is the more performant solution.

Having thousands (hopefully millions soon) of websites each downloading an entire database of vulnerable components and their versions, loading that database into memory on each site, then doing a check … that is a lot of redundant resource overhead (e.g.. will cause performance issues, wasting memory and resources on the website’s servers). This is why we collect just the current running versions of software and do the check on the remote side. This is one of the reasons our plugin’s resource usage is the lowest of all major WP security plugins.

I understand you have concerns about the collection of data, but Patchstack is being honest that your site needs to tell us what software name and versions they are running so we can efficiently cross reference our database of known vulnerabilities.

By doing so we can help people prevent avoidable hacks on their WordPress websites. Our goal is to make WordPress sites more secure in the first place.

Sucuri and the Patchstack plugin have two different focuses when it comes to security.

Sucuri’s main focus is scanning all of your sites files for indicators of compromise. (plus additional misc security features.) This means the protection comes after a hack.

Patchstack notifies site owners when they are running known insecure components. (plus additional misc security features) This means the site owner can secure their sites before the compromise ever takes place.

Patchstack does not perform malware scanning, and Sucuri does not perform vulnerability notifications. This is why I mentioned in your other post that the two plugins should not conflict, in fact if anything, they may work very well together.

• This reply was modified 2 years ago by rawrly.

The Patchstack plugin should be able to be ran alongside Sucuri’s plugin without any issues. The basic (free) versions of both of these plugins provide different features which are unlikely to conflict with one-another.

Sorry for the slow reply @snippet24 , I will help clarify this for you now and someone will update the FAQ soon.

The plugin collects the full name, slug, current version, new version (if any), and type (plugin, theme or core). This information is needed to cross check the database of known vulnerabilities and provide alerts if insecure versions are identified.

I hope this helps.

Hello all, this is Robert from Patchstack.

Foremost, thank you to @xootix for writing and pushing the patch. CSRF bugs are rarely targeted in the wild, but the patch makes your project more complete. Patchstack has updated our records to show this plugin is patched and safe to use.

Regarding WordFence’s “critical” severity claim. Only WordFence can controls their choice of words. This is not the first case where they take a Low or Medium severity risk, and claim it is “critical” to their customers. It is not fair for me to speculate as to why they did this, however I feel I am in agreement with most of the posters here like (@twostrong @espressivo @fearzzzz and @orfevre13) that this critical warning caused undue stress for the users of this plugin who has an attentive developer working on the patch. if you’re interested in clearer security communication, well, maybe look into us.

If anyone has any questions on Patchstack’s process of receiving security bugs from third parties and how we score them, please feel free to reach out. I’ll turn on notifications for this thread.

Have a wonderful day. – Robert

Thank you eskapism, I have followed up with further details via email.

For pietgold and paulshultz, thank you for sharing your observation. WordFence is clearly over stating the threat if they are claiming this as critical. Please remember, when you review our entry, Patchstack states this is a Low severity risk. I can not stop WordFence from saying this issue is “critical” if they so choose. (but they’re clearly not helping)

@eskapism : Can you reach out to me on https://patchstack.com/for-plugins/ and we can start a conversation? I promise we tried publicly listed points of contact for you, but you did not response.

Once we can get in touch I can share the specific input being used in the security report (but I would rather not share this publicly), I will even be glad to verify the patch for you. Thank you for working on the patch as well. There is another great tip from @84em regarding how Jetpack addresses this. It really is just a filter you need to add before saving data into the CSV.

This is Robert from Patchstack here to help if I can.

First, I would like to apologize to the users receiving a concerning report on a Friday morning of all times. I updated the finding regarding this bug in our database to help clarify the concerns, reducing the risk rating down to a Low. Other changes in how this was communicated could have helped too, but they’re out of my control right now.

What is CSV Injection? These have always been troubling vulnerabilities to report and communicate. There is no risk to the website itself, but there maybe a risk to users who download CSV files exported form the website. In a strange twist, it’s the web application that applies the patch to address this concern.

If you do not export CSV files using this plugin then this report is not applicable to you. And if you do, just be careful with the export file, by “careful” I mean: Do not disable multiple security features or ignore warnings when opening the file.

For @eskapism:

Because of the complex requirements of the attack vector, we recently stopped accepting CSV injection reports from the Patchstack Alliance bug bounty program. Why is it being published now? We accepted this report before therecent decision to stop accepting CSV Injection reports. We attempted to reach out to you multiple times in the last few months, but never heard back. It would really help us if you could share a security point of contact (but we should discuss this elsewhere)

We will be re-evaluating if we keep this report active at all, but the decision may take time and will take more time to propagate to the WordPress toolkit or other vendors. For now I have reduced the severity on our end, and can help answer any other questions or concerns you may have.

If you by chance wish to write a patch, I wrote about the concerns of CSV Injection, and how you can patch it easily here. https://patchstack.com/articles/patchstack-weekly-what-is-csv-injection/ — You should not feel this is an emergency thing to patch, but this would have been easier and less stressful had we been able to get in contact with you sooner.

• This reply was modified 2 years, 1 month ago by rawrly.

Hello @yehudah Thank you for the quick patch for those issues and getting the plugin re-enabled.

I noticed however that your patches in changeset 2142184 didn’t get applied to a new version number. Users downloading your plugin today (for updates or new installs) are still downloading the 2.0.2 version which has that code of concern in it.

Your users (including many of our customers) would love to apply those patches in changeset 2142184, but I think we need to have you tag it to a new release version.

Hopefully you can help get this all sorted out. Right now, I can’t update sites to get that changeset on them.

Thank you Yehudah!

• This reply was modified 5 years, 6 months ago by rawrly. Reason: Missed a number in the changeset id