Traditionally, we keep security patches and updates simple and quick in our security haiku series of posts. But sometimes 17 syllables doesn’t cut it. This post will address some of the commotion regarding a vulnerability which was patched in WordPress 4.7.2. The vulnerability was an authentication bypass attack which existed in the REST API (a new feature in WordPress core as of 4.7.0.) It allowed malicious parties with no account or form of privileged access on a site to modify or replace the content of any post on the site. If you host your site with Pagely, you’re good. We applied a virtual patch via our WAF (Web Application Firewall) – which prevented malicious requests from ever reaching the site – before applying a software upgrade on customer sites to 4.7.2. The majority of our customers received this patch on the same day as it was made available. The attacker’s access is limited to changing a post’s content, but that has not stopped many from running this exploit and succeeding on many un-patched sites (at other hosting providers). Leaving in their wake thousands of sites with new “hacked by” posts. This is just unfortunate for those site owners who will not have to go through the pain of restoring their posts from backups, or starting all over again if they lacked those. The events related to the 4.7.2 release are a reminder that practicing security should come first. Here are some takeaways: Always apply security patches quickly. (There is an automatic upgrade option in WordPress which is strongly recommended. If you cannot rely on this functionality, then you must dedicate staff to apply security upgrades, or consider a hosting provider who provides upgrades as part of their service.) Enable a WAF or sign up for a WAF service (Cloudflare, Sucuri, etc..) to be able to apply virtual patches or rules that will block a severe attack of this nature while you wait for the official patch to get deployed on all sites. If you can not do the above to, hope you have good backups and a pot of coffee at the ready. Again, sites hosted at Pagely were not affected by this vulnerability (Hattip: WP Core Team for looping us in early), thanks in large part to our security and devops teams staying vigilant and following the best practice procedures outlined above for addressing security issues on all of our customer sites.
Over the past month or so I have been monitoring the activity of a series of attacks against our hosting customers which had one common vector: insecure WordPress plugins which exposed PHP objects to potential injection. Only a very small number of our customers were affected and with every compromised instance we work with our customers and provide every detail we can regarding the attack. In this case we found the vulnerability being exploited was an unpublished (or zero day) exploit in the wild. As we worked to mitigate the vulnerability we kept an open dialog with our affected customers as we worked with the plugin author on a patch or in some cases: disabling the insecure plugin. About PHP object injection attacks The attack we saw was not a new type of attack, but an attack method that is a little obscure compared to the more commonly talked about: XSS and/or SQLi. PHP Object Injection is discussed in depth by security groups like OWASP as well as being so severe it warranted a large red warning on php.net warning not to utilize the unserialize() function with untrusted data. Many plugin developers have fallen short of this best practice and utilized this function insecurely from what we have seen when reviewing the official wordpress.org plugin repository en mass. How it went down The attacks started late October, and I recall that I spent Halloween day looking into the first few cases. The attackers actions, likely an automated script, were fairly easy to track. They would scan a site looking for active installs of certain plugins, then make a POST request to ../admin-ajax.php or /index.php. Right around the same time of the POST request being made – a backdoor would have appeared on the site which the attackers would then leverage to take further malicious actions. Our security systems did not prevent the attacks at first, but PressARMOR™ was able to detect them and notified our InfoSec team who performed a proper and thorough incident response on each compromised site. Our incident response protocol: notify the customer clean the site identify the source of the compromise communicate finding’s to the customer shore up our own defense to prevent the same attack from being successful in the future flag the site for further scrutiny/follow-up to check our work In the first few incidents we identified a common target of the attacks was a plugin named: bp-profile-search. We performed a security audit of the plugin’s code identifying a few possible exploit vectors, our InfoSec team along with help from our DevOps team concluded that the most likely culprit was a PHP object injection attack which was being exposed by an AJAX action in the plugin. Not certain of the exact exploited object but knowing at least that the injection point was there – we reached out to the author of bp-profile-search directly. The author was extremely receptive to the information we had provided them and within a day had re-written the plugin’s logic to utilize JSON structures instead of serialized objects to store and retrieve that data. And like actual magic, not that wierd David Blaine stuff, we immediately saw the vulnerability in bp-profile-search close and no further sites were using it were affected. This was an unpublished attack vector utilizing PHP Object injections. A week or so later we identified a new series of attacks now targeting analytics-counter. We followed our incident response protocol and the similar conclusion was made, that the analytics-counter plugin was also vulnerable to PHP Object Injections. This time it was not as easy to work with the plugin author as the plugin had been removed from the plugin repository recently – The removeal had the unfortunate side effect of making patches in the plugin unavailable to anyone and making it harder for us to reach out to the plugin author directly. Over several days we continued to monitor compromised sites in hopes to enact a virtual patch (ruleset in our firewall) to protect them but ultimately we had to take action by removing the plugin from all Pagely sites which utilized it. Each site owner was notified directly about the concerns and we worked with them to find suitable replacements if requested. Since the removal of the analytics-counter plugin across our platform: those sites that were using it have not been affected again. A strong corollary that we identified yet another unpublished vulnerability and successfully took action to protect our customer’s sites. Shortly after we removed the plugin from our network, this plugin re-appeared on the official repository with a patch issued 2-3 weeks prior which appeared to have addressed this vulnerability to some degree. Takeaways What we learned from this is that PHP Object Injection attacks are extremely serious. Attackers were able to arbitrarily execute code and/or upload files. If this issue is not mitigated across all vulnerable plugins it may have the potential to reach a RevSlider or TimThumb level of damage. A simple fix is that plugin and theme developers need to: immediately stop utilizing the unserialize() function on untrusted data structures. This is in line with what both OWASP and php.net recommends. However – this vulnerability is a bit more complex as it requires more than just an insecure usage of unserialize(), it also requires an insecure object class to have been created – and this class may or may not be in WP Core – we simply have not had enough time to fully investigate that hypothesis. We briefly weighed the nuclear option of blocking all requests that contain serialized data but did not as the problem is so many plugins currently (insecurely) use it now that it would adversely affect many customers. Our hope is still that plugin authors are educated about this risk and can take the necessary steps now to patch their code before it gets exploited in the wild and becomes a major issue. Plugin security reporting works, when all parties treat each other respectfully and talk about the subject and solutions at hand. I have rarely had issues helping developers understand and patch vulnerabilities found in their code – when I am able to speak directly with them that is, and we are happy to help in that capacity now, simply reach out to security . at . pagely . com if you would like some assistance. With cooperation and understanding the community grows. The Proper Channels During these events we reached out to the team that manages the wordpress.org plugin repository, detailing our experience with affected plugins and the classification of vulnerability. Naming multiple affected plugins and citing one example specifically in code. We were asked for working proof of concept’s for all instances we found – writing these proof of concepts is not a trivial task, let alone writing a few hundred. Due to time constraints we were unable to meet that request but trust the plugin security team will use the information we did provide to the fullest extent. Conclusion It was an exciting November, I hope that getting a few of these patches out and working with cooperative plugin authors helped save others from having a similar problem. It is our goal to continue keeping our customer’s sites secure even in the face of unpublished vulnerabilities and if we must, provide the details of any discovered vulnerabilities so sites hosted everywhere also receive security patches to prevent compromises everywhere for the platform which hosts such a huge percentage of the entire internet. Note: As we mentioned, the two cited plugins above are just a sample of the plugins we identified as vulnerable, we will continue to reach out to the many other plugin authors as time permits and pass our findings back to the wordpress.org plugin team.
<p class="p1"><span class="s1">The question “What is PressARMOR™?” comes up now and again here at Pagely, and this post aims to answer that question. <a href="https://pagely.com/solutions/secure-wordpress-hosting/" target="_blank" rel="noopener noreferrer">PressARMOR™</a>, in short, is a series of procedures we apply towards WordPress security on behalf of our customers. It is not, however, a magic bullet — vendors offering all-encompassing WordPress security solutions tend to be ignorant of the breadth of security risks.</span></p> <p class="p1"><span class="s1">PressARMOR™ helps prevent and mitigate attacks using security best practices, like firewalls and patching, but we don’t limit our security practices to just software. PressARMOR™ also includes how we train staff, perform outreach and research new threats.<br /> </span></p> <p class="p1"><span class="s1">Here’s a non-comprehensive list of where we focus our security efforts:</span></p> <ul> <li class="p1"><strong><span class="s1">Server Security<br /> </span></strong>Building WordPress on a secure platform is vital. Servers maintained by our staff are kept up to date with regular package updates, and in the event of major security flaws, we ensure that the applicable patches get applied across our network in a timely manner.</li> </ul> <ul> <li class="p1"><span class="s1"><strong>Compliance Practices</strong><br /> </span>Regulatory and compliance needs are important to many Pagely customers, and our security staff are here to help as proverbial ‘security concierges.’ We assist with scheduling scans (through third-party vendors,) reviewing the final report generated for any major issues and help with the remediation process.</li> </ul> <ul> <li class="p1"><span class="s1"><strong>Mitigation and Monitoring</strong><br /> </span>Preventing successful site/server attacks is critical. Equally important: taking steps to monitor services in the event an attack was successful and went undetected. Our systems perform daily scans looking for evidence of intrusion. In the event a successful attack is reported, our security team performs an investigation, described below under Incident Response.</li> </ul> <ul> <li class="p1"><span class="s1"><strong>Incident Response</strong><br /> </span>We take steps to investigate every security incident identified or reported. The goal is to provide our customers with details on the attacker’s actions and recommended remediation steps. The investigations we perform not only help the site affected, but all sites we host. We use the knowledge of successful attacks to help improve site security for all of our customers.</li> </ul> <ul> <li class="p1"><span class="s1"><strong>Employee Training</strong><br /> </span>Security concerns are not kept quiet or pushed off as someone else’s problem here at Pagely. Every team is involved and aware of security risks and each team member does their part.</li> </ul> <ul> <li class="p1"><span class="s1"><strong>Community Outreach</strong><br /> </span>We also understand that securing just your network is not the be all and end all of security. Giving back to the community and sharing security issues with others is key. As more sites are able to protect themselves from attacks and WordPress becomes a harder target to compromise, fewer attacks are likely to occur.</li> </ul> <ul> <li class="p1"><span class="s1"><strong>Evolution</strong><br /> </span>Finally, it’s important to note that PressARMOR™ is always evolving. Some features described above were not as well developed last year as they are today. By next year these features and functions will continue to develop and improve what we call “PressARMOR™”.</li> </ul> <hr /> <p class="p1"><span class="s1">The effort we have put into PressARMOR™ has been fruitful. Within the last few months our incident response program has provided us with important details on brute force attacks. Using that knowledge, we enacted new mitigation methods and have all but nullified this attack vector. You can read about it on the blog post “<a href="https://pagely.com/blog/the_wild_west_of_bots_and_brute_forces/" target="_blank" rel="noopener noreferrer">Wild West of Bots and Brute Force Attacks</a>” – as well as where I made light of here: “<a href="https://pagely.com/blog/one-rogue-plugin-a-noncanonical-star-wars-and-wordpress-security-story/" target="_blank" rel="noopener noreferrer">One Rogue Plugin</a>”<br /> </span></p> <p class="p3"><span class="s2">Security does not end with us, though -it will always include you, our customer. This blog is part of our security outreach so please keep an eye for new posts about <a href="https://pagely.com/topics/wordpress-business/security/" target="_blank" rel="noopener noreferrer">WordPress Security</a> here on this blog. Check there as well for posts in the future which may detail further the current state of PressARMOR™.</span></p>
The vulnerability d’jour this week was named HTTPoxy, an applicable pun on pox and proxy. We have patched our servers for this already, and are here to take a few extra steps to help explain the vulnerability and hopefully spread a little knowledge. The first part of this post will explain how the HTTPoxy vulnerability works, and later I will discuss how it may affect WordPress sites. TL;DR: Skip ahead to read how it affects WordPress sites. Here are a few key words / definitions to keep in mind for the following reading: Request Header: This is a list of free-form fields of which browsers or web clients sent to a web server. Proxy: In technology, a proxy is a service that acts as an intermediary for requests from clients seeking resources from other servers. API: In this context web service APIs are interfaces with third party systems to exchange or process data. This vulnerability is surprisingly not new, a similar flaw was reported in libwww-perl back in 2001. This is a reminder that sometimes vulnerabilities will keep coming back until they’re ingrained in people’s minds — perhaps that’s one good side effect of the logo+website method of vulnerability disclosure. The issue is simple, developers wrote code and assuming a system environment variable “HTTP_PROXY” can only by the system. This assumption can be incorrect in some of the most popular environments when the servers (nginx, apache, etc..) pass on information they have about the request to the CGI (php, perl, ruby, etc…) environment allowing a visitor to the site to set the HTTP_PROXY value. This is all caused by request header variables, which are set by the visitor, then renamed “HTTP_variable name” in the code. The problem here, is that a request header variable named “Proxy” gets renamed to: “HTTP_PROXY”. Then in turn if the code uses the value of “HTTP_PROXY” as it’s value to proxy any outgoing HTTP connections it needs to make, you have the perfect storm that creates this vulnerability. The biggest problem that would enable this to be a major concern is, Web based APIs. APIs or other methods in a site’s codebase are used to communicate with remote servers, typically over HTTP are common. They enable a site to be able to talk with other servers, like payment processors, user authentication services and much more to get a task done. If your site does this, perhaps via a plugin or other add-on, and that code inadvertently trusts the value of the HTTP_PROXY to use as a Proxy for it’s connections when sending API requests … well, that will be a problem. Here is two ways it would make you have a very bad day: Stealing secrets: Some APIs require requests to be sent with secret values, this is how they validate who you are and allow you access to the actions you can take. Since the secret key value is sent with every request, they can be stolen if the API request is sent to a server under the attacker’s control. The attackers would then be able to use your API key to tell the service to do whatever that API allows of you! (Imagine how bad this would be if your API key for your payment processor was stolen?) Man in the Middle: The example of a man in the middle attack would affect a site that uses an API to validate an action being attempted. The attackers would send the request to your site with their malicious proxy information and when the site attempts to validate the action the attacker’s proxy always responds how the attacker wants. What should be a failed login, the attackers proxy would respond with successful login. What should have been a declined charge, the attacker’s proxy can say went through, which could mean you’re sending out a product that was never actually paid for. Sounds scary enough to me, but does this affect WordPress? The WordPress core is not affected. It does not rely on an API for authentication or other purposes, nor does it utilize the value of HTTP_PROXY for any purpose. However, plugins are a different matter. With the concerns of the community in mind, I began auditing the source code of every active WordPress plugin to identify what plugins may be vulnerable. In total over 2 dozen likely vulnerable plugins were identified as at risk due to blindly trusting the HTTP_PROXY value. The information gathered was forwarded to the plugin team about the findings. Much thanks goes out to @ipstenu the Representative of the Plugin Repository Team (aka Lead Plugin Repo Wrangler) who volunteered to help spread the word to the plugin authors so they can fix the problem in their code. The majority of affected plugins were caused by libraries they included. While not the plugin author’s direct fault, it’s hopeful that they’ll update their plugin’s library quickly. This would also be a time to remember the importance of keeping a code base’s libraries up to date, especially in the case of security issues that may crop up. For the time being, hosts can apply patches to purge the “Proxy” header (as explained on httpoxy.org), we have done this ourselves but we hope that taking the extra step and getting the plugins patched directly will help avoid any further bad press for WordPress security and community. For more on how we handle reverse proxy hosting here at Pagely, read this.
The key to success is starting with a solid foundation. When it comes to succeeding at security, passwords are part of the foundation. Failure to choose a good password will equate to failure in security eventually– if not almost immediately. In the WordPress sphere of security, brute force attempts at account passwords by attackers is a clear and present danger. The rate of these attempts we see, and every host sees, is staggering. We see these attempts from bots at all times and take steps to prevent them from being successful where we can. Multiple layers of security to prevent these bots from being successful with their brute force attempts include: Preventing customers from setting weak or insecure password from their wp-admin pages. Rate limiting IP addresses that have too many failed logins too quickly. Outright disallow attempts to log in to a site using common insecure password combinations, learned by monitoring the brute force bot activity. To get some insight on this, using around a week’s worth of logs of wp-login attempts, millions of records, we found our firewalls and security mechanisms were blocking the majority of the requests. At least one-third of the time, our rate limiter was blocking IP addresses from making any further attempts. The most targeted account name was: admin (this is no surprise) followed distantly by administrator and user, after these though it is clear the remainder of attempts were targeting site-specific account names. While changing the admin username to something else doesn’t hurt, it’s important to know it is not a solid plan for security sake as your site’s usernames can still be guessed/enumerated. Having a strong password on your admin account by any name is the key to security success. What can we learn? Choosing strong passwords as a preventative measure for site security is critically important. Hidden or secret accounts are not a substitute for choosing a secure password. Extra Credit: Two Factor Authentication Two Factor Authentication, also known as 2FA and sometimes called multi-factor authentication– for clarity reasons I’ll address it as 2FA here. A post talking about authentication and insecure passwords should always discuss 2FA. Consider adding a 2FA step to your WordPress login page. Adding this simply requires a secret token (typically accessed via an app on your smartphone) in addition to the account’s password to authenticate you are the account’s owner. What value does this add aside from being a nuisance? Here’s why: I once set up a WordPress site as a honeypot to collect commonly used passwords by these brute force bots, I also had the audacity to leave the admin account named “admin” with a password of “password”. The admin account remained uncompromised through millions of attempts over the course of a year, all because I had enabled a 2FA plugin which required a time-based token along with that easily guessed password. Many attempts by bots would have gotten through if it was not for that 2FA plugin. In the end, when decommissioning the site I turned off the 2FA plugin just to see how long it would take to be compromised. Spoiler alert: it was compromised in less time than it took to watch a feature-length film. There are many plugins that offer two-factor authentication they are simple and tend to be painless to set up and get running. If you want to take security that extra mile with your wp-admin, then for authentication, 2FA is the way to go. Pagely already gives you the option to enable 2FA on your hosting dashboard for enhanced security and strongly encourages that you do so. For a tutorial on how to do so see this support FAQ.
Over the last week the news has been littered with stories about data leaks. From one of the biggest data leaks in history, the Panama Papers* to a movie that tells the story about a data leak a long time ago, in a galaxy far far away! “Rogue One” coming out in late 2016. Star Wars fans finally get to see the first canonical storyline regarding how the plans for the original Death Star were stolen by the rebels. With these two stories catching the headlines, I felt like putting together a quick last-minute work of fan fiction combining the Star Wars universe with threats that exist in our world and have been loosely connected to massive data leaks. How the rebels might have gotten the Death Star plans if the empire was running insecure website software. It is not far fetched to assume the Empire is built on bureaucracy. It likely included multiple layers of strict policies and paperwork to fill out for the various departments as they request assets, such as websites or, more accurate, blasters. Somewhere in this mix imagine a department of propaganda is tasked with running something like a website and, for the sake of simplicity, they’d choose software similar to WordPress to help them distribute the emperor’s pro-Empire message easily and efficiently to readers galaxy wide. The Empire’s IT team sets up the server as the propaganda department requested on the Empire’s internal servers, because they have plenty of resources like servers and data center space for all the Empire’s IT needs they are smart and set it up on their own system separate from systems that handle email or collect invoices from Blacksun. Like any good website owners, the propaganda team customized the site with plugins/themes and, of course, set up accounts for both the Emperor and Vader so they have direct access to write posts about the future plight of the Bothans and such. With the above scenario, the site would likely get plenty of funding and attention when it was first set up. Vader would be writing his monthly state of the empire addresses and the Emperor occasionally write posts like “The top 10 things that make a Sith better than a Jedi”. Everything runs smoothly for a few years and eventually the people who set up the site and handled updates get promotions to new departments. The people who still log in to the site choose to ignore those “update available” warnings because “someone else had always taken care of those.” Then came one fateful day, which passed like any other day … The “updates available” notices still being ignored and security patches being missed. One unnamed rebel tries an exploit and is amazed that the site that has gone unnoticed is now in their control. Being smart, they don’t modify any content on the site itself (although the idea of writing a post by Vader about how the Emperor never washes his robe would have been epic) they instead see what data they can pull off the site. They have access to the site’s files, databases and little else (remember, the IT team for the empire only built this server for the purpose of just this site) … But, the rebels now had access to the hashed passwords in the database and a place to run commands and access other systems from within the Empire’s network. They get to cracking the passwords: The Emperor’s password of “123456” is guessed immediately, Vader’s password gets figured out some time later: being “Vader<3sPadme” it had more complexity. With their new knowledge, the rebel’s turn their attention to attempting to do what any self-respecting rebel hacker would, pivot and gain further access. They use what information they have now, Vader’s and the Emperor’s email addresses which are part of the account, and their passwords, plus access from a system that happens to be inside the Empire’s internal or “secure” network. The Emperor’s password doesn’t work on palpatine@the.empire, but they get a lucky break with vader@the.empire’s password matching and they get access to a treasure trove of internal documents. Including an email with the subject line “RE: Death Star plans for your review” he was CC’d on, with an attachment of some value to the rebels. Next thing you know, the plans are in the hands of the rebels and being sent to a ship in service of the House of Organa. Vader, feeling ashamed of being at fault takes an Imperial I-class Star Destroyer named Devastator to square off with the much smaller Corellian corvette just outside the orbit of a small desert planet named Tatooine. There you have it, my little WordPress+Star Wars security fanfic. Now, of course, this is all conjecture and you’ll have to wait for the release of “Rogue One” later this year to find out the truth. Of course, if it turns out to contain any spoilers I will apologize and promise I did not have a bootleg copy of the movie or script. We’ve seen plenty of data leaks in real life, though, and even the biggest empires, smallest corporations and personal blogs benefit from the moral of the above story: keep websites for non-critical needs separate from the private or corporate network have it be managed by teams of security professionals that will maintain (update) the systems never share/reuse passwords. Farewell, and may the force be with you.
<p align="justify">This article covers our public notifications related to major security issues our clients and the WordPress community should know about. We are always focused on <a href="https://pagely.com/solutions/secure-wordpress-hosting/">prevention and the mitigation of risk to our clients</a>, and keeping you updated here is part of that process.<!--more--></p> <h3 align="justify">List of Vulnerable Plugins During This Month</h3> <p style="text-align: center"><style type="text/css" name="visualizer-custom-css" id="customcss-visualizer-21824"></style><div id="visualizer-21824-703287860"class="visualizer-front visualizer-front-21824"></div><!-- Not showing structured data for chart 21824 because title is empty --></p> <h3>Plugins Closed by WordPress Security</h3> <p style="text-align: center"><style type="text/css" name="visualizer-custom-css" id="customcss-visualizer-21828"></style><div id="visualizer-21828-630137157"class="visualizer-front visualizer-front-21828"></div><!-- Not showing structured data for chart 21828 because title is empty --></p> <p align="justify">WordPress security team decides to close a plugin when a security issue is found and the developer doesn’t release a patch in a timely manner. You can read more about this <a href="https://developer.wordpress.org/plugins/wordpress-org/alerts-and-warnings/" target="_blank" rel="noopener noreferrer">here</a>.</p> <h3 align="justify">Relevant Vulnerabilities</h3> <p align="justify"><a href="https://wpscan.com/vulnerability/10478" target="_blank" rel="noopener noreferrer">secure-file-manager</a>:<br /> <b>Authenticated File Upload</b></p> <p align="justify"><a href="https://wpscan.com/vulnerability/10471" target="_blank" rel="noopener noreferrer">ait-csv-import-export</a>:<br /> <b>Unauthenticated File Upload</b></p> <p align="justify"><a href="https://wpscan.com/vulnerability/10457" target="_blank" rel="noopener noreferrer">augmented-reality</a>:<br /> <b>Unauthenticated File Upload</b></p> <p align="justify">These plugins have critical vulnerabilities that when exploited would give an attacker complete control over your website. All of them are closed, which means no new installs are allowed but old installs will work without any issues, thus, please check if you have any of them installed <i>(</i><b><i>even if it’s not activated</i></b>) and remove them from your plugins folder.</p> <p align="justify"><a href="https://wpscan.com/vulnerability/10479" target="_blank" rel="noopener noreferrer">woocommerce-anti-fraud</a>:<br /> <b>Unauthenticated Order Status Manipulation</b></p> <p align="justify">Versions < 3.3 of this plugin have a bug that when exploited could cause unnecessary damage to your online store. An unauthenticated attacker would be able to change the status of all the orders making it difficult to handle them since the data will not be reliable. On <strong>November 23</strong> the developer released a <a href="https://dzv365zjfbd8v.cloudfront.net/changelogs/woocommerce-anti-fraud/changelog.txt" target="_blank" rel="noopener noreferrer">new version</a>.</p>
This article covers our public notifications related to major security issues our clients and the WordPress community should know about. We are always focused on prevention and the mitigation of risk to our clients, and keeping you updated here is part of that process. List of Vulnerable Plugins During This Month Plugins Removed From the Repository WordPress security team decides to close a plugin when a security issue is found and the developer doesn’t release a patch in a timely manner. You can read more about this here. If you are using one or more of the above plugins we recommend deactivating them until the developer releases a patch for the mentioned vulnerability or consider a more reliable alternative. Relevant Vulnerabilities Ti-woocommerce-wishlist : Authenticated WP Options Change A critical vulnerability was found in this plugin that when exploited allows an attacker to: Change the site options Create malicious redirects Escalate privileges (login as an administrator) This issue was resolved in the free version 1.21.12 on October 16, however when checking the premium version we noticed it was still vulnerable and was finally resolved on October 28 after we reported it. More details here. WPBakery Page Builder : Authenticated Stored XSS WPbakery Page Builder former Visual Composer had a medium vulnerability in versions before 6.4.1 that was only exploitable by high privilege users. Nevertheless we recommend all its users to update to the latest version. Loginizer : Unauthenticated SQL Injection Loginizer had an unauthenticated SQL Injection in versions before 1.6.4 caused by a lack of filtering before executing a database query. An attacker just had to craft a request with a malicious username. More information here.
Pagely is thrilled to announce our partnership with Object Cache Pro. Utilizing state of the art compression technology, Object Cache Pro is now part of Pagely’s core offering, and available to all of our customers, platform wide. Offering major cost savings, access to some of the world’s best technology, and a dedicated DevOps team to personalize your setup, Pagely customers can look forward to continued scale and growth, with no hosting friction. A first of its kind partnership, Pagely is proud to help fund innovation in this WordPress space by investing part of our budget into working alongside the fantastic team at Object Cache Pro. We’ve already seen great gains with Object Cache Pro and our customers can look forward to more in the future! Why Object Cache Pro? Before Object Cache Pro, we faced two challenges with sites making use of an object cache – CPU overhead and network saturation. The underlying technologies in Object Cache Pro solved both of these problems for us, translating to less money spent on server hardware and fewer situations where the (quite generous) AWS network limits are reached. With Object Cache Pro’s state of the art technology utilizing the Zstandard compression library from Facebook, without a lot of CPU overhead, compression is now done at the extension level, talking to and from Redis. This means less hardware, lower costs, and a better experience for our customers. Aside from supporting an efficient compression algorithm (zstd), Object Cache Pro also uses the igbinary serializer which is a drop-in replacement for the standard serializer in PHP. This works about twice as fast at serializing and unserializing data. Additionally, the data footprint is smaller when using igbinary and that translates into less memory being used by the underlying Redis service. We also found an in-depth comparison on igbinary vs other serializers on Blobfolio that you may also enjoy reading if you’re into this kinda stuff: https://blobfolio.com/2017/03/benchmark-php7-serialization/ With a wide selection of Redis plugins available in the WordPress marketplace, Object Cache Pro was the obvious choice for us not only because of their forward-thinking tech but also because of the dependability we have come to expect and appreciate from their brilliant team. All of this aside, Object Cache Pro is unrivaled when it comes to bug fixing, an extent to which is a rarity across opensource software. There’s a saying in the opensource community that goes, “there’s a lot of eyes so all the bugs get fixed.” But, more what we see concentrated use of the software by lots of users leading to fewer bug fixes for fear of breaking one users’ site. That, and, no one owns the codebase, so less can get addressed in a timely manner. Similarly, we are continuously impressed by their coverage of testing, fully unit tested with 100% code coverage. Further, switching over to Object Cache Pro gives Pagely customers access to our commercial relationship with their team, which means any problems our customers see are fixed within a few days. You benefit from our relationship. Fewer bugs in the caching layer and full unit testing is a good thing, and that’s something we stand behind. So, What’s in it for the Pagely Customer? We are the first premium host to achieve this level of partnership with one of the best technology companies in WordPress. Through our relationship with Object Cache Pro, every single Pagely customer benefits from the work we’ve done to secure that. But real talk, what’s in it for you? Major cost savings. Even when it means less revenue for Pagely, we’re constantly looking out for cost savings for our customers. By decreasing our dependency on more hardware, you see the savings directly on your bill. Access to a premium partner. Since you’re at a premium hosting provider, you automatically get access to the partnerships we’ve developed. What’s more? You don’t pay an extra licensing fee. The best tech, baked into your Pagely account. We’re always on the hunt for the best and most innovative technology for you. With no effort on your part, we do the legwork of implementing this tech across our technology stack. All you do is benefit from it. Bigger performance wins possible with a little extra code work. WordPress has a feature called Transients. It’s a way to store the result of a complex query or a long-running remote API call temporarily in order to make subsequent lookups for that data return a lot faster without doing the same expensive operation again. Normally without any object cache, transients are stored in the WordPress database’s wp_options table. When using an object cache, it is stored in memory. Adding a few extra lines to your code allows you to tap into the power of this API for incredible performance gains. Having an efficient object cache utilizing fast compression and serialization only increases those gains. A dedicated DevOps team. While others might catch on and jump on the bandwagon of partnerships like this, Pagely still stands above the rest in meaningful ways that translate to real gains for you, the customer. Our DevOps staff becomes your dedicated, in-house team. Our engineers handle all the setup and optimization to make sure your usage of Redis is optimized specifically based on your exact circumstances and needs. Other hosts don’t do that! When you partner with Pagely for your WordPress hosting at scale, you know you have selected the most forward-looking host driven by advances in technology, cost savings for you, and tangible outcomes that help your business thrive. Object Cache Pro Helped FanSided Scale So let’s get to a real-life example here. One of the first Pagely customers we switched over to Object Cache Pro was FanSided. Here you can see a dramatic decrease in network utilization on the Amazon Aurora RDS instance after implementing Object Cache Pro along with custom Transients Caching, which dropped usage from 1 Gigabit per second to 400 Megabit per second; and yielded even lower usage after some more optimizations were made. FanSided comprises a massive network of over 300 active websites and needed a fast solution to maxing out servers and using way too much CPU. Pagely found that solution in Object Cache Pro and implemented it with no effort on FanSided’s part to completely eliminate those issues. Here you can see how memory is no longer being maxed out after the date we turned on Object Cache Pro for FanSided. The proof is in the data, and here you can see dramatic drops in CPU usage after Object Cache Pro was implemented, as well as servers being maxed-out-no-more after the switch. Dramatic drops in CPU usage after implementing Object Cache Pro for FanSided. Read the full FanSided + Object Cache Pro case study here, and take it from our CEO: “In the vacuum of 1 website, a small performance gain is useful. At our scale of hosting, processing hundreds of billions of requests per month across thousands of AWS EC2 instances, a small performance gain to each site means a real and quantifiable benefit to our customers and our bottom line. Now what if that performance gain was not so small, but major. We sought out and partnered with Object Cache Pro after seeing the dramatic results in terms of performance and resource usage when testing. We have thus deployed their Enterprise solution fleet wide and the results speak for themselves.” – Joshua Strebel, CEO of Pagely
