How We “Stole” a Non-Public CVE: Draft Artifacts as an Attack Surface

0# What were we doing?

We have been researching the WordPress publishing ecosystem for several weeks (conducting new research that we will publish shortly).

At the same time, we investigated the concept of the editorial pipeline and its relationship to confidentiality and the potential for obtaining sensitive information in any CMS environment (WordPress or otherwise).

This article briefly summarizes one of the main findings outside WordPress ecosystem that, beyond being merely anecdotal, requires us to reflect as an industry and as researchers.

1# We haven’t breached anything

The funny part is that nothing here looks like a breach on paper.

We didn’t touch an API. We didn’t touch an SSO. We never even saw a login page. We simply carefully watched how a top-tier cybersecurity firm published blog posts.

Like most of the industry, ourselves included, they run a fairly standard CMS stack where posts go through drafts, images get uploaded early, and editors tweak layouts. It’s the usual content-generation that sits next to some very serious vulnerability research.

Somewhere in that pipeline, they placed trust in the draft status as if it were a security boundary. And we took advantage of it.

2# The vector as seen by the attacker

From the outside, we only had their public site and recent posts, but that was enough to profile system behavior.

We noticed that media for new articles followed a clean pattern and files landed in predictable locations. If they had used WordPress, it would be something like /wp-content/uploads/year/month. In this case, outside of WordPress framework, it’s not that different.

They’re using /content/images/year/month with filenames that looked like an internal static export pipeline. Think of image paths such as:

/content/images/year/month/fixed-incremental.png

Once you see the pattern, you know roughly where the next assets will land. The key failure here is that their CMS, like most, serves these files as long as you know the URL, even if they are not yet linked from any public article. In this context, “unlinked” is not the same as “private”. It’s the default design.

We did the most boring offensive thing imaginable. We observed. We watched how public posts introduced new assets and tracked how the pattern changes. We discovered, for example, that the last article of November had begun to be drafted at least 13 days before its publication. It was significant in relation to the exposure window, but it wasn’t enough.

Several days passed and nothing changed until last Friday, December 5, when we found images that clearly did not belong to any article published at that time. They were images left hanging in the upload tree within a draft in progress.

3# From Funny Images to a non-public CVE

Most of those ghosts were harmless artifacts. Then we hit one that wasn’t harmless at all.

The slide title was clear.

At that point, we knew two things the majority of the world did not. First, there was a remote code execution bug in a widely IT deployed platform. Secondly, and more importantly, it suggested that a CVE had already been assigned, but had not yet been made public.

As we pulled in neighbouring images following the naming pattern, the story filled out. We found architectural diagrams, code snippets, screenshots of server-side template files and call-flow graphics. We didn’t need the full exploit to understand the risk. We knew the product family, the legacy .NET exploitation shape, and, in general, the risk posed by information of this nature.

In this case, unlike other articles on our blog, we didn’t reverse-engineer anything. The good guys did that part. We haven’t really done anything technical; we’ve just observed through the eyes of the attacker.

We don’t want to appear smarter than we are. We could have let this opportunity pass quietly, or waited for another one where the window between the upload and publication would have been longer. We could have “played around” to see if we could recreate the exploit. We could have done many things, but it seems that the best thing we can do is be responsible.

So, we notified to the affected blog, who informed us that the draft article will be published tomorrow (December 10) and that we can use this information as part of our research. Therefore, we believe it’s reasonable to write this short article to warn about a real risk that may have gone under the radar.

4# Why This Is a Problem for Anyone Who Handles Sensitive Information

It’s tempting to shrug this off as a one-off OpSec slip, but we have researched this topic sufficiently to say the the phenomenon is widespread and implications are significant.

This is an issue of timing. When a firm prepares a deep-dive on a cybersecurity matter, we are usually coordinating disclosure with trusted third parties. If draft leak during that window, we have shortened the race in favor of the attackers. In this case, we’ve confirmed that the publication date is tomorrow, which means five days. We know it could be more in other posts.

This also is an issue of trust. Security research companies rely on credibility. If an untrusted party can index and consume undisclosed material before the market does, we have created a scenario in which attackers have early access while those affected continue to believe they are safe.

Finally, this is an issue of precedents. Today it’s this CVE (perhaps not so noteworthy), but tomorrow it could have been a cloud provider escape or a VPN appliance. The mechanics remain the same: deterministic filename patterns, lack of access control and the assumption that no one is watching.

5# What We Should Change

If we run a research blog, our threat model must include threat actors profiling our infrastructure. We must treat our drafts as sensitive artifacts.

Draft assets belong in storage that is not directly web-routable or is only served via signed, short-lived URLs. Or alternatively, we need to use non-predictable names like UUIDs rather than sequential numbers. Our CDNs should not blindly cache and serve everything under the uploads directory. At the very least, we must establish a separate origin for sensitive draft content and insist on authorization.

On top of that, we have to watch our logs. Repeated probes into future-dated upload paths or systematic fetching of “orphaned” files are not normal reader behaviour. They are the signal of someone mapping our editorial pipeline.

6# Closing the Loop

We won’t spell out the affected vendors or the exploit steps; that isn’t our job. We are looking at a scenario where a top-tier firm did everything right regarding research and responsible disclosure, yet still leaked sensitive content because of how a CMS names its files, and that should give us pause for thought.

Attackers do not care whether the weak link is a complex ASLR-DEP protected endpoint or a simple upload pathname. They only care that weakness exists. So, in this case, if we publish security research, we must ask ourselves a blunt question: if someone watched our uploads directory for two weeks, how much of our future work would they see?

If the answer is too much, we must fix it before our next big write-up.

Update – December 11, 2025

Yesterday, as planned, the research we observed as a draft has been publicly released by watchTowr Labs as “SOAPwn: Pwning .NET Framework Applications Through HTTP Client Proxies And WSDL” (https://labs.watchtowr.com/soapwn-pwning-net-framework-applications-through-http-client-proxies-and-wsdl/). Vulnerability has implications that go far beyond the aforementioned CVE and which undoubtedly deserve a detailed reading of the article and the magnificent work done by Piotr.

The Barracuda Service Center RMM issue is now tracked as CVE-2025-34392 in the National Vulnerability Database (https://nvd.nist.gov/vuln/detail/CVE-2025-34392).

In case it isn’t obvious enough, we do not claim any credit for this CVE. All vulnerability research, exploitation primitives and vendor coordination come from watchTowr team. Our role in this story was limited to observing how draft media artifacts, already sitting on a public origin, can leak sensitive information before publication.

For full technical details on SOAPwn and CVE-2025-34392, see the official watchTowr write-up and the CVE entry in NVD.