WordPress: Unauthenticated path traversal leading to conditional RCE
github.com
github.com
> Paul Ryan 9 years ago
> Note that locate_template() does not prevent directory traversal attacks, so if you’re passing a user-provided template name to the function, be sure to verify that it’s from one of the three appropriate locations (active theme directory, parent theme directory, or /wp-includes/theme-compat/ directory).
https://developer.wordpress.org/reference/functions/locate_t...
/sarc
And its closely related cousin, Joomla.
Edit: wow that's a lot of downvotes! I'm surprised people can't identify a trivial reasoning failure.
Lots of counter examples and definitely no clear relationship. IMO its up to the person making the claim to provide evidence.
The most popular widely deployed software will be the most valuable to attack. That most fail is a function of other properties of the software.
Just today I spent three hours to manually fix a page where a customers site was defaced after they installed and then uninstalled a translation plugin. I had to write a script that manually check every single instance of translatable text there is on the website.
Wordpress is pretty much the exact opposite of that.
It's the WordPress plugin ecosystem that's more often the security nightmare though.
Complexity does not lead directly to exploits, letting errors be ignored does. At what level an error can be ignored - that's quality control. And one can tell poor quality software by how exploitable it is.
Indirectly then? More complexity means more interacting parts, more complex interaction might hide flaws in ways it's hard to predict without looking at the big picture, which might be too big for a single person to picture (he).
I don't advocate for oversimplified systems, the same way I don't advocate for overcomplicated systems. I advocate for finding an equilibrium.
WordPress is a software design from the early 2000's - and not a particularly good example. Even back then there were more secure designs.
Take QMail for example. A simple design, it had security baked in from the start, and remains one of the most secure software packages in history. This exploit would have been prevented if WordPress had followed QMail's security designs. Enforced data flow, avoidance of parsing, eliminating untrusted code, and eliminating bugs by choosing code paths with fewer variables, would've all prevented this bug.
DJB wrote a paper on QMail[1] to try to explain what worked and what was unnecessary. Anyone implementing new software (and wants it to be secure) should consider these [and other] design points. Popular software doesn't have to be bad software. [1] https://cr.yp.to/qmail/qmailsec-20071101.pdf
You know that the scripts doing it are optimized for success rate, so the types of requests they send give you an impression of what's actually out there.
It's clear to me that once we finally achieve rogue AGI, it is going to propagate through unpatched WordPress WooCommerce instances.
People on HN love to talk smack about WordPress. After all these years, it's as much a reflex as shouting "walled garden!" every time there's an Apple story.
Yet some of the biggest web sites on the internet run WordPress, and more importantly, some of the biggest hacking targets on the internet run WordPress.
Prime example: whitehouse.gov.
If you know what you're doing, WordPress fine. The same is true with every other piece of technology out there.
But people on HN like to lump the good in with the bad because everything is binary.
Probably true, but for whatever reason Wordpress seems to attract an awful lot of people that do not know what they are doing
And that is insecure Wordpress: people lego-mounting sites without touching code, only with plugins.
Works as intended, that's why WP has been so popular
Cons: it has a low entry barrier
People who _don't_ know what they are doing are using WP for every project, that they touch, because it is all they know. Given WPs database design, the assumptions baked into that, and the complications resulting from that, make anything other than a posts and pages website a PITA.
This in turn requires one to install shitty plugins, or spend time developing a minimalistic solution to each new challenge. With every plugin the attack surface grows, and the vast majority of larger WP sites is this cobbled together mess of WP plugins, having some WP expert trying to make them all work together without stepping on each other's toes, while hopelessly falling behind on updates, because updates could, and _will_ break things.
People only knowing PHP and WP, try to use WP as a sledgehammer, not realizing that hammer actually being made out of glass. Very few plugins are actually minimalistic, no-bloat, safe, well-developed. Lots of those plugins are 80% marketing fluff and wanting to make a business out of worse than mediocre code bases. That's also due to many people in that community being exactly those, who don't know anything but WP.
Even normal core WP updates can break the legality of ones site. I have had that at some point, where after some WP update it started loading emojis from a friggin third party, to replace the unicode symbol I had used. I was furious, because this needs to be part of the data protection policies/statements. One does not simply load a third party shit, replacing what the dev actually put there, which was just a unicode symbol. That's an idiotic thing to do. If I wanted third-party emojis, I would have included them myself.
Finally, some big pages run on WP says not much, given the catastrophic state of many websites. whitehouse.gov is laughably badly made. Another complete failure. The first thing I see that it loads Google tags manager. A government site loading shit.
fonts.googleapis.com
googletagmanager.com
gstatic.com
parsely.com
And the navigation font is tiiiny. What a horrendous design.
When I click on some navigation link, it wants to go to:
https://www.whitehouse.gov/wp-content/uploads/2026/01/Wide_Site_Primary_02.mp4
If it is a prime example, then it is a prime example of a very shitty made website, by people, who don't know what they should be doing.
So all this shows is one can make a shitty site using WP. Great. I am sure one can also make a not shitty site using WP. Like you say, _"If you know what you are doing ..."_. Just that most WP people don't. They don't know how to not make a mess, or choose the short-term easy way out, and install tons of shitty plugins. Many of them just have to put things up once initially and are paid, or hold the hand open for some maintenance fee they extract, required only due to how badly made these WP sites are.
Drupal (also popular in governments and such), by contrast, will check that it can’t write to anything but its designated file uploads directory, and complain if it can, and has careful guidance around avoiding letting uploads be accidentally executable too. The blast radius of the typical vulnerability, and the possibility of persistent takeover, is drastically reduced.
It’s possible to use C correctly, but in practice using it invites security problems, because it’s frightfully easy to make subtle but disastrous mistakes, even for experts, so there are reasons why people are moving to safe languages.
WordPress is that kind of bad. It has always been bad, though it’s somewhat less bad than it used to be. Some of its badness is a part of how it got popular.
You do not need to. Its to help people who cannot manage an ssh login update. You can use the cli to update if you can. I am pretty sure big sites will not be doing their updates from the big site.
The problem with plugins is lack of a proper framework. Its very easy to do things like pass user inputs into a query by strong concatenation because you have to make in extra effort to not do so.
That said, its no guarantee. I have seen people do things like call exec on user inputs in Django.
> has careful guidance around avoiding letting uploads be accidentally executable too.
That should be the default, not something you need to take extra care over.
I can mitigate the damage a little bit with some chattr +i, but overall, every plugin is another gigantic attack surface.
I agree. That’s one of the problems of PHP’s file-based execution model, and how the likes of Apache and nginx work. Drupal is no paragon of security, but it’s far closer than WordPress. For all its faults, even Node.js avoids this class of problem.
Sometimes the same IP address hits two or three URLs before going dead.
Sure is quiet around here at night.
As a courtesy, I try not to say more than one bad thing about WP every day. FWIW about 1/3 of installs are not on the recent 7 branch.
I've been building https://github.com/Qbix since 2008 and let me tell ya, I took a lot of great ideas from Drupal, Kohana, Symfony, etc. But never Wordpress. It's just ... a mess. Wordpress just won by being first, basically. Kind of like Bitcoin.
PS: Years ago, I hired a guy in Pakistan to work with me on some Wordpress sites, for clients. I thought that the Divi theme and basic Wordpress would be secure. Every one of those sites got pwned, badly. Sure, maybe it was the plugins. But why take the chance? In 2026 it's way past time to not have to worry about basic security.
Drupal admin was not for humans back then.
This is the problem WordPress faces - it's powerful enough for people to get stuff done on a shoestring. But the professionals who want to do things on a shoestring are also likely cutting corners elsewhere (hosting, backups, security, etc). In many cases there's money changing hands and it's easier to blame WordPress than poor decision making.
I have more sympathy for those building with it on a shoestring for personal/charitable projects who may lack the skills/experience to follow https://developer.wordpress.org/advanced-administration/secu.... They're probably better off on Wix or Squarespace.
If you run WordPress, you should be aware of this already. Either upgrade to the latest versions, constantly and quickly, or have extremely restrictive WAFs up and ready. Especially if you have any plugins installed (as those are usually where the WordPress exploits are coming from).
I'd recommend everyone unhappy only finding out about WordPress' long-standing support policy to ask their money back.
For the Wordpress RCE (nominally CVSS 9.2), it looks like many standard deployments of WordPress would be affected, barring extra mitigations. But in the case of these Hugo ones (9.3), it looks like very specific circumstances (anti-mitigations, if you will) are needed. E.g. running arbitrary builds of untrusted user content without a sandbox; running it in a GitHub workflow against PRs from untrusted contributors, etc.
Never had to worry again about sequencing updates where the update changed the database schema and I had a cluster of 6 web servers. Never had to worry anymore about long ass load times because the web servers were in 3 colos and wordpress wouldn't play nice with local read only mysql replicas. No more worries about why pingbacks and comments keep showing up in the database even those those features were turned off; at least they weren't showing up in a moderation queue, but still.
My website is hosted on 1and1 via PHP. I am guessing that this would not work for me as installation needs server access. Moving to VPS, along with transferring domain, would require more time than I would like to spend. Thanks.
Sadly, almost all language standard libraries do not provide the right abstractions for dealing with files (the primary focus is on global paths as opposed to scoped paths or file descriptors / file handles) so it's little surprise bugs like these just keep popping up every few weeks.
To eliminate these from your codebase you need to rethink and really focus on being aware of how you deal with files. If the program you're writing has root privileges then you need to be more careful about misdirected writes to /proc or other pseudofilesystems.
The documentation is a perfect reflection of the absolute mess of spaghetti code that it is, half of the methods that you will use constantly when developing plugins are undocumented, even untyped. It's literally unusable.
I know WordPress is good thanks to its ecosystem, but really, really, do NOT use it.
Site hacked within a day from install. Thankfully we have limited outogoing traffic (whitelist on proxy) so only thing exploit managed to replace is their main page with our proxy's 403 error page, but damn, how this piece of software remains so shit till this day is massive achievement in incompetence.
They also manage to fail on every level, like a simple problem of "a service behind a loadbalancer/reverse proxy" is still unsolved because devs refuse to support X-Forwarded-For header in core "because it's not official RFC", and also do not support official RFC for same feature.
However at least in principle all of the affected versions [0] could be automatically updated. Not sure if they have set it to auto-update as far back as 4.7 though.
[0] except 4.9.3 which has a bug in its automatic update mechanism.
Also, with pearcmd (if you can get to that, there's no open_basedir) and containers a novice sysadmin will publish insecure sites.
Has anything changed with AI? It did help me switch from wp to rust+dioxus, but I am a programmer.
Edit: looking at the patch itself it looks like it fixes the root cause and so it shouldn't matter what themes are doing themselves. But possibly I'm reading it incorrectly.
Not really. They are very good at describing the technical impact. Sometimes pre-condition is very rare and that reduces overall likelihood but for those few it applies, the impact still could be catastrophic. Who wants to risk it if whole business could go down?
Many GUI CVSS calculators exist just for this, it takes a minute to requalify a vuln and adjust its CVSS based on your specific environment.
This one for example is pretty basic but works well: https://www.first.org/cvss/calculator/4.0
> These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user’s organization, measured in terms of complementary/alternative security controls in place, Confidentiality, Integrity, and Availability. The metrics are the modified equivalent of base metrics and are assigned metric values based on the component placement in organization infrastructure.
This isn't just a CVSS issue: there have been a variety of attempts to reduce a risk score down to a single general number and they all end up as somewhere between marketing material, scare tactic, and junk science.
Would you say that vulnerability with CVSS score that points to low is equally important to verify and take care of than CVSS which points to critical?
The most boring reason, even if you take CVSS scores at face value, is that in many cases it is possible to leverage multiple "low" severity vulnerabilities into a massive impact.
But the bigger reason is that CVSS scores are all over the place, and the people operating roulette wheel that generates them do not have any insight into any specific person's systems.
For example, you might react differently to these scores:
- <8/10: check that your systems are indeed secure
- 8.6/10: check that your systems are indeed secure and tell your junior analyst to train on creating a custom monitoring rule for that attack and follow-up with you
- 9.8/10: double-check that your systems are indeed secure, ensure that if you had a hole another security layer would have caught it (if not, that's a problem!), set up a honeypot to get some info on the assholes that have repeatedly attacked you lately and will undoubtedly try to 0-day you in the next few hours, etc.
That is dangerously incorrect, a whole lot of themes are vulnerable. The main pre-condition, "presence of a top-level directory named 'page-xxx' like 'page-templates' in the theme's directory" is actually an official recommendation in the WordPress documentation.
See here: https://developer.wordpress.org/themes/classic-themes/templa...
> As discussed in Organizing Theme Files, WordPress can recognize page templates stored in the theme’s root folder or in a first-level subdirectory of the theme folder. *The page-templates/ folder is a common convention* for organizing global page templates, but it is not required. Page templates can also be stored in other first-level subdirectories, such as templates/ or page_templates/.
On a fresh WP install, a random user can't upload PHP files. Normally you don't even need to allow random users to register an account since avatars on comments come from gravatar anyway.
Indeed, but you don't need to upload anything as long as there's already a PHP file that allows you to execute arbitrary commands somewhere on the server, right?
Well, as it turns out, the default PHP Docker image has had such a file readily available until version 8.5 =)
- especially the functions that are explicitely exposed to be used on front-facing interfaces (ie: templating functions).
- and especially when the security flaw in question was not only raised 9 years ago but described in details on the official documentation page of the affected function
(No particular disagreement with the rest of your comment though)
When you use a dependency and a 9+CVSS vuln comes out, you read it and respect it. If you come to the conclusion that CVSS don't mean anything because there's just so many vulns, that's saying something of the dependency and your security posture.
Burn Wordpress with a flemmenwerfer, or build a hard virtualization layer around it, give it its own scoped certs, your Wordpress things will get hacked, especially if they use plugins.