> website activity logs show the earliest request on the server for the URL https://obr.uk/docs/dlm_uploads/OBR_Economic_and_fiscal_outl.... This request was unsuccessful, as the document had not been uploaded yet. Between this time and 11:30, a total of 44 unsuccessful requests to this URL were made from seven unique IP addresses.
In other words, someone was guessing the correct staging URL before the OBR had even uploaded the file to the staging area. This suggests that the downloader knew that the OBR was going to make this mistake, and they were polling the server waiting for the file to appear.
The report acknowledges this at 2.11:
> In the course of reviewing last week’s events, it has become clear that the OBR publication process was essentially technically unchanged from EFOs in the recent past. This gives rise to the question as to whether the problem was a pre-existing one that had gone unnoticed.
The URLS are predictable. Hedge-funds would want to get the file as soon as it would be available - I imagine someone set up a cron-job to try the URL every few minutes.
2025-Q1-earnings.pdf - smash it every 5 seconds - rarely worked out, generally a few seconds head start at best. By the time you pull up the pdf and parse the number from it the number was on the wires anyway. Very occasionally you get a better result however.
Given the market significance of the report it's damn obvious that this would happen. They should have assumed that security via obscurity was simply not enough, and the OBR should have been taking active steps to ensure the data was only available at the correct time.
> Hedge-funds would want to get the file as soon as it would be available - I imagine someone set up a cron-job to try the URL every few minutes.
It's not even just hedge-funds that do this. This is something individual traders do frequently. This practise is common place because a small edge like this with the right strategy is all you need to make serious profits.
The idea of the site hosting such an important document running independently on WordPress, being maintained by a single external developer and a tiny in-house team would seem really strange to many other countries.
Everyone is so terrified of headlines like "OBR spends £2m upgrading website" that you get stuff like this.
I think most of the tech world heard about the Nobel Peace Prize award so it doesn't seem that suspicious to me that somebody would just poll urls.
Especially since before the peace prize there have been issues with people polling US economic data.
My point is strictly, knowledge that they should poll a url is not evidence of insider activity.
This is being treated as an incredibly big deal here: https://www.bbc.co.uk/news/articles/cd74v35p77jo
It's not a technical error at all!
Technical errors are faults caused by technology, like a software or hardware bug. That's not what happened here. WordPress behaved exactly as it was supposed to.
The true cause is revealed later in the article,
> staff thought they had applied safeguards to prevent early publication, there were two errors in the way in which they were set up
The problem was the staff. It's a human error.
Given the importance of keeping this information confidential, they really ought to have a custom system for releasing it, not just configuring a third party Wordpress plugin.
As an industry we should know this by now. Defaults matter.
https://www.humanfactors.lth.se/fileadmin/lusa/Sidney_Dekker...
It makes me wonder what exactly is driving this.
That's the main flaw. Wordpress was configured to allow direct access to file, so they did not go through the authentication system. My experience is with Drupal (and a decade or more out of date), but it sounds like this behaves very similar. And this is a giant footgun, the system doesn't behave the way normal people expect if you allow unauthenticated access to files (if you know the URL). I don't understand why you would configure it this way today.
I would also assume that the upload happened via Wordpress, and not someone manually uploading files via FTP/SFTP or something like that. And in that case it would be entirely non-obvious to users that attaching a file to an unpublished document would put it in a place where it is potentially publicly accessible.
Wordpress does not have this in core—no surprise. I was surprised to find that it’s not even available as a community plugin. I had to pay a developer to write a custom plugin when building a members-only website in Wordpress.
Some folks downplayed the risk of someone finding and directly accessing the file URL if it wasn’t referenced on a public page. It’s crazy to see it created a national government incident in the UK.
To me it really doesn't make any sense to have that kind of giant hole in your permissions system from the start.
I found this one https://wordpress.org/plugins/prevent-direct-access/
I'm not sure publishing some information 3 hours early was really their biggest failure in 15 years...
Especially when much of the info was already public because hundreds of civil servants involved in making these decisions told their family members who told the press...
the effects are not minimal
if you're crooked: getting this sort of information early is potentially extremely lucrative
(why crooked? because trading on UPSI is illegal)
I'm not clear from the doc which of these scenarios is what they're calling the "leak"
A bunch of people were scraping commonly used urls based on previous OBR reports, in order to report as soon as it was live, as it common with all things of this kind
The mistake was that the URL should have been obfuscated, and only changed to the "clear" URL at publish time, but a plugin was bypassing that and aliasing the "clear" URL to the obfuscated one
We don't actually know that, it's just that the report did hit Reuters pretty swiftly.
Not hard to guess really. Wouldn't they know this was likely and simply choose a less obvious file name?
It's a ubiquitous practice to serve file uploads from a place outside of webserver middleware. This happens pretty much any time an upload permalink is on a different domain or subdomain, and it's standard on probably 90% of platforms.
Discord and Twitter file upload urls would be an example off the top of my head.
It would have been prevented if the public url used a random UUID, for example. But that's also not the behavior users necessarily want for most uploads.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::obr-leaky-bucket/myfirst.pdf",
"Condition": {
"DateGreaterThan": {
"aws:CurrentTime": "2025-11-26T12:30:00"
}
}
}
]
}The problem was essentially that, through a misconfiguration, they published it early.
Using WordPress plugins (with the exception of a limited sub-set) is like chewing gum you find on the sidewalk.
A technical oversight fail at multiple levels.
My guess is that the team responsible for this didn’t anticipate or at worst were not informed of its value to particular groups of people, at least not to a degree that would’ve warranted extra security measures.
Vs. if you just let Will and Pete do it in WordPress (or on Facebook, or such) then needed tasks might actually be accomplished.
But I still have a few questions. What is WordPress’s default behavior? Does it prevent files uploaded to the media library from having public URLs? Are they only public once they are inserted into a published post? Images make sense because they are embedded, but what about a PDF linked inside a post? My understanding is that media files become publicly accessible as soon as they are uploaded, as long as someone knows or guesses the URL. I mean, the leak could have happened even without the plugin?
The contents of market sensitive information critical to the finances of the entire country is behind stored on a damn vulnerable Wordpress server.
It's not even accidental access or a premature push of the button to release the document, but the site was regularly breached over and over and over again likely for insider trading ahead of the budget.
Might as well store the UK nuclear key codes on a large bright yellow Post-It note in Piccadilly Circus.
What a complete joke on the lack of basic security.
The amount of requests I get on my servers for WP related files is insane
This one is painful to read. What was their option here? Calling WP Engine to take it offline?
I find this an implausibly low number. It was all over Bluesky, X etc., not to mention journo Signal and WhatsApp groups.
Edit: Or (and more likely) cached/copies of the original.
Note that GES works a bit different to traditional Cloudflare implementations, HTML requests are basically passed through to the WP Engine NGINX reverse proxy server that's in front of the WordPress site (as opposed to being heavily cached with Cloudflare). Static assets, like a PDF - would indeed be cached with GES.
A honest-to-goodness proper fucking omnishambles.
11:52 - senior OBR and Treasury officials telephoned each other to discuss the breach. These Treasury officials made OBR staff aware of the URL leading to the PDF of the EFO that was accessible.
11:53 - OBR staff and the web developer attempted to pull the PDF from the website, and also to pull the entire website (e.g. via password protection), but struggled to do so initially due to the website being overloaded with traffic.
11:58 - an email was received to the OBR press inbox from a Reuters journalist confirming that Reuters had published details of the EFO and asking for comment.
12:07 - the EFO PDF was renamed by the web developer.
12:07 - the EFO PDF appeared on the Internet Archive. This means it was, at that precise time, visible entirely generally on the open internet via search engines. It is assumed that this happened very briefly in the rush to remove it.
WordPress is a nice piece of software, but the plugin situation is getting worse and worse. (Too many pending updates, premium features and constant upselling, selling of plugins to new sketchy owners...)
The plugin situation is a mess largely because Wordpress isn't a nice piece of software.
It's popular, and functionally it's great, but the codebase is really showing its age. Wordpress has never properly rearchitected because it would break plugins on a scale that would endanger its dominance.
Even if that is the case, the backend must validate.
Or is the significance of this news based on the advantages that players on the market who caught hold of it early will have? Is it only important to civilians relative to their ability to question who may be benefitting from the 40 minute head start that these players might have gained or (for the conspiracy-minded) been handed through nefarious means?
[1]: Which would lead me to ask why would it belong on a platform typically intended for publishing things in public.
At the same time, almost every piece of legislation in recent years has been relentlessly leaked and taken apart way before the official announcement in parliament, so this is a wee bit ridiculous.