This is a group of questions and answers to help explain SA-CORE-2017-002 which has CVE CVE-2017-6919.
Q: Can you explain the risks associated with this vulnerability, and what an attack would look like?
As the advisory description explains, if a site has the REST module enabled and is configured to accept PATCH requests, it may be vulnerable to letting the attacker take more actions than they generally should. The site is more likely to be vulnerable if an attacker can create or get access to a user account. There are some other, less common exploit vectors that require a site to have weak permissions allowing an anonymous user to perform actions typically reserved for authenticated users. We follow a process of coordinated disclosure and security releases that include only the security-related changes, so the best solution for nearly all sites is to quickly update to the version that fixes the issue. In this case, update to Drupal 8.3.1 or 8.2.8.
In general, we also recommend that sites follow best practices for securing access. User registration should be disabled if it is not important to a site, and anonymous or untrusted users should be given only the minimum permissions that are appropriate for the site's needs. Sites should also make it more difficult for an attacker to otherwise gain access to a more privileged account. For example, sites can reduce the risk of an account compromise by requiring strong passwords, two-factor authentication, HTTPS, etc.
If the PATCH request type is not important to a site they could also mitigate this particular vulnerability by disabling it. A big caveat for this information is that Drupal's APIs can be used to build a lot of things, and we don't know for sure how all sites use Drupal. The vulnerability that we know about and that affects the most sites is what we have described here, but sites that make extensive use of the RESTful Web Services module in Drupal core should update to the latest release as there could be other vulnerabilities without the release.
Q: What was the timeline for this vulnerability?
The security team was advised of this issue on March 18th by Samuel Mortensen, a Senior Engineer at Acquia. The next security release window was April 19th and the patch was included there.
Q: Why was 8.2.x patched even though it has reached end-of-life?
This issue ranked as critical on our risk calculator and we released Drupal 8.3.0 on a calendar schedule just 2 weeks ago.
All Drupal 8 releases are made on a release schedule, because predictability is very important for site owners. In this schedule, a new minor release (like 8.3.0) comes out every six months. Only the current minor release is supported at any time. Minor releases are backwards-compatible overall, but can include some disruptive changes in internal APIs and experimental modules that require updates to contributed and custom modules and themes (per Drupal core's backwards compatibility and experimental module policies). Those updates to contributed and custom modules and themes might not be available immediately, so we have a minimum "grace period" of 1 month between the release of a new minor version and public disclosure of security issues that affect the old minor version. In the case of this issue, however, we wanted to make the fix available as soon as possible in our April security window. Releasing 8.3.1 with the fix disclosed the issue inside of that 1-month grace period, so we also included a fix for the old minor version.
It's important to keep in mind that only the current minor release of Drupal receives bugfix or security support. Drupal sites should always update to the latest available release to ensure they continue to receive security fixes. So, while Drupal 8.2.8 is available to ensure that sites can update safely, these sites still need to update to Drupal 8.3.1 when ready to receive future security support.
Q: Sites that use Drupal 8.2 can update and yet still see a notification that their site is not secure - why?
Since 8.2 is no longer supported, they must update to 8.3. While 8.2.8 includes the fix for this particular security issue, no further releases will be provided for 8.2. 8.3.0 already included many non-security fixes that are not available in 8.2.8, and future security fixes will also only be made to 8.3.
Q: Does this vulnerability affect Drupal core 8.1 or 8.0?
Yes! Drupal core 8.1 reached its end-of-life more than six months ago, and 8.0 has been past its end-of-life for a year. There are other disclosed security vulnerabilities that also affect 8.0 and 8.1, so anyone who has a site based on these should update as soon as they can.
Q: The REST code in Drupal 8 is based on some of the Drupal 7 modules. Does this affect any of the contributed modules for Drupal 7?
We have done some tests and believe it does not affect the similar Drupal 7 contributed stable modules that are hosted on Drupal.org. As always, anyone who finds a vulnerability in Drupal code should follow the process to report a security issue.
This document may be updated over time to clarify answers or add content.