Your CMS could leak sensitive information if you don’t have the proper security measures in place.
The big story about the budget was not so much its contents, but the fact the entire thing was leaked ahead of time by the Office for Budget Responsibility (OBR). Richard Hughes has now resigned as chair of the OBR over the embarrassing leak. A swift inquiry into what happened has already uncovered the issue:
According to the Guardian: “It [the inquiry] found the OBR had uploaded its budget documents to a link that it believed to be inaccessible to the public. However, because the organisation was using a particular add-on to the WordPress publishing system, the link ended up being live, unbeknownst to the OBR itself.”
Journalists could access the document simply by changing the date in a URL from "March" to "November". The document was ‘unpublished’ in the CMS, but it was sitting in a publicly accessible location—protected only by the assumption that nobody would guess the right web address.
This wasn't the result of a sophisticated cyber-attack or a security breach. It was the predictable outcome of relying on obscurity rather than proper access control.
Why this matters
The OBR's CMS set them up to fail. The content admins would have thought they’d done the right thing by leaving the content ‘Unpublished’ until the agreed go-live date. Without them knowing, their CMS already hosted the content, and a simple URL tweak led to a huge breach.
It’s vital that organisations like the OBR have far better procedures in place to stop this kind of leak. Budgets move markets, so leaks can enable illegal insider trading. It’s a problem that extends far beyond the OBR. Any public body will inevitably have documents it needs to protect until they are due to be published. Relying on a CMS that hosts the content and just hopes that journalists can’t guess the URL is a recipe for embarrassing leaks.
How your CMS creates risk
By default, when you upload a file to a website, it’s placed in the public file system. This was the case with the WordPress system used by the OBR, and most other CMS work in the same way.
This means the file has a direct URL and can be accessed by anyone who knows or discovers that URL. The file might not be linked from any published page, but it’s sitting there in the open, unprotected.
This is exactly what happened with the OBR document. The file was uploaded and had a predictable URL structure. It wasn’t linked from any public page yet, but the file itself was accessible to anyone who could construct the right web address.
For most content, this default behaviour is perfectly fine. But for organisations that regularly handle embargoed information—policy documents, financial reports, research findings, ministerial statements—this approach introduces unnecessary risk.
Private file systems for sensitive content
For our clients in the policy and regulatory space, we implement a different architecture. Market-sensitive files are placed in a private file system that sits outside the web root. These files don’t have direct URLs and can’t be accessed without proper authentication.
When a page is in draft or unpublished status, any attached files remain in the private file system. Even if someone discovers the file’s reference or guesses at a URL pattern, they can’t access the file without the appropriate permissions. Only when the page is published do the files move into the public file system, where they can be accessed publicly.
This isn’t just an add-on to a Content Management System - it’s a strategic enhancement that can significantly strengthen your security posture. While it requires thoughtful planning and careful implementation, it ultimately shifts the model from “hidden but accessible” to one where content is actually protected.
The cost of getting it wrong
The consequences of the OBR incident extended well beyond the early release of budget information. Not only did their chairman have to resign, but the organisation’s reputation also was damaged. Questions were raised about the reliability of sensitive information handling across government.
For organisations in the policy, regulatory, and public sector space, trust is everything. Your stakeholders, the media, and the public need confidence that you can handle sensitive information responsibly. A technical vulnerability that allows premature access to embargoed documents undermines that trust in ways that go far beyond the immediate incident.
Is your CMS properly configured for sensitive content?
If your organisation regularly publishes policy documents, research findings, financial reports, or other embargoed information, it’s worth asking: how is your CMS configured to protect unpublished files?
If you’re not certain, or if you know that files are placed in publicly accessible locations by default, you may be relying on obscurity rather than proper security.
It's worth understanding this and fixing it, especially if you’re already considering a website rebuild. It’s much easier to implement the right architecture from the start than embark on a costly retrofit later on.
At Numiko, we work with organisations across the policy, regulatory, charity, and cultural sectors to create digital platforms that are not only accessible and user-friendly, but also appropriately secure for the information they handle. If you’d like to discuss how your CMS handles sensitive documents, or if you’re planning a new website that will need to manage embargoed content, we’d be happy to talk through the right approach for your needs.
