There's a couple of passing mentions of Download Monitor, but also the timeline strongly implies that a specific source was simply guessing the URL of the PDF long before it was uploaded
I'm not clear from the doc which of these scenarios is what they're calling the "leak"
For those of you not closely following UK politics: the Office for Budget Responsibility (OBR) mistakenly published their Economic and Fiscal Outlook (EFO) document 40 minutes early, pre-empting the announcements by the Chancellor.
I agree, and I also am familiar with how WP Engine's 'GES' (global edge security) works. obr.uk points to two IP addresses held in the name of WP Engine, but they're actually BYOIP with Cloudflare. Cloudflare act as a caching layer, DDOS mitigation and WAF.
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.
> The available mitigation is at server level and prevents access to download or file storage directories directly. If configured properly, this will block access to the clear URL and return a ‘forbidden’ message. This is the second contributory configuration error – the server was not configured in this way so there was nothing to stop access to the clear URL bypassing protections against pre-publication access
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.
> It is the worst failure in the 15-year history of the OBR
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...
> 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.
Part of this is a product of the UK's political culture where expenses for stuff like this are ruthlessly scrutinised from within and without.
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.
So is the significance of this news based on what could have leaked if the document was not intended for the public? [1]
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.
They didn’t suffer a breach; they published a market-moving PDF early because they put it on a public WordPress server at a predictable URL with no access control, then acted shocked when someone typed it into a browser. The report dresses this up in solemn language about “pre-publication facilities” and “configuration errors”, but the reality is negligent basics: no authentication, no server-level blocking, blind faith in a plugin they didn’t understand, and not one person running the obvious test of guessing the URL before go-live. Their claim of “independence” just meant running the most sensitive part of their job on an underpowered, misconfigured website while assuming everything else would magically hold together. This wasn’t a cyber incident. It was institutional incompetence wearing a suit.
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.
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?
This doesn't seem to have much to do with Wordpress or its plugin ecosystem but rather an oversight since the behavior itself isn't necessarily a bug. I think the "well yeah, why would you use Wordpress?" comments kinda miss that.
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.
The log of events in that document is absolutely hilarious/pitiful. It’s like something lifted directly from an episode of In The Thick Of It.
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.
If you've ever looked at the admin panel of even a minor league, single page Wordpress site you'd probably recognize it as a major risk for any organization instantly. So many of the plugins look like spaghetti, with most you're trusting some random name to not be malicious. Unsurprisingly there are 60,000 CVE related to WP. I get that we all use a dozen node packages that we can't reasonably verify, but WP seems so much more wild west than that. I guess i's fine if you are a low value target, but a commercial CMS is not terribly expensive, and should be mandatory for any government org.
> 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 doso initially due to the website being overloaded with traffic
This one is painful to read. What was their option here? Calling WP Engine to take it offline?
29 comments
[ 5.8 ms ] story [ 49.4 ms ] threadI'm not clear from the doc which of these scenarios is what they're calling the "leak"
This is being treated as an incredibly big deal here: https://www.bbc.co.uk/news/articles/cd74v35p77jo
I find this an implausibly low number. It was all over Bluesky, X etc., not to mention journo Signal and WhatsApp groups.
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.
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.
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...
> 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 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.
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.
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.
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?
[1] https://www.bbc.co.uk/news/live/cly147rky81t
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.
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.
This one is painful to read. What was their option here? Calling WP Engine to take it offline?