CMS security updates: best practices for staying patched

In December 2005 the phpWordPress staff announced a critical SQL injection vulnerability in three parameters of index.php and released a patch. A customer who bought a copy afterwards asked whether it already contained the fix. Staff said versions after 1 December 2005 did. That exchange still describes the two questions every publisher has: what is the flaw, and is my copy fixed?

What is SQL injection and why did it matter?

OWASP defines SQL injection as inserting, or injecting, a SQL query through the input data a client sends to an application. If the application builds its database query by gluing that input into a string, the attacker’s text becomes part of the query. OWASP lists what a successful exploit can do: read sensitive data, modify database data, execute administration operations on the database, and in some cases issue commands to the operating system.

For a news site that means readers’ account details, unpublished stories, or the ability to alter published ones. It is one of the oldest web vulnerabilities, and it still appears in plugins and custom code.

How is SQL injection prevented?

OWASP’s cheat sheet names the primary defences in order of preference:

The PHP manual makes the same point for PDO: if an application exclusively uses prepared statements, no SQL injection will occur, but injection is still possible if other portions of the query are built up with unescaped input. One concatenated clause is enough. OWASP also recommends minimising the privileges of every database account, so that a flaw in the front end cannot, for example, drop tables.

As a publisher you will rarely write these queries yourself, but you decide which plugins to install and who writes your custom code. Ask developers whether their code uses parameterised queries, and prefer extensions that are actively maintained.

How do I know which version I am running?

The 2005 customer could not tell whether their copy had the fix. You should be able to answer in minutes. Keep a simple inventory with one row per site:

• CMS name and version
• Every plugin, module and theme, with versions
• Server software: PHP version, database version, operating system
• Who is responsible for updating each, and where the code is deployed

Many systems show core and extension versions on an admin status page, and a developer-managed site will record them in its deployment files. According to the vendor’s documentation, check where your CMS reports this. Treat “bought after the fix” as a hint, not proof. A bundled copy, a theme or a custom module may be older than the core, so verify the actual version against the advisory.

Where are security advisories published?

Each project has its own channel, and you should subscribe to those for everything you run.

• Drupal.org states that all security announcements are posted to an email list, with RSS feeds for core, contributed projects and public service announcements. Its advisories carry a risk rating from Less critical to Highly critical, scored out of 25 points on factors such as access complexity, authentication required, impact and exploit status.
• WordPress documents that minor core updates, such as maintenance and security releases, are applied automatically by default. Plugin and theme updates are not automatic unless you enable them.
• Plugin and theme vendors publish their own notices. If a vendor has none, count that as a risk factor when choosing it.

Drupal’s published schedule shows how predictable a mature process can be: a monthly security release window on the third Wednesday, with the caveat that not every window includes a core security release. A published window lets your team set aside time instead of reacting to surprises.

What should an update policy say?

A short written policy beats good intentions. Include:

1. Severity targets. For example, critical advisories applied within a set number of days, routine updates monthly. Choose numbers your team can meet.
2. A backup before every update. WordPress documentation advises backing up the database regularly and always before an upgrade, and notes you need both the database and the files to restore a typical site.
3. A staging copy. Test updates on a copy with realistic content before production, especially with custom themes.
4. A rollback plan. Know how to restore, and test the restore at least once.
5. An owner. One named person or agency, with a stand-in.
6. Retire what is unmaintained. A plugin with no updates and no author response is a liability.

Should I enable automatic updates?

For a small publication without custom code, automatic minor and security updates usually reduce risk more than they cause breakage. WordPress applies minor core updates this way by default. For sites with custom code, auto-update the low-risk layers, test the rest on staging, and keep a restorable backup. Our guide to self-hosting a CMS covers who carries this work when you run the system yourself, and the cost guide shows where maintenance sits in the budget.

What if I find a vulnerability or get breached?

Report a suspected flaw privately to the project’s security contact, not in a public forum. If your site is compromised, restore from a clean backup, update everything, rotate database and admin credentials, and review who has accounts. Keep the incident notes, because the next advisory is easier to judge when you know what happened last time.