REGEXSS Demo: How Hackers Exploit Regular Expressions in WordPress with Mat Rollings

Robert Abela: Hello, and thank you, everyone, for joining. Today is a recorded session. We’re recording a few sessions because during the next few weeks we’ll be traveling, and we’d still like to keep streaming a podcast every Thursday.

Today I’ll be talking with a bug bounty hunter and security professional who has found quite a lot of vulnerabilities in WordPress plugins and similar software. We’ll mainly focus on regexss, or regular expression cross-site scripting. It’s a specific vulnerability class in which a cross-site scripting issue is triggered by the abuse of regular expressions. I’m probably butchering that, so I’ll let Mat explain it. With me today is Mat Rollings. Hello, Mat. How are you?

Mat Rollings: Hi, I’m doing well. How are you?

Robert Abela: I’m good. Thanks for joining us. As I already explained, we’ll be talking about regexss. Before we jump into the details, can you give us a brief introduction to yourself and what you do?

Mat Rollings: Definitely. I’ve had quite a different background. I originally started in physics, mainly because at school, I got some bad advice from a teacher who told me not to go into computing because it was just for nerds. For some reason, my parents and I listened to him, even though I was already a massive nerd.

I ended up going down the physics route, but I did enjoy it, especially the problem-solving side. One of the modules we had was literally called problem solving, and it was all about learning to think laterally. You’d get abstract questions like, “If you eat a donut, how far can you walk on it?” or “How many windows are there in the city?” There wasn’t one fixed answer. You just had to show how you would reason your way toward a solution.

That stayed with me. I’m naturally curious, and I like figuring out how things work. With bug hunting, once you understand how something works, you can often figure out how to bypass it or use it against itself to find more interesting bugs.

I stayed in academia for a while and really enjoyed making my own experiments, doing simulations, and building small hardware and programming projects. Around that time, Android phones started coming out, and I got really interested because I’d always been into Linux and open source.

I wondered whether I could write an app for Android, so I did. I ended up writing a few applications, and one of them started making a bit of money. That pushed me to pursue it more seriously, so I paid my own way to one of the early Google I/O events in America. There I met a lot of people, and I randomly bumped into someone from the same city as me who was the CTO of an app development company. They offered me a job, so I dropped out of university and joined them.

I had a really good run there and learned a lot. I did a lot of Android development. Eventually, the company went bust, but I took on the clients and apps I’d been working on and moved into freelance development. That was a lucky transition, because it gave me good money and time to keep developing my skills.

That probably continued for around ten years. Then I moved into cybersecurity. I’d always been interested in the hacking side of things and had been into Linux since I was about eighteen, but I didn’t realize cybersecurity was something you could actually do professionally and get paid well for. I thought hacking was just for the bad guys.

Then I found that a nearby university offered a cybersecurity master’s, so I applied and studied part-time while still doing Android development. That went really well. During that time, I used training from Immersive Labs, which builds practical secure coding labs for developers and attackers so they can better understand vulnerabilities and learn how to write more secure code.

What I liked about it was that it helped developers build more of a hacker mindset. If you can teach developers to think of incoming data as potentially hostile, they can catch more bugs. In my view, a lot of vulnerabilities come from trusted assumptions about data that originally came from a user, even if it now seems to be coming from a database.

I eventually joined the AppSec team at Immersive Labs. I had reached the top of their student leaderboard, and they reached out to ask whether I wanted to do some contract work writing labs. I started contracting with them, then joined full-time, and after a couple of years, I was leading the AppSec team. It was a great experience.

After that, I spent a few months in fintech, but it wasn’t really for me. A lot of people seemed unhappy, and it felt like the kind of place where people get stuck because the pay is so high that leaving means taking a major cut. So I left after around six months to focus more on what I actually enjoy.

One of those things is teaching. I teach kids how to code once a week, which is really fulfilling. The other thing I really enjoy is bug bounty hunting. I’ve only been doing bug bounty work for around three years, with about two of those being full-time.

I got into WordPress bug bounty hunting because someone I worked with at Immersive Labs mentioned that WordPress bug bounty programs were starting up. Since WordPress is open source and I already had AppSec experience, it seemed like something I’d enjoy. So I started looking at WordPress plugins, which have a bit of a reputation for containing lots of vulnerabilities.

It started off slowly. I found one vulnerability, and it took me around a month to properly exploit it. I remember thinking that if it was always going to be that hard, it would take forever to make any money from it. But the more I learned about WordPress, the easier it got. There are so many plugins that if you can imagine how someone might accidentally write vulnerable code, you can often find many variations of that pattern across the ecosystem.

Robert Abela: That’s a very interesting journey. Thanks for the explanation.

Before we jump into the technical details, you mentioned that most vulnerabilities usually happen because developers trust user input, whether it goes into the database or gets reflected into the interface. This is a common problem. I speak to a lot of developers, including very brilliant ones. It’s not that they’re incapable. You can specialize in security or development, and only sometimes in both. Is it mostly because they’re simply not aware of the kinds of attacks they need to protect against?

Mat Rollings: Definitely. A lot of it does come down to awareness. You can achieve a lot just by increasing developers’ awareness of how attacks work.

That’s something we focused on when I was training in cybersecurity. You try to empower developers to take responsibility for security, because at the end of the day, if you’re writing code, it does need to be your responsibility to make sure that code is secure. It shouldn’t all sit with one person, though. There should also be safety mechanisms, like code review and other people looking over what’s being committed.

It can also be difficult in practice. If you’re working at a company, you’re often being paid to ship new features, and you may not be given enough time to test everything or spend enough time hardening the code. So you need buy-in from both sides. Developers need to care about fixing security issues, and management needs to give them the time and space to do it properly. That includes training, too.

This probably changes a little with AI becoming more common, because AI can be a powerful tool for writing code, reviewing code, and helping developers write more secure code. If you ask it to look for security issues in something you’ve written, it will often do a pretty decent job.

Robert Abela: Since you mentioned AI, I’ve spoken a couple of times to Maciek from Patchstack, and I think even Oliver mentioned this at CloudFest. The number of reported vulnerabilities is going crazy. I think they received at least 2,000 reports last month, and they still have to validate them. It’s becoming quite wild.

Mat Rollings: It really has gone mad, and that’s having a knock-on effect for bug bounty hunters. A lot of people are still submitting genuine bugs, but triage teams are getting overwhelmed by AI-generated reports from people who haven’t even bothered to install the plugin and verify whether the issue is actually exploitable.

That means legitimate researchers are waiting much longer for their bugs to move through triage. I know some reports are taking around a month, and I think that’s true for both Wordfence and Patchstack at the moment. In the short term, it’s going to affect the whole security landscape because vulnerabilities may remain undisclosed to customers for longer.

The companies are trying to improve triage speeds by using AI themselves and by asking unvetted researchers to provide videos or stronger proof that they can actually exploit the issue. At the moment, too many people are just spamming in reports for things that aren’t even vulnerable.

Robert Abela: I’ve seen that too. Some people are not even installing the plugin. They just download the repository whenever there’s a release, run a diff, use AI to highlight something, and then try their luck. I’ve also heard of cases where people are using autonomous tools that go off on their own, do the research, and come back with results. It’s getting pretty crazy.

Let’s jump back to regexss. This is a vulnerability class you coined. It’s not a commonly used name, but it combines regex and cross-site scripting. On your blog, and speaking about bug bounties, you mentioned you’ve made around $20,000 from this vulnerability class so far. Is that right?

Mat Rollings: Yes. From this vulnerability class alone, it’s probably around $20,000 to $30,000 by now, just because of the number of times I’ve found it. It’s definitely under-researched at the moment.

Hopefully, more people get interested in it. I’ve already had one person reach out, and we collaborated and found a lot more instances. So it’s definitely an interesting area for bug bounty hunters to explore.

Robert Abela: Good. So, regexss is basically a combination of regex and XSS. Let’s start with regex, or regular expressions. For people who are new to this, can you briefly explain what regular expressions are?

Mat Rollings: Let’s back it up slightly and start with HTML and XSS, then I’ll get into regex. I’ll jump straight into a demo.

We’ll start with some very basic HTML. For people who aren’t familiar with it, you might have a heading, a paragraph, and an image. HTML handles the more static structure of the page.

On the client side in the browser, you generally have three things. You have HTML for the static structure, CSS for how things look, and JavaScript for the dynamic behavior. JavaScript is what powers things like fetching data asynchronously and updating the page without reloading.

With WordPress and other HTML-based sites, you often need to include user data in the page. Sometimes that data is just plain text, but users may also be allowed to include some tags, like bold tags, depending on the context. That can be perfectly valid, but you still need to define a security boundary. You don’t want users executing JavaScript.

JavaScript can appear inside script tags, but it can also appear inside attributes. That’s what a lot of cross-site scripting attacks rely on. If I can insert something like an event handler, such as an onclick, then clicking the image can trigger a JavaScript action. Security researchers often use a simple alert box in demos because it shows that they’ve achieved JavaScript execution.

There are lots of events that can be abused this way, like onload and onerror. If we can insert those, then we can get JavaScript execution in the browser.

Robert Abela: Just to confirm, the JavaScript runs on the client side, correct?

Mat Rollings: Yes, exactly. It runs in the visitor’s browser, so the attack affects the person viewing the website.

It’s also important to explain what an attacker would actually do with that. A simple alert box is just a proof of concept. In reality, an attacker could redirect the user to another site, which could be a phishing page. But more importantly, they can often control what the user is doing inside the site.

If I’m logged in as an administrator on a WordPress site and a malicious payload runs in my browser, that payload can abuse my privileges. For example, it could create a new admin user in the background. In a demo, that might look obvious, but in a real attack, the whole thing could be hidden and invisible to the victim. That gives the attacker control of the entire site.

Robert Abela: Because JavaScript is running in the browser, if the user is logged in, can it read cookies and send requests in that session?

Mat Rollings: With modern protections, you can’t usually read the cookies directly, but you can still use the session to do things. Any action that the current user is allowed to perform can potentially be abused.

If the victim is a subscriber, you may be able to update their details. If they’re a contributor, maybe you can make posts. The real target is the administrator, but you can still start with other users and work your way toward that.

That’s the important part of XSS. The alert box is just the simplest visible signal that arbitrary JavaScript is executing.

Mat Rollings: If we move on to regex, it can look like someone fell asleep on the keyboard, but it’s actually much easier than it appears. I avoided learning it for years because it looked intimidating, but now I use it constantly. It’s incredibly useful for development and appears in pretty much every programming language, including PHP and WordPress.

A simple example would be matching a phone number or an email address. Regex gives you a way to define patterns in text, and in WordPress or PHP, you might use it either to extract data or to replace matched content with something else. For example, you might replace email addresses or phone numbers with asterisks for privacy reasons.

That’s all perfectly valid. The problem is that once developers learn regex, they often start using it everywhere. It becomes the hammer that makes everything look like a nail.

That becomes dangerous with HTML, because HTML is flexible and structured, while regex is strict and treats everything like a string. Regex can’t understand HTML context. It doesn’t know whether something is inside an attribute, crossing attribute boundaries, or changing how markup will be interpreted once it’s rendered. That lack of context is the crux of the vulnerability class I’m calling regexss.

Mat Rollings: If you take a simple HTML link and write a regex to capture the href, that can be perfectly fine in isolation. But the more you rely on regex to manipulate HTML, the easier it is to create patterns that are technically correct from the regex engine’s point of view while still being unsafe once the browser renders the result.

Learning regex has been a kind of superpower for me in bug bounty hunting, because I don’t just use it to understand vulnerable code. I also use regex to search huge numbers of WordPress plugins for the kinds of patterns that might be vulnerable. I can download a large set of plugin code and quickly look for the specific kinds of regex usage that might create these issues.

Robert Abela: So you’re using regex to find the issues where regex is being abused.

Mat Rollings: Exactly. It’s regex all the way down.

One reason people use regex is that it’s fast. It’s not as fast as simple string replacement, but it’s often faster than more robust alternatives. The safer alternative for HTML is usually parsing it with something that understands the DOM or a WordPress-aware HTML processor. Those approaches are more secure because they understand context, but they also require more knowledge and more code.

If you want to avoid this vulnerability class entirely, though, learning those context-aware tools is worth it.

Mat Rollings: The basic idea behind regexss is this: WordPress sanitizes user HTML and blocks most standard XSS payloads quite well. Their built-in checks are solid. The problem happens when a developer performs another regex-based transformation after WordPress has already sanitized the content.

So now you have HTML that started safely, and then a plugin modifies it in a way that an attacker can abuse. In some cases, this is also called mutation-based XSS. The developer isn’t injecting a dangerous payload directly. They’re transforming safe HTML into unsafe HTML after the fact.

For example, a plugin might use preg_replace to delete a certain attribute from HTML. On normal-looking content, that may seem harmless. But an attacker can carefully craft input so that the deletion starts in one place and ends in another, effectively changing the structure of the HTML.

You can then end up promoting something that was previously inside a string into a real attribute, or creating a javascript: URL where there wasn’t one before. You can also abuse quote swapping between single and double quotes, because HTML allows both. That lets you break out of one attribute and inject another.

A common payload I use in demos relies on autofocus and onfocus so the browser automatically focuses the element and triggers the JavaScript. That’s one of the standard ways of demonstrating the issue.

Mat Rollings: The first vulnerability of this type I found was in a plugin called Schema and Structured Data for WordPress and AMP. The plugin was using a lot of preg_replace calls to modify output HTML, often replacing matched content with an empty string.

That’s exactly the pattern I was talking about. The content had already passed through WordPress sanitization, but then the plugin was deleting matched attributes in a way that could be abused. When I tested the pattern in a regex tool, it behaved exactly the way I expected.

From an attacker’s point of view, this was useful because the vulnerable transformation happened on pages where comments could be displayed. So I could submit a malicious comment as an unauthenticated user, wait for it to be approved, and then have my payload execute when an administrator viewed the page.

If comments were auto-approved, it would trigger immediately. If they weren’t, the attack could still succeed once an admin approved the comment. In some variants, the payload could even trigger on the moderation page itself, before approval, which is even more powerful.

Once the JavaScript runs in the admin’s browser, the site can effectively be taken over.

Robert Abela: So the code posted in the comment gets executed as JavaScript when the administrator loads the page. And if the payload created a user, for example, then that would succeed in the admin’s session.

Mat Rollings: Exactly. The attacker could completely compromise the site.

This was the first one I found, but I’ve found many more since then. Altogether, they would affect roughly 3 million websites if you add up the installs across the various plugins. That makes it quite impactful, especially because many of these are unauthenticated attacks. If anyone can submit a comment, they may be able to trigger the exploit.

Some of the more interesting cases trigger as soon as an admin loads the comment moderation page, before the comment is even approved. In that scenario, the attacker could potentially exploit the admin immediately and even force the approval as part of the payload. That’s very powerful.

Robert Abela: That really highlights how important it is to keep plugins up to date. If you’re running a vulnerable version, someone could exploit it through a comment, even if they aren’t registered. The admin just loads the comment, and the exploit fires.

Mat Rollings: Yes, exactly. That said, it’s also difficult because WordPress plugins frequently have vulnerabilities discovered in them. You’re not automatically safe just because you’re on the latest version. New issues are always being found.

That’s why the broader defensive layers matter too. The companies running the main WordPress bug bounty programs also offer security plugins with virtual patching and firewall protections. Those tools help block common attack patterns, including attacks that the defenders may not yet know about specifically.

I’ve looked into some of those protections, and I haven’t found them easy to bypass. So if you can, it’s definitely worth running a good security plugin.

Robert Abela: It’s funny because cross-site scripting is probably the most common and easiest-to-exploit vulnerability people talk about, and it’s often treated as if it’s not very serious. But as you’ve shown here, it can be very dangerous.

Mat Rollings: I think it’s easy to dismiss it because we usually demonstrate it with a tiny pop-up. If you don’t already understand the impact, you might think, “I don’t care if someone makes an alert box appear.”

But the alert is just a way of proving JavaScript execution in a simple and visible way. Once you can run JavaScript on a page, you can often do anything that the current user can do on that site.

Robert Abela: With something like SQL injection, the proof of concept often looks more dramatic because you’re visibly pulling data from the database. XSS can look less impressive at first glance.

Mat Rollings: That’s true, but if you exploit an administrator with XSS, you could argue it’s even more impactful. A SQL injection bug might let you extract some data, but if you take over the admin account through XSS, you can leak data, create new admins, install plugins, edit files, or potentially pivot into full remote code execution if the environment allows it.

So from an attacker’s point of view, a successful XSS against an admin can be extremely powerful.

Robert Abela: When developers need to manipulate HTML, WordPress already does some sanitization for them. But there are still cases where they need to change the data or modify the output. What should developers avoid, and what are the best practices when it comes to HTML manipulation?

Mat Rollings: I think there are three main approaches.

The first is rejecting input you don’t want. You don’t see this as often, but it’s a perfectly valid strategy. You can use regex here, because you’re just saying, “Only allow these characters.” For XSS specifically, the main things you want to block are <, >, and single and double quotes. Those aren’t the only dangerous characters, but blocking those four would stop a large number of XSS payloads.

What I usually tell developers is to work out the minimum set of characters their feature actually needs. Maybe it’s alphanumeric characters and some extended ASCII for international support. A lot of special characters simply aren’t necessary in many fields.

There are plenty of places in WordPress itself where the allowed characters are surprisingly broad. For example, first and last name fields allow almost any character other than angle brackets. That led to one of the first large-scale issues I found, where a subscriber could put a double quote in their name and inject additional attributes when someone viewed their profile. I found that pattern in roughly fifty themes, including some with over a million installs.

The second approach is sanitization, where you remove characters or markup you don’t want. That’s probably the most common. WordPress does a lot of this already. The trade-off is that the data the user puts in isn’t necessarily the same as the data that comes back out, so it doesn’t fit every use case.

The third is encoding, where characters are transformed into safe representations before output. That can work very well, but you have to make sure the result still renders correctly for users. There are lots of ways to prevent XSS. The main rule is to be paranoid about data sources and never assume the input is safe.

Robert Abela: You mentioned content security policy as well. Do you mean plugin developers can’t really rely on it easily inside WordPress, even though site owners can configure it at the server level?

Mat Rollings: Yes, exactly. A site owner can enable CSP on the server, and I’m sure there are WordPress plugins that help with that, too. The hard part is making sure all your installed plugins still work correctly under that policy.

A stricter CSP may block functionality that plugins rely on, and then parts of the site stop working. It would be great if WordPress had more framework-level support for that, where plugins could declare what they need and the platform could help manage the policy safely. That would be really powerful from a security point of view.

Robert Abela: When you find these bugs, they look simple once they’ve been explained. Is there anything that still surprises you about these technically simple issues?

Mat Rollings: They look simple because I’m trying to explain them simply, but the first one took a lot of research. Even now, it can still be mentally tricky figuring out exactly which combination of single and double quotes will make a payload exploitable.

I once reported one of these bugs to a plugin developer, and afterward, he asked me to review the rest of the plugin. During that review, I found a pattern in his code that also existed in several other plugins. I submitted those too and ended up making around $5,000 from that group of findings.

Because I found those extra issues by reviewing his plugin, I gave him a discount on the review and helped him secure the rest of the code. In the end, I tried very hard to fix the regex expressions themselves, but in some cases, it just wasn’t possible. We had to switch to something context-aware that could parse the HTML properly and do the transformation securely.

So yes, once you know what you’re looking at, the bug can seem simple. But getting to that point often takes a lot of work.

Robert Abela: That’s what I meant. Not simple to discover, but once you recognize the pattern, it becomes clearer. Early on, it took you a month to find and exploit a vulnerability, but now a lot of it is pattern recognition, both in the code and in the kinds of mistakes developers make.

Mat Rollings: Exactly. I really enjoy sitting down with code, reviewing it, and seeing the different ways people write things.

One of my favorite methods is to keep a large local collection of WordPress plugin code and write regex to look for specific patterns. A lot of bug bounty hunters do the same thing. I’ll write regex that loosely matches the kind of regular expression usage I think might be vulnerable, and that gives me a large list of leads.

Then I go through them and inspect each one. After you’ve seen the same kinds of problems enough times, you start to recognize when something feels vulnerable. You can tell whether it’s executing in the right place, whether it happens after sanitization, and whether WordPress will still have a chance to clean it afterward.

There are also cases where the same code pattern turns out not to be vulnerable because the transformation happens before WordPress sanitization, which is much safer. Once you build up the tools and experience, it becomes much easier to keep finding these issues.

I think I’ve found just over 600 WordPress vulnerabilities now.

Robert Abela: That’s a huge number.

Going back a little, you said you enjoy looking at people’s code and doing the research, but now with AI, people are not even installing plugins before submitting reports. It almost feels like AI is killing some of the fun. At CloudFest, for example, there was a capture-the-flag challenge, and the winning team found all the flags within eighteen minutes. They were technically good, but most of their time went into tuning the AI, not actually finding the vulnerabilities themselves.

On the way back, I was talking to someone who said the same thing: they installed a few tools, got everything running in half an hour, and suddenly AI was doing a lot of the work. It makes you more productive, but it also seems to remove some of the fun of trying things manually. Isn’t there something a bit ironic about that?

Mat Rollings: There definitely is. I’m seeing a lot of success when I augment my own work with AI, and I do know bug bounty hunters who have automated parts of the process so much that they seem less interested in the work itself.

I think what we’ll probably see is the easier, lower-hanging fruit getting picked off quickly by automated systems. The more creative work will still remain, especially as more code itself becomes AI-generated. That may create new classes of more complicated bugs that AI can’t easily reason about.

Once an issue spans multiple files, classes, or logic boundaries, a human who has built up knowledge of the application often still has an advantage. If you get close enough to a system, you can understand context in a way current tools still struggle with.

Robert Abela: Hopefully. Let’s see where we are in five years. It feels like five years is a very long time nowadays.

Mat Rollings: It’s going to change massively. We don’t know exactly where it’s heading, but it will definitely be an interesting ride.

Robert Abela: Thanks a lot, Mat. Thanks for your time, and thanks for sharing your demo. It was very insightful.

Before we end this episode, can you tell everyone where they can find you, get in touch, or learn more about you and your work?

Mat Rollings: I’ve got a blog at sec.stealthcopter.com, where people can find me. From there I link to my WordPress hacking resources, and a lot of my reports and proof-of-concept material are public on my GitHub.

I also created a small capture-the-flag site at wpctf.org. It has some live challenges. There’s one modern WordPress instance you can try to take over, and there’s also a fun challenge for people who know WordPress well that uses the original WordPress 1.0 codebase. I think it’s about twenty years old.

It took me a while to get that running, but it’s great fun because back then, there wasn’t the same incentive structure around finding WordPress bugs, so there are a lot of very strange and very bad bugs in that codebase. Anyone interested in this area would probably enjoy exploring it.

Robert Abela: Thanks a lot, Mat. We’ll add links to your websites and everything you mentioned in the show notes as well. Thank you again.

Thanks everyone for following, and we’ll see you in the next one.

Mat Rollings: Perfect. Thank you. Thanks. Bye-bye.