Well with hacker summer camp now over the research presented can now start to sink in and be digested. Two things stood out to me with my background in supporting websites and content management systems (CMS), those were vulnerabilities that affect the WordPress and Drupal CMS. These are ones to be aware of they look likely to be able to cause some major pain if not mitigated.
Drupal: TLDR How much should I worry? I would go 7/10 Patch available, get it applied.
The team behind Burpsuite(Portswigger), the web application scanner and web app penetration testing suite, revealed some research around web cache poisoning. Specific to Drupal is the ability to poison the built in cache for Drupal, which can allow the attacker to redirect users who are trying to navigate to content. This can have implications around, redirecting for malicious advertising, to phishing sites, or even redirecting the admin login page to steal the administrative credentials. Drupal has patched this in early August, and have the Drupal security details here:
Drupal Core – 3rd-party libraries -SA-CORE-2018-005
The vulnerability is record as CVE-2018-14773
And the original research can be found here:
https://portswigger.net/blog/practical-web-cache-poisoning
(you’ll need to navigate around 75% down the page to get to the Drupal info and the video showing the exploit in action to redirect an admin page)
WordPress: TLDR How much should I worry. Again 7/10, no patch, restrict authors and file uploads. Block xmlrpc.
This research was presented by Sam Thomas of Secarma Labs. It was around php deserialization looking specifically into ways to exploit using the phar file format for php executables. In this case an attacker who has the ability to upload a file to the site can craft the upload specific to allow this exploit to take place by then being able to trigger it by issuing crafted requests to the XMLRPC feature of WordPress. WordPress was notified by the researchers back in February, but no patch exists at this time. Looking at the research paper you can review yourself here:
It looks like on successful exploit results in code execution.
Key things here are, you likely need to be an author level user on the site to exploit, so keep a close eye on those accounts. And as I recommend block access to the XMLRPC file if you can to also help mitigate this kind of issue, you can find my WordPress hardening guide here: