SQL injection is a string-concatenation bug with a blast radius

In WordPress the safe form is prepare with placeholders; in plain PHP it is PDO with bound parameters; in any modern framework the query builder does it for you unless you deliberately drop to raw SQL. The unsafe form is easy to recognise because it looks like string building: a query, a full stop, and a variable that came in from outside.

For a site owner the exposure almost always arrives inside somebody else's component. One plugin gluing a search term into a query is a route into every table on the account, including the users table. That is why the practical controls are a patching habit, a restricted database user, and a rule set in front while you wait for the fix.

You can do this over SSH in a few minutes. Search the plugin tree for direct query calls and look at what surrounds them. A query built with concatenation and no preparation is your candidate; a query passed through preparation with placeholders is fine. Then check whether the values reaching it came from a request at all — plenty of concatenated queries are joining constants and are harmless.

Do this before you install, not after you are compromised. A plugin with three hundred thousand installations and an author who last shipped an update two years ago is a risk you can measure in about the time it takes to read the changelog.

A WAF matches the shape of an injection attempt in the request and refuses it before PHP runs. That is genuine coverage for the window between an advisory going public and your update window arriving, and it costs you nothing on cached traffic because inspection never runs on a cache hit.

It is not a fix, and treating it as one is how people end up running vulnerable code for months. Neighbouring entries: WAF, Cross-Site Scripting, Database and Malware. Free SSL on every plan renews itself before expiry, so the transport half is never the thing you forgot.