World Food Programme (WFP)

WordPress.org blog: WordPress 7.1 Beta 4
by Benjamin Zekavica on 29th July 2026 at 15:30
WordPress 7.1 Beta 4 is ready for download and testing! This beta release is intended for testing and development only. Please do not install, run, or test this version of WordPress on production or mission-critical websites. Instead, use a test environment or local site to explore the new features. How to Test WordPress 7.1 Beta 4 You can test WordPress 7.1 Beta 4 in any of the following ways: WordPress Beta Tester PluginInstall and activate the WordPress Beta Tester plugin on a WordPress install. Select the “Bleeding edge” channel and “Beta/RC Only” stream.Direct DownloadDownload the Beta 4 version (zip) and install it on a WordPress website.Command Line (WP-CLI)Use this WP-CLI command: wp core update --version=7.1-beta4WordPress PlaygroundUse a 7.1 Beta 4 WordPress Playground instance to test the software directly in your browser. No setup required-just click and go! The scheduled final release date for WordPress 7.1 is August 19, 2026. The full release schedule can be found here. Your help testing Beta and RC versions is vital to making this release as stable and powerful as possible. Thank you to everyone who contributes by testing! Find out what’s new in WordPress 7.1: Read the Beta 1 announcement for details and highlights. How important is your testing? Testing for issues is a critical part of developing any software, and it’s a meaningful way for anyone to contribute – whether or not you have experience. Details on what to test in WordPress 7.1 are available here. If you encounter an issue, please share it in the Alpha/Beta area of the support forums. If you are comfortable submitting a reproducible bug report, you can do so via WordPress Trac. You can also check your issue against this list of known bugs. Curious about testing releases in general and how to get started? Follow along with the testing initiatives in Make Core and join the #core-test channel on Making WordPress Slack. What’s in WordPress 7.1 Beta 4? WordPress 7.1 Beta 4 contains more than 114 updates and fixes since the Beta 3 release, including 51 in the Editor and 63 in Core. Each beta cycle focuses on bug fixes, and more are on the way with your help through testing. You can browse the technical details for all issues addressed since Beta 3 using these links: GitHub commits for 7.1 since July 22, 2026 Closed Trac tickets for 7.1 since July 22, 2026 Beta 4 brings a round of fixes that make the editor smoother to work with. Notes now stay reliably tied to the passage they refer to, and tagged people are displayed cleanly and clearly. A Beta 4 haiku Testers lend their eyes,edge cases hide in plain sight—Patch, rebuild, refine. Props to @krupajnanda for preparing this post and @annezazu, @wildworks, @amykamala for proofreading and review. Join us for the launch of WordPress 7.1 at WordCamp US 2026, August 16–19.
WPTavern: #227 – Maciek Palmowski on Testing Secure WordPress Hosting: Does the Marketing Match Reality?
by Nathan Wrigley on 29th July 2026 at 13:00
Transcript [00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley. Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, testing secure WordPress hosting, does the marketing match the reality? If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players. If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox, and use the form there. So on the podcast today we have Maciek Palmowski. Maciek is based in Poland and works at Patchstack, one of the companies in the WordPress ecosystem dedicated specifically to security. At Patchstack, Maciek collaborates with other security professionals on industry reports, bug bounty programmes, and solutions for agencies, product owners, and hosting companies aiming to secure their client sites. I met up with Maciek at WordCamp Europe, and we discussed his presentation there. It examined the claims of secure hosting made by many WordPress hosting providers. He describes how Patchstack set out to test these claims with real world penetration testing, using 30 known plugin vulnerabilities across multiple hosts. Employing standardised methodologies and validating their results independently. The findings are sobering. The majority of WordPress specific attacks still get through, and there’s a significant gap between the marketing hype and real protection. The conversation starts with Maciek’s background, and how his journey in the WordPress security space led to a focus on the promises made by hosts. From there, the discussion gets into the research approach, the selection of well-known vulnerabilities, consistent testing across different hosting environments, and the surprising result that even hosts with identical security tooling produce drastically different outcomes, showing it’s not just about the tools you use, but how you use them. We talk about the Swiss cheese model of security, every layer will have holes, so you need multiple overlapping defences, and honest communication from hosts about their limitations. We also explored whether an industry-wide standard, or badge, for secure hosting is feasible or even desirable, given how easy it is for strong marketing claims to outpace reality. AI also enters the conversation, increasing both the speed and sophistication of attacks, and making patching, and processes, even more important, especially as the volume of vulnerabilities continues to rise and the time to exploitation drops. If you’re interested in understanding what secure hosting really means, how to ask intelligent questions of providers, and the realities of WordPress security in 2026, this episode is for you. If you’d like to find out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well. And so without further delay, I bring you Maciek Palmowski. [00:03:56] Maciek Palmowski: I am joined on the podcast by Maciek Palmowski. Hello Maciek. Perfect. You did great. [00:04:01] Nathan Wrigley: For some reason, your name has got into my head. A lot of the people that I interview, I struggle with their name, and I continue to struggle, but for some reason, I established many years ago that was how to say your name. And I think I’ve done it correctly ever since then. [00:04:16] Maciek Palmowski: Yes you did. You’re almost having the typical Polish accent, so you’re doing great. [00:04:21] Nathan Wrigley: So we are at WordCamp Europe, which is in Krakow, or Krakow, I don’t know how. [00:04:26] Maciek Palmowski: Krakow. [00:04:27] Nathan Wrigley: Thank you, that was good. And the reason Maciek is correcting my pronunciation is because Maciek is actually from Poland, which I suppose means that this is a bit of a, well, it’s like a home game to you. [00:04:37] Maciek Palmowski: In a way so, but it’s also like a bit of a shame because I do like travelling when WordCamp Europe’s are happening. And, you know, just hopping on the train and going to Krakow, it was like a, I mean it’s cool because, yeah, the venue’s amazing, everything is great, but still I’m staying home, so yeah. [00:04:53] Nathan Wrigley: Yeah, mixed feelings. So Maciek has done, or is going to do a presentation at WordCamp EU. Have you done it yet? [00:05:02] Maciek Palmowski: I will do it tomorrow. [00:05:04] Nathan Wrigley: Okay. And are you all set, are you one of these like really prepared people that has all the slides done, or are you last minute? [00:05:11] Maciek Palmowski: Everything is ready. I already did one version of it at the Checkout Summit in Palermo, so. [00:05:17] Nathan Wrigley: Oh I see. So you’ve had a sort of dry run of elsewhere. [00:05:19] Maciek Palmowski: Of course. [00:05:20] Nathan Wrigley: Excellent. So the presentation, which is going to be the focus of today’s conversation, is called Testing the promise, does secure hosting deliver? And I may as well read the blurb because it was a reasonably short one. So it says, secure hosting, in quotes, is everywhere in WordPress. What does it actually protect against? We put this claim to the test with real penetration testing. 30 known vulnerabilities, multiple hosting providers, standardised methodology, validated by independent observers. The findings reveal a critical gap between marketing and reality. WordPress specific attacks succeed most of the time. That’s quite an alarming sentence. This talk shares the complete results and explains why generic security fails. So, we’ll get into that in a moment. But as with all people, when I’m talking to them about security, I guess it’s good to establish who you are, and what your credentials are and what you’ve done, and how is it that you get to talk about security with authority. So over to you really, a little moment to give us your bio and tell us about you. [00:06:20] Maciek Palmowski: Okay. So I work at Patchstack, and Patchstack is one of those few companies in WordPress space that are doing a lot in terms of security. We are constantly running this bug bounty for the whole ecosystem. We have quite a few solutions for both clients and hosting companies, and I work there right now. My role is, if I remember, the Growth Team Engineer, something like this. But yeah, I do spend a lot of time working with other security people. So when we are working on all the reports, when we are checking the data, I’m also part of those teams that are working on it. So yeah, I think I know a thing or two about what is happening behind the scenes when it comes to WordPress security. [00:07:02] Nathan Wrigley: Yeah, thank you. Always good to get that established though, right at the outset. Patchstack is a company which is not a host though, I suppose that’s important to mention at the beginning. It’s a company which is in the security space, very much in the WordPress space, but perhaps more broad than WordPress, I’m not sure. But not a hosting company. But obviously your presentation focuses its aim on hosting, I guess because that’s one of the places where the claim about security is most often made. You know, you’ll go to a, the landing page of hosting Company X, and you’ll see somewhere fairly near the top, secure hosting, or something along those lines. And you’ve decided to examine that in fine detail and look at these 30 vulnerabilities. I guess really just tell us about this test and what it is that you decided to do and some of the items that came out of that. [00:07:50] Maciek Palmowski: Okay, so maybe let’s start with how it even started, right? Because there was a trigger. At some point we published one report about the state of WordPress security. We tweeted about this. We got the response from none other than Matt Mullenweg, who kind of asked a very interesting question, but isn’t hosting companies taking care of this already? And this was, kind of at this moment when we were, we thought that we know the answer that, no they aren’t. But to be honest, we didn’t have any broader proof about this. We knew how it’s working at some hosting companies, but we could say that it was more of an anecdotal evidence that we had. So this was kind of the trigger that made us, okay, let’s check this. But not with one partner or two partners, but with more hosting companies. So we did this research twice. First we just did kind of a beta run because we weren’t sure about the result and, is it even a good idea to go deeper inside of it? And during our first run, we were already very surprised because like the methodology was very simple. We just installed vulnerable plugins and we checked if we would be able to use the vulnerability. Because if the hosting is claiming that, we got your back, we are making your website secure, we have this and that, this means that they should protect against it. So it was as simple as that. And when we were doing our first test, we were quite surprised because we saw, if I remember, that 80% of the attacks went through. 80% of the attacks. So our first reaction was, okay, we are doing something wrong. Okay, this was only few hosting companies, less plugins, but still the result were so surprising for us because we thought that, okay, that the problem exists, but it’s not that big of a problem. But it was. So that’s why we did the second test. And this is about which the, my talk will be mostly when we tested more hosting companies, more plugins. And we saw that the problem still exists. Of course it was, in some cases 70 few percent. So still, it’s a huge problem, especially if we are talking about some companies that are literally saying, you don’t have to install anything additional when it comes to security on your website. We got your back. They don’t. We found a lot of interesting things, but still the problem exists. [00:10:21] Nathan Wrigley: So just deep diving into that a little bit, when tests like this are done, there’s obviously, the claim might be levelled, you know, obviously Patchstack would, this kind of maybe benefits Patchstack, if you know what I mean. So let’s just sort of clear up what the test involved. So presumably the plugins that you chose are ones where it’s publicly known that there’s a vulnerability in this component or this particular file or what have you. So is that the case? This is stuff that, longstanding understanding that there’s a problem here. [00:10:51] Maciek Palmowski: Yes. We only use the plugins that we had all the proof of concepts. So we know how have the vulnerability happened, what was the attack vector? They were all reported through our bug bounty programme, because that’s why we had the proof of concept. Yeah, and that’s it. It was, like I said, it was as simple as that. We had a really broad mix of all the plugins. How many? It was 30 something of those plugins, if I remember. Different ones. Some were connected with WooCommerce. So, like a very broad selection of them. Different vulnerability types. So we try to mix it up as much as possible. [00:11:27] Nathan Wrigley: Was the situation for each hosting company the same though? In other words, was the things that you did in one hosting environment the exact same as you did in another hosting environment? No. You mixed that up a bit as well. [00:11:38] Maciek Palmowski: I mean we used all the same plugins, like the methodology was always the same. But we got totally different results. Even if, and this was one of the most interesting findings, because very often hostings will put a logo of some company that takes care of security. For example, say, Cloudflare. And despite using the same stack for security, they got different results. [00:12:02] Nathan Wrigley: Interesting. [00:12:03] Maciek Palmowski: So it turns out, in many cases, it’s not about the tools that you are using, it’s how you are using them, which was very interesting. And we did everything. We tried to enable every feature, every security features on those hosting, to kind of give them a chance to kind of make sure that they are defending the most as they can. And the result in most cases was very simple. They were doing quite well with the generic ones like uploads, patch reversal, things like this, which are very generic in PHP. But with those WordPress specific attacks, they just failed miserably. [00:12:44] Nathan Wrigley: That’s so interesting. The word secure hosting, which you’ll see all over the place, it feels a bit like using the word healthy on food. There’s no real definition of what healthy is. You know, a company selling chocolate could probably pretend that it’s healthy compared to something else. [00:13:04] Maciek Palmowski: Like here, healthy chocolate is exactly, like in some cases secure hosting. [00:13:07] Nathan Wrigley: Right. So what do you take from this then? I mean basically, is your survey saying that whenever you see the word secure hosting, be sceptical? [00:13:16] Maciek Palmowski: Yes. [00:13:16] Nathan Wrigley: Okay. As simple as that. [00:13:18] Maciek Palmowski: It’s as simple as that. Because one of the things that we were always promoting, security is not a plugin, it’s not a one button thing. Security is a process. It’s layers. And that’s kind of why we, especially after this report starting kind of using the term, Swiss cheese layer model. Because every layer will fail in some way. That’s also why you still need all the security solutions that hosting provides, because they do have a lot of interesting solutions against those generic attacks. Because they’re doing really great when it comes to those generic ones. And that’s great because some of the attacks will be already dealt with. So whatever passes to the second layer, it has less work to do because a lot of it was already stopped at the first layer. The second layer should be something more WordPress specific that understand what is installed. And with this it can catch also a lot of it. But still, you have to be prepared that, because again, this layer also isn’t perfect. Because there are zero days vulnerabilities, there are custom code, there are a lot of things that can happen, that your website will be hacked. I mean, weak password. Simple as that. That’s why you also need to have a layer, which will be more of what to do if everything else fails. Because you do need to know that you have to inform your clients, all the GDPR related things. How to kind of, I don’t know, use the backups. In short you need to have procedures. You have to be prepared before the attack happens. Because let’s be honest, asking some lawyers about, what should we send to our clients? The moment when, well, the milk is already spilled. It’s like the worst moment to think about it. Especially that, hey, your website was just hacked. It’s not just a technical problem, it’s also a business problem. Again, with those GDPRs and everything. So yeah, the more layers, the better. You still need to remember, every layer can fail in some place. That’s why the more, the better. [00:15:29] Nathan Wrigley: Would you like to see a standard industry-wide definition of something like a badge or, I don’t know, let’s say for example, that you put the word secure hosting on your website, that has to actually stand for something. Because obviously coming from the background that you do with a broad oversight on what that is, you have a vast amount of data at your disposal. You can see all of this kind of stuff. But every company can make the claim that our food is healthy, our hosting is secure. But I don’t know, in the model that we’ve got where any company can put anything they like on a website, I don’t really know how you do that, but some sort of accreditation or something. I don’t know. [00:16:08] Maciek Palmowski: Honestly, it’s really difficult because as I said before, a lot of companies using the same tools were failing in different ways. So that’s a problem. On the other hand, like sometimes the, those stupid things like weak passwords. And it doesn’t matter that you had a, let’s call it a certified secure hosting, you still failed because your password was weak, you know? So, also certificates like this can backfire because some people might think I have a secure hosting, I don’t have to worry about things. And then you have 10 admin accounts for everyone. [00:16:43] Nathan Wrigley: Is there is there something, some mark of that description that you, personally, that you go looking for though? Is there some credentialing system which you think actually does carry some weight? So for example, I don’t know, like the insurance space or the accountancy space or something like that. You have to have that accreditation in order to do business. Is there something like that? Is there a mark which hosting companies can apply for which you could have some confidence in it? [00:17:13] Maciek Palmowski: Okay. So for sure one of those things would be, and I don’t want to say it as an advertisement, but it is a thing that you see that the hosting is thinking a bit better about security, kind of looking if they are a Patchstack partner. Because this kind of automatically means that they do have this WordPress, the security WordPress layer. So that’s already a good sign. So yeah, I would start with this. I think that’s kind of one of the simplest ways, but again, Patchstack isn’t the only solution that does it. So looking for partners of such companies might be the best way to start because having those Patchstack aware security solutions built in, into the hosting is a really good sign. [00:18:05] Nathan Wrigley: Yeah, okay. Now, the inevitable conversation in the year 2026 is AI. It doesn’t matter which area of WordPress you’re talking about. AI manages to get in somewhere. I am presuming that the landscape in terms of security only got more complicated because of AI. Because I’m imagining that attacks that needed to be conceived by a human can now be conceived in a fraction of the time by an AI agent. But not just one, maybe a dozen or a thousand or whatever it may be. Let’s just talk about that for a moment. It feels almost as if AI and security are like, that’s a real systemic problem for the future of the entire industry. Because these things can happen so fast, a plugin vulnerability is discovered by an AI agent. It then discovers the attack surface, implements the attack all in a matter of seconds, possibly. What’s the position? Like, how do we stay calm basically in the year 2026? [00:19:09] Maciek Palmowski: So the problem already existed around a year ago, because a year ago when we did our State of WordPress Security Report, we already saw that vulnerabilities are being used after around five hours after kind of being published. So five hours. That’s the first thing, because we still have a lot of people that say, yeah, just update your WordPress weekly and you’re good to go. No, you’re not. Looking at this number, you have five hours. [00:19:39] Nathan Wrigley: Okay. Let’s just parse that at the moment. So the vulnerability is published. So there’s a whole thing there, like the vulnerability may well have been discovered prior to being published, so that’s a whole other thing. [00:19:52] Maciek Palmowski: So first the vulnerability is discovered. Then at least how it works on, with our bug bounty. We inform the vendor they have, let’s say around a month to fix it. When they fix it, we publish everything and, yeah. [00:20:09] Nathan Wrigley: Okay, so from the moment you publish, you can then detect that that is being leveraged within a space of five hours. [00:20:17] Maciek Palmowski: Yes. [00:20:17] Nathan Wrigley: Okay, that’s really interesting. [00:20:19] Maciek Palmowski: But there is a problem. There is a really big problem. So if the vendor doesn’t respond, we still publish it. [00:20:26] Nathan Wrigley: How long do you give them? Is it like. [00:20:27] Maciek Palmowski: It is the one month. [00:20:28] Nathan Wrigley: Okay, thirty days. [00:20:30] Maciek Palmowski: Of course, if they reach out that there is some problem, they need like extra days. But in most cases, we’re talking about the vendors that just don’t respond at all. We publish it anyway. But the problem is that, from all the vulnerabilities that were discovered last year, 50% weren’t patched at the moment of publishing about it. 50%. [00:20:50] Nathan Wrigley: So half of the plugins where there was a known vulnerability, the vendor had been informed, they’d had this 30 day window. Half of them made no amendment to their code. [00:21:01] Maciek Palmowski: Exactly. [00:21:02] Nathan Wrigley: Okay. Wow, okay. [00:21:03] Maciek Palmowski: Again, going back to this classical, yeah, just update your WordPress regularly. No. [00:21:08] Nathan Wrigley: No, that’s a really different surface, isn’t it? [00:21:11] Maciek Palmowski: It doesn’t work on so many levels. Because not only the problem is with the fact that, still the famous five hours, which also, it’s five hours now. It was much longer a few years ago. On the other hand, yeah, most of those, I mean around half of it aren’t patched, so the attacks will happen quicker than it get patched. So yeah, there is a lot of problems like this. And also the problem with security is that it’s really difficult to sell. [00:21:39] Nathan Wrigley: It’s like insurance, isn’t it? [00:21:40] Maciek Palmowski: Yeah. But insurance, okay, you see your car, your house, it’s real. It’s real, you kind of see it. The only category of websites that it’s much easier to kind of explain is e-commerce. [00:21:54] Nathan Wrigley: Yes. You can feel the tightening on your wallet. [00:21:56] Maciek Palmowski: They literally see the money. They can kind of really, okay, one hour of my website not working equals this and this Złotys or Euros or whatever. So that’s easier to explain. But for most people, yeah, security, meh. [00:22:11] Nathan Wrigley: Yeah. That’s really interesting. So you mentioned, about this survey, you mentioned that fully 80% of your penetration testing resulted in something. What were the sort of, the high level items? Apart from that 80% figure. What were some of the other, because you said there were a few interesting things that dropped out of it. Can you mention anything else? [00:22:31] Maciek Palmowski: So like I said, one of the things was that we learned that, despite using the same tools, we got different results. That was also a surprise for us. [00:22:39] Nathan Wrigley: So let’s just figure that out. So at hosting company A, we’ve got a WordPress website with the same collection of plugins in. Hosting company B, exactly the same as far as you can make it the same, but things are different. [00:22:52] Maciek Palmowski: No, no, they are, for example, they’re using for security the same tools. [00:22:56] Nathan Wrigley: Right, okay. [00:22:57] Maciek Palmowski: So in theory, if they’re using the same tools, we should have exactly the same results. [00:23:03] Nathan Wrigley: So does that then point to a different set of configurations on the backend, or is it more curious than that? You just don’t quite know what’s going on. [00:23:12] Maciek Palmowski: I mean because it’s not something that they will tell us. But yeah, in most cases, it’s all about configuration because the fact that you’re using a tool, it’s also important how you use a tool. Also, with security is very often about, is something easy to use or is something secure? And kind of finding the balance. So some of the companies probably had a bit more aggressive configuration, which is better from the security point of view, but probably more often result in some annoying side effects for the user. Also what, this was one of the most interesting things, but also what was very interesting because we contacted every company afterwards and we informed them that we did the test. Here are the results, what went through, what was blocked. And some of the companies did an amazing job of fixing whatever they could. On the other hand, we saw that some of the companies, because we did some extra tests later just to check what they did with our report, did nothing. That’s one of the things about security in general, not about the hosting, about even having vulnerability in your plugin. That’s normal that we make mistakes. We’re humans, right? So that’s normal. What’s important is how we deal with them. If you have a problem and you fix it as quickly as possible, as good as possible, that’s great because you learn from your mistakes, you fix it, and you move on. Perfect. Good job. Now you are in a much better position than before. But if you get this, you look at it and you say, ah, this is fine, that’s the worst behaviour from the security point of view that you can have. [00:24:57] Nathan Wrigley: I’m going to ask you not to name names here, but were some of the companies familiar to us? [00:25:05] Maciek Palmowski: For sure, because we did test the biggest ones. But there is a reason why we didn’t want to name them, and it wasn’t about that we were afraid that I know someone will get mad or whatever. It was more about this weird side effect that could happen. Some users would think, my hosting isn’t on this list, so probably I’m secure. Probably you’re not, you just weren’t in the test. Because we also did some site checks and everything. And we saw that a lot of those problems happen at most of the hosting companies. And like I said, the more important part was how did they reacted after getting the report. Like I said, it was a more common problem that we even thought. [00:25:43] Nathan Wrigley: Do you, obviously, you know, caveat all of this with the fact that you work for Patchstack and what have you, do you see it even as the role of a hosting company to have any position on security publicly? Or would you prefer them not to make grand claims about things that you believe they can’t necessarily substantiate? I don’t really know where I’m going with that question, but I’m just wondering if there’s just a sense that the language that’s being used is too strong. You know, secure hosting implies we’ve got all the padlocks, and the padlocks are there and you’ve got nothing to worry about. You’ve found a different picture. So I’m just wondering whether or not you would just prefer that the hosting companies stop talking about this altogether. [00:26:27] Maciek Palmowski: I do think that’s, one of the biggest problem here is about the claims, the bold claims, the whole marketing around it. Sometimes even you can find documentation of some of them that, yeah, you don’t need to install any third party tool because we got you covered. We checked it, no they didn’t. So that’s kind of the problem. It’s really more about the, how they market it. If they would say, okay, so we have a really performant hosting that does this, this and this. When it comes to security, kind of do it yourself. I mean we are providing this layer, but the rest is up to you. And that’s okay. That’s an honest claim. We are not doing everything for you. We are doing this part, but this is up to you. This would be much better. I know that from the marketing point of view, it doesn’t sound as good as, we got all the security that you can imagine, don’t have to worry about this. Because that’s kind of the thing that very often managed hosts trying to sell, that you don’t have to worry about things. You just have to focus on whatever you have, writing content, selling stuff. If you have a e-commerce, whatever, that’s it. That’s kind of the only thing you should think of. Not about performance, because we got your back. Not about security, again, we got your back. And if you are paying for a managed hosting and suddenly they would start having like this different way of messaging to, it’s not that obvious that we have your back in everything. That would be very difficult for them. So now it’s kind of the problem that, because everyone is kind of using this messaging, everyone else also has to. And also if we think about how a lot of those algorithms, look like that algorithms love bold claims. They want something white or black, not grey. And the truth is, most of the things we are talking about, it doesn’t matter, security, SEO performance, it’s everything in the grey zone. That’s why a lot of developers can end their talk with, yeah, it depends. There is no right or wrong. It depends because there are so many things you have to think about. I could say that, and this is my kind of thing that, most of the websites that people have should be static. They don’t need even WordPress at all. This is a horrible claim if you’re a manager of a WordPress hosting, right? So that’s the thing. But it all depends on so many things, but yeah, the messaging is important. [00:29:08] Nathan Wrigley: Yeah, if you were, on a personal level, if you were going out there looking and let’s say, if you can somehow put your job hat to one side, what would be the kind of things that you would be looking for? What questions would you be asking related to security if you were to be going to these companies? From everything that you said, obviously it’s not black, it’s not white, it’s definitely grey. So every setup has some way of being vulnerable. But what are the kind of intelligent questions that you would be bringing to hosts to get some reassurance that at least they appear to know what they’re doing, even if they can’t make the claim that they’re a hundred percent cast iron, water tight? What might be some intelligent questions to start asking? [00:29:49] Maciek Palmowski: One of the best questions you can ask is just, is there any solution in your security stack that is WordPress aware? Not the general one. Because if they only start talking about some web firewall, things like this, it’s already kind of a red flag. Because this is, overall, if we’re talking about firewalls, that’s not the correct layer about which, this is the generic one. So this is the main question. How do you take care of WordPress specific attacks? Simple question. And if they will start responding, yeah, that we have this web application firewall that, in most cases this will be a sign that, no, we are not talking about the correct layer. That’s not it. It’s probably not aware about what is happening in WordPress. [00:30:40] Nathan Wrigley: Okay. So given that this is a WordPress podcast, and we are at a WordPress event, that would be the beginning of your questioning is demonstrate that something in your stack is specific to WordPress. [00:30:52] Maciek Palmowski: Exactly. [00:30:53] Nathan Wrigley: Okay. And beyond that, is there any questions that, so let’s imagine that they come back with, yes, we have something specific, it’s WordPress. What would be sort of sensible follow up questions? [00:31:00] Maciek Palmowski: I mean you can kind of start off about, okay, what exactly you are using? Because there is a limited amount of tools that are really WordPress aware. So if they will answer with kind of a product name, that’s kind of the easy way that then you can check it on your own. But that’s kind of the thing. Is it WordPress aware? [00:31:19] Nathan Wrigley: Does it worry you in some way that there’s this perception out there that WordPress is insecure? You know, if you ask a thousand people, you’d maybe get 800 saying, oh WordPress, you know, we’re not touching that with a barge pole. Do you worry that content like this, that you are putting out, that that might fuel that fire? Does it concern you in any way that it might lean into the argument that, I don’t know, somebody can link to that blog post from a rival CMS, or a SaaS platform, which does something similar to WordPress? Where do you sit on that? [00:31:51] Maciek Palmowski: That’s a really difficult question. And this is one of the questions that when I talk on non WordPress events, I love to ask people. Is WordPress secure? And in most cases, I see that most of the room is, yes, it’s unsecure for sure. And I’m like, no, that’s not true. WordPress is secure. Every year there is just a few minor vulnerabilities in Core. That’s it. The problem is, of course, that WordPress on its own lacks some functionality. That’s why we install plugins. And here we enter another problem because, okay, every year we have like thousands of those vulnerabilities in general in plugins. On the other hand, we have thousands of plugins. So kind of statistics will always look bad. But that’s why every time when you want to select a new plugin, you need to do some research. Yeah, I know it’s boring and everything but, hey, now we have AI, you can do it much quicker. It can help you a lot. But looking at all those databases, for example, we have one database, WPScan has. There are those databases of WordPress vulnerabilities that occur to every plugin. And you can see, is the plugin you’re interested in had a lot of vulnerabilities? On the other hand, how it kind of looked historically. It’s not just about the number of them. In general, it requires some research. And yeah, if we are just like looking at this, and this kind of vibe that right now we have that we are just about really bold opinions stated quickly that will fit one TikTok, yeah, WordPress is in a horrible position because, let’s be honest, it’s like, if you have, I’m not sure how many seconds does a TikTok movie has? [00:33:39] Nathan Wrigley: I think 30. [00:33:40] Maciek Palmowski: Okay, let’s say 30. So it will sound much better that you will say, yeah, WordPress is unsecure, which is not entirely true because it depends again. One of the most boring, especially again for those algorithms and everything, it’s a grey zone. Because we are collaborating with a lot of companies that are making plugins, and we see how their security flow looks like. How they are dealing with vulnerabilies that are discovered. And honestly, I’m amazed how well some of those companies are doing it. They are very serious about it. They understand how important it is. For them it’s something very important. [00:34:22] Nathan Wrigley: I suppose WordPress is a victim of its own success in that sense. And it would be a bit like, I guess a good analogy might be if you’ve got a car manufacturer and they produce a thousand cars a year and you compare them to Ford who make, let’s say, I don’t know, 20 million a year. And the question is, well, whose cars break down more often? [00:34:41] Maciek Palmowski: Yeah. Do we look at the percentage of the number? [00:34:44] Nathan Wrigley: Right. And if you say, well, 400,000 Fords broke down last year, and one of these other manufacturer, you can immediately see why there’s a problem there. And that I think is the landscape in which WordPress is often painted. The reason there’s lots of publications like yours bringing out WordPress information is because it’s the most popular thing. It makes sense to write about the most popular thing and to try to find the vulnerabilities and disclose them in a sensible way. So I don’t know what we do with that. It is just the way it is. [00:35:15] Maciek Palmowski: I would also say there is one more interesting aspect because WordPress is considered unsecure because of the plugins. But what’s funny, for example, Elementor is also considered unsecure because there are plugins for Elementor. This is a very weird moment when the thing that brought WordPress to its bigger success, security wise, is its biggest problem right now. Because WordPress did a lot of, I mean it was always great to, being as it’s kind of, let’s call it entry level CMS. For many people, it was also the way how they began the adventure with PHP development because it was so easy. Now we kind of have the, all the consequences of being that easy. [00:36:06] Nathan Wrigley: Yeah, in a sense, this is going to sound ridiculous, we should be glad that there’s people talking about WordPress vulnerabilities, because it means the project is successful. And it also means that it’s, there’s an industry of WordPress security solutions, and there are people who take this very seriously and dedicate their lives to it. And you may not find that in some of these other ones, you know, some of the smaller CMSs and things like that. I think we’ve probably hit about the sweet spot for the amount of time. But Maciek, I don’t know if there was anything in that report that you have got lined up in your presentation that I never got to. If there was a particular thread that you wanted to pull. If there is, go for it. [00:36:46] Maciek Palmowski: No, I think we covered all the important things. And as you kind of said, this AI aspect, this will change so many things. [00:36:55] Nathan Wrigley: Yeah, we’ll come back in two years and this conversation will be a very different thing. [00:36:57] Maciek Palmowski: Oh, I think even in few months which will be very interesting. Yeah, so this aspect, it’s really very surprising. And I think that everyone who is right now kind of giving somewhere a talk about AI and security is in a very difficult spot because. [00:37:14] Nathan Wrigley: Yeah, your content is going to look stale quickly. [00:37:16] Maciek Palmowski: Yeah because you know it’s like, but a week ago everything changed. Yeah, I have to rewrite everything. [00:37:20] Nathan Wrigley: Speaking of which, by the time that this goes out, hopefully you have managed to give out your presentation at WordCamp Europe. I will link to it and anything else that we’ve mentioned today in the WP Tavern post. So go and check that out. But I will specifically link to the wordpress.tv version of your presentation, which no doubt will have been created by then. So Maciek, thank you for chatting to me today. Good luck. I hope presentation goes well. [00:37:43] Maciek Palmowski: Thank you. Thank you so much. Yes. I might need a bit because, you know, it’s WordCamp Europe. It’s a big conference. [00:37:49] Nathan Wrigley: It is, yeah. Good luck. I hope that you manage to stay calm. [00:37:52] Maciek Palmowski: Thank you. On the podcast today we have Maciek Palmowski. Maciek is based in Poland and works at Patchstack, one of the companies in the WordPress ecosystem dedicated specifically to security. At Patchstack, Maciek collaborates with other security professionals on industry reports, bug bounty programs, and solutions for agencies, product owners, and hosting companies aiming to secure their client sites. I met up with Maciek at WordCamp Europe in Kraków, and we discussed his presentation there. It examined the claims of “secure hosting” made by many WordPress hosting providers. He describes how Patchstack set out to test these claims with real-world penetration testing, using 30 known plugin vulnerabilities across multiple hosts, employing standardised methodologies, and validating their results independently. The findings are sobering. The majority of WordPress-specific attacks still get through, and there’s a significant gap between the marketing hype and real protection. The conversation starts with Maciek’s background and how his journey in the WordPress security space led to a focus on the promises made by hosts. From there, the discussion gets into the research approach: the selection of well-known vulnerabilities, consistent testing across different hosting environments, and the surprising result that even hosts with identical security tooling produced drastically different outcomes, showing it’s not just about what tools you use, but how you use them. We talk about the “Swiss cheese” model of security, every layer will have holes, so you need multiple, overlapping defenses, and honest communication from hosts about their limitations. We also explored whether an industry-wide standard or badge for “secure hosting” is feasible or even desirable, given how easy it is for strong marketing claims to outpace reality. AI also enters the conversation, increasing both the speed and sophistication of attacks, and making patching and processes even more important, especially as the volume of vulnerabilities continues to rise and the time to exploitation drops. If you’re interested in understanding what “secure hosting” really means, how to ask intelligent questions of providers, and the realities of WordPress security in 2026, this episode is for you. Useful links Patchstack Checkout Summit Testing the promise: does secure hosting deliver? – Maciek’s presentation at WordCamp Europe 2026. It includes the video of the presentation. State of WordPress Security in 2026 Report WPScan
Open Channels FM: Navigating Client Expectations in the Age of AI-Assisted Web Design
by Bob Dunn on 29th July 2026 at 12:49
The growing use of AI tools is reshaping web design, as clients increasingly present AI-generated content. Education and proactive communication are essential for web professionals to navigate these complexities effectively.
Open Channels FM: Fame Then and Now – How the Internet Changed What It Means to Be Known
by Bob Dunn on 29th July 2026 at 10:39
Today on Channel 4, in The Sh*t Show series, Bob Dunn and Nathan Wrigley tackle the fascinating topic of fame: what it means in our modern, hyper-connected world and how our perception of celebrity has evolved over time. From royal visits scheduled to the exact minute to unexpected close encounters with iconic figures like Willie
Open Channels FM: Leading Tech Firms Unite to Form Open Source Secure AI Alliance
by Bob Dunn on 29th July 2026 at 10:11
Today's top story. NVIDIA announces the formation of the Open Source Secure AI Alliance, a coalition of over 40 companies.

Programme Assistant (Protection and Accountability to Affected Populations-AAP, Gaza, SC4

Chargé(e) des Ressources Humaines NOA | Kinshasa, RDC

Driver, SC2 (Beira&Chimoio)- 2 positions

Programme Assistant (Resilience) SC5, Pemba – Ancuabe

Programme Assistant SC5 (Multiple Districts Location) – Pemba

Programme Policy Officer (Project Manager: School Meals) – CST II – Karachi, Pakistan

Gender, Protection, and Inclusion specialist- LACRO

Driver SC2, Pemba – 6 positions

Driver SC2, Nampula

International Consultant, Monitoring & Evaluation Officer, CSTII, Abeche, Chad