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.
WordPress 5.3.1 Security Release
December 13th, 2019
A vuln is a vuln,
until a patch is released.
Now it is secure.
The WordPress core team has released WordPress 5.3.1, which addresses 3 security vulnerabilities and includes 1 security hardening measure. The higher risk vulnerabilities include XSS (Cross Site Scripting) in some unlikely situations, as well a vulnerability which could allow someone to mark a post “sticky” on the site, without the need for authentication.
Pagely has tested this version and has the patch available for all customers running any WordPress version. Due to the weekend being upon us, we will begin upgrading sites on Monday December 16th. Any customers who would like the upgrade to be performed over the weekend can reach out to our support staff and they will be glad to help.
PHP-FPM+Nginx Remote Code Execution (CVE-2019-11043)
October 29th, 2019
Hasty vuln released.
We checked immediately;
Our servers are safe.
On October 22nd, 2019 a security researcher released their findings related to a remote code execution in PHP-FPM, which was present on hosts with specific nginx configurations using fastcgi_split_path_info.
Pagely’s stack does use the fastcgi_split_path_info directive within our nginx configurations, and our staff investigated the vulnerability on the 22nd the day of the relase. We identified we were already properly using the recommended remediation of try_files to ensure the file being requested actually exists on the website. Pagely’s default nginx configuration is not vulnerable.
On October 24th the PHP dev team released the official patch version to address this vulnerability. Our staff have already started applying this patch to all customer servers.
WordPress 5.2.4 Security Release
October 15th, 2019
Secure WordPress Fast
Secured by this Patch.
The WordPress.org core team has released WordPress 5.2.4, a security release addressing six vulnerabilities from XSS to viewing unauthorized posts.
Pagely staff have already begun applying patches to our customer’s WordPress websites. Customers with version holds will only receive the patch for the branch they are currently running.
WordPress 5.1.1 Security Release Addresses XSS
March 15th, 2019
Comment filter for
Cross Site Scripting prevention;
Helps secure WordPress.
The WordPress.org core team has released WordPress 5.1.1 which is a security release to address two vulnerabilities related to improper filtering of comments on WordPress sites.
Pagely staff have already begun applying the patch for each of our customer’s WordPress version, and will keep customers on their current branch version if they have requested a version hold.
WordPress 5.0.1 (and 4.9.9) Security Release
December 13th, 2018
WordPress new release
Patches seven vulns in all.
Handled by our team.
The WordPress.org core team has released WordPress 5.0.1 which is a security release to address a number of vulnerabilities found in WordPress versions 5.0, 4.9.8 and older. The core team has also provided security releases for WordPress versions 4.9.x, 4.8.x, etc.. which addresses the same vulnerabilities for that WordPress branch release.
Pagely staff will apply the appropriate patch for each of our customer’s WordPress version, and will keep customers on their current branch version. This means, if you’re running 5.0, we will apply the 5.0.1 patch, if you’re running 4.9 then we will apply the 4.9.9 patch, and so on with 4.8 and etc… This patching will be completed by the end of the week.
WordPress 4.9.7 Security Release Addresses Arbitrary File Delete (CVE-2018-12895)
July 5th, 2018
We patched this last week.
This security release
is safe to wait for.
The WordPress.org core team has released WordPress 4.9.7 which adds some functionality and includes a security patch for the previously reported “Arbitrary File Delete” vulnerability (CVE-2018-12895) which we addressed last week Pagely implemented a patch to address this vulnerability on all customer websites, as there was no WordPress.org patch available when the vulnerability was publicly disclosed.
Pagely customers can request to be upgraded to patched versions of WordPress over the weekend, all customer sites will be upgraded by early next week.
WordPress Author Arbitrary File Delete (CVE-2018-12895)
We trust our authors,
to not delete files, but
let’s not allow it.
RIPSTech researchers Slavco Mihajloski and Karim El Ouerghemmi reported yesterday of a vulnerability in WordPress core which would allow users on a WordPress site with Author level access or higher the ability to delete and/or re-upload any file writable by the PHP process WordPress runs under.
The limitation of this vulnerability hinges on the fact a malicious user must also be someone a site owner trusted with having author level access already (or a compromised author user account could be abused)
The consequence of this vulnerability would be that an attacker or malicious user could potentially remove files on the server, which may disable protections (such as .htaccess files, or security plugins), or allow them to re-write a site’s wp-config.php (to point your site at the attacker’s database, or install their own credentials/secret keys.)
Our infrastructure configuration does not allow PHP processes to be able to modify any WordPress core files, however the risk of modifications to plugins, .htaccess files or other user uploaded files remains.
To address this we have implemented a recommended hotfix which sanitizes the file path in the attachment delete/modification function used by WordPress core.
The patch implemented has been tested and verified as safe and will be pushed out to our customer servers this week. If for any reason this hotfix causes issues with your site user’s ability to remove or edit media on your blog, please let our support staff know and we can help sort out the problem.
PHPMyAdmin File Inclusion and Remote Code Execution (CVE-2018-12613) (PMASA-2018-4)
Admin your DB
with php, securely.
We did the upgrade
Pagely customers who have phpMyAdmin configured on their servers can rest assured we have taken steps to upgrade all of our customer’s phpMyAdmin installations to address multiple vulnerabilities recently reported.
TLS 1.0 Retirement
It’s been a long time coming, so break out the gold watch and cake. TLS 1.0 is finally being retired across the web thanks to the push by PCI-DSS.
Pagely is updating our customer websites this week to address this and will be supporting TLS 1.1 or higher by default on our servers this week. By default, customer websites will only communicate over HTTP using the more secure TLS 1.1 and 1.2 protocol versions, and TLS 1.0 will no longer be an option.
The reason for the change has been a long time coming. There are multiple browser based vulnerabilities in TLS 1.0, and the protocol version has been depreciated for years. However, the big deadline is that PCI-DSS counsel has set a hard deadline for June 30th, 2018 as the final day that sites will no longer be able to pass PCI scans if they have TLS 1.0 enabled in any manner.
The impact of requiring TLS 1.1 or higher, is almost certainly going to be negligible. Every major browser supports TLS 1.1 and 1.2, rough estimates put less than 4% of the global internet traffic as using a browser that only support TLS 1.0, this is mostly composed of old mobile devices. So, sorry everyone on a dated iPad or Android tablet/phone, it’s not safe for you to transmit data over HTTPS and hasn’t been for a long time! Luckily, this number continues to drop every year, as these old devices eventually get replaced or taken out of service.
Pagely Login Page Updates
Pagely customers will notice something new when accessing their Pagely administration panel https://atomic.pagely.com on May 31st 2018. Our new login portal! Don’t worry, this change is expected as we are rolling out some improvements to our administration panel and preparing for it’s replacement.
When you visit https://atomic.pagely.com your browser will automatically be redirected to our new version of Atomic. You may see the words “BETA” here and there, and some customers (those already upgraded to ARES) will have new features available as well.
There is nothing you need to do on your end at this time, your login will function as normal and the new atomic panel has all the same basic features as the old one — If you’re feeling a little nostalgic, you can still switch back to the old Atomic panel by hitting the “Atomic (Legacy)” button found in the panel.
In the near future we will be offering a new 2FA feature to give our customers a better experience with their 2FA management, but this first login portal change on 2018-05-31 will not affect your existing login credentials.
PHP Security Patch (CVE-2018-10546 CVE-2018-10547 CVE-2018-10548 CVE-2018-10549)
You need a null byte;
Or you get heap overflows!
MakerNote take Note.
PHP has released a security patch which addresses four security vulnerabilities, the worst of which is a heap overflow from uploaded images which lack null bytes or corrupted EXIF data in MakerNote files. Further details available in the PHP 7.0 Changelog and PHP 5.6 Changelog.
Pagely has begun upgrading customer servers and all PHP versions will be on patched in the next few days, if not already.
WordPress 4.9.5 Release
in the four nine five release;
Other bugs fixed too.
WordPress version 4.9.5 has been released and is considered a security and maintenance release. The WP core team addressed 3 security related bugs which are not critical security bugs, but improve the code’s overall security. You can read more about the release here.
Pagely will begin updating customer sites to 4.9.5 shortly.
DNS must be trusted.
Or else, oh no! Hacks!
Nick explains that if attackers control the name servers the website uses to lookup domains, then it’s possible to “spoof” being the WP update server due to WordPress defaulting to HTTP communications when HTTPS fails during updates. This report outline that if attackers were able to take control of a DNS server, they could pivot that access to then also take over WordPress website via the WordPress auto-updater as well as exposes a PHP Object injection as well.
Pagely customers are not affected by this vulnerability, as we are a managed host and do not allow modifications to what name servers our customer’s servers utilize. Secondarily, our server permissions would not allow WordPress auto-updater to function on it’s own (we handle upgrades for customers), this is identified in the “caveats” section of the vulnerability disclosure page as a preventative measure.
WordPress load-scripts.php DoS (CVE-2018-6389)
Feb. 6, 2018
Loading all the scripts,
leads to long web responses.
Rate limiting, Win.
We are aware of the reported Denial of Service (DoS) affecting WordPress’s /wp-admin/load-scripts.php; Assessing the risk we believe our caching system dramatically reduces any DoS threat targeting a single URL with scripts like this.
We are implementing a fix which is currently in testing, it will limit the number of requests people can make to this file before being throttled and subsequently blocked. This fix will be available for all customers, including those on the new ARES platform.
WordPress Security and Maintenance Release: 4.9.2
Jan. 16, 2018
Other people’s code
How did it get on your site?
Sad emoji face.
WordPress version 4.9.2 has been released and it contains an update to address an insecurity in the Media Elements library, which is included in WordPress core. The patch addresses a cross site scripting (XSS) vulnerability, which could allow remote attackers to inject their own HTML onto your site.
Pagely will be patching customer sites immediately, and should be finished shortly. If you would like to read more about this release please see the WordPress blog announcement here.
Spectre and Meltdown
Jan. 5, 2018
outside of your privilege.
Time to patch kernels.
[Update: Feb 2, 2018 CST]
Our kernel hotpatch provider has released a working patch for Meltdown as well, and it has been applied to all customer servers.
[Update: Jan 18, 2018 09:00 CST]
Spectre: Patched without the need for a reboot
Meltdown: Patch available if you request a reboot, we are still waiting on the no-reboot patch which is close to being tested as safe to apply. If you are concerned about the risks associated with Meltdown, contact support to request a server reboot. Or wait until our no-reboot patch has been tested and is working safely.
Risk associated with Meltdown: There are still no PHP based proof of concepts, therefor we consider it a low-likelyhood that anyone (aside from someone with SSH access to your server) would be able to perform this attack on your site/server. If you disagree with this risk assessment, then please contact support and we will schedule a reboot to apply the patch for Meltdown ASAP.
[Update: Jan 11, 2018 11:30 CST]
Our kernel patch provider has released a working patch for Spectre, but not Meltdown. We will be applying the Spectre patch to all servers before the end of the week, and will be awaiting their patch for Meltdown when it becomes available.
If you would like to hasten the patch time, we can apply the kernel patch from Ubuntu (released yesterday) however this will require a schedule reboot for the change to take affect. If you would like to schedule a reboot of your server, please contact our support staff from your account’s primary contact email address (or via our administration panel)
These patches are known to cause a negligible performance hit on servers when applied. It’s likely you will not notice this performance hit on your site unless your code does a large amount of system calls and/or you are already close to needing an upgrade. Our engineers are working on a solution to this issue and we may be able to work with customers impacted to entirely remove this performance hit or actually come out ahead.
[Update: Jan 9, 2018 09:00 CST]
At this time (Tuesday January 9th) we do not yet have a stable patch to apply to customer’s servers.
The patch plan for early this week was not met. This was due to the complicated nature of this patch, and ensuring a stable patch is what is pushed out to servers.
It’s been identified by multiple sources that this patch is not the simplest, concerns of stability and CPU overhead come up and this has delayed the patch from either Ubuntu (our operating system) or KernelCare (our kernel patch provider).
Risk assessment: The existing proof of concepts for these vulnerabilities are not executable against our customer’s sites due to how our PHP is configuration (we restrict/ban any exec/shell calls) which reduces the risk of this vulnerability. Only customers with compromised SSH accounts would be vulnerable (and if there does exist a PHP PoC in the future, only customers with compromised sites would be exposed.)
We are delaying the patching process. This decision is made under the consideration that many people are reporting issues with the patches available, and the lower risk this vulnerability has at exploiting WordPress sites on our network.
We expect patches from one of the upstream providers (Either KernelCare or Ubuntu) tomorrow, Wednesday Jan 10th, however this may be delayed.
When a patch is available, if it is Kernel Care, no reboot will be required. If it is Ubuntu, then we will need to reboot your server for the change to take affect. We will begin applying patches for customers this weekend or next week (a few days after the patches are released so we have time to test the patch sets.)
We will contact customers via email to schedule a reboot, if it will be required to apply this patch.
Pagely is aware of the multiple related vulnerabilities in Intel (and other) CPUs known as “meltdown” or “spectre” and has been working on patching affected servers. This vulnerability is a bit different than most, as it requires patching done on the bare-metal server as well as a second round of patching on our virtual instances for Pagely customers.
Our data center provider notified us regarding what servers were affected by a security concern and needed reboots to apply a patch. We have already been working with the affected customers on and scheduled reboots to address this security concern. It’s likely that these CPU architecture vulnerabilities were likely the cause for the scheduled reboots in December. At least check, we have address almost all of these (and the last few are scheduled with the respective customers to happen shortly.) All remaining EC2 instances are on bare-metal servers which likely have been patched without the need for a reboot (however this may change).
If you did not receive an email related to scheduling reboots on your site/server, then the patch for this vulnerability did not require a reboot to take affect. If this changes, we will be on contact with any customers who need to schedule a reboot.
That only leaves the linux kernel on each of our EC2 instances as a remaining concern. Luckily we now utilize a new technology in the linux kernel which allows for live-patching the kernel without the need for a reboot. This patch will be applied to all of our customers as soon as the kernel patch is officially out and properly tested. The tentative timeline for this should be this weekend or early next week (and require no reboot of the server, it should be applied seamlessly.)
Jan. 5, 2018
Click this link my friend
Cross-Site Request Forgery!
But not with Pagely.
Over the holiday break there was a CSRF vulnerability reported with PHPMyAdmin, this class of vulnerability would allow an attacker to send malicious links to users with browser’s already authenticated in PHPMyAdmin to perform actions as the logged in user.
A patch was applied in 4.7.7 to address this issue, and all PHPMyAdmin installations Pagley has have been updated.
WordPress Security and Maintenance Release: 4.9.1
Nov. 20, 2017
Holidays are for:
Family, eating too much,
Don’t worry you can stay distraction free when dining with friends and family this holiday season, knowing that we have handled this WordPress security release update for you and your sites. Instead of worrying if your site has been patched, you can be the one to bring it up at social gatherings and watch as your friends or family with WordPress sites become uncomfortable not knowing if their sites are secure or not.
Pagely customers will receive the WordPress 4.9.1 security release update this week. This security and maintenance release includes patches for multiple vulnerabilities including a cross-site scripting (XSS) and XML eXternal Entity (XXE) issues. This will also officially bring all customers up to the 4.9 branch from 4.8.3, unless you’ve previously written in requesting an upgrade to 4.9 in the last few weeks.
You can read more about this security release and specific details on what it includes here on the WordPress news blog, as well as more details on how we handle major WordPress releases (like 4.9) on our blog here: WordPress 4.9 Release.
Oct. 31, 2017
We patch the tricks, 4 8 3
You get the treats. Boo!
There is nothing spookier than a WordPress security release, the 4.8.3 patch addresses an SQL injection vulnerability in WordPress core which could be exposed by insecure coding practices found in some plugins. This release hardens the WP Core code to protect the sites who may harbor an insecure SQL query that trusts user input, sanitizing the input before it’s passed along to the database server.
More information on this release can be found on the WordPress blog, details on the changes and how it modifies the return value of of esc_sql() have been posted by Gary Pendergast on the Make WordPress Core developers blog.
Thanks goes out to the reporter of the vulnerability (Anthony Ferrara) for working with the WordPress security team. And a special acknowledgement to our own Arman Zakaryan for the Haiku this time around.
Sept. 21, 2017
over OPTIONS requests sent.
This patch stops the leak.
The vuln-du-jour is called OptionsBleed and affects Apache2 web servers. It was caused by a programming oversight in the Apache2 server project which allowed small amounts of memory to be leaked when an OPTIONS request is sent to the web server. This bug only affects sites that are configured with a LIMIT directive which attempts to filter nonexistent HTTP methods, which is extremely rare but does exist in just under 500 of the Alexa top 1 million websites. A more detailed write up about this can be found here.
The Apache2 dev team wasted no time in providing a patch. Which we have already begun applying to customer servers.
We are rolling this patch out slower than a normal security patch because it’s so rare for this misconfiguration to exist and initial reviews of customer sites shows no Pagely customers have misconfigured LIMIT directives which would put them at risk. That said, the patch will be applied in a safe manner over the next week as to minimize any risk of downtime on customer sites related to the upgrade.
Sept. 19, 2017
Within this release,
Nine security patches.
Sites are now secure
This week brings a security update to WordPress core.
The security patches include multiple serious vulnerabilities and we are applying patches as soon as possible for customers. The WordPress core and security team have also released version to address any of the patched vulnerabilities for the following versions: 4.8.2, 4.7.6, 4.6.7, 4.5.10, 4.4.11, 4.3.12, 4.2.16, 4.1.19, 4.0.19, 3.9.20, 3.8.22, and 3.7.22. Any customer of Pagely running older branches of WordPress will also be brought up to date with these security patches.
Malicious Code in Display Widgets
Sept. 13, 2017
We coined a new term:
“plugin identity theft”.
Let it not catch on.
A popular plugin in the WordPress.org repository has been “hijacked” (for lack of a better term) by a developer with suspicious intent. The popular plugin “Display Widgets” is described as “Adds checkboxes to each widget to show or hide on site pages“, yet in the last few releases there have been some unexpected new features added: such as adding posts directly to the site and tracking site visitors. Wordfence, a security plugin, wrote a full explanation on how this might have happened, it’s worth a read here.
For our customer’s safety, we have banned the plugin from our customer sites. If your site hosted with Pagely was affected we have already reaching out directly to help you with the concern.
Update: The plugin team at WordPress.org have released a patched version of Display Widgets which reverts it back to the last known safe version, but there appears to be no author to continue maintenance on the plugin. The plugin will remained banned on our network until a time that we see someone has taken responsibility for the plugin and the future of patching it’s code.
Which plugins and themes aside from display-widgets should you avoid? See our full list here.
WordPress 4.7.5 Release
May 17, 2017
Patchy patchy patch
I love patches for WordPress
Here come the patches
- Pagely customer sites are being updated to address 6 vulnerabilities.
- The ExploitBox Unauthenticated Password Reset Vulnerability has still not yet been addressed; Pagely customers are still not affected.
- Further details on this release can be found here: wordpress.org
May 5, 2017
Return to sender
sending to the wrong domain
read from HOST header.
There was a recently released authentication bypass vulnerability that affects WordPress before and including 4.7.4, with specific server configurations. The attack requires a request to a WordPress site via it’s IP address, while the attacker sets the HTTP request header to their own HOST value. Pagely does not allow direct access to WordPress sites via IP address and requires the HOST field sent in the headers to be the actual site being requested, thus a request with a HOST value controlled by an attacker will not be directed to a WordPress installation at Pagely.
Pagely hosted sites
are not affected by this
For more details on the vulnerability and how it works, please read:
WordPress 4.7.3 Security Release
Mar. 6, 2017
XSS and more
bugs get patched in this release.
The update is done
- Customer sites are being updated to address 6 security related issues.
- Further details on the release can be found here: wordpress.org
CloudBleed, Shattered, CVE-2017-6074
Feb. 28, 2017
SHA One Collision
CloudFlare Leaking Memory
and Kernel Patching
Normally these Haiku’s are short and sweet, but it was a busy week for security in the headlines last week so I took a little more time to compile the following information for you:
The CloudFlare Bug (A.k.a. “let’s not call it CloudBleed”)
A security researcher working for Google’s Project Zero disclosed information on a bug identified in CloudFlare’s services. The bug was in CloudFlare’s services, and in some cases resulted in a trace amount of the contents of the CloudFlare’s servers memory being leaked. This could have had major repercussions as the contents of these servers may contain sensitive information being sent to or from the web server behind CloudFlare’s services (such as passwords, encryption keys, or other sensitive data.) Many news outlets reported this as a catastrophe, however CloudFlare patched it’s server’s before the announcement and there have been no reports of this being attacked in the wild before the report by the Project Zero researcher.
Key points include that the data being leaked was not controllable by the attacker (it was always random, including no ability for an attacker to target a specific site’s data). The data was also limited to small chunks. The leaks however, have likely been happening for a while, no one knows how much data has been leaked to people looking for it or if any widespread attacks could have gleaned any usable data from the memory leaks. Ultimately, while it’s possible every password, SSL cert, and secret keys were pulled from CloudFlare server’s using this attack, it’s not likely to be the case. Most probably: the researchers at Google’s Project Zero were the first to be aware of the problem and reported it responsibly to CloudFlare. However, it is still yet to be seen if anyone reports malicious activity caused by these leaks in the weeks and months to come.
How could this affect you? If you utilize CloudFlare on your site (or utilized a service that used CloudFlare) and wish to be absolutely sure your private data (such as a password) is safe then you may want to be pro-active and change that password or other secret data.
The SHA-1 Collision: (A.k.a. “Shattered”)
A collision in the SHA-1 algorithm was reported by a different team at Google. SHA-1 is a cryptographic hashing algorithm, commonly used to validate the integrity of data being sent. The collision released by the team at Google showed that they were able to send two different messages but they both validated with the same SHA-1 value; ultimately meaning that data signed or verified using a SHA-1 algorithm can no longer be trusted. There is some good news however, this attack is fairly expensive to execute (over $100k) and SHA-1 has been on it’s way out for the better part of a decade. SHA-256 has already been established as the replacement and most people have already migrated to the more secure algorithm.
How could this affect you? If your site has SSL/HTTPS, then that certificate might be signed using SHA-1 , but it is probably already signed using SHA-256 (as of 2015) if you would like to double check you can always utilize a utility like ssllabs.com to look up your site’s SSL certificate and see what method is used to fingerprint it. If you find you are using SHA-1 only, then the fix is to get a new certificate (most likely whomever you purchased the certificate from will issue you a new one using SHA-256 without much hassle.)
Secondarily, if you developed your site’s code explicitly using the sha1 function, then you may wish to swap that sha1 function with the sha256 function.
While CVE-2017-6074 did not have a cool name or website or lots of media coverage; it was a more serious threat. This flaw could allow anyone with access to a Linux server to escalate their privileges from a normal user to root on the server. Linux servers running up to date kernels (such as ours) were affected and we were very concerned about getting this patched for our customers. Luckily we have been updating our infrastructure and these kernel based vulnerabilities no longer require reboots to apply new patches. We applied a patch to address this vulnerability on the same day it was made available and noted no issue with the new kernel code running.
WordPress 4.7.2 Security Release
Jan. 26, 2017
Sites updating now
we handle the patch. So you
focus on your site.
- Customer sites are being updated to address 3 security related issues.
- Further details on the release can be found here: wordpress.org
CVE-2016-5195 “Dirty COW”
Oct. 26, 2016
We have sent many
about the reboot.
- Kernel patches have been applied on our servers, however a restart is required for it to take affect. Scheduled reboot notification emails have been sent out and reboots will take place the week of October 31st.
- More information on the vulnerability can be found here: dirtycow.ninja
WordPress 4.6.1 Security Release
Sept. 12, 2016
The update happened
faster than I could write this
haiku about it.
- All sites have been updated to address 2 security related issues.
- Further details on the release can be found here: wordpress.org
Jul. 20, 2016
A pox on proxy
headers; that are misused by
- Updates to our server configs are being pushed out that remove any “Proxy:” values attempted to be set by a request header.
- More details here: httpoxy.org
- And see also: Pagely’s Reverse Proxy WordPress Hosting
WordPress 4.5.3 Security Release
Jun. 21, 2016
issues are addressed.
- We are currently testing and rolling out this security update.
- Further details on the release can be found here: wordpress.org
WordPress 4.5.2 Security Release
May 9, 2016
4 point 5 point 2;
in cross site scripting
- Updates on our platform are finishing up today.
- Further details on the release can be found here: wordpress.org
May 9, 2016
tragedy; is currently
patched by policy.
- Further details: ImageTragick.com
May 3, 2016
High Severity Vuln?
We patched openssl,
so you don’t have to.
Security Haiku: CVE-2015-7547
Feb. 19, 2016
Host lookup dangers?
No worry, we already