Lessons from the OBR Leak for WordPress and Beyond

What the OBR Leak Tells Us About Publishing Sensitive Documents on WordPress

When the Office for Budget Responsibility (OBR) accidentally released its November 2025 Economic and Fiscal Outlook (EFO) early, it instantly became headline news. The report contained market-sensitive information and should not have been visible until the Chancellor finished speaking.

But this wasn’t a hack.

And it wasn’t an insider leak.

It was a very familiar web-development problem: predictable file URLs, accompanied by misunderstood website setup and a lack of process scrutiny.

OBR have released a statement themselves on their investigation into the leak:

OBR Investigation-into-November-2025-EFO-publication-error →

What went wrong? (In simple terms)

The OBR publishes several EFO PDFs each year.
For years, these URLs followed a similar pattern.
After doing some digging, it seems only from October 2024 onward did the naming become especially clean and easy to guess. Prior to that, the PDF releases contained more random file names.

Here are the file names for the last few years if you’re interested:
- OBR_Economic_and_fiscal_outlook_November_2025.pdf (November 2025)
- OBR_Economic_and_fiscal_outlook_March_2025.pdf (March 2025)
- OBR_Economic_and_fiscal_outlook_Oct_2024.pdf (October 2024)
- E03057758_OBR_EFO-March-2024_Web-AccessibleFinal.pdf (March 2024)
- E03004355_November-Economic-and-Fiscal-Outlook_Web-Accessible.pdf (November 2023)
- OBR-EFO-March-2023_Web_Accessible.pdf (March 2023)
- CCS0822661240-002_SECURE_OBR_EFO_November_2022_WEB_ACCESSIBLE.pdf (November 2022)
- CCS0222366764-001_OBR-EFO-March-2022_Web-Accessible-2.pdf (March 2022)
- CCS1021486854-001_OBR-EFO-October-2021_CS_Web-Accessible_v2.pdf (October 2021)


Anyone familiar with the naming convention could reasonably guess the next one.

On Budget Day, the OBR pre-uploaded the PDF in advance—a normal practice used so that documents are ready the second they need to go live. The assumption was that WordPress’s “draft / scheduled” state meant the file couldn’t be accessed until published.

Using the re-interpreted Murphy’s Law line from Interstellar:

“Whatever can happen, will happen.”

Or how Tim, our Glass Mountains front-end designer described it on our internal Slack, referencing Top Gun:

And in this case, it could happen, and it did.

A quick breakdown of the OBR Document process and what ultimately happened:

1. A plugin generated a public-facing download URL

The Download Monitor plugin created a direct link to the file that bypassed WordPress’s draft protection.

2. The server didn’t block direct access to the upload directory

With no access restrictions, typing the URL into a browser simply opened the PDF, even though the page linking to it wasn’t “published”.

At this point I would have liked to say a key piece of server software was lacking (such as bot protection, or a service like Cloudflare). This would prevent users or scripts from repeatedly checking URL schemes. For example, if someone attempted 10 consecutive guesses that all returned errors, bot protection would likely treat it as an “attack” and block the activity. However, in this situation, the URL structure was so clear, that a person or script would probably have found the correct URL within the first few attempts (before a bot/hack protection would be triggered anyway). Bot protection is not a substitute for secure publication workflows—but it can reduce opportunistic guessing.

3. The URLs were predictable

People were already trying possible filenames before the file was uploaded. As soon as it appeared on the server (11:30), they got in (11:35).

This combination of predictable path, plugin behaviour and missing server/file protection rules is what allowed the leak.

This isn’t all that unusual surprisingly for websites as a whole—and it isn’t unique to OBR.
All day, everyday, people (and bots/scripts created by people) are trying random URLs, for various reasons, even the mundane. You may have even done it yourself, for example manually typing a URL, in the hope of finding a page or product not yet released; such as trying to find your favourite brands latest product before they officially announce it—by trying a URL such as: myfavouriteproduct.com/new-for-2026/

 

Why gov.uk doesn’t necessarily have this issue

Most central government documents live on the GOV.UK Assets CDN, which uses long, random paths like:

https://assets.publishing.service.gov.uk/media/683d89f181deb72cce2680a5/The_Strategic_Defence_Review_2025_-_Making_Britain_Safer_-_secure_at_home__strong_abroad.pdf

That random ID (683d89f181deb72cce2680a5) isn’t guessable.

Even if a document is pre-uploaded, the obfuscation is strong enough that nobody is realistically brute-forcing it, and I’m assuming that the surrounding main Gov.UK website architecture has inherent protections against scripts randomly searching also.

OBR, by contrast, used a conventional WordPress uploads folder with human-readable filenames. That’s the difference.

However, in the OBR findings report, the following line stood out as something I would have worded differently:

“1.7 Unlike all other IT systems and services, the OBR’s website is locally managed and outside the gov.uk network.”

It’s to be made clear that being on the .gov.uk domain does not automatically give any protection.
Many public-sector bodies still use WordPress or WordPress-like publishing setups on the gov.uk domain:

• https://naturalengland.blog.gov.uk/
• https://laqm.defra.gov.uk/
• https://www.judiciary.uk/
• Hundreds of UK council websites run WordPress on .gov.uk domains.

A website is only as secure as the freedoms humans are allowed to use within it — whether that’s process or limitation. What I mean by that is: if you allow a user to upload a document in a rush, is the risk the fault of the human uploading it, or the lack of process that allowed that situation to happen?

As an example, it’s common to restrict how large an image a user can upload. As creators of WordPress sites for clients, we hand over a certain amount of control, and inevitably people upload huge images, alter layouts, or sometimes choose Comic Sans with a flashing red banner. Too much freedom eventually causes issues, visually or technically.

Interestingly, the OBR report mentions a line I don’t fully agree with:

“One simple example of this that emerged during the investigation is the remarkably small file size to which the OBR is limited in publishing.”

At Glass Mountains, in certain circumstances, we do the same. Uploading a huge, high-resolution image is a quick way to slow a website down. We often set sensible maximum caps to prevent someone clogging up the site, though we now use more advanced approaches that automatically resize images anyway.

The problem is the lack of prior thought to the process as a whole.

According to the OBR investigation:

“1.6 All organisational risks, including those relating to IT, information security and website, are discussed at Oversight Board meetings, which take place three or four times a year. At each of these meetings OBR staff present an updated risk register.”

I assume that items of “higher consequence” are being discussed at these meetings, but it is interesting that with so many meetings, a review of the publication process did not surface earlier.

What Glass Mountains would have done differently

When handling sensitive or time-critical publications, we suggest following best practices, no matter the size of the organisation:

1. Never rely on filenames for secrecy. If something must stay private until a specific moment, the URL must not be predictable.
2. Block direct access to upload folders if required.
3. Avoid plugins that expose file URLs unless configured correctly. Many download-manager plugins create “public routes” to files. This is convenient, but dangerous if misunderstood.
4. Use controlled staging for sensitive documents. For time-sensitive publications (like budget reports), safer options include:
   – private storage until the moment of publication
   – authenticated access directories
   – secure pre-staging areas
   – API/software-driven “release” triggers
   – using truly random asset URLs
5. Review the entire publication pipeline, not just the WordPress page. It’s easy to protect a page but accidentally expose a file. It’s always best to test both.

The OBR leak wasn’t caused by incompetence or carelessness. It was caused by:

• a small team
• assumptions about plugin behaviour
• human control over process without enforced checks
• and the pressure of publishing a huge document at a precise moment

Many organisations using WordPress (or any CMS) could make the same mistake.

The key lesson is simple:

If a file is on your server and publicly reachable, it’s public, whether or not you’ve linked to it yet. If the URL is predictable, someone will find it.
This could happen to any organisation, it’s only when processes are tested or scrutinised do these issues get surfaced, and many organisations likely don’t realise that.

What organisations should do now, if you handle/publish online:

• policy PDFs
• financial reports
• annual statements
• budget documents
• consultation papers
• anything that must be published at a specific time or remain hidden

…then it’s worth reviewing how your site handles uploads and publication.

At Glass Mountains, we help organisations with this situation:

• audit their file-publishing workflow
• tighten server-level access
• configure secure download management
• introduce safer staging and timed release methods
• or migrate to more robust asset infrastructures when appropriate

If you want help reviewing your current publishing setup, would like us to sense-check your website, or you just want a second pair of eyes, get in touch.

No Comments