alt Hacker News> 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.
Since at least Drupal 7, the core CMS has included the concept of “private files.” The files are stored in a directory that is not served publicly by the web server. Instead the CMS generates a proxy URL for each file, which is handled by the CMS like a page URL before serving the file by streaming it through PHP. So: it’s a heavier load on the server, but you get full permission management by the CMS.
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.