WordPress themes, plugins backdoored in supply chain attack
bleepingcomputer.com
bleepingcomputer.com
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
0. https://www.wordfence.com/blog/2021/03/recently-patched-vuln...
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.
It’s a deceitful way to present it. Jetpack and WordPress are the same company.
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).
Source: I work at Automattic and used to work on a Jetpack team.
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).
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.
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.
Look it up, you're routing everything to static files in file system directories.
Only if you are requesting an URL (however "you" are identified) the webserver even contemplates serving something else.
It's an explicit rule for the special case. Everyone else doesn't see a PHP-FPM execution path at all.
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.
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.
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?
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.
- Can section off certain requests
- Can rate limit
- Can catch basic injection attacks
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".
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.
tl;dr: Use a static site generator.
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.
Is there a proof for that?
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.
Wordpress has only one entrypoint and only needs to write to its data directory, so it's quite decent.
The big issue with wordpress is with the vast plugin system, where all bets may be off depending on what you run.
even whitehouse.gov uses WordPress: https://wordpress.org/showcase/the-white-house/
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.
The original Codex can be considered obsolete as it has been replaced by developers.wordpress.org which is much more informative and up to date.
Here is an example for a tutorial on how to configure the FastCGI cache for Wordpress: https://easyengine.io/wordpress-nginx/tutorials/single-site/...
[1]: https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#...
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.
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.
I used to recommend WordPress, but I can't anymore, the plugin system (and bloated themes) is a mess.
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.
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.
> 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:
https://patchstack.com/database/vulnerability/wp-super-cache
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.
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".
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".
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.
That's not the issue with WordPress plugins, which generally suffer from unknown provenance and suspect security-posture.
oof
0. https://twitter.com/avillegasn/status/1450089053794230278
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 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.
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.
Depending on your needs, a staging version can be built and hosted. To be promoted to production once chief editor Acks. Or multiple such versions.
You can have multiple stages. Or just one, with a preview on localhost. You can have testsuites crawling a build. Or just a manual quick glance.
This problem is not hard. It is, in fact, much simpler to solve with static sites.
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.
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).
https://jetpack.com/2022/01/18/backdoor-found-in-themes-and-...
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.
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.
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.
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.
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.
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.
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.
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.
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.
For worse.
> 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.
That can't be said about critical infrastructure.
"critical" means something. If the water system or the power grid goes down for a few hours, the world has a major problem.
If everything widely used is "critical infrastructure", then nothing is.
i think i agree with you but then started to think that huge whole parts of the Internet may not qualify by your definition.
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.
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.
https://roots.io/bedrock/ is a neat boilerplate for how this can be done.
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.
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.
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.
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.
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.
You do have to be really careful about what plugins you install, but there are useful ones out there.
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.
There should be some competing products in this space.
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.
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.
> <azonenberg> wordpress is an unauthenticated remote shell that, as a useful side feature, also contains a blog
Circa mid-00s
The alternative is a low-trust low-collaboration regression to 1990s style software development, and that is simply untenable.
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.
[0] https://docs.github.com/en/pages/setting-up-a-github-pages-s...
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.
You got this.
CI can do the build, and the last step of CI can be ftp, rsync, scp, or whatever. It's just static files, normal hosting anywhere is fine.
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.
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.
If you're unwilling to read documentation, then yes, you're probably better off sticking to Squarespace or WordPress.com
- Good support for posting source code from various languages, both inline and in blocks, with syntax highlighting.
- Zero-effort image posting ala WordPress, ie with automatic down-sizing of the inline image if needed (in these days ideally multi-resolution).
I imagined these were quite basic needs, but I've been disappointed each time I've gone looking. Been a year since last time though.
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.
> 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.
I use Ghost + Cloudflare.
It is not for security but for occasional spikes of traffic. Nothing says we can't use static-site-generator + Cloudflare. Even better.
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 do still admire the company and the project.
So I take it your code could handle a 1GB blog post safely without giving you an error about exceeding post_max_size or something similar?
That would be a bug.
Small code != bug free code.
> 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.
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.
Auth is a cookie, session, ip and password check.
It builds a html document from 3 strings.
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.
> 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.
How many users would there be who know the WP code base inside out? 1 in a million seems a lot?
Interesting to see how 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.
[1]: https://www.jemjabella.co.uk/2019/security-alert-pipdig-inse...
The sector where WordPress gets "mis-used" most is real estate. It really isn't designed for that usecase: https://smallbusinessforum.co/why-an-alternative-to-wordpres...
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.
"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?
Threat actor: https://en.wikipedia.org/wiki/Threat_actor
Supply chain attack: https://en.wikipedia.org/wiki/Supply_chain_attack