oday we are releasing three different posters related to WPScan and WordPress security. Hopefully you find them useful enough and beautiful enough to hang on your wall.
rs related to WPScan and WordPress security. Hopefully you find them useful enough and beautiful enough to hang on your wall.
day we are releasing three different posters related to WPScan and WordPress security. Hopefully you find them useful enough and beautiful enough to hang on your wall.
Yesterday, October 14th 2019, WordPress released version 5.2.4 as a security release. According to WordPress, WordPress version 5.2.4 fixes 6 security issues.
- WordPress <= 5.2.3 – Stored XSS in Customizer
- WordPress <= 5.2.3 – Unauthenticated View Private/Draft Posts
- WordPress <= 5.2.3 – Stored XSS in Style Tags
- WordPress <= 5.2.3 – JSON Request Cache Poisoning
- WordPress <= 5.2.3 – Server-Side Request Forgery (SSRF) in URL Validation
- WordPress <= 5.2.3 – Admin Referrer Validation
WPScan started as a simple Ruby script in 2011 to help identify vulnerabilities in self-hosted WordPress websites. The simple script matured into a large software project and gained popularity amongst the security and WordPress communities.
For many years we did not think of WPScan as a business, but since last year we decided that to make WPScan self sustainable it needed to generate income to be able to pay for all the things it needs to maintain itself and to grow.
Password brute forcing is a common attack that hackers have used in the past against WordPress sites at scale. In 2017 Wordfence documented a huge password brute force attack, which saw 14.1 million attacks per hour at its peak.
Attackers are looking for users, preferably administrators, with weak passwords to be able to login to WordPress and compromise the site. Depending on the compromised user role, once logged in, the attacker could escalate privileges by attacking other users, embed malicious code into the site or compromise the entire server.
Well, in fact, there is just one change, but it’s a big one. Recently we released some big changes to WPVulnDB, which we recently blogged about. Now, we want to tell you about a big change that we are going to be making to the WPScan CLI tool in version 3.7.0, which will be released sometime within the next few weeks.
The Google Chrome web browser plans to set the SameSite attribute on all cookies by default in Chrome version 80. Google Chrome by far controls the largest share of the web browser market. Their changes have a significant impact on the Web. It wouldn’t be surprising if other major web browsers also followed their lead, implementing the SameSite cookie attribute by default too. How is this change going to affect the Web and WordPress security in particular?
Recently we have been working on some big improvements to WPVulnDB, which you will see being released over the next few weeks. Below is a list of the improvements which will impact users the most.
We released APIv3, the successor to APIv2, on March 20th 2018. The new APIv3 requires users to register a free account on wpvulndb.com and use an API Token to access our API. With the old APIv2, no user registration or API Tokens were required. Requiring API Tokens meant that we could easily identify heavy usage of our API by a particular user, which may have affected other API users, and more easily prevent abuse.