WordPress Plugs Bug that Led to Google Indexing Some User Passwords (zdnet.com) 32
A week after releasing v5.0 major update, WordPress has pushed the first security patch for its popular CMS service. ZDNet: Released hours ago, WordPress version 5.0.1 fixes seven security vulnerabilities (some of which allow site takeover) but also plugs a pretty serious privacy leak. The latter was found by the authors of the popular Yoast SEO plugin, who discovered that in some cases the activation screen for new users could end up being indexed by Google. With specially crafted Google searches, an attacker could find these pages and collect users' email addresses, and in some rare cases, default-generated passwords. This leak could have catastrophic consequences if the user has an admin role or if the user didn't change his default password, as is regularly advised.
Re: (Score:3)
The end result is that WordPress makes building a website accessible to anyone – even people who aren’t developers.
Re: (Score:1)
Not very well or securely, apparently.
Re: (Score:2)
Neither. It's mostly momentum. The problem is, critical software like MySQL was written without security in mind, and had poor support for query construction, leading to everyone rolling their own functionality, 100% of which contained security bugs, give or take some very small epsilon.
By the time they finally sorted out the security abomination that
Re: (Score:2)
I've never used it, but I sure as hell block all of their domains at the browser level.
Hit a page, it's got dozens of references to one of the word press domains, and happily block them.
I don't trust WP as a visitor, because I've heard endless stories about how it infects users ... and I wouldn't trust it on the back end because I've heard endless stories about how it's insecure.
At this point I have to conclude that WP is a steaming pile of shit, and have no idea why it's still in use.
I pretty much assume web sites that my blockers link to word press are not a site I'd *ever* trust to set cookies, have a login, or receive any personally identifiable information -- because either the admins are incompetent, or the software is defective, or both.
All popular CMSs - and even many unpopular CMSs - have had security issues. The open source ones tend to get fixed super quickly.
Plenty of wonky toolkits, runtimes, etc. - used by oh so super smart devs on their (at a higher level) completely custom websites - have had security issues too.
WP did have a rather distressing frequency in its early years, but has got much better and has been for quite some time now.
Re: (Score:2)
In this case, WordPress 5.0 was only out for about a week before 5.0.1 was released, going by the dates I installed them.
Re: (Score:2)
All popular CMSs - and even many unpopular CMSs - have had security issues. The open source ones tend to get fixed super quickly.
One problem with WordPress is that it allows plugins from pretty much anyone.
So in that sense, it's not just a blog/CMS, it's a full-blown platform, and full-blown platforms are much more vulnerable than standalone pieces of software.
Re: (Score:3)
Re: (Score:2)
Fuck anything written in PHP - it's too much of a risk and there are too many idiots making mistakes (and non-idiots as well).
Thank goodness no one could ever write insecure code in Java, C++, Ruby, Python, ASP, Go, Rust, Haskell, Swift, Kotlin, JavaScript, C#, Elixir, Scala, Objective-C, TypeScript....
Re: (Score:2)
This is why WordPress is secure. (Score:2, Informative)
No joke.
WP is a messy blob of spaghetti code, albeit one with 160 million active installs. That means a bug like this that would go undetected for months on any other System comes up with a fix two days after its release. And that in turn makes for some pretty relyable security.
you're wrong, RTFA (Score:1)
MIME type verification is standard verification for almost any file upload system system these days.
We're talking 10+ years it took for those 160 zealots to even realize that MIME types were a thing and they can be used to spoof file uploads (and yes you can spoof MIME type afaik but that's not the point)
The other vuln was in a 3rd party plugin, totally unrelated to Wordpress core. The 3rd party even admits in the article *they* found it, not the 160 million zealots you describe above.
Yep. Wordpress. Totall
Sorta offtopic but... (Score:2, Offtopic)
I misread the title as "WordPress Plugs Butt" - chuckled to myself when realized my brain made a mistake and thought I'd share.
Use protection, kids! (Score:4, Interesting)
"With specially crafted Google searches, an attacker could find these pages and collect users' email addresses, and in some rare cases, default-generated passwords."
Another fabulous win for WordPress. (sigh)
Seriously, if you run WordPress, at least install the WordFence plugin. It's free and prevents a lot of malicious behavior from occurring. I don't know about this specific exploit, but it has stopped a ton of bot-style attacks on the few WP sites I have some responsibility for.
Install WordFence and look at the logs after a day or two- you'll be astounded (and horrified) at the level of malicious activity it catches and stops.
(And in case you're wondering, no, I have no connection or financial interest whatsoever in WordFence, I'm just a fan).
Barebones CMS is better in every way (Score:1)
Barebones CMS is secure in ways that WordPress will never be, it's out-of-the-box performance blows away WordPress no matter how you might configure WordPress, Barebones consumes far fewer system resources than WordPress (100KB instead of 64MB RAM per user), and supplies everything you could ever need in terms of content authoring and content management. Barebones CMS is also a fraction of the size of WordPress, Joomla!, and Drupal and offers a sane open source license (your choice of MIT or LGPL).
WordPres
Never store passwords (Score:3)
This just seems like novice mistakes. Passwords should NEVER be stored. There is never a need to store a password at any time. If it's not stored then there is minimal chance of exposing the password. I think the newbies to programming don't know this, and they think that they have to compare the password typed in to a stored password, which is wrong. The first step is to make a secure hash of the password, and the second step is to clear the password from memory. Of course that's not all you need to do, but if you don't use those two steps then it means the implementer doesn't understand security. If a password is ever in a database then someone has screwed up.