Title: rmhall's Replies | WordPress.org --- # rmhall [ ](https://wordpress.org/support/users/rmhall/) * [Profile](https://wordpress.org/support/users/rmhall/) * [Topics Started](https://wordpress.org/support/users/rmhall/topics/) * [Replies Created](https://wordpress.org/support/users/rmhall/replies/) * [Reviews Written](https://wordpress.org/support/users/rmhall/reviews/) * [Topics Replied To](https://wordpress.org/support/users/rmhall/replied-to/) * [Engagements](https://wordpress.org/support/users/rmhall/engagements/) * [Favorites](https://wordpress.org/support/users/rmhall/favorites/) Search replies: ## Forum Replies Created Viewing 4 replies - 1 through 4 (of 4 total) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Link Library] Any plans on addressing SSRF vulnerability?](https://wordpress.org/support/topic/any-plans-on-addressing-ssrf-vulnerability/) * Thread Starter [rmhall](https://wordpress.org/support/users/rmhall/) * (@rmhall) * [5 months, 4 weeks ago](https://wordpress.org/support/topic/any-plans-on-addressing-ssrf-vulnerability/#post-18778545) * Excellent, thanks for the confirmation! No worries, I understand. I discount what Wordfence says in many similar situations, as I have seen it happen to other plug in authors where the first notice they receive about an issue is when notifications start pouring in once they hit Wordfence, despite having never received contact regarding responsible disclosure notifications prior to that time. I only received the notice today, even if it was added to their site on Dec. 24th and the other one referenced above, also on the 24th. Only thing I can imagine is that Wordfence might be prioritizing notifications and email notices about higher ranked CVSS issues with a greater risk of immediate exploitation, plus having to batch notices due to such a high volume of outgoing emails (WordPress show 5 million plus active installs of WordFence and over 10k of your plugin, so a minimum ~10k emails to deliver). If you dig a little deeper, here:[https://vdp.patchstack.com/database/researchers/77f3d989-ee90-4bb0-b503-e03752dd3714](https://vdp.patchstack.com/database/researchers/77f3d989-ee90-4bb0-b503-e03752dd3714) Thats the profile page for the user who found and reported it on November 24th, and according to Patchstacks own policy, they validate submissions within 72 hours and then follow responsible disclosure policy listed here: [https://patchstack.com/patchstack-vulnerability-disclosure-policy/](https://patchstack.com/patchstack-vulnerability-disclosure-policy/) which means reaching out to the author, and giving 30 days. Clearly they didn’t reach out to you, and WordFence took an additional 12-13 days to send out after it was disclosed after 30 days, so who really knows, but I certainly won’t hold it against you.Also, I personally have a low likelihood of this particular issue being exploited given the specific requirements, so I totally get it. In any case, understand your position – seen it happen to others and been there myself. 😉 Best of luck! - This reply was modified 5 months, 4 weeks ago by [rmhall](https://wordpress.org/support/users/rmhall/). * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[IP2Location Country Blocker] Fatal error on upgrade to version 2.39.0](https://wordpress.org/support/topic/fatal-error-on-upgrade-to-version-2-39-0/) * Thread Starter [rmhall](https://wordpress.org/support/users/rmhall/) * (@rmhall) * [1 year ago](https://wordpress.org/support/topic/fatal-error-on-upgrade-to-version-2-39-0/#post-18525258) * Well my comment above was flagged as “spam” (which is crazy) and then 10 minutes after I posted the above, I see that a new commit was pushed that adds the “Requires at least: 7.4” along with some other changes, and moves things to 2.39.1 I see no other real usage of PHP 7.4 specific functionality beyond the spread operator in the 3 functions I identified.I patched this easily to remove the PHP 7.4 requirement, by leveraging array_merge on the …$args being passed into those three functions– example: * `$merged_args_arr = array_merge(…$args); return $GLOBALS['wpdb']->query($GLOBALS[' wpdb']->prepare($query, $merged_args_arr)); Perhaps you would consider implementing something like the above since those three functions using the spread operator appear to be the only place where PHP 7.4 is actually required. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Jetpack - WP Security, Backup, Speed, & Growth] sender ip in comments](https://wordpress.org/support/topic/sender-ip-in-comments/) * [rmhall](https://wordpress.org/support/users/rmhall/) * (@rmhall) * [1 year, 11 months ago](https://wordpress.org/support/topic/sender-ip-in-comments/page/2/#post-17894201) * [@koullis](https://wordpress.org/support/users/koullis/) Happy to help. Looks like this helped get someone on it formally, and they have already made a very similar patch to the official repo for Jetpack plugin, and the pull request is one review away from being approved, so it should be in the next release. 🙂 Reference: [https://github.com/Automattic/jetpack/pull/38352/commits](https://github.com/Automattic/jetpack/pull/38352/commits) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Jetpack - WP Security, Backup, Speed, & Growth] sender ip in comments](https://wordpress.org/support/topic/sender-ip-in-comments/) * [rmhall](https://wordpress.org/support/users/rmhall/) * (@rmhall) * [1 year, 11 months ago](https://wordpress.org/support/topic/sender-ip-in-comments/page/2/#post-17891838) * I worked up a custom plugin that dumps all the IP’s from Feedback Responses marked as SPAM into a separate file for reference on a cron schedule or on demand, for my own blocking/reporting purposes. I may publish it at some point, its very bare bones. I hated not seeing the IP in the Feedback Form Responses admin page without having to run my plugin to view/dump them. So I spent a few minutes and put together a quick one line patch to restore this functionality. * Reference the GitHub issue here: [https://github.com/Automattic/jetpack/issues/29124](https://github.com/Automattic/jetpack/issues/29124) No time or inclination to submit a formal pull request or determine if it aligns with any WordPress coding standards (just quick and dirty to get going), but here it is for anyone who wants to quick copy and paste a single line of code to a single file to restore the missing IP display row – or use this as a reference point to investigate exactly where things are going wrong/broke and implement properly.Edit this file:/wp-content/plugins/jetpack/jetpack_vendor/automattic/ jetpack-forms/src/contact-form/class-admin.php (Reference: [https://raw.githubusercontent.com/Automattic/jetpack/trunk/projects/packages/forms/src/contact-form/class-admin.php](https://raw.githubusercontent.com/Automattic/jetpack/trunk/projects/packages/forms/src/contact-form/class-admin.php)) Insert the following line of code at line 740:`$content_fields["_feedback_ip"] = substr($chunks[0], strrpos($chunks[0], "IP:")+3);`Save the file and then view your Feedback Form Responses admin page and you will note that the missing “IP” row with IP address of the form submission is now visible again, just below the horizontal rule in the “Response Data” column, and directly before the “Source” row – like it used to be.Basically it looks like the $content_fields array is not getting the _feeedback_ip set properly. Didn’t have time to go back and look at commit history to determine the cause/where it broke originally, and yes, its kludgy without error checking, but it works in a pinch, and might help someone to finish this off properly with a jumping off point. Will post a version of this on the GitHub issue as well in case that gets it addressed formally a little faster. Viewing 4 replies - 1 through 4 (of 4 total)