UK's OBR budget leak exposes the real cost of "cheap" publishing tools

When a government body accidentally leaks market-sensitive data, the instinct is to blame human error - but what if the real culprit is the technology it has chosen? The OBR's premature publication incident reveals an uncomfortable truth about consumer-grade CMS tools being used for high-stakes communication.

by Denis Haman

Published: 16:31, 02 December 2025

It is easy, in the aftermath of a public failure, to point fingers. It is also usually unhelpful, but fills the gap before the facts come to light. So, it's worth noting that I base my comments below on the official report into the incident in question - carried out at remarkable speed, by the former head of the UK National Cyber Security Centre, no less.

The failure in public here is the accidental publication online of critical financial data underpinning the official announcement of the UK's national Budget, last week, nearly an hour prior to the formal speech made in Parliament by the Chancellor of the Exchequer. In simple terms, the annual report for UK Plc was released early, and state-level and market-defining information was revealed before it should have been.

The Office for Budget Responsibility’s premature release of its November 2025 Economic and Fiscal Outlook was clearly not the result of recklessness or incompetence. A rapid and thorough investigation conducted within days shows a team working under intense pressure, using widely adopted tools, and following what would be considered normal practice across much of the public and private sector. It's worth reading the report to see how much of the timeline of events is recognisable to sites of all sizes in publishing and media.

And yet the outcome was serious. Market-sensitive information was accessible ahead of schedule, and trust was damaged. The organisation’s credibility took a hit through no malicious act, forcing its Chairman to resign within days and heaping embarrassment on the Chancellor and Prime Minister - the two most senior offices of state. 

The sad part is, the root cause was not a human's error in the usual sense. It was structural, driven by the choice of the platform.

WordPress and high-stakes environments: a mismatch waiting to happen

WordPress powers a vast proportion of the web. Time and again we have gone on the record as saying it has been a key tool in the history of the web. In the right place, for the right job.

It is flexible, still seemingly "open-source", and supposedly easy to staff and support via a rich ecosystem of plugins and hosting providers. For blogs, marketing sites and general communications, it is often an entirely reasonable choice.

But the OBR incident underlines a hard truth that many organisations prefer not to confront – WordPress was never designed for mission-critical, time-sensitive publishing. Those using it often find that "free" comes at an eye-watering cost, and "open-source" brings a level of business risk unrecognised until it blows up in their faces.

A basic security scan today (Dec 2nd) of the OBR site using an official WP scanning tool, wp-scan,, shows that six days after the Budget incident, the site still shows a pattern familiar to countless large WordPress deployments. On the OBR site, the listed issues shown by wp-scan include:

• Third-party plugins carrying known vulnerabilities, including unauthenticated stored XSS and CSRF risks
• Residual exposure through features like XML-RPC, still enabled largely for legacy compatibility
• Operational attack surface created by externally accessible WP-Cron and discoverable internal structure
• A reliance on plugin updates and configuration hygiene to maintain security rather than structural guarantees

None of this implies negligence. In fact, the OBR's WordPress core version is up to date, the hosting stack is modern, and the site is maintained by competent professionals who had well-understood processes in place to prevent the very thing that happened. From what I can see in the report, they deserve no flak at all.

And that is the actual point. 

Even well-run WordPress installations inherit systemic risk because the platform optimises for extensibility, not containment. Security is hard to maintain because of the very things which make WordPress attractive and "cheap" in the first place - plugins. The publishing tools are pretty basic until you invest in building the sort of tools that publishers need, using plugins and developer graft. And if you are building those tools, congratulations, you are now in the building-a-CMS game. 

Publishing is much more than just content management

For organisations handling market-making data, regulatory disclosures, or government communications, publishing is not a CMS problem. It is a control problem.

Enterprises need to be able to say with certainty:

• This document cannot be accessed before a specific point in time
• There is no alternate URL, API endpoint or cached variant which bypasses access controls
• Security does not depend on every plugin being configured perfectly and working only as expected
• Failure modes are closed by default, not open

WordPress does not fail because it is poorly engineered. It is excellent at doing what it was actually built for, and it fails because it was never intended to solve this class of problem, at least not without major investment and commitment to its upkeep.

Retrofitting enterprise publishing requirements onto a general-purpose CMS is like installing vault doors in a garden shed. You can add locks and alarms and spend big on guards and fluorescent jackets, but the structure underneath still dictates your risk. All the seemingly boring, yet best-practice features that specialised platforms provide are rarely valued, until mistakes happen.

Empathy first, architecture second

It is important to stress again that incidents like this are rarely caused by bad people or bad teams. They are caused by reasonable decisions made within constraining assumptions, by people attempting to do the right thing. In aviation terms, it is called the Swiss cheese scenario - no single problem in a chain of events leading to an accident could cause the accident. But when all the holes all line up...

WordPress is familiar. It strenuously bills itself as being cheap. It appears secure when well maintained and without any plugins. It has been “good enough” before in many a career.

But “good enough” is a dangerous standard when failure carries national, financial, or reputational consequences.

The OBR’s situation is not unique. Similar issues have occurred across government, finance, healthcare and regulated industries worldwide. The platform is not always the same - WordPress has many open source alternatives - but the ethos that lead to the scenario often is.

What enterprise publishing should look like

None of this is to suggest that enterprise platforms are flawless. They come with a cost and complexity which require organisational commitment to use properly, and in his report, independent expert Professor Ciaran Martin sums it up thus: "...content management systems, like other key systems, will not function as intended if they are not configured absolutely correctly".

But as I said, there is a philosophy of architecture and diligence which should guard against even those errors. Specialist systems should not 'fail open', allow content to be released before authorised, or leave timing and access controls dependent on manual processes.

A proper enterprise publishing platform treats content release as a controlled operation, not a page update. 

That means:

• Hard, non-bypassable publication controls enforced at the platform level
• No public access surfaces unless explicitly enabled
• Separation between content preparation and content delivery
• Minimal dependency on third-party extensions for core security guarantees
• Auditability that does not rely on web server logs or luck

This is not about gold-plating or vendor snobbery, but rather boringly, is about aligning tooling with risk and consequence. Basically, will the fundamentals of your chosen system lead to what has been described as the worst failing in your organisation's history? The ex-Chair of the OBR may well be asking himself that very question right now, and I have real sympathy for him.

A quiet lesson worth learning

The OBR incident was not anomalous, and it certainly was not due to a security breach. Content became publicly accessible prematurely because the workflow and publication controls were insufficient for a mission-critical release. The root cause was structural: the platform was not designed to enforce strict timing and access controls because, at its core, it lacks sophisticated, publisher-grade best practices. You have to build them yourself - that is the WordPress bargain.

Publishing has more than its own knowledge of this. Our periodic scans of WordPress-powered publisher and media sites reveal a similar recurring pattern resonant of the OBR incident, rather than it being a one-off. 

We today again tested 117 sites against the latest version of WordPress, 6.8.3, released on September 30th. Of the 117 sites:

• Fewer than one quarter, 29 sites, are on the latest version of WordPress
• 87 are on older versions of varying vintages
• 19 sites had well-documented security issues

While these sorts of issues did not cause the OBR incident, they do reinforce a broader lesson: “cheap and simple” platforms can look fine right up until a basic workflow or business-critical process fails, causing reputational, financial, or operational harm. 

They also don't maintain themselves. Yes, the OBR the WordPress site is on the latest version of WordPress, but it still has out-of-date plugins and some vulnerabilities. 

Organisations like OBR, constrained in budget and staffing, don't see themselves as publishers. However they absolutely need robust publishing controls. This is not a failure of people: it is a structural limitation of using a general purpose CMS for high-stakes content, and assuming risk has been removed by plugins and DIY.

For low-risk publishing, WordPress continues to be an excellent tool, and we would be one of the first to recommend it - even as it seems to be suffering its own crisis of identity. 

However for time-sensitive, confidential, or high-trust communications and publishing, it is self-evident that specialised platforms are the necessary choice. 

Choosing the right tool for the job is not controversial; don't set up your teams to fail.