29 Comments


  1. I realize people do a lot of custom stuff with WordPress, but it’s been a long time since I had an upgrade not go smoothly and it’s been a decent while since an upgrade broke a critical plugin as well.

    I don’t know if somehow the web just has a long memory of back when those things happened frequently or I’m just not the typical WP user but I have plenty of sites and it’s not a big deal to keep them updated.

    Annoying? Yes. But not that big of a deal. For someone like Scoble to call out WordPress despite the fact that he wasn’t uptodate is just irresponsible (although unfortunately also quite typical of the drivel that’s spewed by him on a regular basis).

    Now, I don’t think Matt handled it all that well getting pissed at rackspace but the point remains, if you keep things updated, you avoid a large percentage of the issues that hit WordPress users.

    I don’t mean to drone on, but I think it’s time for Automattic to invest in WordPress security more heavily. I understand it’s open source and always going to be under attack, but hiring someone with a devious mind to try and break things would seem like a great investment and would go a long way to assuring worried users that WP will remain safe and stable.


  2. If you aren’t capable of keeping your blog software up to date, for whatever reason, then you shouldn’t be running your own blog. Use WordPress.com instead.


  3. This post overlooks a couple of things.
    Firstly, the reports of sites being hacked is not restricted to just that one exploit. In the past few weeks users have reported various exploits, from the rather common iframe hack to injections of code into the footers of WordPress 2.8.4 sites.

    Secondly, there really are good reasons for some people to not upgrade. Those reasons include clients who don’t want their sites worked on every few weeks, to clients who cannot use later versions of WordPress. Accessibility issues in WP 2.7+ mean some people just can’t use later versions. Other sites use custom plugins that cost them a lot of time and money to develop.

    Look at the release cycle:

    June 11 – 2.8 released
    July 9 – 2.8.1 fixes security issues
    July 20 – 2.8.2 fixes an XSS vulnerability
    Aug 3 – 2.8.3 security release
    Aug 12 – 2.8.4 security release

    This is just too fast for any site that is running custom code that has to be tested and may need to be updated. WordPress doesn’t release information on which few lines need changing. They don’t release patch files of only the necessary security changes. With WordPress, its a full upgrade or nothing (or countless hours running diffs through uncommented code to try to find the security patches). It doesn’t take much to post the lines for users to change. WordPress also includes changed/new functionality with most updates, making it even harder for anyone who just wants to apply a security fix.

    The frequency of releases indicates a branch that has not yet stabilised. When its a continual “patch the patch” going on users cannot be blamed for waiting until their plugins are updated & reports of bugs have settled. Every release of WordPress says its more secure, every time multiple blogs are hacked users are told to upgrade – then that release is hacked. It happens. The sad thing about this latest round of attacks is that WordPress developers have started a blame game. The only ones to blame here are the hackers.


  4. @Elpie – There shouldn’t be a reason to need to modify your core files, so what does it matter what files changed?

    And your comment is wrong as well. WordPress is developed using SVN, so it’s incredibly easy to track changes. For example, here is every single change between v2.8.3 and v2.8.4: http://v007.me/wp284diff


  5. Maybe the core WordPress developers should add an entire nag page, which is displayed when an administrator logs in and there WordPress version is out of date. The page could have a huge update button followed by a list of vulnerabilities in the current version their running.

    WordPress should also assure people that their site isn’t going to break when they upgrade. We (developers) could create scripts that check plugins and themes for functions that would cause problems. We could introduce site cloners, so people could test out their actual site before updating the real thing. We could state some facts from the plugin repository, such as all your plugins work in the current version of WordPress. I think the WordPress backend could do a better job of forcing people to do the smart thing and upgrade, as well as informing them about problems that will or will not happen when they upgrade. I think even a “more info” link in the update nag would help people over come their fear of updating. I don’t see why administrators aren’t getting more information about the functionality and compatibility of the software and extensions they are using in the backend. Take for instance Linux, I think there is a reason it tells be about compatibility issues before I install or update… it creates informed decisions, that create fewer problems.


  6. @Elpie – as Viper said, if you can’t update WordPress on a regular basis (for any of the reasons you mentioned) you shouldn’t be using it. It’s that simple.

    People use it for the simplicity, the wide array of plugins, and the huge community that offers support, but all those benefits have a cost as well.

    In much the same way, editing core files should only be done with the realization that it’s going to cost you in the long run when it comes time to update it. It might save you time at the beginning but you’ll have to pay the piper at some point.

    As I said, I think it’s time for Automattic and WP to take security to a professional level and the recent release cycle has been ridiculous but there’s just no excuse for not updating, especially when the most recent release is nearly a month old.


  7. @Elpie – I’ll buy your argument of not upgrading because of accessibility issues but not for anything else.

    Clients who do not want their sites worked on every few weeks obviously don’t understand the nature of the web or web based software. Better education up front would solve this problem.

    Sites that use custom plugins or code really should have taken it upon themselves to check with the developer to make sure it was coded in such a way to not interfere with the core of WordPress or provide deep integration without an easy way to upgrade the parent software. Again, this is what I consider to be a short sighted stance of using WordPress. Make a decision today, it haunts you tomorrow.

    I see nothing wrong with that release cycle. It tells me that the folks behind WordPress are true to their ‘Word’ in that when their is a security issue that has been addressed, it will be pushed out asap for us to take advantage of. Let’s flip the coin here and say that 2.8.4, 2.8.3, and 2.8.2, were not released because of the fear of too many releases in too short of time. Meanwhile, a security bulletin goes out to the public saying their is a major vulnerability in the software along with a proof of concept of the code. Now all the hackers get to exploit all the blogs they like. I prefer the former versus the latter.

    As for a list of the files revised, generally, a page is created on the Codex for that specific version of WordPress. For example, WordPress 2.8.3 http://codex.wordpress.org/Version_2.8.3 however, you usually have to go to the WordPress Trac to download the changed files for the version changeset. I suppose it would be nice to have that information upfront as part of the release post.

    The only patch the patch that occurred was I believe 2.8.3 which missed some things in 2.8.1. That was a blunder. The other things addressed separate issues.

    If it weren’t for the damn hackers and worms, we wouldn’t have to worry about all of this lol.


  8. @Viper007Bond – Hobbyists or people with too much time on their hands may follow every change in SVN but anyone trying to keep track of development needs to follow trac, the developers blog, the dev site on wordpress.com, and the hackers mailing list. That might work for people like you and me, but it doesn’t work for most users.

    I think its arrogant of any of us to say why people use WordPress or how they use it. Most of those who are interested in following/contributing to WordPress development only ever hear back from a teeny percentage of users. Fact is, people use it for all kinds of reasons, including the fact that its open source code that can be modified however they want. People do hack the core code – whether they should or not is moot.

    WordPress updates aren’t updates – they are full installs that just happen to be able to be applied to an existing site. If the database isn’t changed then its only files. Security releases usually only change a file or two so why can’t these be distributed as patches for existing installs? If one line is changed, why can’t the codex show this? It’s a lot easier for anyone who can’t run the update as they can then manually change the line(s) and be assured that their core code is as secure as possible given current knowledge of vulnerabilities.

    But, hey, let’s get off this “Elpie – you…” thing eh? My comments were based on feedback I get and from interaction I have with others running WordPress sites. None of which apply to me or my own sites. I do manage sites for others that cannot upgrade (for one or more of the reasons I gave) and each of those is as secure as possible. Each also had a line or two of core code changed to match the security fixes plus the addition of the current_user_can check to all applicable admin files. (This is actually one example of why core files get hacked too, because the core could be more secure but current_user_can() is only used in a few files atm).

    IMO, this latest round of attacks is an opportunity to look at what works and what doesn’t work for WordPress users. Shame if the blame game gets any worse.


  9. @Elpie – We’re not saying who can or can’t use WordPress, we’re simply saying that those people who don’t update shouldn’t be blaming WordPress, they should be blaming themselves.

    Most releases aren’t just one or two lines of code. The security portions maybe, but often times they fix other bugs, and make a few other tweaks while they’re at it. The upgrade process is just a matter of a few clicks as long as you’ve done your job right ahead of time. Complaining about that strikes me as lazy.

    This bitching about WordPress’ security when a secure release has been out for nearly a month is ridiclous. If you install a home security system but don’t arm it or lock your door, there’s not much anyone can do.

    If you manage sites that can’t upgrade, then you’re putting those sites at risk by using WordPress, plain and simple. Of course, the same would be true of any open source CMS. So in reality, the problem is with you and those sites, not the CMS.

    If you or your clients or anyone else is going to use WordPress but not upgrade for any reason, they’ll probably have to deal with being hacked.


  10. You do all realise that regardless of who is right or wrong the pain of running a site on WP may push people away?

    I think support of two versions back would be a good thing… keep 2.6 supported, and 2.7 supported, for example, and there’d be a lot less complaining going on.


  11. There are perfectly good reasons for not upgrading, or at least for being scared of upgrading. The typical WordPress installation should be fine. If a plugin doesn’t work after an upgrade, then it probably wasn’t a very good plugin anyway and so you shouldn’t be using it.

    I’ve had serious problems upgrading because of integrations between WordPress and other software. If it’s just a WordPress install, then that’s fine, there isn’t really anything to be worried about, just hit the “upgrade” button and be done with it. But for seriously customised setups you need to be darn careful as a small change in WP can break the software it’s interacting with.

    I have a rather scary upgrade to do either this evening or tomorrow and I’m NOT looking forward to it.


  12. I like Elpie’s comment about the security patches.

    If security patches were separate from functional upgrades, then people could have their blog *automatically* apply those. Yes, some security updates affect functionality, but for the most part they don’t.

    The only part I don’t like about this suggestion is that it would keep people on older versions of wordpress longer. But I guess that’s not the end of the world.


  13. @Ryan – seriously scary? That suggests you’re stressed about it. In other words, WP is causing you stress. Which means, perhaps, it’s not the right tool?

    Heaven knows, coding for the web, with all its weaknesses and attacks, is hard enough already. We can do without more hassle in our lives.


  14. Perhaps as a community we could do like an “upgrade barn raising” where the more tech savvy folks (the audience of WP Tavern) could volunteer a little bit of time every day to help get folks set up correctly on the latest version, like install4free used to work for installations.

  15. Dave Doyle

    I get that the WordPress crew likes you to upgrade ASAP.

    BUT…

    I just spent the last 4 months skinning, tweaking, writing plugins for and modifying WordPress for a corporate blog. When I started, 2.8 hadn’t come out. When I deploy, it has to go through two other teams before it hits the live webserver. It’s tested, prodded, punched, poked by at least a dozen people. I simply can’t “upgrade” on a whim. It has to go into our version control. It has to go thorugh all these people. WordPress 2.8 came out early June. But from July 9 to Aug 12, FOUR minor point releases came out. FOUR. I can’t push those through at all in that timespan.

    I recognize that that’s a pain in the butt. I recognize that it’s stupid to have to do thigns this way. I don’t want to. However, it is a corporate reality for a lot of us.

    Why is there no maintenance at all for previous releases? I can’t expect it, I get that. But to drop support for a version of the software so quickly… seems crazy to me.

    There are some changes from 2.7 to 2.8. None so huge that it won’t require but a little work. It looks like there are bigger changes that will affect me from 2.8 to 2.9. I can’t just roll out as soon as they come out.

    I would beg the WordPress team and Matt to consider backporting some of the security fixes. I would beg you to issue a patches, not a full upgrade. Tell us when the DB is changing and when it is not. Make it EASIER for us.

    The release schedule that has been set since the 2.0 release means a new major point version every 3 to 4 months and having old releases completely unsupported, I can’t help but think I’ll fight harder to not use WordPress in future at work.


  16. @Matt:

    Perhaps as a community ( WordPress community ) we could do a bit more than that.

    You probably have the stats needed to find a working strategy to sequre WordPress installs. The important question is what stops people from upgrading, and what may be done to make people upgrade. We do know that plugin compability and borked upgrades are one factor making people hesitate to upgrade, but what are the other factors and how is it possible to change behaviour.

    Theres some discussion inside The Tavern and just upgrading WP is not enough as discussed here: http://www.wptavern.com/forum/general-wordpress/835-wordpress-security-about-more-than-wordpress.html

    You should grab a virtual beer with us in the bar, since I at least, talk about yore responsibility ;)

    Lets say Matt then. If you make an easy-to-setup CMS with a famous 5-minute-install and have 100.000 or more users installing and running it, without having a clue about servers or security then you also have some responsibility towards these 100.000 + users.


  17. @DavidCoveny – It’s not scary because of WordPress. WordPress is so easy to upgrade a monkey could do it (literally, it’s just a matter of clicking a single button). The problem is that I’m EXTREMELY worried the software I’m integrating with is going to break. This is not a failing of WordPress, but a failing in the other software. However it doesn’t make upgrading WordPress any less problematic. Last time I upgraded this particular site took me about three days to fix all the problems that occurred during the upgrade.


  18. @Dave Doyle

    … I would beg you to issue a patches, not a full upgrade. Tell us when the DB is changing and when it is not. Make it EASIER for us.

    I like that idea a lot.

    I don’t think the WordPress developers themselves will bother though as they’ll be keen for everyone to just upgrade to the latest version (and with good reason), but your suggestion may be a good project for someone else to take on. A single site you could go to which outlines the various fixes and how to implement them would be terrific for people like you and myself.


  19. @Dave Doyle – if you’re smart enough to use patches, you’re smart enough to wrangle SVN. SVN can give you arbitrary diffs between any release or revision of WordPress, compare it to your local version, allow one-click reversions and updates, and you can browse it visually and even download diffs of any file or changeset on the WordPress Trac. It also works great with binary files, something patches really can’t. Any patches we provided would be inferior to what you could get yourself via SVN, so if that’s important to you I would recommend diving into it. There’s a fantastic free book on SVN available here:

    http://svnbook.red-bean.com/


  20. Perhaps as a community we could do like an “upgrade barn raising” where the more tech savvy folks (the audience of WP Tavern) could volunteer a little bit of time every day to help get folks set up correctly on the latest version, like install4free used to work for installations.

    I can’t see how that could help. Upgrading is literally just a matter of clicking a single button, so there’s not really anything to help with. The problems would be related to testing plugins, themes etc. which the site owner would need to do themselves since they know how their own site ticks better than anyone else.

    Maybe there are exceptions where some technical help could be needed, but those would be fairly few and far between I imagine.


  21. @Ryan – All it would take from the WordPress developers is a simple comment in the code to show where a change has been made for hardening security. If they used a consistent comment it would then be very easy to run a diff and/or grep that comment.

    If we collaborated on doing this and sharing the patches checking for security fixes would not be onerous.

    I prefer to see this on the Codex but getting updates on one particular section of the Codex is impossible.


  22. sorry, but if you got hit by this it’s because you didn’t upgrade. make all the excuses you want, it’s still your fault. you can’t blame the wordpress team for your lack of planning.


  23. This last comment got me curious – how many of those who have commented here actually got hacked by this latest worm?
    None of the sites I manage were. Logs showed plenty of attempts, even on the 2.6.5 sites, but all attempts to date came to nothing. WordPress Tavern wasn’t hit.
    Was anyone hit or are we all just discussing ways in which securing WordPress could be easier?


  24. I’m 0 for 6. That because I actually understand that security is something you have to think about BEFORE something goes wrong. It always amazes me that these public “tech” figures know crap about implementing technology.


  25. First of all WordPress is a blogging platform, yes we’ve forked it to do so many things, but that’s what it is inherently.

    We’re in version 2.8.4, by now people using WordPress should have realized that things like this can happen and when they do it’s a serious issue. So if you’re customizing it to perform all kinds of “thingamajigs” you better be prepared to deal with re-doing those “thingamajigs” when it comes time to upgrade.

    WordPress provides you the tools to do whatever. But if you use it in such a way that your entire website/blog has to DREAD an upgrade, well then, you’re doing it wrong.


  26. @Matt – I always knew that was possible with SVN, but just never thought about applying it to patching production installs quickly for security updates. Great tip.


  27. if you’re smart enough to use patches, you’re smart enough to wrangle SVN. SVN can give you arbitrary diffs between any release or revision of WordPress, compare it to your local version, allow one-click reversions and updates

    Yeah, but that wouldn’t tell us which changes were for security and which were just bug fixes … or at least I think that is the case. I don’t have a lot of experience with SVN so maybe there is some functionality in there I’m not aware of which tells you what the diff’s are for. If so, then it maybe someone will take those and create a site offering information on how to apply them manually perhaps. That’s not something I think the WordPress.org project needs to deal with though as it isn’t something you should be encouraging people to do since most will be doing it for the wrong reasons.



Comments are closed.