On the RIPSTech.com site they've posted a warning to the WordPress users out there about a vulnerability that would allow a malicious user to delete any file in the WordPress installation, not just file uploads.

At the time of writing no patch preventing this vulnerability is available. Any WordPress version, including the current 4.9.6 version, is susceptible to the vulnerability described in this blogpost.

For exploiting the vulnerability discussed in the following an attacker would need to gain the privileges to edit and delete media files beforehand. Thus, the vulnerability can be used to escalate privileges attained through the takeover of an account with a role as low as Author, or through the exploitation of another vulnerability/misconfiguration.

The post includes more details around the impact of the issue and where in the code the problem lies. It also offers a temporary "hotfix" as a way around the issue by adding a new filter that uses the basename function to reset the thumbnail data.

The Drupal project has announced a critical security vulnerability in the currently supported versions of the popular CMS: Drupal 7 and 8 (as well as v6). The announcement on the main Drupal site details the issues and provides a link to an FAQ with more detail about the issue.

A remote code execution vulnerability exists within multiple subsystems of Drupal 7.x and 8.x. This potentially allows attackers to exploit multiple attack vectors on a Drupal site, which could result in the site being completely compromised.

[...] Drupal 8, 7, and 6 sites are affected. According to the Drupal project usage information this represents over one million sites or about 9% of sites that are running a known CMS according to Builtwith.

The issue could allow an attacker to take full control of the application and execute whatever code they'd want to on the server. They recommend upgrading immediately to safeguard your Drupal application. They also provide links to a guide on what to do if you are hacked and to the Drupal 6 patch (as well as steps you can take if you can't upgrade).

On the DotDev.co site Eric Barnes has written up a post talking about a recently announced vulnerability (and 0-day exploit) for WordPress allowing for password reset emails to be delivered to a user-specified address instead of the correct one on the account:

On the Exploitbox site Dawid Golunski shares a 0 day vulnerability in the WordPress core affecting all versions:

The vulnerability stems from WordPress using untrusted data by default when creating a password reset e-mail that is supposed to be delivered only to the e-mail associated with the owner’s account.

The post includes a snippet of code from the WordPress core where the issue lies, relying on the value from PHP's $_SERVER['SERVER_NAME'] variable for the domain in the address the reset email is sent to. Unfortunately this value is pulled from the Host header in the request and is user-controllable. There's a solution offered using an Apache setting and it's noted that this exploit only seems to work against the default VirtualHost as it will act as a fallback if the Host does not reference a configured domain.

Recently a major security vulnerability was announced centering around the the HTTP "Proxy" header and how incorrect handling could result in major issues with external requests. In the PHP ecosystem, a major HTTP library - Guzzle - was vulnerable (along with any application using it). However, according to Michael Dowling, a lead developer on the project, a new release has already been made to correct the problem.

httpoxy is a set of vulnerabilities that affect application code running in CGI, or CGI-like environments. It comes down to a simple namespace conflict [between the "Proxy" and "HTTP_Proxy" headers]. This leads to a remotely exploitable vulnerability. If you’re running PHP or CGI, you should block the Proxy header now. Here’s how.

The main HTTPoxy site as more information about how you can test to see if your application is vulnerable and what software/server configurations are typically vulnerable. There's also more language-specific information on the page as well as some immediate mitigations for various web server types.

The Paragon Initiative site has a new tutorial posted aiming to help you more securely use the serialize and unserialize handling in PHP to prevent security issues. In this tutorial they offer some advice - mainly don't unserialize unless you're on PHP7 - and some other solutions you could use.

A frequent problem that developers encounter when building web applications in PHP is, "How should I represent this data structure as a string?" Two common examples include:

• Caching a complex data structure (to reduce database load)
• Communicating API requests and responses between HTTP-aware applications

This seems like the sort of problem that you could expect would have pre-existing, straightforward solutions built into every major programming language that aren't accompanied by significant security risk. Sadly, this isn't the case.

He starts with a look at the serialization handling and how it could allow remote code execution if an attacker were to modify the serialized data. He includes an example of using the new "allowed classes" parameter in PHP 7 too, though, preventing the issue. He also walks through two other ways you could replace serialized data: JSON structure and XML handling. Each of these have their own issues too but they're very different than the code execution with serialization.

The Check Point blog has posted the first part of a series from one of their vulnerability researchers about finding security vulnerabilities in the core WordPress code (and some of the results along with CVE numbers).

In this series of blog posts, Check Point vulnerability researcher Netanel Rubin tells a story in three acts – describing his long path of discovered flaws and vulnerabilities in core WordPress, leading him from a read-only ‘Subscriber’ user, through creating, editing and deleting posts, and all the way to performing SQL injection and persistent XSS attacks on 20% of the popular web.

In this first part he focuses on the concept of "identity" in a WordPress application. He focused on the "roles and capabilities" functionality to find bypass methods in operations like editing and adding new posts. As he works through his process, code is included from the WordPress core showing where the issue(s) lie and what would be needed to exploit the issue.

The Paragon Initiative has posted a new tutorial that wants to provide you with everything you need to know about preventing cross-site scripting in PHP applications.

Cross-Site Scripting (abbreviated as XSS) is a class of security vulnerability whereby an attacker manages to use a website to deliver a potentially malicious JavaScript payload to an end user. XSS vulnerabilities are very common in web applications. They're a special case of code injection attack; except where SQL injection, local/remote file inclusion, and OS command injection target the server, XSS exclusively targets the users of a website.

[...] Cross-Site Scripting represents an asymmetric in the security landscape. They're incredibly easy for attackers to exploit, but XSS mitigation can become a rabbit hole of complexity depending on your project's requirements.

He introduces the concept of cross-site scripting (XSS) for those new to the term and provides a brief "mitigation guide" for those wanting to jump to the end. He then gets into some examples of what a XSS vulnerability could look like, both stored and reflected and provides the "quick and dirty" method for preventing them. He also mentions some tips in implementing your solution including avoiding HTML in your data if at all possible. He goes on to talk about the use of HTMLPurifier to prevent attacks, context-sensitive escaping (HTML vs JS vs CSS) and some of the browser-level features that help prevent XSS for the user.

Pádraic Brady has a new post to his site talking about the recently announced (but actually relatively old) issue with PHP hash comparison, the "magic hash" issues.

A while back, I noticed a flurry of activity around a somewhat obvious outcome of PHP’s type juggling antics. As the snowball gathered pace and grew, it’s being more widely reported as a vulnerability dubbed “Magic Hashes”. What is this mysterious potential vulnerability in PHP applications? The vulnerability is a straightforward outcome of PHP’s type juggling antics.

He talks about the == (double equals) versus === (triple equals), how they differ and how the use of the triple equals basically negates this issue. The problem comes back around to PHP's type juggling and how it assumes equality based on the data given. He includes some specific examples showing places the issue can happen even when comparing two variables of the same type. He also makes a mention of another issue that can come in separate from this called timing attacks and how to prevent them as well.

Anthony Ferrara has a new post to his site sharing the results of some PHP version statistics he's gathered and how it relates back to the security of applications.

After yesterday's post, I decided to do some math to see how many PHP installs had at least 1 known security vulnerability. So I went to grab statistics from W3Techs, and correlated that with known Linux Distribution supported numbers. I then whipped up a spreadsheet and got some interesting numbers out of it. So interesting, that I need to share...

He starts with the versions that currently have no known security issues and matches those up with the linux releases that currently include them. He then looks at the adoption rates for more recent versions and maps those against the security status as well...with some "grim results". He summarizes the totals of all of the version results and comes up with an interesting statistic: over 78 percent of PHP installations (and thus applications) are vulnerable to some kind of security vulnerabilities just because of what they're hosted on.

In his most recent post Anthony Ferrara gives a lesson in security prompted by the recent major issue with a SQL injection vulnerability in Drupal. He gets into detail about the vulnerability itself and the ultimate question: "how could this happen?"

Recently, a severe SQL Injection vulnerability was found in Drupal 7. It was fixed immediately (and correctly), but there was a problem. Attackers made automated scripts to attack unpatched sites. Within hours of the release of the vulnerability fix, sites were being compromised. And when I say compromised, I'm talking remote code execution, backdoors, the lot. Why? Like any attack, it's a chain of issues, that independently aren't as bad, but add up to bad news. Let's talk about them: What went wrong? What went right? And what could have happened better? There's a lesson that every developer needs to learn in here.

He details (complete with code examples) where the vulnerability was, how it could be exploited and what the resulting SQL would look like when it was abused. Fortunately, the fix for the issue was relatively simple, but fixing is easy - distributing that fix is much more difficult.

How did this happen? Everyone makes mistakes. Everyone. It's going to happen sooner or later. Heck, this vulnerable code was in the database layer since 2008, and was just discovered two weeks ago. That says something about how complex vulnerabilities can be.

He suggests that the bigger lesson here isn't about who made the mistake or even the code that caused it. It's more about how it was handled, and that, in using any kind of CMS/framework like this there's always risk. People are human, people make mistakes - "the key is how you deal with it".