Quarterly threat intelligence.
Long-form research from the RedSecLabs team on what we are seeing across compromised WordPress sites, trends, families, and the techniques attackers are reaching for now.
Findings from real cleanups, not repackaged vendor statistics
Threat reporting in this market is largely aggregate telemetry: counts of blocked requests, top attacked plugins, month-on-month percentages. Those numbers are real and they are mostly useless to a site owner, because knowing that attacks rose eleven per cent tells you nothing about what to do on Tuesday.
What we write up instead are mechanisms. How a particular payload achieved persistence, why it survived a filesystem cleanup, which table it hid in, what the scanner that missed it was looking for, and what would have caught it. That is the material that changes how someone configures a site.
Where a technique is novel enough that publishing it would help attackers more than defenders, we describe the class rather than the recipe. That judgement is made case by case and we would rather be criticised for withholding detail than for publishing a working method.
The three that account for most reinfections
Database persistence is the largest single cause of a site being cleaned and then compromised again within days. A serialised payload in wp_options, a fake transient that reinstates itself after deletion, or a hook that rewrites files on the next page load, the filesystem cleanup was thorough and irrelevant.
Credential reuse is the second. The compromise did not exploit a vulnerability at all; someone logged in with a password that appeared in a breach corpus years ago. No amount of scanning prevents that, which is why two-factor authentication matters more than any detection feature.
The third is the unpatched window on a disclosed plugin vulnerability. Exploitation begins within hours of public disclosure, patches take days to ship and weeks to be applied, and a large share of compromises land in exactly that gap.
Reading threat research without changing everything
The failure mode of security reading is reactive configuration: an article describes an attack, and a site owner enables six new controls without knowing whether any of them address their actual exposure.
A better test is whether a described technique would work against your site as configured, and that is a specific question with a specific answer. If the payload persisted in wp_options, run a database scan. If it arrived through credential reuse, check whether two-factor is on for every administrator. If it used an unpatched plugin, look at how quickly you actually apply updates.
Most sites need three or four controls done consistently rather than fifteen done once. Research is most useful when it tells you which three.
wp_options rows and serialised post meta. What changed, what to watch in 2026.Quarterly threat reports straight to your inbox.
One email per quarter. Only when we publish. No marketing.