I’ve spent years optimizing WordPress sites, tuning MySQL, standing up server configurations, and chasing down performance bottlenecks. But nothing prepared me for the discovery I made when my own server began melting under relentless CPU load over the last month. It wasn’t a traffic spike. It wasn’t a failing plugin. It wasn’t even a bad query in the usual sense. The real culprit turned out to be something I never expected: the way WordPress redirects plugin cache matches.
On the surface, caching redirect results seems smart. If a redirect plugin detects a pattern match, why re-evaluate it for the same path? With exact one-to-one redirects, this behavior is harmless—even beneficial. But once a site is under attack, and you mix in LIKE or regex-style redirects, the redirect cache becomes a liability so severe that it can quietly destroy your server resources.
This is the story of how I uncovered that vulnerability by tracing performance issues from CPU spikes to MySQL saturation and then deeper into table growth that went completely out of control.
The Collapse Begins
My server had been running faster than ever since migrating to FlyWP, so the sudden rise in CPU consumption was concerning. MySQL was consistently pegged at high utilization, PHP workers were queuing, and even simple page loads felt sluggish. Restarting the server bought me a brief window of stability, but within hours, everything would degrade again.
Something was fundamentally wrong.
I switched on full query logging, expecting to find expensive joins or unindexed lookups. Instead, a surprising pattern emerged. A massive number of queries were hitting a redirect cache table created by WordPress redirect plugins. At first, this didn’t alarm me—caching redirect matches is a common technique to speed up future requests. But the number of cached entries was far beyond anything normal traffic could justify.
That led me down a rabbit hole.
Tracing the Problem to MySQL
The redirect cache table was ballooning in size. Every time I checked, it had thousands more rows. A closer look revealed why: each time a URL hit the server and any redirect rule used partial matching—LIKE comparisons, wildcard patterns, or regex—the plugin logged the result as a brand-new cache entry.
Hackers and crawlers weren’t attempting a handful of URLs. They were hitting thousands of permutations across the entire site:
/random-path
/random-path1
/random-path2
/admin-old
/admin-new
/login-old
/login-backup
Each of these paths triggered a new redirect evaluation. With pattern-based redirects in play, the plugin had to run expensive comparisons against its redirect rules. And since it cached every match, the table grew with every request made by bots, scanners, and brute-force tools.
The larger the table became, the more expensive each comparison grew. MySQL had no chance of keeping up. The server wasn’t being overwhelmed by legitimate traffic. It was being overwhelmed by the cost of managing redirect patterns.
The Hidden Danger of Pattern-Based Redirects
Redirect plugins for WordPress all promise flexible matching:
Redirect anything that starts with a specific path
Redirect anything that ends with a specific structure
Redirect patterns using wildcards
Redirect using full regex support
These features are powerful in theory and harmless on smaller sites. The danger appears only when redirect caching and pattern matching collide at scale.
Caching seems like good practice—and with exact redirects, it is. But when LIKE operators or regex patterns are involved, caching becomes a ticking time bomb. The combination of heavy lookup logic, continuous matching, and unbounded cache growth means a determined hacker doesn’t even need to target redirects specifically. Probing paths across your site is enough to cripple your server.
As more URLs are tested, more cache rows are created. As more rows are created, every new comparison becomes slower. As comparisons slow, CPU usage spikes. Eventually, MySQL becomes overloaded, PHP threads stall behind it, and the entire architecture begins to buckle.
This isn’t a flaw in one plugin. This is how WordPress redirect plugins universally operate when complex matching is enabled.
Finding the Root Cause
Once I had correlated the query load with redirect caching activity, I inspected the cache table directly. It had grown so large that even basic operations were slow. It wasn’t unusual to see thousands of rows added in a short window. Every scanner, crawler, and bot hitting unpredictable paths was adding more entries.
At this point, the vulnerability became clear: WordPress redirect plugins unintentionally allow attackers to incur exponential costs by probing large numbers of URLs. They don’t need valid paths. They don’t need to break in. They only need to force the redirect logic to do work.
The redirect engine did the rest.
The Fix
Once I understood the mechanics, the solution emerged quickly. Though the table name varies by plugin, every redirect plugin maintains a similar cache. In this case, I’m using Rank Math for my examples below:
Remove all LIKE and regex-style redirects: Any redirect rule that used pattern-based matching had to be disabled. Only exact one-to-one redirects were allowed to remain active. Because admin was responsive, I had to do this via an UPDATE query directly on my database.
UPDATE wp_rank_math_redirections
SET status = ‘inactive’
WHERE sources NOT LIKE ‘%”comparison":"exact"%’;
Truncate the redirect cache table: Clearing the table removed the massive backlog of stored matches:
TRUNCATE TABLE wp_rank_math_redirections_cache;
Monitor the server after cleanup: CPU load dropped almost instantly. MySQL stabilized. PHP workers resumed normal operation. The runaway growth stopped.
Exact redirects worked exactly as expected. Without wildcard or regex redirects, no attacks could force the cache to grow.
What This Means for WordPress Users
WordPress redirect plugins aren’t insecure in the traditional sense. But they share a common architectural vulnerability: caching redirect results is only beneficial when those redirects are exact. Once pattern matching is introduced, caching becomes dangerous because every unknown URL becomes a new cache entry.
On a high-traffic or heavily crawled site, that means:
Table growth becomes unbounded
MySQL becomes overwhelmed
CPU usage spirals
The server slows or fails
The best protection is simple:
Never rely on wildcard or regex redirects inside WordPress
Keep redirect logic exact wherever possible
Push complex redirect rules to NGINX or a CDN edge layer
Periodically inspect or clear redirect cache tables
Redirect caching is helpful when used with simple, exact rules. But once the site is hit with automated probing and you have pattern-based redirects, that same caching mechanism becomes a liability that can devastate server performance.
I learned this the hard way. Hopefully, this helps someone else avoid the same trap.
©2025 DK New Media, LLC, All rights reserved | DisclosureOriginally Published on Martech Zone: When WordPress Redirects Become a Server-Killing Vulnerability