Public disclosure by the people that found the backdoor. I couldn't find any disclosure about it by AccessPress themselves between 15. October when they pulled the compromised themes and plugins to now.
That's not the timeline. It was a single day from contact to removal of compromised plugins. According to the article, the issue was that the vendor's contact form didn't work, not that the vendor didn't quickly remove the plugins.
You are also confusing plugins with themes. They are not exactly the same.
Had this happen recently to a site. The SMTP password was set wrong and I don't know how many months/years this form just failed to submit but no one was aware of it... was for a landing page type site.
That’s simply not true. Jetpack is owned by Automattic. Automattic has an exclusive license to the name “WordPress” from the WordPress Foundation but WordPress is owned, operated, and managed by the WordPress Foundation and is a totally separate entity.
Source: I work at Automattic and used to work on a Jetpack team.
It's not deceitful at all. Anyone who's in the WP ecosystem understands this.
Jetpack is part of Automattic. Automattic's main thing is wordpress.com (the hosted platform). Automattic and WP.org are not the same thing even though ( as with many open source projects that have commercial implications) the lines are somewhat blurred.
Presenting this as "deceitful" is really quite the over-reaction.
Deceitful implies intention. Qualifiers help. "Unintentionally misleading" fits better. It's like the difference between manslaughter (whoopsiedeath) and murder (intentional).
You have to understand that this sort of intentional obfuscation of ownership and responsibility under a single root of ownership is in most areas of business a pretty good indication of ill intent (even if it is depressingly common).
So isn't the reasonable deduction here that the vendor was responsible for this given it was present on their website but not on the plugins through Wordpress? They probably didn't have the back door on the wordpress plugins because those would face a higher scrutiny than the ones on their site. Finally they get caught and go silent, but then when wordpress knows they finally respond because they know the jig is up and are trying to save face.
I don't think that's a reasonable deduction, it seems like the contact form on the vendor's website didn't work. That could possibly be compromised by the attacker.
Since most people don't seem to be aware: you can use Wordpress as a mostly-static website generator.
Use WP Super Cache, and most of your pages are static anyway. A small PHP stub will be hit still, but if you don't even want that, you can just serve the generated static pages without it.
It's well documented, you just edit your httpd.conf/.htaccess or your nginx config to serve the static files generated by the plugins.
Only logged-in users (in most personal Wordpress installations: "just me") or recent commenters, depending on configuration, hit any PHP code at all.
Oh, and commenting works, unless with SSGs out of the box.
Keep the number of plugins small, use a static plugin and security is mostly a non-issue for a personal weblog (it's different for a "real" media operation with all kinds of complicated workflows, of course).
> Since most people don't seem to be aware: you can use Wordpress as a mostly-static website generator.
> Use WP Super Cache, and most of your pages are static anyway.
This isn't "static" in the sense of a static site generator because your web server is still running code, reading/writing files, sending SQL queries, interpreting URL query parameters (e.g. for search results pages) and injecting data into templates when pages are being viewed. There is a much greater attack area and types of possible attacks.
For example, the caching plugin itself you mentioned has had remote code execution and XSS security holes in the last 6 months and others in the past:
Many of these kinds of attacks aren't possible when your hosted website is only HTML, CSS, JavaScript with a CDN in front. Saying you think securing WordPress is practical is one thing, but there's a huge difference between dynamic and static.
> Many of these kinds of attacks aren't possible when your hosted website is only HTML, CSS, JavaScript
Had you read the other comments, where I have replied to this misconception several times already, you would have seen that the setup I describe is just that: "your hosted website is only HTML, CSS, JavaScript".
You need to read past the second sentence where I explain that WP Super Cache can be configured for fully static operation.
Or if three sentences are too much for you, you could read any of the other comments, all made hours before you jumped in with your inane "well-actually".
Can you link to anywhere that explains more? Pages are only generated when editors make edits and never from requests from visitors? How do you regenerate when you update the theme and what about tag, category and search pages?
At least when using nginx you don't even need WP Super Cache or any other Wordpress plugin. Instead you can utilize Nginx' FastCGI cache feature [1] which works for anything using FastCGI and not just Wordpress.
As shown in the linked guide you'd configure that based on something like an application specific cookie, which is probably required for the shopping basket in the first place anyway. I believe solutions like WP Super Cache handle that the same way, but I might be wrong about that.
Caching solves only the performance problem, which in my mind is the least compelling reason to go for static site.
If your wp-admin routes are still accessible to the public internet, then you are still at risk for broken plugins causing a hack. You have to both cache all static directories and firewall the actual server if you want to avoid being hacked by one of the thousands of scripts that scans every IP address for WordPress plugin vulnerabilities.
> Caching solves only the performance problem, which in my mind is the least compelling reason to go for static site.
One the other hand there are compelling reasons for not going with a static site as well.
Try getting non-technical users to write the markup for their posts by hand without a WYSIWYG editor. Or try to integrate features like comments with a static site without using a third-party service.
> If your wp-admin routes are still accessible to the public internet, then you are still at risk for broken plugins causing a hack. You have to both cache all static directories and firewall the actual server if you want to avoid being hacked by one of the thousands of scripts that scans every IP address for WordPress plugin vulnerabilities.
That's a risk you have with every internet facing software. Yes, static sites are great, because they greatly reduce the attack surface, but there are reasons why not every website is a statically generated site. As the comment which lead to that thread already mentioned it's quite easy to reduce the risk by keeping the number of plugins as small as possible.
I run several websites powered by Wordpress since more than 15 years and so far didn't have any security incident with them.
This is true. But none of my clients have ever stuck to it. The temptation is too great, within 6 months they always seem to justify installing 20 plugins grinding their performance and security to the ground.
I used to recommend WordPress, but I can't anymore, the plugin system (and bloated themes) is a mess.
It sounds like you've yet to experience having clients. The decision-making authority generally flows quite differently from what you imagine here. The nature of the decision-making authority is what leads the parent commenter to conclude they can't set clients up with WordPress in the first place (because if they tried to tell the clients "no you can't do that" the client would do so anyway and/or switch to a new vendor do be able to do so).
Yep. This was my experience with WordPress as an employee. The marketing team was very loud about needing admin access to the WordPress instance, installed a file manager plugin, and that file manager plugin was shortly used to start serving malware from our domain.
Guess who got to clean it up? It wasn't the marketing team.
Yes, it's a people problem, not a technical problem. But I arrived at the same solution to the people problem as OP: don't set up a WordPress instance for someone who isn't capable of maintaining security themselves.
> It sounds like you've yet to experience having clients.
No, my experience has been the exact opposite. Our clients don't want to fiddle around themselves. They don't care whether their site/app is made with Wordpress or Laravel or Nodejs or w/e as long as it works well and is tailored to their needs. We also explain why this is more robust, flexible and efficient for all parties involved.
> because if they tried to tell the clients "no you can't do that" the client would do so anyway and/or switch to a new vendor do be able to do so
If they did that we've lost them and they lost us. It's just not how we work.
However it's the other way around, many clients we've had moved away from solutions that were too malleable and unstable/slow/hard to maintain etc.
This comment is a load of nonsense. Wordpress core has regular and comprehensive security reviews. Wordpress is the most deployed publishing platform globally. Like with any web application you should be deploying it behind a Web application firewall with a fit for purpose ruleset, and additionally with wordpress you can integrate one of several application firewalls into the application - several of which have decent full time security and development teams that actively discover, patch and mitigate zero days and new exploits.
Anything you add beyond that is on you, and you should be vetting your vendors or own code properly.
I have to wonder what your purpose for attack here is. Are you developing a competing product?
I don't know enough to comment about WordPress. But a secure applications don't need a WAF to be secure. WAFs in the steady-state are really just fuzzy bug injectors that hope to inject bugs over top of exploitable code.
The main use for WAFs that I consider valid is emergency response to recently discovered vulnerabilities while a patch is being discovered and applied.
The other use case is external rate limiting and DoS protection. But most often it is better to do that in the app anyways.
With the wafs that integrate with WP such as wordfence they can also do things like:
- Check for bad file permissions
- Check for bad web server
configuration
- Recieve ruleset updates for zero days that are actually threat surface specific
Having a WAF in place that is threat surface specific isn't as much about saying "its not needed if the code is good" as much as it is saying "the code might not always be good. We are not perfect. I'm at least going to have an extra layer or two of defence to try and stay safe(r) and give me some breathing room between an exploit and a patch".
In my experience it's quite the opposite. It's not perfect, but it's safe enough for most users.
As long as you have WP updated, and a good configuration with your stack (PHP, MySQL, Nginx) it's hard to hack.
The main vulnerabilities come from 3rd party plugins and themes, and shared hosting with older versions of the stack. It's like faulting windows for vulnerabilities in an external .exe app.
If you use the default setup, and follow security guidelines, you should be ok.
This comment is a lame hit job. WordPress is the most widely used publishing platform in the world and highly extensible, so there are always going to be third party plugins and themes which get compromised.
If security is a concern you can simply avoid third party plugins and themes, or limit your use of them to reputable vendors who have good track records.
The code of WordPress itself is pretty robust and the Core team has a great history of fixing vulnerabilities quickly.
I have had a different experience. I’ve been using WP since it was a wee bairn, and have written a number of plugins and themes, over the years.
It is not for every use case. I think some of the new static site generators are great, but WP fits the bill, when we need a fairly dynamic, configurable, maintainable, site.
The “security issues” are, IMNSHO, a reflection of the much wider “depenecapocalypse,” that is plaguing the entire software development industry, where lightly-trained, and inexperienced, devs, slap all kinds of executables into their projects, with hardly a glance at the bona fides of said executables, which, in my experience, can be … questionable.
I admit that I have created “Frankensites,” by using too many plugins (in fact, today, I am about to rewrite one, using as "bare bones" an architecture, as possible). Even good plugins can have a limited shelf life, and I have learned (the hard way) that paying for extensions and themes buys me almost nothing. I have been aghast, when examining the code, in some of these.
There’s a lot of crap WP code, out there, but I have been fairly impressed with the quality of the code and architecture of the core system.
The one thing that I think needs improvement, is the WordPress Codex. It’s a mess. I’m often better served, examining the code directly, than relying on that.
I don't do Web sites as a living. There's millions of better Web developers than me. I like to be able to walk away from a site, and let it stand on its own. WP has served me well, for that.
As I said: with this setup, all the readers (everyone but me) do not even hit any Wordpress code anymore. It truly is a static site generator. You can look at the generated HTML files in the file system. That's what the web server serves.
If it generates something, it can still do whatever it wants with the generated files if the purpose is to, for example, embed spam links.
If the server is the target, it either still has access to it, or to some alternative computer which, for a private individual writing a blog, will be their much more valuable personal device.
Yes, you can spin up a VM, generate html, run it through all sorts of tests and only then upload it. The victims of this hack aren’t going to do that.
Tell your web server to only serve the login stuff to you (certificates, HTTP Basic Auth, whatever). Problem solved.
And what is your solution?
A SSG also generates something and could embed bad stuff.
Something has to upload your SSG generated files and thus needs access to your web server. If you're running it on your personal device it could compromise it.
Really, stop trying so hard to invent Wordpress problems. If you don't like it, nobody forces you to use it.
If you can login or comment, you do hit Wordpress code right?
It could be fine if you put the admin portal behind a firewall but I would also recommend moving forward and stop developing new websites using Wordpress if you care about security. And you should probably care about security.
The issue here was plugins from compromised third-party repository. This has little to do with WordPress. It’s the mechanism Apple refers to as justification for the App Store monopoly which, I guesss, is hated on alternative days to supply chain hacks.
Your Favorite platform will be exactly the same if a bad guy has access and inserts it;s code or if you are dumb enough to install a random third party code from a random website.
My personal blog uses one of the default themes, I hosted extremely cheap, I NEVER touch it because it is autoupdated and it just works.
I did not review WordPress code so I can't tell how secure it is, but using this article to do a lazzy hit on WordPress is pathetic, this issue is as related with WordPress as you installing an .exe fom a random website is a Windows issue.
The biggest reason is that its pages are not statically generated and allows for code execution when they contain no dynamic content.
The second biggest reason is the marketplace for plugins and themes; even if WordPress security audited their entire standard release, every single theme or plugin you install could compromise your installation. You’d think of a theme as something that provides colors and spacing, but they’re fully executable programs.
WordPress is conveniently written in PHP, which attracts inexperienced programmers with no understanding of web security.
The attack that OP links to is a supply-chain attack made possible by WordPress’es software architecture, but it could have happened on most more secure alternatives if they were equally popular.
So while it’s easy to ridicule WordPress for having no security and a poor architecture to withstand most attacks, we mustn’t forget that it’s a combination of its huge popularity and the ease of use caused by its simplistic choices that has lead to this breach.
If the critics spent as much time building and selling what they see as the “better option” to WordPress, perhaps we wouldn’t be in this place. As it is, they just do the easy thing, playing “pigeon chess” by making these hackneyed, unsupported assertions.
A better assessment is that WordPress has made trade-offs regarding security, as anybody in the real world must. Individuals must also make their own trade-offs, including whether to run WordPress at all, then how to configure it and which third-party code to use. Sometimes we get the trade-offs wrong, and that should affect how people make future decisions.
Most People that use WordPress are not develoeprs or technical people. Find similar product with a WYSIWYG GUI , theme , plugins, cheap hosting, no bullshit licensing or breaking backwards compatibility and promote it to people or whoever hosts this blogs.
I think you are suggesting someone to replace his IDE with notepad since you can build application with notepad and gcc directly.
All my logs, if wordpress or not, get constantly hammered with random wordpress backdoor requests. Even if it were generally secure, the one day it's not can break everything.
Have those newer platforms been audited to the same extent as WordPress? Even if the core of any new CMS is “more secure”, it’ll be faced with the exact same problems the moment it grows big enough that third-party developers begin to release add-ons.
I think it's clear that the fewer plugins one installs (ideally none) the better, though it's difficult to follow this rule in practice. I recently had to set up a WP website from scratch, and plugins are a very common way for people to solve their problems (especially non-technical users). Plugins are even used for basic ops work like rewrite rules, backups, log parsing, caching—and I get it, for most people if they didn't exist they wouldn't have done the ops stuff, or solve many of the other types of problems, so it's kind of a blessing and a curse given your attack surface increases with each plugin and WP feature. I've learned that Wordpress really is what you make of it, directly proportional to the engineering effort you put in.
I don’t think is really at all clear. Whether it’s word press plugins, or a few thousand JS or Python modules you install with npm/pip, the market has moved into this direction because it is the most efficient. The problem is 100% in testing which is something most places slack of at because people joining, if they do write tests at all, only test their additions to the codebase.
It isn’t just Wordpress, either, I think that testing of large scale interconnected software is not yet a solved problem and whomever can devise a system that eliminates all the vulnerability types we’ve seen exploited over the last few years will become very rich.
You don't test for malware. You test to make sure the attack vector that's used to install malware is closed to attackers. For example, if you have an upload feature your tests should check that your file type filtering actually works, that things in your upload directory aren't executable, that you can't upload to the path of an existing file, and so on. You should build with security in mind, and test that the code you wrote does what you think it should do, and that it doesn't do things it shouldn't do.
Yeah exactly, that’s my point. We haven’t been developing and using a ton of test types we could realistically do now given the proper incentives. At some point, with more and more data being accumulated and more and more services being brought online, we will have to start adding more foolproof tests suites as it it’s reaching a point where it’s not just company reputation but national security that we’re risking.
For people recommending static sites to replace WordPress, what do you do if you want to give users a basic page builder in the CMS where you can easily preview the page before it goes live?
E.g. bolting together page blocks for testimonials, feature lists and a contact form with some basic customisation like colours and images.
Markdown only support is straightforward but most company websites need a bit more than this. Accurate page previews before production deploys is really important too. Open source preferred as well.
I built it specifically to address shortfalls of other site builders:
- No themes
- Uses 'modules' rather than the strangely popular drag and drop thing with blocks and widgets (which then jumble about the page wildly when resizing). We have 40 modules at the moment and I keep building more.
- 100% mobile optimised. We hide no functionality and most page editing I tend to do side by side, with the CMS in a separate window next to the preview site
- The preview site updates automatically when you hit 'save' so that it can be viewed on many devices in real-time at the same time (and shared easily too)
- It's very fast. No React or other shenanigans. There is JS for the more complex interactions, but it's been applied sparingly. Doesn't work without JS though.
- Sites are deployed to Cloudflare Workers Sites. The SSG behind the scenes is Hugo
I don't advertise this thing anywhere and all my clients are word of mouth. I have yet to hear a single negative thing from anyone.
I live in the countryside so my clients are all pensioners who don't know computers. They've all had run-ins with WordPress and naturally hated it. (though I don't want to knock a properly setup WordPress, IMO you have to be technical to do it and my system is aimed specifically at non technical people)
I don't do shops and even blogs are probably not directly my target audience. But if you just need to make a simple site with pictures, videos and images (maybe a mailchimp signup, instagram gallery or Google calendar signup or showing some PDF newsletters), then I'd challenge you to do it faster in any other system.
I'm doing this on the side, so have no time to build websites, so it takes no time to build websites in my system :) (I've built a lot of websites for free and just end up collecting the hosting charge which is between £8-£13 a month, which is hopefully similar to some sitebuilders, but I can't compete with the £3 per month offerings that tie you into other services and immediately become more expensive as soon as you add any meaningful functionality.)
There are about a billion things I want to improve about it of course. It's certainly not perfect, but finding the time is a challenge. I hope to one day be able to make it my full time job.
Next.js, and most likely all the big players, can achieve that. I use Prismic for a lot of projects, and here's documentation about how to achieve previews with it and Next.js https://prismic.io/docs/technologies/previews-nextjs
Yeah, easy, all you have to do is rewrite WordPress in JavaScript. Now instead of worrying about malware in plugins, you can worry about malware in plugins and your npm dependencies!
You shouldn't run your web server as root. I think the most common way of running WordPress is to use nginx in front of Apache, so you can easily run Apache as a special WordPress user for extra security.
Every backend has access to your DB though. If a WordPress alternative supports plugins, it is just as vulnerable. If it doesn't support plugins, it's not a WordPress alternative for most use cases.
> Accurate page previews before production deploys is really important too. Open source preferred as well.
I just like to keep it simple and write markdown on a local git repository that is mirrored on github + github pages for viewing (but I'm sure there's other ways to do the same too). You can just commit your changes locally to test that everything works, and then push it to remote and it will get picked up by "production". It works as a single user but I can imagine working for a small team of contributors as well.
Lock down your WP install within your VPC & serve the static pages from S3.
If you do have a dedicated engineering team, the trend now is using headless cms (sanity or contentful) and a ssr platform (Next.js or any of the traditional frameworks).
If you're not completely against markdown, I particularly like Grav (https://getgrav.org) combined with the optional Admin plugin. Very quick and easy installation; I don't need to keep detailed notes on getting the exact packages loaded to make it work.
The admin plugin gets you easy editing capabilities, although you still write in markdown by default it has quick buttons for common markdown and a preview button.
There's a lot of domain hacks you can do with .af however I imagine the sovereign risk of using a domain controlled by the Taliban would be higher than average
Ghost is pretty decent, but it ties you to the node/npm upgrade treadmill and has a few weirdnesses like pushing very hard to get people to sign up for Mailgun instead of using their own mail server.
Like say you want to update the heading text and background image for a landing page header and check it looks good on desktop and mobile. Does it line wrap nicely? Maybe bolding some words would look good? Is the text still readable when it overlaps the image? I want to be able to preview and tweak this kind of thing in seconds.
What would you use for this? I wouldn't want to wait a minute for Netlify to build and deploy to staging each time for example.
It seems you want to optimize your frontend-work. Tweaking a live setup that goes `client-> CMS -> Database. [switch-tab] [F5-refresh] -> client -> CMS -> Database -> client` is quite certainly not the direction you want to go.
Instead, most frontend-development optimizes with things like that jekyll --preview: some devserver that autoreload (and autorefreshes!) your website on change.
I now ask you: if you are happy about the changes: How do you save it? How do you reproduce it onto those other two websites? Or, if you were carefull and did the work on test/acceptance/staging, how to reproduce it on production? How do you communicate to your colleagues what has changed? How do you communicate to your future self what you changed?
This stuff commonly lives in code, which is version controlled. Having it in a database is suboptimal, for this reason too.
In my search engine work, I found an enormous cluster of websites that had a huge number of pages with link spam on them, but with a seemingly legit front page. Sometimes linkfarms will have some sort of a facade, but this was more elaborate.
More confusing still, they were all on .net and .com-domains. I just couldn't figure out what was going on, .com-domains are expensive, typically link farms are on .xyz, .icu or something similarly cheap.
I don't have the number, but I'm certain I identified tens of thousands of them, if not a hundred thousand. That's close to a million dollars in domain fees. The numbers didn't add up, who would spend that sort of money on link farms? They were also hosted all over, not just on Chinese clouds like most spam offenders are.
It finally dawned upon me: What I was looking at was hacked wordpress instances. Holy crap there's a lot of them floating around.
A local 2nd hand Swiss watch dealer/shop runs their online store off a Wordpress set up (no e-commerce/online payments though). Sometimes when I visited to look at their current stock, when clicking into something of interest I would get bombarded with all sorts of random adware crap, new tabs etc. opening with blogspam - typical “Win an iPad” type stuff.
The owner was totally unaware, as this never happens to them - they are logged into the site the whole time, so it deliberately never triggers/fires itself as they make updates, etc.
It was also somewhat random for users of the site, but when users see it, they probably just close it / ignore it.
Nobody told them this happened when browsing their website so they were totally unaware they had been comprised.
Moral of the story, always occasionally browse your own web properties from other devices and incognito windows, etc. to see what other people see.
I’ve seen this on non-wp sites as well. So it’s not just specific to wp sites. Basically if you have a vulnerability somewhere, someone is going to do this to your server.
But TL;DR: It's a form of search engine manipulation. The theory is that if you put a bunch of links to your low-ranking domain on a high ranking domain, search engines will think your content is more valuable and be more likely to crop up as top results. You set up a lot of these so they promote each other, making it look like your shady website is popular when it is not. It used to be more effective than it is today, but it's still relatively common.
Search engine manipulation doesn't need to be on these link farms, it's also relatively common to for example have a shady online casino raise their ranking by sponsoring open source projects, which reward them by linking to the online casino. That way the popularity of those projects will "rub off" on the online casino.
It's mostly a problem for search engines, they typically don't want human visitors. Many of these wordpress installs are innocent small businesses that just haven't realized they're hacked.
> wordpress can at this point be considered critical infrastructure.
True, sadly, though I'm thankful that after yet another security incident the mid-size company I work for has decided to officially end WordPress use across all our domains. Hopefully, others will begin to do the same.
As someone who has been using WordPress since 2006, my brain exploded when I saw this.
WordPress has always been an absolute mess. The basic architecture was insane even in the early 2000s. There is no effective sandbox for plugins or themes, and you can't really make serious use of WordPress without those.
Nowadays, there are so many better applications that accomplish the same thing, and they aren't stuck on a half-baked database schema from 2003, they can be version-controlled, multiple people can work on them at the same time...
WordPress is one of the worst widely used pieces of software on the web. It is a catastrophe.
> here is no effective sandbox for plugins or themes, and you can't really make serious use of WordPress without those.
I mean, literally thousands of sites do make serious use of WordPress. Quite surprised that in your use of WordPress since 2006 you haven't heard about any of them.
The CMS space is incredibly crowded. The vast majority of WordPress websites would be cheaper, faster, and more secure if they were just moved to SquareSpace, which has the WordPress features that 99% of sites would need.
For more custom projects, I prefer the headless variety[1] because it makes sense to separate the data and presentation layers. That means you have the full ecosystem and flexibility of HTML/CSS/JS.
Ghost[2] was the first serious competitor I saw years ago. Gatsby is among the most popular these days[3].
But honestly, information sites should just use SquareSpace or something like it. There's no reason to maintain static site infrastructure at this point.
If we're starting to compare to hosted offers, then hosted WordPress (WP.org or any other managed host that curates access to plugins/themes) surely needs to be added back to the list?
For enterprise level stuff, Drupal. Drupal development is a pain in the ass, but it's incredibly powerful, has a great community, and has a huge focus on security. But for the average blog/site, Drupal is overkill and too technical for what most people need
The trouble with WordPress is that it makes it too easy to set up and far too easy to install random plugins.
People spin up a WordPress instance for their blog that they're totally going to use every day, install a bunch of plugins and a fancy theme, then within a few months have completely forgotten about it. Meanwhile, vulnerabilities are discovered in the plugins they installed. Maybe they're patched and maybe they're not, but either way their server doesn't get updated.
Within a few months it's hacked, and the ex-blogger probably doesn't know until they get an email from their hosting service complaining about malware being served from their blog.
This is made worse by the fact that, since WordPress is everywhere, it's worth the time for bad actors to write scripts to exploit vulnerabilities in outdated versions of popular plugins. It doesn't matter how obscure your site is, if it's written in WordPress and not up-to-date, it's as good as hacked.
The value of managed solutions for the every day person/company is almost priceless. Squarespace / hosted email / cloud storage etc should be standard vs Wordpress/self hosted email/ a shared drive on the local network.
Unless hosting the product is your core business model, let someone else do it, because then there will be one or more people dedicated to making sure it works perfect and is regularly updated.
After building some sites with Wordpress recently, I think another problem is the business model of most plug-in vendors.
They all seem to charge $90 for a year of updates. Gets steep quickly- theme, backups, layout builder etc. Fine for the first year but probably don’t get renewed and then the plug-ins don’t get updated.
I’d love to see a list of fully featured open source plug-ins.
Its also totally possible to be burned by auto updates. Say for example if you're running php 7.3 and the vendor specifies the plugin needs php 7.4 (even if it doesn't!) . Your plugin gets updated, you get the white page of death, your site is offline, and now you need to ftp/ssh in and rename the directory for that plugin.
The difference is that it is bad for business reputation when some of the largest companies on planet are regularly leaking data through exploits. Testing will become an economic requirement over time.
I recently had to take over a wordpress site for a volunteer project and it almost immediately got hacked with spam despite taking great pains to not have this happen.
Thousands of SEO pages showed up in the DB after installing some well known marketplace plugins. I was able to remove the hacked plugin and fortunately, it wasn't a big deal as this was just a temporary site for an event, but I would never work on wordpress again and I dissuade people from using it when I hear that they are considering it.
It was great for its day, but times have changed and it's just not a secure platform.
Any benefit given by all the plugins is outweighed by "hack roulette" you are playing when you install and customize them.
There are now many other solutions out there that will be more secure and fit the need for most people.
The key to running Wordpress securely is usually to set the file permissions correctly and protect all admin routes. Basically, don’t expose any write endpoints to the internet.
And the easiest way is to use as few third party plugins/themes as possible.
Base Wordpress is pretty secure if you put the admin panel behind a VPN and don’t install any plugins.
If you professionally build a WordPress site, please consider turning off the native plugin and theme management, and replace it with composer and files non-writable to PHP.
We tried a "secure plan", which, a.o. ran the WP codebase on read-only filesystem (technically: chrooted, so WP could not change its own codebase).
We pitched this with the "professionals" amongst the customers. They liked the idea, but abandoned it nonetheless. Too many themes won't work OOT. Too many plugins write files. Too many features appeared "broken" to their clients. When someone logs in as root, hits the update-button and gets errors, they consider it crap, rather than "proper security practice".
So, while it seems nice in theory, the practice is -unfortunately- not there yet: as long as it is not the de-facto way, but an obscure, unfamiliar way, to run a WP site, people will too often abandone it. A feedback-loop causing it to never become really secure.
When I was doing agency work I was fortunate enough to be able to set a priority for security and build most things from scratch, only using a hand full of utility plugins (e.g. ACF) where I could have at least a glance at the code doing things well. Anyone who has a site valuable enough to do that (and use a git workflow) should be using a framework like Bedrock.
I've never had a positive experience with a theme that had a thousand built-in options or even turned WP into a fully blown site builder. The code quality - both of the plugin/theme code and the generated markup - was usually quite bad. I imagine the main audience for managed WP hosting is there.
I feel like WordPress sort of "wraps around" (quality horse-shoe, it was so bad but popular that now it's good). Core WordPress is one of the most audited codebases on the planet, it has a ton of duct tape and scar tissue.
Any new relevant bug classes, people will tend to look for it and fix it in WordPress first, because practically every bounty program has one or more instances somewhere.
People aren't doing these kinds of attacks against WordPress plugin distribution because it's uniquely vulnerable. They're doing it because WordPress is incredibly popular.
If you need the stuff WordPress can do and can't get away with a static site, IMHO it's usually still the best choice.
Main caveats being, plugin quality varies very widely (including at supply chain level), and you can quickly run into issues if you get an agency to customise and they do a bad job.
From a technical sense there are plenty of alternatives, even similarly disliked platforms like medium or wix.
The problem is none of them are interested in turning a basic CMS into a wasteland of kitchen sink functionality that aims to turn blogging software into the ultimate web swiss army knife.
People are happy to build blog software, but that's not what WordPress' customer base wants. They want professional services in the form of a grab bag of sketchy plugins. Nobody's going down that path again.
If the goal were simply "let's build a better blogging platform" or "let's build a better storefront platform" or "let's build a better music venue website platform" there might be a receptive audience. But the goal is "let's build all three in one and also 500 other use cases." Who would see that as a compelling goal in 2022.
I concur, many of my clients are 'rescues' from Wix and Wordpress and the only thing more hated than Wordpress is Wix.
More often than not it comes down to the horrifyingly confusing documentation, inconsistent UX, hilarious over-promising the world + dog on landing pages, etc.
Also, exfiltrating a website from Wix (changing the nameservers, which should take two seconds, like it does with any other hoster) is a huge ordeal. They make it very difficult.
To be fair, I referred to it as "similarly disliked." From a technical sense I'm less afraid of malicious plugins destroying my business like I might be with WP.
My stance is if I'm doing X, my preference is to find software or a platform that does X but not X, Y and Z.
landing on a Wix page is noticeably worse for someone who tries to limit ads and scripting. Everything has to pretty much be off for a Wix page to work, it is very heavy.
I can see how the lack of plugins may make it more secure though. I haven’t tried Wix, but squarespace is pretty good for getting something out the door quickly. It’s quite limited otherwise and the customization of wordpress makes it a very appealing CMS for most.
If WP provides security screens for add-ons and integrates it into their hosting business it would protect their ecosystem moat.
Storefront... you have Shopify. The most valuable use case, people are building those. The problem is people want a million different things for lots of other stuff. Shopify now has its own ecosystem too. It's the nature of creating popular platforms that businesses rely on.
Exactly, as much as I dislike dealing with it, it does allow our sales and marketing people to do things like publish content, fiddle with SEO, deploy custom redesigns of the website, etc. Without much support from me. That's important for me because I have more important things to do.
We've had multiple people do work on this setup. When we get new people in, they already know how to work with it because it is so widely used. We had a sales person with some Wordpress experience setting up things like CMS integrations, do some basic SEO, etc. Then recently we had a new designer that got busy redesigning our website. All that stuff happened without support from my side. That happened multiple times actually since we have been working with student trainees a bit. It's great. These people come in and they know how this stuff works already and get things done without me having to spend a lot of time on it.
That's it's main redeeming feature. It's horrible for technical people to deal with but it's main feature is that non technical people are able to use it without requiring assistance from technical people. All I do is makes sure it stays up to date, is configured properly, and make sure backups happen.
Other CMS solutions are available of course and I would recommend anyone in a position to choose to use some hosted and managed solution. Something like Squarespace or whatever rather than setting up their own wordpress server. But there's nothing that comes close in terms of non technical people actually knowing how to work with it. It's been the go-to solution for this stuff for a very long time now.
> That's it's main redeeming feature. It's horrible for technical people to deal with but it's main feature is that non technical people are able to use it without requiring assistance from technical people.
Which also makes it kind of a Black Swan risk: it's fine for the majority of times. Preferable, because it leaves you to do other work. But when sh*t hits fans, it hits it bad. If you cannot afford your tech-staff to spend two hours a week supporting the website, you certainly cannot afford them to spend days cleaning out some backdoor, infected servers, acquiring untainted IPs, getting off spam-lists and so on. Or afford the ransom if hit by a crypt-locker.
> All I do is makes sure it stays up to date, is configured properly, and make sure backups happen.
And that is more than most do. But, unfortunately not enough. Given the amount, frequency and severety of holes and exploits in the larger WP ecosystem. All you might be doing, is backup that ransomware, spamscript or backdoor for months. Encrypted, offsite and incremental, probably.
Honestly, if you use wordpress for the basic functionality and don't install plugins, it's pretty nice. You got a fully functional blog, you can give non-technical users a login and they know how to use it too.
You do have to be really careful about what plugins you install, but there are useful ones out there.
Wordpress is similar to forum software in that the modern landscape have diversified and depending on what you are trying to accomplish there are a ton of alternatives. Almost none of them are a reimplementation of what Wordpress does though since it comes from a time where you would purchase shared hosting that came with Apache, PHP and MySQL built in. It’s a giant monolith that is as widespread as it is because 90% of everyone who started a website in the 2000s used Wordpress.
WP is way past being a blogging platform. Try: replacement for online multi-role portal editor with knowledgebase, shop, forum, stock management, image gallery, document converter, .... elements installable in 2 clicks.
I see Wordpress as a kitchen knife that is being sold to all ages - I did have more to say in reply to your question, but the more I think about it, the more I think that analogy speaks for itself
None of those have a plugin ecosystem that remotely approaches WordPress's, let alone the bevy of WP-specific consultants. It is not much of an exaggeration to say that companies can make WordPress do anything without any real programming on their part; this is just not true for the developer-focused alternatives, no matter how much better they are on a technical level.
Publii doesn't work well when you want to edit your one blog from multiple computers. Hugo or whatever is not much of a stretch and you can edit from your laptop and desktop w/ git.
It's not a "supply chain attack" when you wantonly deploy unreviewed code on your server. We don't need a fancy term for it. It is just jackass behavior.
I have thought about moving my personal blog onto something that isn't someone else's service. But every time I think about running my own blog server, stories like this come along.
This is 100% possible without a server. Your repo can be your database if you run it statically with something like Hugo (a single binary with no dependencies). Store your content in your own repo in Markdown files (or something similar, like MDX) and host it on Netlify, Vercel, AWS, etc.
If your site has 10K posts and you don’t want to deal with long build times, use Next.js with ISR (make some high traffic pages static, others dynamic (server side rendered)).
As the founder of Forestry.io and Tina.io, I’m biased about a content editing UI, but there are many options if you want a GUI on top of your content files.
There's usually a huge difference in access latency though. The usual cheap ftp hosting means a choice of whether you want to be 200ms away from the US or from Australia.
As others have said, static site generators are super easy to set up, and for a blog you'd be able to do basically everything in Markdown. You can also very easily include Netlify CMS or similar for a GUI editor (which will make commits directly to your repo).
I'd recommend at that point just using GitLab or GitHub pages as others have suggested, but if you do want to move completely off of other people's services, it's much simpler to set up nginx or Apache to serve static files than it is to safely host a WordPress instance.
Hugo or Jekyll should be super easy for anyone who's seriously considered hosting their own WordPress instance, like OP is. If setting up a static site generator is too difficult, they definitely shouldn't be running WordPress themselves.
Hugo, at least, has built-in syntax highlighting (both block and inline) and at a glance it looks like Jekyll does, too.
Netlify CMS has zero-effort image posting (saves to your repo's static folder). I'll grant that it doesn't do automatic downsizing, though Netlify as a CDN does.
Doing everything in a web browser without editing local files, mostly. "Open a text editor" or "git commit" are enough to put off people who don't think of themselves as computer people even though complexity wise they are no different than WP, simply because you gotta leave the browser.
Netlify CMS is pretty easy to set up and has all of the basic features that you need for a simple blog.
And again, I would never recommend a static site generator to someone who doesn't think of themselves as a computer person. The context in which this conversation started was someone who was seriously considering hosting their own WordPress instance. I dearly hope that they think of themselves as a computer person.
I'd count all of those in the "easy for developers" category, as long as you're willing to read documentation. It's 1-2 lines of config for any one of those, and the config in question is at the very front of the doc pages.
If you're unwilling to read documentation, then yes, you're probably better off sticking to Squarespace or WordPress.com
You're assuming that the person running the instance and writing content is the same. There are WP instances backing up serious business where people who don't know what CMS even means successfully edit content every day.
Context matters. I recommended a static site generator to a very specific person. Here's the comment I initially replied to:
> I have thought about moving my personal blog onto something that isn't someone else's service. But every time I think about running my own blog server, stories like this come along.
So... yes. I was assuming that OP was going to both be the person running their personal blog and writing on it, and I was assuming that OP is pretty technically competent if they were seriously considering running their own blog server.
That's a pretty good option, as long as your CMS is thoroughly firewalled and only accessible from your computer and Cloudflare. If you can reach the admin console from the wider internet then you haven't solved the real problem with WordPress, which is security not speed.
A theme is server code :) Since WordPress is PHP, rendering the front end is done in PHP on the server. A theme writes PHP to render custom templates, which (on top of styles) is a large part of what themes do in WordPress.
This is changing to an extent with the Full Site Editing project, but themes and plugins are both very powerful and flexible in WordPress, which has in part led to its massive success.
For all the Hugo and Jekyll and other static site generators mentioned, you can run Wordpress locally and have it generate static output. Granted, it would be with a plug-in, but presumably not accessible from the outside world.
Anything that can be written to and executed from the Internet will be a security issue. The only thing your public facing web server should be able to write to is the log file.
For me, mostly control. I've been writing my blog in Markdown for ages, but Blogger only natively supports its bad WYSIWYG editor or pasting raw html. I've decided the friction in pipeline is enough that I kinda want to cut it out of the loop.
My blog is one small php file that can 1) load a html document (that is a blog post) into a textarea. 2) Write out a html document by sticking html above and below that what sits in the text area. 3) find links to the html document on the index page, rss feed and tag pages. 4) load and update the index and tag pages. It does 4 whenever a html document (post) is saved.
There are no bugs in my code. There isn't enough of it to have bugs.
php stopped working at least twice over the life of my blog. As all pages are static html everything simply continued to work with the exception that editing and posting had to be done over ftp.
I download wordpress OS one time and spend a few hours gazing over the thousands of files. I remember thinking sarcastically how I wish I had that level of confidence in my own code. What could possibly go wrong?
> I download wordpress OS one time and spend a few hours gazing over the thousands of files. I remember thinking sarcastically how I wish I had that level of confidence in my own code.
> There are no bugs in my code. There isn't enough of it to have bugs.
Apparently you have a lot of confidence in your code.
I'm pretty confident if you'd post a link to your code here, it wouldn't take long for people point out some bugs in it.
Depends on your definition of a bug. The topic is a bug that affect hundreds of millions of websites. WP probably has many more. They do share their code but there is so much of it that you cant find those bugs.
How many users would there be who know the WP code base inside out? 1 in a million seems a lot?
I've never tried inserting that much text into a textarea.
> To prevent users from causing server timeouts, the default maximum upload size in WordPress typically ranges from 4 MB to 128 MB.
> Google will index up to 2.5MB of an HTML file.
But I read lynx has no issues with giant html files.
If I had a need for it I could use ftp. If the need is frequent I could upload chunks of textarea at a time. Until then I'm going to consider it undesirable.
That's fair, but my point was small code doesn't mean bug free, and just because you only use it in a certain way and don't see any bugs doesn't mean they're not there. In fact I'd wager there are multiple gaping issues with it, that you simply wont encounter.
If your code is as small as I'm imagining it, then it's not handling a lot of error cases, and doesn't cover any edge cases. That's where bugs lurk.
It writes the document to the file system and to the backup folder.
Which part do you imagine to be the most error prone? I'm having a hard time imagining doing fwrite wrong. I mean? lol?
For the malicious actor to gain access they would need to guess the url, guess what the post vars are called, obtain a cookie (set by a deleted php file) and guess the password.
Then one would be able to edit or create a html document. I suppose inserting some malicious js into the newest post shortly after its created could escape my attention. It could take some time for me to notice it. When I do notice it ill restore the documents from a backup. It wouldn't take a DBA.
My rss reader wouldn't like <script> onload onclick etc. I think I would notice my own feed getting flagged.
I'm sure someone could hack the blog but its not worth the effort.
Plugin and theme vendors DDOSing each other via their WP plugin code (that is, via your WP site), where one vendor is supposedly selling other vendor's plugin/theme, is a thing [1] (2019), so idk where you get the notion that things have changed ;)
The whole "plugin" idea, where customization code can basically modify and monkey-patch whatever functionality it desires, has to go away, in WP and elsewhere. SGML has a concept of declarative pipelined markup stream processors to decorate and augment base HTML in a structured and bounded way. A "theme" should ideally only consist of CSS not arbitrary PHP. But I guess WP is a lost case, and has been for 20 years, in this regard.
As dismal as cesspools like Medium are, I'm starting to understand why they're options to self hosting anything at all. Managed services are someone else's security problem.
As someone who runs a small company that self hosts as well as maintains our own hardware, it's great when things are running smoothly (>95% of the time), but when there's a problem, it's a complete time sink.
On one hand, it's much cheaper, it's fun, makes integration work much easier, and I've learned a lot with each deep dive...
...but on the other hand, it can be more stressful, causes more downtime, and it a distraction to the mission of the company.
"According to Sucuri researchers who investigated the case to figure out the actors’ goal, threat actors used the backdoor to redirect visitors to malware-dropping and scam sites. Therefore, the campaign wasn’t very sophisticated."
"Threat actor" and "supply chain attack" sound like attempts to elevate a crime into terrorism. As if their intent was to keep food off of the shelves rather than theft and fraud. Aren't those bad enough?
Both of those terms are technical terms with specific meanings, and they're used correctly here. It's no more intended to scaremonger than when a medical journal uses fancy words for different body parts... it's just how cybersecurity people talk.
Policing language helps with marketing. I'm not saying I like it, but what is the alternative? "Some randos with domain knowledge and free time made the system do something other than what its designers intended, and now are hoping that distracted or gullible users will get fooled into scams"?
2021-09-22: Jetpack Scan team discovers the dropper and back door in the FotoGraphy theme, and tries to contact vendor about the initial finding.
2021-09-27: Confirm presence of dropper + back door in all current free plugins and themes downloaded from vendors website.
2021-09-28: Confirm that dropper + back door is not present on downloads from wordpress.org
2021-09-29: Trying to contact vendor again, with updates on new findings.
2021-10-14: Escalated to WordPress plugins team to try to obtain contact with the vendor.
2021-10-15: Compromised extensions are removed from the vendor’s site.
2021-10-16: Response from vendor
2022-01-17: Most plugins have been upgraded to new versions, themes have been pulled from WordPress.org.
2022-01-18 Public disclosure