3 ms·

> On May 5, a month after a patched version of the plugins was released by Delicious Brains, Patchstack published details of the flaw. It's recommended users up

> On May 5, a month after a patched version of the plugins was released by Delicious Brains, Patchstack published details of the flaw. It's recommended users update their plugin to at least version 6.1.6. Emphasis mine. It is not actually that hard to run Wordpress securely. Stick to supported plugins and themes, and install security patches quickly when they are released. The vast, vast majority of WP attacks are based on known vulnerabilities, and only start after the details are disclosed. The bad guys who bother targeting WP are generally lazy and unsophisticated. Obviously if you know you are a high value target, you may want to stand up additional defenses.

SllX 3y ago
Thanks. For a moment I thought this was 2007.
safety1st 3y ago
To add to this advice, you can enable auto-updates for any WordPress plugin with one click. Anyone who enabled auto-updating for ACF would not be affected by this vulnerability. If a site is not mission critical or you don't have the time/budget to maintain it, just enable auto-update on everything. This will protect you from the vast majority of vulnerabilities. There is a very small chance an auto update may break something on the site. If a site is mission critical, every 1-3 months you should take a backup, update manually, and do some testing to verify that nothing broke. It's not rocket science and not particularly difficult or expensive. There is a proposal to make auto-updating the default. But because WordPress has to support everything from millions of personal blogs to whitehouse.gov, a proposal like that is a complicated topic. Notably whitehouse.gov has never been hacked.
- e12e 3y ago
  > Anyone who enabled auto-updating for ACF would not be affected by this vulnerability. Pedantic, but you would have been vulnerable if someone else also found the hole, but kept it secret? Sure, when an exploit makes into metasploit or gets published things are worse if you don't patch - but just because the barn door is closed now with a patch, it doesn't mean you were secure when there was a big hole in the door...
  - lesuorac 3y ago
    Of course, in another completely different scenario that different scenario may play out differently.
    - e12e 3y ago
      I don't understand - there was a hole for X months, it was found (once) and responsibly disclosed. Everyone was vulnerable for those X months. We don't know if anyone else found that hole in those X months? Your vulnerable WordPress install wasn't "secure" for those X months, it just wasn't wide open to script kiddies? So making WordPress "secure" isn't "just install updates as they come out". That's just "don't be criminally negligent".
      - snowwrestler 3y ago
        You’re right, but the thing you’re right about is true for all software, not just Wordpress. Every piece of software out there has exploitable bugs sitting in the code just waiting to be found. Software is, fundamentally and essentially, insecure in that it is built by humans who make mistakes. A static HTML site does not protect against this since it’s still being served by a flawed software stack. Nginx has undiscovered bugs; Linux has undiscovered bugs. For sure. But from a practical perspective, anyone running a site just wants to keep the bad guys out today, by resisting the intrusion attempts they directly experience. And for the vast majority of Wordpress sites, that is achievable with correct file and directory permissions, strong passwords, and prompt patching.
throw0101b 3y ago
> It is not actually that hard to run Wordpress securely. Stick to supported plugins and themes, and install security patches quickly when they are released. Depending on your site's functionality, it may also be possible to run a static WP site: * https://wordpress.org/plugins/simply-static/ https://wordpress.org/plugins/simply-static/ * https://wp2static.com https://wp2static.com You do all your regular updates via the CMS, but, instead of putting the dynamic site on the public Internet, you generate static files and point your public web server's HTML rootdir at those.
- snowwrestler 3y ago
  Good example of an additional defense that’s possible. But it’s significantly more complicated to set up, and can run into issues with large sites that are updated frequently.

SllX 3y ago

Thanks. For a moment I thought this was 2007.

safety1st 3y ago

To add to this advice, you can enable auto-updates for any WordPress plugin with one click. Anyone who enabled auto-updating for ACF would not be affected by this vulnerability. If a site is not mission critical or you don't have the time/budget to maintain it, just enable auto-update on everything. This will protect you from the vast majority of vulnerabilities. There is a very small chance an auto update may break something on the site. If a site is mission critical, every 1-3 months you should take a backup, update manually, and do some testing to verify that nothing broke. It's not rocket science and not particularly difficult or expensive. There is a proposal to make auto-updating the default. But because WordPress has to support everything from millions of personal blogs to whitehouse.gov, a proposal like that is a complicated topic. Notably whitehouse.gov has never been hacked.

e12e 3y ago
> Anyone who enabled auto-updating for ACF would not be affected by this vulnerability. Pedantic, but you would have been vulnerable if someone else also found the hole, but kept it secret? Sure, when an exploit makes into metasploit or gets published things are worse if you don't patch - but just because the barn door is closed now with a patch, it doesn't mean you were secure when there was a big hole in the door...
- lesuorac 3y ago
  Of course, in another completely different scenario that different scenario may play out differently.
  - e12e 3y ago
    I don't understand - there was a hole for X months, it was found (once) and responsibly disclosed. Everyone was vulnerable for those X months. We don't know if anyone else found that hole in those X months? Your vulnerable WordPress install wasn't "secure" for those X months, it just wasn't wide open to script kiddies? So making WordPress "secure" isn't "just install updates as they come out". That's just "don't be criminally negligent".
    - snowwrestler 3y ago
      You’re right, but the thing you’re right about is true for all software, not just Wordpress. Every piece of software out there has exploitable bugs sitting in the code just waiting to be found. Software is, fundamentally and essentially, insecure in that it is built by humans who make mistakes. A static HTML site does not protect against this since it’s still being served by a flawed software stack. Nginx has undiscovered bugs; Linux has undiscovered bugs. For sure. But from a practical perspective, anyone running a site just wants to keep the bad guys out today, by resisting the intrusion attempts they directly experience. And for the vast majority of Wordpress sites, that is achievable with correct file and directory permissions, strong passwords, and prompt patching.

throw0101b 3y ago

> It is not actually that hard to run Wordpress securely. Stick to supported plugins and themes, and install security patches quickly when they are released. Depending on your site's functionality, it may also be possible to run a static WP site: * https://wordpress.org/plugins/simply-static/ https://wordpress.org/plugins/simply-static/ * https://wp2static.com https://wp2static.com You do all your regular updates via the CMS, but, instead of putting the dynamic site on the public Internet, you generate static files and point your public web server's HTML rootdir at those.

snowwrestler 3y ago
Good example of an additional defense that’s possible. But it’s significantly more complicated to set up, and can run into issues with large sites that are updated frequently.