as you may already know or you may not know that Patch Stack recently conducted a bug bounty where they analyzed more than a thousand plugins uh to see what security threats on what loopholes do they have and they came up with a very interesting report and to discuss that we have uh we have with us Oliver Sil Uh you might know Oliver Sil from from patch tag from different word camps and events I mean Oliver has been has been a huge contributor towards the WordPress 4 He he and his team has been contributing towards WordPress and WordPress security over the past so many years And I’m so excited to have Oliver Oliver uh how do you feel how are you and if you can just give a short introduction about yourself to our audience Hello everyone Happy to be here Um yeah I’m Oliver I’m the co-founder and CEO of Pashtag So indeed we’ve been working on WordPress security since a very long time I think over 10 like I personally over 10 years already So what we do at patch tech is we provide vulnerability management and mitigation So if we if we look into security vulnerabilities in the WordPress ecosystem more than half of them are uh essentially disclosed and kind of published by patch So that’s something that we really really focus on Awesome along with Oliver we have Msk Palmowski I’m I hope I’m pronouncing his re name right So we have Myk uh with us today in in a panel discussion So let me just give a brief introduction of my uh so my has been with Pashtag along with along with Oliver He’s a web security enthusiast He’s a seasoned web developer and he has been working you know with with with Oliver and and Pashtag over the past few years to make sure that we have a safer you know online environment So my thank you so much for being here We are so excited to have uh you know you know be here to to present this uh to have this panel discussion with us Uh my would you like to give a short introduction about yourself i may have missed something but if you like to add anything to it So yeah for most of of my career I was a developer but at some point I decided to switch to more people related roles like dev deil community management So this is my role right now I’m a comm security community manager at Patch Tech So I’m so I’m managing our our lovely group of researchers that we have and uh it’s fun It’s really fun I’m I’m sure it is my I think Patchag is an amazing team I have a few friends who work at Pashtag as well and they have really nice things to say about you folks So u let’s move on with the first question of this panel discussion Uh so you know you conducted this bug bounty and it’s it seems like a lot of work I mean I’m sure it had a lot of manh hours go into this a lot of money invested into this so what was your motivation behind conducting this bug bounty I mean what came to your minds when you think when you thought that okay so this is something that we have to do and what was the motivation behind targeting WordPress plugins and at that magnitude at that scale I mean Oliver if you like to start us off I think Actually it would be even better if Mashk starts with that because they like he was very much involved with you know setting this whole thing up and I think it would be better if it comes directly from the source Okay Sure So so so in short we run bug bounty every month Uh we just have a usual event that uh that is quite simple Researchers try to find vulnerabilities inside of WordPress themes plugins or core uh they gain experience points and at the end of the month based on the leaderboard they earn money It’s as simple as that But once in a while we run some special events and back in October because October is uh cyber security month together with Darius we decided yeah it would be really cool to clean up the repository a bit So we changed our back bounty rules for that month and we allowed smaller and older plugins to uh take part in it In short because uh if if I remember correctly back then uh a plug-in had to have 10,000 installs and be updated in the last three years And let’s remember WordPress is 25 years old already So there is a lot of plugins that are much older and still weren’t used on more than 1,000 sites So yeah we changed those rules and um and that’s how it started and it ended up with uh 1,500 something valid reports So it was it was huge and as you mentioned it was a lot of work hours our our triage team well how how to put it mildly they were tired they were very tired at the end of the month I think uh maybe a good addition to have here is that um if you compare like before we created the patch deck alliance program which is ethical hackers kind of like open bug bounty program around WordPress ecosystem um in so in 2022 uh the total number of security vulnerabilities found in the WordPress ecosystem was 500 in the entire year So now we are now during this program inside of like a single month we did three times the volume of an entire year of 2020 So you know the internal processes that our triage team has and like the whole setup of how we kind of can even validate that many vulnerabilities It’s like incredible So Awesome That’s awesome work Again I would like to appreciate and you know acknowledge the fact that a lot of you know work and time and and you know money has been gone into making sure that you analyze these plugins and and you know you find and and you address this issue to the larger audience and uh and and what does that would lead me to my next question I mean what does that tell us about the overall security of the WordPress landscape you talk about you you say that you conduct this activity every month You find loopholes every month I mean you you you turn out you know reports every month So what does that tell you like is WordPress really safe for people like is is the landscape really safe for users nowadays or should people you know think about something else yeah I mean funny thing is that I just gave a talk at work uh sorry in CloudFest like one hour ago uh on stage here in person I’m uh on the call right now from uh from the hotel here But uh when we look into 2024 for example the total number of security vulnerabilities found in the WordPress ecosystem was almost 8,000 So 8,000 vulnerabilities uh published in a single year That’s a you know quite crazy number right what we need to think about is that these vulnerabilities have existed in the WordPress ecosystem for years for many many years It’s not that they these are new vulnerabilities that are now being like introduced into the ecosystem These are vulnerabilities that have been sitting there being available to hackers to just take over websites So what we have started to do at patchack is just to kind of like put a lot more attention into like okay we need to find those vulnerabilities before the hackers can and make sure that these are getting properly patched that they are getting you know correctly disclosed uh you know we coordinate the CVS for them and all these kind of things but something to maybe keep in mind of is like 33% of all those vulnerabilities never received a patch So if you’re a developer and you are you know thinking that oh like you know my websites are secure I’m just going to you know keep my website updated and things like that then this is today not realistic security measure anymore like uh first of all hackers are taking vulnerabilities like they are exploiting vulnerabilities in a matter of hours So like if if a vulnerability is being disclosed at 2 am in the morning you’re most likely not waking up 4:00 a.m to start you know patching things up um and you know in 33% of the cases you don’t even have an update So I think the security measures need to really change in terms of um if we want to have like an effect in protection against WordPress And maybe something I could add here additionally for what we see kind of happening already and what I see happening when we go into you know uh 2025 uh is the AI um and specifically the we start it’s like a double-edged sword right because what we see is that WordPress as a ecosystem has always been a platform where a little bit less technical people can set up very functional websites so now in the past they’ve been using plugins for that where they can just choose whatever plugin install you know click install and you know go forward with her with her life and like all they care about is whether it’s visually functional right now additionally to plugins they have AI which basically does the same thing uh where they kind of like ask the AI to hey can you create me this functionality and then if it visually looks functional uh they just deploy it and we already see uh people generating plugins and uploading those plugins to WordPress.org before which are completely AI generated and they are just riddled with vulnerabilities Um so we are now seeing like this situation where um those AI generated plugins don’t have any or like supervision of whether they are secure or not because they’re people that created those plugins they don’t necessarily have the technical knowledge to look into that and then there’s this this second half or like the other end of the sword is where AI can also be very effectively used to find new vulnerabilities Um we have an internal tool that we’ve built over a year already which we are like slowly kind of become making it a public information but we are soon releasing this as a new product which already find security vulnerabilities in the plugins automatically So we need to take into account that this is not only patch that has capabilities such as this but over time hackers will have tools like that as well which will make finding vulnerabilities a lot easier but also exploiting them even quicker So that’s kind of like the direction where I see plus compliance but I think this is a separate topic on its own Yeah Yeah Uh my anything that you would like to add to Oliver’s response No I’m really happy that that Oliver mentioned about about the AI because uh even now we can see on social media there is one one guy getting viral because he how he nicely called vibe vibe coded an application and suddenly everyone is hacking it from like every everywhere and it was a paid application so so this is even like level higher right and uh he was very surprised that this is happening because uh it turns out that people really trust AI and uh for me it’s quite scary that we kind of learn to trust trust AI that quickly uh without thinking about potential consequences uh or the fact that yeah AI still uh can’t think about everything I mean uh how how how it was nicely put once that AI is garbage in garbage out So if someone doesn’t know uh a lot about programming about some consequences uh the prompt he will create will be probably correct in terms of functionality Uh but there won’t be any security measures there because the person don’t have a clue about this So without asking uh AI with the proper prompt and asking it to add those security measures because it would probably help a bit or at least it would be a great starting point Uh yeah we will now we will be flooded with with with a lot of code like this and um and and I think that next year we might have even more vulnerabilities than we had this year it’s only it’s only going to get more uh more vulnerabilities and you know more insecure for for users out there That’s what the data tells us right uh and before I move on to the next question I just want to jump into the comments I think there are a few questions uh from our audience over here for you guys So I will start off with uh I will start off with Ralph who has a question that what’s the process to evaluate a plug-in for security and stability I think the answer to this will be a bit longer but if you can just briefly share what the process looks like when you are evaluating a plug-in for security and stability I mean for anyone to evaluate the plug-in for the security and stability I would look into uh their security processes like do they have a vulnerability disclosure program and that puts down into the compliance pick because we have a cyber resilience regulation in the EU which is like a GDPR for software security So if you have if you’re using a plugin you have to look into whether they have a vulnerability disclosure program in place If they don’t then it kind of like tells already that probably you know other things security related are not getting attention either So that’s I think one of the kind of like the easiest way I think at this point to kind of look into it Um I would go and I would start with with with with the vulnerability database for example we have one uh word fans at WPCan has them too and kind of checking a plugin that you want to install uh there you will find uh this plug-in history of vulnerabilities and status of those vulnerabilities So if you will see that a plug-in has vulnerable I mean had vulnerabilities but all of them were fixed were fixed quickly it’s a good sign because it’s normal that we make mistakes uh but it’s very important on how they handle the problem If they fix a problem very swiftly they were open about it it’s a great sign But if you will see that you will see in the history that there were vulnerabilities but you will cross check the change log and there won’t be any word about this that’s a huge red flag because it means that they are hiding some things So there are a lot of those small little things you have to take into account Uh but but but in general uh as Oliver mentioned if uh this plug-in has some security related processes it’s already a great great sign and together with connecting it with plug-in history uh it should give uh quite a good uh opinion about uh if if it’s a good solution at least in terms of security Awesome Uh my next question is about like you can you talk about plugins and how plugins have the these security vulnerabilities loopholes apart from plugins I mean where do you see the biggest security gaps in WordPress I mean is it the core is it the hosting environments like the third party integrations that many users opt for apart from plugins where do you see uh users getting you know security threats coming from well if we look into our data set then it’s like 99.9% of the vulnerabilities are coming from plugins and out of the 7,000 was it like 7,966 vulnerabilities I think it was last year seven of them were from WordPress core and none of those in the WordPress core were actually critical vulnerabilities that were ever exploited So it’s 100% about plugins and like everything that you are kind of like um you know installing on top of this Uh honestly WordPress like this this discussion about like okay like uh you need like to to stay to keep your WordPress website secure you need to use a secure hosting company I think this is like you know um this is something that is like 10 years old kind of like a recommendation where uh hosting companies have like a really bad uh configurations everything was in a shared environment and like config files were like publicly available and things like that where we’re not in this world anymore right like uh web hosting infrastructure is pretty secure um but what is not secure is the way how people are actually building and putting together those applications that they are hosting in those environments If we look into like how websites are getting hacked there’s three main core reasons One is essentially everything related to the kind of like cyber hygiene of that user who has um you know access to the WordPress admin panel and that’s where you know they have like just like a very poor password policy where they use weak passwords usernames their maybe their username and password is stolen because they are crossing it on multiple websites and some website got hacked and there’s also like session hijacking where you know the devices like we see malware that is essentially uh faking browser updates and asking you to install like fake widgets and then it will steal all the session cookies from your browser Um and then you know this is another way of getting in So it also boils down a lot into like what is your uh how do you actually take care of your everyday kind of like a security posture right um and then there is uh the second half really of all why all the WordPress websites are getting hacked are plug-in vulnerabilities Um so you know to solve WordPress security basically what you need to have is you know make sure that nobody’s getting access to your admin tunnel because of your you know password and you know username and like your stolen sessions and whatnot And the second half is literally just vulnerabilities That is the um that is the kind of like the two main uh main avenues where where most of the attention should go Yeah All right My anything like you would like to add uh I I remember then during one word camp that I was uh I think in Rosswaf there was one guy who did an experiment He prepared a server with with with WordPress that was kind of open for hacking He wanted to check what will be the the approaches of how how how the hacking will happen and uh he observed the logs and and he saw like the first phase was and it was really matter of minutes since the website was up So so so the thing that Oliver mentioned before about uh how quickly uh the vulnerabilities can be used So first phase was kind of detecting what what is happening uh on this website What CMS is is is it Laravel is it WordPress okay it’s WordPress Great So they started with a brute force attack So uh having a weak password uh can be a huge huge problem I mean like not using two-actor authentication right now Wow It’s yeah it’s like asking yourself for for for for having some additional problems and uh so in in in his case at least uh he saw that like the first wave was let’s call it quite primitive right because those brute force attacks some very obvious ways of checking if there is some password shown like for example maybe someone left a backup of WP config file things like this but Uh but very quickly the brute force was enough when he started uh when he changed the password to something stronger and when the brute force phase ended Yeah They started scanning more deeply about uh to check what plugins they are and so this would be another phase vulnerability Awesome Awesome Uh coming back to the security coming back to the bug bounty I mean uh we do have a lot of questions regarding that and my next question is like what were the most common security flaws that you found out in this bug bounty hunt and how can developers avoid making the same mistakes again because I understand that there must be a trend that you may have noticed when you were doing this bug bounty when you were analyzing the reports I mean there there there must have been a trend where you can see okay so these are the security flaws that are present present in most of these plugins and I think people would hear would like would love to know what those trends were that they can avoid those in the future So I think that the biggest trend was cross- sight scripting always Yes So uh if I remember let me just check because I have this article right now with with the stats So cross- sight scripting was uh yeah 67% of the vulnerab of the vulnerabilities we found during this uh back bounty and from what I remember from our uh white paper uh it was also a number similar to this so in in a scale of year so so yeah cross-ite scripting is like the most popular way because it’s It’s quite the simplest I mean it’s it’s both the simplest to to have and it’s quite simple to detect by by researchers We all we also see this So so so it it goes in both ways Um and well validation uh sanitizing data things like this kind of let’s be honest the basics the basics we have the functions already in WordPress for this uh but very often we uh we forget uh we we just forget to use it Yeah And before I move on to the next question we have uh a question from the audience and Afkar asks that if you can just explain briefly what cross-ite scripting is to our audience So uh it goes in short uh it goes about planting this vulnerable let’s say link or payload somewhere on the website and at some point this will be executed by someone with for example admin privileges So this might just give access I’m for example it can create a another user and we can plant things like this thanks to the fact that someone didn’t uh sanitize the data somewhere and we could insert this link that would launch a script and like a real real life experience uh like example would be that you would like imagine you your website has a commenting form and then I submit a comment in there but my comment is actually HTML code that includes also JavaScript that is saving the session file from the browser um or sending it into you know a fake file or or somewhere third party So now I submit that comment and because if the comment form doesn’t sanitize the input of what the comment should look like in the real life then it basically loads that script into the site now tries to show that comment to the users but while it tries to show that comment to the users it’s actually loading that script as part of the website and then doing whatever action we kind of like or the hacker wanted to do So that’s kind of like maybe pick a simple simple example of that Yeah the comment the comments the search engine this is also like another very obvious vector uh that often kind of happens All right of course I hope this answers this qu this answers your question I mean if you still have any confusion please feel free to comment and Oliver and my will definitely answer your question in the comments Uh so next question is around uh you know it’s it’s around behavior and attitude I mean we all know that when you when you tell a developer that this is something that is wrong with your product I mean they they not they don’t normally react in a very pleasant way I mean this is what we have observed in the past I mean when we when we talk to a developer who have worked very hard on a plug-in and we tell them that you know this is something that is wrong with your product this is something that is wrong with your with your plugin This security loophole that we found out I mean how do they how do they react i mean uh how how are they you know responding to that feedback like are they cooperative or have you faced resistance like you know our plug-in is fine and you know we won’t change anything or are they normally very cooperative classical it depends it depends we we had all groups from those very resistant maybe it’s good to start with the good ones um so so batch uh created so in during word camp us last end of last year uh we launched what is called the managed vulnerability disclosure platform So it’s essentially for plug-in developers to have a single dashboard where all security reports will be kind of like streamlined into and then a tech helps to validate them in the proper way and make sure that like vulnerabilities are getting like properly disclosed So for example we have over 600 plugins that have in the WordPress ecos like over 600 plugins that have signed up to the batch MVDP Um and these include like some of the biggest and most popular plugins like for example Elementor So if you find or like if any security researcher finds a a a vulnerability in elementor then elementor is actually like sending them to report that vulnerability to patch that and then we we make sure that this is getting properly fixed before disclosure We reward the security researcher and that also allows us to provide fastest protection to all element users because as patchack is providing virtual patching and vulnerability mitigation This allows us to kind of like protect fits before anyone else uh as well Um but then there’s and these are like those plug-in developers that are very proactive and I mean they also want to be compliant with the upcoming cyber resilience act which is actually making this mandatory Um but then I would say there’s like plugins where you try to report vulnerabilities to and then they you try to like send a report and they say like hey send it to our customer support ticket and then you start sending it to customer support ticket and turns out that oh but we only have customer support tickets for premium customers who have uh you know paid license and then you cannot send them a security report and then and then some of them uh like the biggest issue is that they’re just missing that information they don’t have a system at all where to report vulnerabilities Um and they just like kind of miss it until and then we need to like escalate that to the WordPress.org Um and WordPress.org is like we work with the plug-in review team Um they then have the direct connections to the plug-in owners and then they reach out to them But that very often uh goes into a direction where those plugins are just getting you know temporarily closed or permanently closed dependent of like whether they are abandoned or not And if your plug-in is getting closed for security reasons obviously like the plug-in developers are not super happy about it But every time we get like this kind of like a negative I would say like kind of like outburst from a developer saying like hey what the hell like why didn’t you report it to us and we’re like we did And that’s one of the reasons why we are actually making screenshots of every single time when we are reporting vulnerabilities through like uh like contact forums and when there’s like no other way to report vulnerabilities to and like then they eventually come back to and say sorryly and like oh yeah they really need to like improve their processes I think it’s starting to get a little bit better Um I think it’s maybe also because patch tech is very known in the ecosystem already and they know that we’re actually you know we’re out there doing good Uh but yeah like it’s definitely like some try to hide information about vulnerabilities because how they they think that it might affect their reputation but actually the worst thing that you can do in terms of your reputation is try to hide that information because then it’s going to come out your users are not protected and this is the kind of vulner the the kind of plugins that developers should avoid at all costs uh to be honest Yeah Although during this this bug bounty in in October uh we had 70 almost 74% uh reports we had to uh go through WordPress review teams because we did not get any answers or there was just no contact point because uh well some if I remember the oldest plugins we we found with the vulnerability back then was 17 years old So uh that company probably don’t exist anymore This those emails were just Yeah they still have active installations like there’s still websites and still running with those plugins That’s even worse Yeah So so I would like to extend on this a bit as well and uh ask that how long do you sort of you know chase after a developer or a plug-in plug-in provider uh before you say that okay it’s not worth it anymore because obviously it’s it’s time consuming you know chasing after people telling them that is something that is wrong with your plug-in and not getting a response So how long do you normally you know chase after these people and you know try to communicate this this issue with them until you decide okay it’s not worth it We should focus on something else Do you remember the numbers yeah because I I I believe our default policy is 30 days Um so we we are we are either waiting so the default is 30 days If the plug-in is getting updated to a fixed version then we are obviously disclosing it as soon as it gets updated because the users need to know that they need to update to that version Um and honestly this is information that there’s no point of like kind of like hiding away anyway because hackers are actually monitoring the change log So they are seeing like all the like even we have internal systems that are like in real time like kind of like scanning every every plug-in update in the WordPress ecosystem and we we we see immediately when there is like a security update being released So hackers do the same thing so they could like weaponize those vulnerabilities as quickly as possible Um but like when the plug-in developer is not like responding at all or like we have a like trouble then we wait 30 days and if after that they still like they still don’t respond to us we just publish the vulnerability and let our users know that there’s a security vulnerability that they need to um you know eliminate uh essentially because most likely the developer isn’t fixing it and it could have it could very easily be like abandoned plugin Awesome Yeah I would again like to know stroll into the comments before I move on to the next question I think Ral has a question uh where he asks that what guidelines do you recommend and use for your own sites in determining a safe or risky plug-in and do you have a scale that you classify for example A for a trustworthy plugin B for you know it’s okay but we use with caution and C for don’t use at all like do you sort of grade these plugins in these categories like when you use plugins for yourselves we don’t necessarily score them based on that but we do look into their history like it’s a bit hard to like have like a standardized scoring system like that because all of the plugins are very different Um the code quality is different Like we obviously like we are half of our team is basically threat intelligence and security researchers So we have the capability of like kind of like figuring out whether there’s like vulnerabilities in any of the stuff that we are using internally as well Um and in fact we are probably the biggest bet testing company for WordPress plugins out there So many of the of the companies who are building WordPress plugins they come to us and we actually do security auditing as a service as well Um but like most of the cases what we look into is like literally the source code and we go like just pure technical like is that code well written are there security vulnerabilities in there and the second part is like obviously like how does the developer um react to security issues how what is like like Mashk said like what is their background of like how how they dealt with the security vulnerabilities in the past like how they are communicating this to the users because some of them are just like okay we’re fix the vulnerability but we don’t let anyone know because like the correct way is that you need to actually let let your users know that there was a security fix um and so forth so there’s like a bunch of those things and actually if you look into our blog we have like a series where we kind of like have analyszis on different categories of plugins I believe like there’s like form plugins and things like that which is kind of like what your what the question is about actually where we’ve analyzed all the available kind of like let’s say form plugins and we kind of like look into those different categories and which ones are like more safer option in that sense where the developers are taking security seriously Yeah All right U moving on to the next question I mean uh you you obviously conduct this you know bug bounty and you find out a lot of issues and you know vulnerabilities and threats but do you think on top of that it sort of exposes a bigger problem of uh you know having the need for a stricter plug-in development standards for WordPress i mean you do this every month right and every month you find out new issues and new vulnerabilities So don’t you think that there has to be a need for a stricter plug-in development standards like there are with other provider with other platforms like I mean we know other platforms that have their own marketplaces and they vet the plugins themselves and they make sure that the plugins that are listed on the marketplace are safe and with zero vulnerabilities but with WordPress that’s not the case So you do you think that there has to be a better you know you know check check and balance for these plugins before they get listed on the repository uh I mean in theory to get into repository your code is being reviewed So this is the only review that your plug-in gets and this is kind of the problem because uh that’s the only review So I think that uh what we are lacking is uh having even some quite simple automated tests running on every update Uh it wouldn’t solve everything It would probably report quite a lot of false positives Mhm But maybe it would open open eyes for some developers Uh and maybe they would say “Okay maybe maybe I will take a look at at this update again Maybe I really made a mistake.” Uh and let’s also remember that um WordPress uh.org orc is mostly run by volunteers or it’s uh or we all know what is right now happening with some cats but so I I won’t but what what what I want to say uh right now it’s probably impossible to think about uh making the WordPress security team bigger so it could work in a more proactive way So we we should probably start thinking about uh yeah using some simple ways in which we could at least remove a part of the problem Uh also another problem is because okay that’s great we discovered uh during that one month and we kind of closed even almost 10,000 plugins That’s great But most of users won’t even know about it because WordPress still misses the mechanisms for about informing the users that hey this plug-in is closed because of the security reasons I mean you can go into plugins you have to click in one place but that’s not enough I mean if you can go into admin panel and see hey there is an update for this plug-in there should also be hey this plugin is closed think what to do with this maybe you should find an alternative something like this because uh right now uh I think uh the ecosystem is kind of kind of failing with those quite simpler things that and easier things that we could uh that we could really change like for example the those those notifications uh because this would uh make uh work of every every WordPress security company much more meaningful because uh users would know better to what to do with with with those plugins Uh but yeah like I said um yeah those volunteers have limited time so they can be more proactive and and that’s also a big problem Now Oliver do you would like to add anything to this or I mean good thing is that uh we have we’re from Europe and what we do the best is regulations right so ultimately like the plug-in developers need to comply uh because like we had law the law was already passed this is going to affect both WordPress core plugins for example you would need to start releasing um updates uh like functional updates separately from the security updates uh and things like that So this is all going to be like mandatory starting from 2026 already So plugins that are currently lagging behind They’re not setting up those things up They are just going to have a lot of trouble like the cyber resinians act has the same file structure that GDPR has and like nobody wants to get fined for not just like having security processes in place when they are sh like shipping software that is being used by you know thousands of companies around the world So so the positive side of it is like you know regulations are pushing some of the people into it even whether they like it or not and this is the this is the very shortterm future already All right awesome Uh I think we have another question in the comments I sort of missed that earlier Uh we have uh yeah so I need to sort of ask this question that how can we identify highrisisk plugins before installing them like is there a sign are there like any checkpoints that we should cover before you know installing plugins on our websites i think we kind of covered it already Uh history Yeah Yeah the history like like Mik said as well like look into the historic like go to patchack.com database and look into uh search the plugin there and then basically figure out like are there like any historical vulnerabilities present that have not been fixed Important note here is that if a plug-in does not have any vulnerabilities found this can be also bad uh that could that would just like that could just like mean that first of all there’s no information whether they actually have a proper security process in place and this could just also mean that nobody has looked into it um so so yeah I would again look into signs that they have security processes in place that they have vulnerability disclosure program that they have like a clear way how to report vulnerabilities to them and so forth awesome u so next question is around like top three actions that you know people could take today if they want to improve their WordPress security on the top of your head What are those top three actions like anything password and uh sessions related and the second I would literally have just top two like uh like one is like uh yeah basically setting up two factor two factor authentication and making sure that your own devices are secure Uh and the second one is to have virtual patching and vulnerability management Like today virtual patching is like the most essential security thing that you can have because as I mentioned we have eight almost 8,000 vulnerabilities found in a year 33% of them are not patched at all Um so if you like even if you have auto updates enabled you are not protected So to have that kind of like uh exposure covered that you won’t get hacked while you’re waiting for the official developer to release a patch or there’s no patch coming at all then you need something that is capable of basically like holding back those vulnerabilities um while you figure out what to do next So I would say yeah like everything like two factor authentication and kind of like um personal kind of like cyber security hygiene and the second part is really hard focus on the vulnerability management and virtual patching I see that you also you also took my proposals and what can I know but okay if if there should be three I I would add one more thing because we have this thing in in in WordPress that uh we have this saying there is a plug-in for that and He kind of got used to it and everything in WordPress everything should be simple right you want to have a faster website hey there is a caching plugin Do you want an accessible website hey there is a plug-in for this You want a secure website hey you should install a plug-in And that’s kind of a problem because we are very often changing processes that should always run in the background uh into into plugins And while those plugins very often should be the part of the process because they should uh because using a security uh plug-in as a part of the whole security process yeah is a must because we can’t sit all the time in front of the computer uh just I don’t know looking at patches like I don’t know like well I’m looking at yeah the vulnerabilities or whatever it’s it’s it’s impossible but uh we should also think about more things So for example yeah creating kind of your own framework of of how to decide which plug-in is safe which not Uh kind of evaluating all the plugins that you use from time to time and checking if it’s still a good idea to use them Uh also being prepared if something goes wrong Make sure do you have backups make sure if you are ready with kind of the formal parts So for example informing your users that hey there is a chance that part of our data was compromised because uh the moment when you are in the situation you have much less time to think So you should prepare for things like those uh before So yeah kind of uh instead of uh looking for just oneclick solutions Yeah processes are processes Sadly they have to run in the background Maybe even add a little bit on top of it is also so three days ago or two days ago I had a talk here in CloudFest and where it was talking about WordPress security and layers and I think it’s also very important to say that you should cover security on all of the layers Uh but you should also do the right things at the right layers So for example malware scanning uh backups you should never use plugins for that You should basically use a serverside solution because like if you look into our white paper you will see also that there is very widespread malware that is just the first thing that it check injects the website It basically looks whether the site has like uh you know word fence and other those kind of like security plugins installed and then it would just whitelist itself in there So then you get like a very false sense of security because you know they you think that you’re secure because you have a security plug-in that scans for malware but then the malware is like injecting itself in there and basically deleting the you know the the security or like the malware scanner plugins from understanding that it is a malware So you never should run malware scanner as a as a WordPress plug-in um because you cannot like have that kind of like functionality be in the same place where the compromisation can happen It’s a very like if you think about it’s like it’s like a big like a logical flaw right like you can’t like kind of rely on malware scanner that is controlled by the same environment that is infected with malware Um so you know these kind of things that are also important like for example virtual patching you need to run it on the application So this is something that you need to do uh inside of WordPress site as a plug-in because this is the only place where you have full visibility into the plugins You have full visibility into the sessions So you can like reduce the amount of false positives and make developer patches as effective as possible And then if you want to protect the website from like you know traffic and things like that like a very generic kind of like like a traffic filtering you should do that on the network layer which is more like you know cloud flare and things like that and you should have those all like layers covered and have solutions in there Awesome Awesome Uh last question guys uh on this panel discussion uh and that is you know one golden rule uh that you can share for WordPress security in 2025 like what would that be what would be your you know first thing that you would like to share with people who wants to secure their websites this year h I think with all the things especially related with AI with all the things we talk trust trust less in everything I mean really um we we we already talk about uh how how easy it is to generate code and uh if this code will be a plug-in there is there will be a bigger chance that someone will install it without checking what’s inside So uh I I think that for for many years we we already were trying to explain very often to to a lot of people hey don’t click in suspicious emails for on on links and stuff So now I think it will be even more difficult because AI makes everything much real and so that’s why really I I I think that uh we should have much more trust issues with everything and uh we should always check uh whatever we can Yeah for sure like um I mean we already know based on the statistics like if you look into the white paper that I shared a link to as well like this was done in collaboration with Sukuri uh Sukuri is another uh security company in the WordPress space that is owned by GoDaddy um and they gave us statistics about like how many WordPress websites were hacked and it was like 500,000 WordPress websites that were hacked last year So we need to like really think and look into like what are the main ways how those websites are getting hacked and then we have the statistics of like it’s literally like half of them are because you know vulnerabilities and half of them is because of you know um s like session hijacking and kind of like very poor usernames and passwords The session hijacking and username password is actually the easiest to solve because you can just like you have full control over it at all times Um but the vulnerabilities is something that is much harder to do because you need to basically do you know there’s so much more volume of information coming that you need to react on So I would definitely recommend people to like turn like vulnerability management and kind of like vulnerability mitigation into a like essential because this is going to be you know the hardest part of that 50% of the reasons why your website would get hacked Um so yeah I mean not only is is it going to be now like vulnerability management and mitigation is actually also now mandatory if you if you want to have PCIDSSV4 compliance So basically for all e-commerce websites that are accepting credit card payments vulnerability management is already mandatory Uh so 2 same thing So I think 20 I hope really that 2025 will kind of like show us that this is going to become like essentially essential thing that is being deployed across all uh all possible um factors Yeah Yeah My your golden rule Yeah Like I said trust less That’s it Trust All right All right Perfect Guys this was it from uh from this panel discussion Uh I think this was this was great I think this was amazing A lot of people on in the comment section really appreciate your time and and your uh your knowledge and wisdom around security and vulnerability I think this is a topic that needs to be discussed more uh that needs to have more deeper conversations around you know plugins and plug-in loopholes and vulnerabilities But I think this this session covered up a lot of you know things that people uh you know would want would want to hear especially coming from you guys So thank you so much my thank you Oliver for being here Uh it was a pleasure having you on this event and on this note I would also like to thank Pashtag who are our partners for this event as well Uh so thank you guys and I wish I wish you best of luck