WPCycle
Well-known member
- Joined
- Dec 31, 2016
- Messages
- 123
- Points
- 18
Hi Everyone. Passing along information for fellow WordPress users.
https://make.wordpress.org/core/2017/02/01/disclosure-of-additional-security-fix-in-wordpress-4-7-2/
WordPress 4.7.2 was released last Thursday, January 26th. If you have not already updated, please do so immediately.
In addition to the three security vulnerabilities mentioned in the original release post, WordPress 4.7 and 4.7.1 had one additional vulnerability for which disclosure was delayed. There was an Unauthenticated Privilege Escalation Vulnerability in a REST API Endpoint. Previous versions of WordPress, even with the REST API Plugin, were never vulnerable to this.
We believe transparency is in the public's best interest. It is our stance that security issues should always be disclosed. In this case, we intentionally delayed disclosing this issue by one week to ensure the safety of millions of additional WordPress sites.
On January 20th, Sucuri alerted us to a vulnerability discovered by one of their security researchers, Marc-Alexandre Montpas. The security team began assessing the issue and working on solutions. While a first iteration of a fix was created early on, the team felt that more testing was needed.
Meanwhile, Sucuri added rules to their Web Application Firewall (WAF) to block exploit attempts against their clients. This issue was found internally and no outside attempts were discovered by Sucuri.
Over the weekend, we reached out to several other companies with WAFs including SiteLock, Cloudflare, and Incapsula and worked with them to create a set of rules that could protect more users. By Monday, they had put rules in place and were regularly checking for exploit attempts in the wild.
On Monday, while we continued to test and refine the fix, our focus shifted to WordPress hosts. We contacted them privately with information on the vulnerability and ways to protect users. Hosts worked closely with the security team to implement protections and regularly checked for exploit attempts against their users.
By Wednesday afternoon, most of the hosts we worked with had protections in place. Data from all four WAFs and WordPress hosts showed no indication that the vulnerability had been exploited in the wild. As a result, we made the decision to delay disclosure of this particular issue to give time for automatic updates to run and ensure as many users as possible were protected before the issue was made public.
On Thursday, January 26, we released WordPress 4.7.2 to the world. The release went out over our autoupdate system and, over a couple of hours, millions of WordPress 4.7.x users were protected without knowing about the issue or taking any action at all.
We'd like to thank Sucuri for their responsible disclosure, as well as working with us to delay disclosure until we were confident that as many WordPress sites were updated to 4.7.2 as possible. We'd also like to thank the WAFs and hosts who worked closely with us to add additional protections and monitored their systems for attempts to use this exploit in the wild. As of today, to our knowledge, there have been no attempts to exploit this vulnerability in the wild.
https://make.wordpress.org/core/2017/02/01/disclosure-of-additional-security-fix-in-wordpress-4-7-2/
WordPress 4.7.2 was released last Thursday, January 26th. If you have not already updated, please do so immediately.
In addition to the three security vulnerabilities mentioned in the original release post, WordPress 4.7 and 4.7.1 had one additional vulnerability for which disclosure was delayed. There was an Unauthenticated Privilege Escalation Vulnerability in a REST API Endpoint. Previous versions of WordPress, even with the REST API Plugin, were never vulnerable to this.
We believe transparency is in the public's best interest. It is our stance that security issues should always be disclosed. In this case, we intentionally delayed disclosing this issue by one week to ensure the safety of millions of additional WordPress sites.
On January 20th, Sucuri alerted us to a vulnerability discovered by one of their security researchers, Marc-Alexandre Montpas. The security team began assessing the issue and working on solutions. While a first iteration of a fix was created early on, the team felt that more testing was needed.
Meanwhile, Sucuri added rules to their Web Application Firewall (WAF) to block exploit attempts against their clients. This issue was found internally and no outside attempts were discovered by Sucuri.
Over the weekend, we reached out to several other companies with WAFs including SiteLock, Cloudflare, and Incapsula and worked with them to create a set of rules that could protect more users. By Monday, they had put rules in place and were regularly checking for exploit attempts in the wild.
On Monday, while we continued to test and refine the fix, our focus shifted to WordPress hosts. We contacted them privately with information on the vulnerability and ways to protect users. Hosts worked closely with the security team to implement protections and regularly checked for exploit attempts against their users.
By Wednesday afternoon, most of the hosts we worked with had protections in place. Data from all four WAFs and WordPress hosts showed no indication that the vulnerability had been exploited in the wild. As a result, we made the decision to delay disclosure of this particular issue to give time for automatic updates to run and ensure as many users as possible were protected before the issue was made public.
On Thursday, January 26, we released WordPress 4.7.2 to the world. The release went out over our autoupdate system and, over a couple of hours, millions of WordPress 4.7.x users were protected without knowing about the issue or taking any action at all.
We'd like to thank Sucuri for their responsible disclosure, as well as working with us to delay disclosure until we were confident that as many WordPress sites were updated to 4.7.2 as possible. We'd also like to thank the WAFs and hosts who worked closely with us to add additional protections and monitored their systems for attempts to use this exploit in the wild. As of today, to our knowledge, there have been no attempts to exploit this vulnerability in the wild.
Out the box nginx rate limiting is also deployed on wp login and other common wordpress php attacked files too with optional connection limited at nginx level that end users can enable 
