Rendered at 16:31:10 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
zelphirkalt 22 hours ago [-]
These are the reason, why every easily reachable web server will be spammed with /something/something.php?somearg=someval. If I had to guess, which software on the web has been the most exploitable over all of the web's history, WP would surely be among the top candidates. Maybe right after MS Teams or Sharepoint or some stuff like that.
toyg 22 hours ago [-]
TBF, some of it is structural: if you're the most popular anything on the internet, you'll be the most attacked and the most exploited, and hence the most exploitable.
teunispeters 3 hours ago [-]
That's bad designs for you. Assume that just because it's widely visible, must mean it has exploits. (this is the only point on that list I'll call "that's bad logic" on).
acomjean 13 hours ago [-]
And it's very extensible. With that power and flexibility come exploits
fragmede 18 hours ago [-]
How many times has Google been hacked? It's not zero, but just because something is popular doesn't mean it has to get exploited. Repeatedly.
snowwrestler 16 hours ago [-]
There is only one Google and it is operated by professionals. Who do not need to disclose the vulnerabilities that they find.
Wordpress is pretty much the exact opposite of that.
ValentineC 15 hours ago [-]
We can say the same about most of open source.
It's the WordPress plugin ecosystem that's more often the security nightmare though.
AdrenalinMd 12 hours ago [-]
Yes, and if you take Linux for example, there are also tons of exploit for it.
zelphirkalt 9 hours ago [-]
True, but then again WP is a very simple system, in comparison to the Linux kernel, and WP operates on a very different level, at which it should be much easier to get right. Also WP is not written in C. Granted, PHP is not all that great either, but probably still miles ahead, when comparing it to having to write bug-free C code, as one doesn't have to deal with all the manual memory management stuff, which people, even experienced engineers _will_ get wrong at least sometimes (remember the Chromium statistics about vulnerabilities).
formerly_proven 21 hours ago [-]
nginx serves a third of web traffic.
tommica 21 hours ago [-]
Nginx also has cves.
coldtea 20 hours ago [-]
Nowhere near what WP has, and nowhere near the crap design allowing it, and the clusterfuck of bad decisions WP has that enables them...
Sohcahtoa82 20 hours ago [-]
WP is just RCE-as-a-Service.
atoav 20 hours ago [-]
Yes and Wordpress is a pile of garbage.
bartvk 7 hours ago [-]
In what sense?
sloat 4 hours ago [-]
wp-includes/class-wpdb.php
Retr0id 21 hours ago [-]
That's not really true.
Edit: wow that's a lot of downvotes! I'm surprised people can't identify a trivial reasoning failure.
dwattttt 18 hours ago [-]
You could've included a little more nuance. An interpretation of your response is "being the most popular remotely accessible software" != "the most attacked", which would need defending.
hdgvhicv 15 hours ago [-]
25 years ago alache hosted about 10 times as many sites as IIS, yet IIS was always the one being backed.
graemep 7 hours ago [-]
I imagine anyone with any knowledge of the field could see the flaws in the claim that most popular = most attacked.
Lots of counter examples and definitely no clear relationship. IMO its up to the person making the claim to provide evidence.
nom 21 hours ago [-]
The access log of public http servers is truly interesting to watch.
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.
jamesfinlayson 10 hours ago [-]
Yep I see this at work pretty regularly - a SpringBoot log file full of requests for all sorts of things (mostly WordPress but I think some IIS as well).
mitxela 21 hours ago [-]
Not success rate per request though.
lyu07282 19 hours ago [-]
It seems the most common issue of them all is an exposed .env file by that measure.
graemep 6 hours ago [-]
I think that is very likely to be common. It is an easy mistake to make if your code is in a directory the web server can read, which is common, and is usual with PHP.
traceroute66 22 hours ago [-]
> WP would surely be among the top candidates
And its closely related cousin, Joomla.
bombcar 22 hours ago [-]
Joomla makes WP look like Fort Knox.
foul 8 hours ago [-]
It has its share of vulnerabilities but flaws in core are rarer, more (a lot more) (i swear to god a LLM would be better) in the modules ecosystem. Also like most CMSes they are still vulnerable to what i call the "webapp bug" (you install this blob on a hosting that should not be aware of what you dump on there and allows you to run a php file on any subdir, while with a CMS, whatever you use, only a very limited number of files should be allowed to be reached, executed or even included in any php call).
bombcar 5 hours ago [-]
All I remember with Joomla! is that it was really, really susceptible to the “plugin we use is abandoned and not updated and the new version of core is completely incompatible” causing everyone to run various out of date packages with stupid security layered on top. Web application firewalls are an abomination.
rmoriz 18 hours ago [-]
Never forget PHPnuke and phpmyadmin
pmlnr 3 hours ago [-]
The internet was different when those two were conceived.
reaperducer 21 hours ago [-]
If I had to guess, which software on the web has been the most exploitable over all of the web's history, WP would surely be among the top candidates.
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.
chrismorgan 12 hours ago [-]
WordPress’s security model is distilled insanity, concentrated vulnerability. You’re supposed to give your site write access to its code, which turns almost any vulnerability into complete and persistent site takeover. Not to mention how many things will store code in the database and execute it from there, and how much of its design is fragile as anything, and how many plugins, often popular ones, do obviously dumb things that would not have been possible in most ecosystems.
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.
graemep 6 hours ago [-]
> You’re supposed to give your site write access to its code
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.
chrismorgan 1 hours ago [-]
> That should be the default, not something you need to take extra care over.
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.
trollbridge 4 hours ago [-]
I support plugins for a client that require write access to their homedir that contains their code. They use it to hold temp files!
I can mitigate the damage a little bit with some chattr +i, but overall, every plugin is another gigantic attack surface.
imnotr0b0t 17 hours ago [-]
Yeah, I agree that with the right expertise you can keep WordPress safe, and the White House is a good example of that. But the problem is the WP ecosystem and defaults push people without that expertise to install plugins and themes, and "if you know what you're doing" is the exception, not the rule for its user base
spogbiper 21 hours ago [-]
> If you know what you're doing, WordPress fine.
Probably true, but for whatever reason Wordpress seems to attract an awful lot of people that do not know what they are doing
otherme123 20 hours ago [-]
Anecdote: we contracted a web page, and the guy started saying "it would be a Wordpress. It has very bad press, but it's because it is widely used". Ok, we start developing in the latest version of php, and soon he say "we have to go down a couple phpversions, because x pluging don't work in the latest". Requested version had a dozen critical CVEs. Plugin in question did something really basic, like a preview card with OpenGraph data, or something like that. Something a junior could code in a day.
And that is insecure Wordpress: people lego-mounting sites without touching code, only with plugins.
type0 20 hours ago [-]
> 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
yangm97 19 hours ago [-]
Pros: it has a low entry barrier
Cons: it has a low entry barrier
zelphirkalt 21 hours ago [-]
I think the problem is of another nature:
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.
lol. From nav directly to some mp4 video?? Not a URL of a page, which then would display the video, but a URL directly to a video? Good that my noscript blocked media on that domain!
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.
nkozyra 21 hours ago [-]
> If you know what you're doing, WordPress fine
If you know what you're doing, a loaded gun without a safety is fine, too. But you have the option, why not pick the unloaded one with a safety mechanism?
Zak 19 hours ago [-]
Manual safety or not is a real debate among people who carry pistols for self defense and law enforcement, and no manual safety is the majority position. The reasoning is that an extra step when the user needs the pistol in an emergency is problematic, a properly designed pistol can only fire if the trigger is pulled, and a properly designed holster makes pulling the trigger impossible until the pistol is drawn. Nobody seriously advocates carrying an unloaded pistol for those purposes, and only lunatics advocate having people who don't know what they're doing carry pistols.
It's not a great analogy to Wordpress, which attempts to provide as much capability as possible in a CMS while requiring as little expertise from the user as possible. Vanilla Wordpress, kept up to date is pretty safe. Plugins are just a click away though, and using plugins safely requires evaluating each plugin's risk profile and track record individually, which is real sysadmin work.
ImPostingOnHN 17 hours ago [-]
If the only gun you would choose to have is an unloaded one, you could just not have it, save a few hundred dollars, and lose no marginal utility.
BorisMelnik 21 hours ago [-]
to be fair it is one of the top CMS's on the web (probably won't be in 2027) and its PHP / Mysql which in history have been very exploitable.
n3rd1990 30 minutes ago [-]
[dead]
beezle 19 hours ago [-]
"WordPress 7.1.2 has been released containing a fix for the vulnerability, and as a courtesy to users on older branches the fix has been backported to all branches back to 4.7"
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.
jeroenhd 1 hours ago [-]
WordPress doesn't to LTS. WordPress usually backports security fixes to older branches (like the 6.x branches) but going all the way back to 4.x isn't something they'll do for every fix. Who knows how many bugs lie in wait for older versions that are out of support.
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.
EGreg 17 hours ago [-]
There was a time I looked up to Matt Mullenweg, but never to Wordpress.
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.
tweetle_beetle 1 hours ago [-]
A tale as old as time... I made money by outsourcing to third party labour to a much cheaper country than my own, using a third party low code theme builder and third party plugins I didn't vet. All of my customers got hacked.
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.
pmlnr 3 hours ago [-]
WP won by having a very simple but flexible admin page.
Drupal admin was not for humans back then.
krapp 17 hours ago [-]
Wordpress wasn't even first, Movable Type was the big thing before it.
segfaultbuserr 16 hours ago [-]
WordPress began as a FOSS replacement of Movable Type after Moving Type 3 made the controversial decision to change its licensing fee for some features. So it was like a Unix/Linux situation.
mgkimsal 16 hours ago [-]
That was Perl though, wasn't it? mod_perl more specifically, IIRC. That alone relegated to a small pool of users.
cyphar 12 hours ago [-]
This kind of bug pathology is incredibly common in all sorts of programs and is the reason (disclaimer: self-plug) I wrote libpathrs[1].
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.
Is there a simple quick fix for older wp installs? I dont want to go through 20 meetings and two weeks of discussions
random_savv 22 hours ago [-]
I am so happy that I asked Codex to rewrite our website as Hugo templates which allowed us to statically host it and get rid of Wordpress. So much stress gone!
woah 21 hours ago [-]
You can make the most intricate drag and drop admin interfaces to allow the editor to customize everything, and they will still call you to put up every post, so might as well go static
rsolva 9 hours ago [-]
This! My customers love that they can call and email me to update their websites, not having to remember usernames, passwords and how the publish interface works. Wordpess or static does not really matter in many cases.
foco_tubi 3 hours ago [-]
We are in a big migration project at work and one of the goals is to rewrite all 30 or so WordPress sites into Astro. It’s so much fun to cut out all the blackbox plugins with paid features and cruft, and just have something work as I intended. I’m stoked.
toast0 22 hours ago [-]
When I finally got approval to rewrite the company blog from Wordpress into something that was mostly static, it was the best week. I used PHP to do mobile/desktop and language selection, because PHP is pretty useful, and it can be pretty fast and secure if you only do simple things.
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.
themeiguoren 21 hours ago [-]
Is there a good replacement for wordpress comments? That's the one thing holding me back from porting at the moment.
karthikeyankc 18 hours ago [-]
I had the same itch when I ported my personal blog from WordPress to Astro. I built a fully customisable self-hosted comment system called Discuss. It's got a dashboard and tokenized UI customisation. Pretty light weight too. It's available here - https://github.com/karthikeyankc/discuss . Do give it a spin or fork it. Would love to hear your feedback.
alok-g 13 hours ago [-]
Looks nice.
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.
karthikeyankc 11 hours ago [-]
Ah okay, yeah, you'd need server access. Perhaps a one click install to cloudflare or vercel could've helped you. They offer generous free tiers and for personal blogs that should be good enough. But if your website has high traffic, free tiers might not work thou. Either way, this flexibility should help others like you. I'll see if I can work on one-click setups for cf and vercel this weekend. Thanks for checking it out.
I think you can render Disqus on static websites, but Disqus is its own piece of crap so not sure you'd want to.
alok-g 13 hours ago [-]
May I know how much token costs came out to be for this? Also, how did it handle Wordpress plugins? If you have comments on the website, how did you handle those and spam detection? Thanks.
vntok 22 hours ago [-]
Sorry in advance if you were joking, but for readers who aren't in the know: Hugo had, in fact, two 9.3 CVSS vulnerabilities just 11 days ago...
To be clear, those are CVEs in the tooling, not in the generated static sites. Not great, but very different from this WordPress CVE
BadBadJellyBean 18 hours ago [-]
I have full control over the inputs for hugo and the output is pure static HTML. It's better if there are no CVEs but I really don't sweat these. My Hugo template runs 100% pure CSS and no JS.
benregenspan 16 hours ago [-]
This seems like a really good example of Base CVSS scores not telling us much on their own.
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.
jklinger410 21 hours ago [-]
[flagged]
Exoristos 18 hours ago [-]
Codex wrote you a website, or wrote you a pluggable CMS usable and configurable by non-coders?
It's crazy to me that WP still doesn't make use of proper function type declarations, 11 years after they were added to PHP.
paulryanrogers 19 hours ago [-]
Inertia. The minimum PHP version that WP needs--in practice--is PHP 7.0.
mgkimsal 15 hours ago [-]
Would have been nice to have a test demonstrating the fix.
vntok 23 hours ago [-]
Ironically, this 9 years old comment on the official documentation page of one of the affected functions perfectly describes both the nature and remediation of this major security flaw:
> 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).
Ahahah I remember to have patched themes for clients by hand, years ago. A different time, where a core team would for whatever reason leave security holes around to be sure you need three frameworks around their pile of dung code.
IshKebab 20 hours ago [-]
I wonder if they'll add a `locate_template_safe()` function to "fix" it. :D
brinepot 4 hours ago [-]
Classic WordPress. Path traversal leading to conditional RCE always feels like a blast from the past.
Luker88 8 hours ago [-]
Wordpress was the go-to for people who did not know programming and wanted a website.
Has anything changed with AI? It did help me switch from wp to rust+dioxus, but I am a programmer.
pmlnr 3 hours ago [-]
It's wix and squarspace now.
foco_tubi 3 hours ago [-]
and Webflow
johsole 46 minutes ago [-]
I have a client that uses webflow and they author everything in the edit mode and the site is constantly breaking. They just email me to update everything now.
Sweepline 6 hours ago [-]
Ah, WordPress security. Just when you thought you patched everything, a new unauthenticated RCE drops.
iLoveOncall 22 hours ago [-]
WordPress really is a piece of garbage software, and if you've ever developed plugins for it it is soooo apparent.
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.
whycome 23 hours ago [-]
hmm, this may be why i just saw an unexpected update to a very old theme.
patrickdavey 22 hours ago [-]
It's not clear to me: do we need to both apply the patch _and_ check if our themes are vulnerable, or just apply the patch?
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.
system2 24 hours ago [-]
pearcmd.php must exist, and register_argc_argv must be on, not common with hosting providers. But I am assuming the other themes and meeting conditions possibly affect a lot of WordPress sites.
dofm 23 hours ago [-]
As the article points out, one issue is that the official Docker container for PHP has this configuration.
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.
foul 23 hours ago [-]
pearcmd and register_argc_argv are just examples. get_page_template was unsanitized in some themes, that's the flaw, you could then combine it with one of a million unauthorized file upload in wordpress plugins to try and eval code. An attacker would like to use upload + this chain of requires (instead of just uploading a php) because of hardened configuration and the pwn can go unnoticed in the logs.
Also, with pearcmd (if you can get to that, there's no open_basedir) and containers a novice sysadmin will publish insecure sites.
PunchyHamster 19 hours ago [-]
It's a wonderful piece of software. We've had one of our clients wanting us to "just provide a simple PHP install for wordpress, just hosting" (among some more complex java stuff company wrote for them).
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.
tptacek 23 hours ago [-]
These CVSS scores don't mean anything and it would be better for everyone if they stopped showing up in headlines. This is a somewhat situational Wordpress RCE that impacts only a couple themes.
dofm 23 hours ago [-]
Not sure if it’s a couple. Devs routinely make heavily edited copies of the core themes so there will be many, many unpublished themes that use the “page-“ prefix for templates; it was (is?) a reasonably common convention.
(No particular disagreement with the rest of your comment though)
paulez 23 hours ago [-]
This score specifically means that given some specific conditions, anyone can execute code over the network on a vulnerable WordPress setup. Is this not true?
tptacek 23 hours ago [-]
I'm not saying that the vulnerability isn't severe or important to people running Wordpress, only that CVSS scores are literally a Ouija Board that can come out to whatever the user wants them to.
ferngodfather 22 hours ago [-]
Yeah give me a vuln and I can make it anything between a 2 and 8 quite easily. I routinely see 10s that are "Critical 10.0 CVE (but only if you're using X language with X setting changed from default, and the attacker can MiTM your traffic)"
nicce 23 hours ago [-]
> CVSS scores are literally a Ouija Board that can come out to whatever the user wants them to.
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?
akerl_ 23 hours ago [-]
So if I get a 9.8 that doesn't apply to my usage, what is the CVSS score doing for me?
cleansy 23 hours ago [-]
Published CVSS is a base score that gives you a hint of how important the analysis of a vulnerability is to prioritise the patching or mitigation. What you see on websites is only ever the base spiciness so to speak. If you have for example wordpress only running in an isolated environment behind internal firewall rules you‘d downgrade it accordingly. It’s a imperfect metric but so far the best we have to signal priorities. It’s all described in its spec that no one seems to read and websites also communicate it badly.
akerl_ 21 hours ago [-]
CVSS is impossible to communicate effectively. We don't need a metric; I'm already going to have to read and assess the vulnerability to decide how I actually want to assess the risk given my infrastructure, so the number's not doing me any good.
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.
nicce 21 hours ago [-]
> We don't need a metric; I'm already going to have to read and assess the vulnerability to decide how I actually want to assess the risk given my infrastructure, so the number's not doing me any good.
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?
akerl_ 21 hours ago [-]
Yes. I believe that using CVSS scores as a first pass to decide which vulnerabilities to review is risky.
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.
vntok 23 hours ago [-]
Yes. It's amazing how supposedly security professionals only take the base score "as is" and never adjust.
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.
> 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.
vntok 23 hours ago [-]
You need to reason about both probability and impact, not one or the other. In your example, it just means that the probability is very low, perhaps even down to 0 in your specific case. But even at a low probability, the impact of the vulnerability remains very high so it helps you reason about it.
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.
23 hours ago [-]
bombcar 23 hours ago [-]
My assumption is that any Wordpress setup whatsoever allows anyone to execute code remotely.
6c696e7578 23 hours ago [-]
Indeed, it's a foothold into a network.
0xbadcafebee 11 hours ago [-]
Themes whose banner you can google for. If those sites have pearcmd.php is available, they're using the official Docker php image, and/or using default cPanel, the site is vulnerable, afaict. Basically a drive-by exploit for anyone with some google-fu.
vntok 23 hours ago [-]
> This is a somewhat situational Wordpress RCE that impacts only a couple themes.
reply
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.
> 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/.
AlienRobot 17 hours ago [-]
I'm not sure I understand. That's the main pre-condition... to include an arbitrary PHP that is already in the server.
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.
vntok 5 hours ago [-]
> On a fresh WP install, a random user can't upload PHP files.
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 =)
dawnerd 23 hours ago [-]
Yeah not sure why you’re being downvoted when the built in themes are vulnerable as is the default docker image pre php8.5 which a lot of people use as a base and I bet a lot of hosting providers use as well behind the scenes.
TZubiri 22 hours ago [-]
It's crazy how many users are standing by this take. Not only is a 9.8 CVSS critical, even if it doesn't affect your config, you should trash any dependency that has so many 9+CVSS vulns that you become numb to them.
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.
lyu07282 19 hours ago [-]
There is always this idea that the most used software also has the most vulnerabilities, but I think its an interesting question if this is actually true in light of AI. Like humans wouldn't spend a combined 100,000 hours or something looking at some obscure code, but an AI might do the equivalent across the entire ecosystem. Like if this idea is really true, we should see CVE's go into the millions per year soon, although I guess for now it's still bounded by compute budget but I question if the initial premise is true to begin with or if PHP is just shit. /s
Roscius 19 hours ago [-]
Using WordPress is like chewing discarded gum you find lying in the street.
Wordpress is pretty much the exact opposite of that.
It's the WordPress plugin ecosystem that's more often the security nightmare though.
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.
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.
And its closely related cousin, Joomla.
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.
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 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.
I can mitigate the damage a little bit with some chattr +i, but overall, every plugin is another gigantic attack surface.
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.
All this crap. And this is only what is loaded right out of the box. I haven't even allowed their shitty scripts to run yet.And the navigation font is tiiiny. What a horrendous design.
When I click on some navigation link, it wants to go to:
lol. From nav directly to some mp4 video?? Not a URL of a page, which then would display the video, but a URL directly to a video? Good that my noscript blocked media on that domain!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.
If you know what you're doing, a loaded gun without a safety is fine, too. But you have the option, why not pick the unloaded one with a safety mechanism?
It's not a great analogy to Wordpress, which attempts to provide as much capability as possible in a CMS while requiring as little expertise from the user as possible. Vanilla Wordpress, kept up to date is pretty safe. Plugins are just a click away though, and using plugins safely requires evaluating each plugin's risk profile and track record individually, which is real sysadmin work.
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.
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.
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.
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.
Drupal admin was not for humans back then.
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.
[1]: https://github.com/cyphar/libpathrs
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.
https://app.opencve.io/cve/CVE-2026-89259
https://app.opencve.io/cve/CVE-2026-89258
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.
https://github.com/WordPress/wordpress-develop/commit/9c4e85...
> 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
Has anything changed with AI? It did help me switch from wp to rust+dioxus, but I am a programmer.
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.
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.
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.
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.
(No particular disagreement with the rest of your comment though)
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?
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.
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.
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 =)
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.