Home/ Blog/ Security news/ Article
Blog · Security news

An old ownCloud flaw is now stealing files from unpatched servers, including a nuclear agency

CVE-2023-49105, an ownCloud auth bypass patched in 2023, is now in CISA's KEV list after a suspected Chinese operator stole nuclear-agency files.

A lone filing cabinet on an empty plain with one open drawer streaming papers away

A file-sync server on a nuclear research network was running a version of ownCloud that the vendor had patched almost three years earlier. That gap is the whole story. The flaw an operator used to walk off with reactor records, staff files, and encryption keys was closed in November 2023. What was still open, in August 2026, was an unpatched box that nobody had touched since it was stood up.

On August 27, the US cybersecurity agency (CISA) added CVE-2023-49105 to its Known Exploited Vulnerabilities list, the catalog of bugs confirmed to be under active attack, and set a federal patch deadline of August 30. The trigger was a report from threat-intelligence firm Hunt.io that a suspected Chinese-speaking operator had used the flaw to steal data from a Philippine nuclear research body. This is not a new vulnerability. It is an old one that never got patched, and the lesson is about patch latency, not about ownCloud.

What the flaw is, in plain terms

CVE-2023-49105 (CVSS 9.8) is an authentication bypass in ownCloud, the self-hosted file-sync and share platform. ownCloud can hand out pre-signed URLs so a user can fetch a file over WebDAV without logging in each time. The signature that is supposed to make those URLs trustworthy was, by default, computed against an empty secret. If the signing key was never set, an unauthenticated attacker who knew a username could forge a valid request and pull that account's files straight off the server.

The precondition matters more than it sounds. The vulnerable state is the default state: a deployment with no signing key configured. So "we never changed anything" is not the safe answer here, it is the exposed one. The bug affects the 10.6.0 line up to and including 10.13.0, and the fix landed in 10.13.1. Exploitation status is no longer theoretical: it is in CISA's KEV catalog, which means confirmed use in the wild.

A 2023 fix, exploited in 2026Nov 2023: Patched (10.13.1). Aug 13 2026: Theft found. Aug 25 2026: Report public. Aug 27 2026: Added to KEV. Aug 30 2026: Federal deadline.A 2023 fix, exploited in 2026Nov 2023Patched(10.13.1)Aug 13 2026Theft foundAug 25 2026Report publicAug 27 2026Added to KEVAug 30 2026Federal deadline
Sources: ownCloud advisory (2023); Hunt.io; CISA KEV.

Why a 2023 bug is a 2026 problem

The operator behind this campaign did not burn a zero-day. Every flaw Hunt.io documented was old and had a fix available. The ownCloud bug was patched in 2023. The second entry point, at a separate naval contractor, was a privilege-escalation flaw in the LiteSpeed Cache WordPress plugin (CVE-2024-28000) disclosed in 2024. This was a harvest of known, patch-available holes, not a sophisticated intrusion. That is the uncomfortable part: the attack surface was patch latency, not attacker skill.

Self-hosted file sync, a WordPress site, an attendance system: these are the shadow infrastructure of most networks. Installed once, useful, and then owned by nobody in particular. They do not show up in a patch dashboard because nobody registered them as something to patch. A KEV listing with a three-day federal deadline is a real forcing function, but only for federal civilian agencies. A research institute, a contractor, or a private company running the same software has no deadline at all. That absence of a forcing function is exactly why a 2023 CVE was still live and reachable in 2026.

How the theft actually ran

According to Hunt.io, the operator drove the ownCloud theft with five custom Python scripts. Four each targeted a single account; the fifth added directory enumeration and logging. The scripts constructed signed WebDAV requests against paths under /remote.php/dav/ using the empty signing secret, so the server accepted them as authenticated actions with no credentials supplied.

One detail is worth dwelling on because it doubles as a detection tell. The scripts inserted a random pause of roughly three to six seconds between requests, specifically to stay under volume-based alerting. From the nuclear agency alone, the researchers describe 176 files totaling about 372 MB staged for exfiltration, with a reference file pointing at roughly 9 GB of material overall: research-reactor component records, fuel inventories, radiation-safety documents, personnel files, passport scans, and encryption-key material from BitLocker and password managers.

The Philippine nuclear-agency theft, in numbers
9.8
CVSS severity
CVE-2023-49105, WebDAV auth bypass
~33 mo
Patch to exploitation
fix shipped Nov 2023
176
Files exfiltrated
about 372 MB, nuclear agency
Sources: Hunt.io analysis; CISA KEV. CVSS per the ownCloud advisory.

The same operator hit the naval contractor differently. There, Hunt.io reports a custom exploit for the LiteSpeed Cache flaw, which predicts a weakly seeded security hash to mint an administrator account, followed by a password-guessing run against xmlrpc.php. The haul included a full WordPress tree, a database dump, and the media library. According to Hunt.io, a separate 192 MB database dump from a ZKTeco BioTime attendance system referenced several Philippine science and research organizations, which suggests the target set was wider than the two confirmed intrusions.

On attribution, be precise about what is known. Hunt.io reports Chinese-language docstrings, code comments, and output folder names in the operator's tooling, folders labeled for finance, radiation safety, and nuclear-material accounts, and assesses that the operator is likely a native Chinese speaker. That is a well-supported analytic judgment, not a courtroom finding. The victims are a nuclear research body and a naval contractor; Hunt.io is the firm that discovered and reported the activity, not a victim.

How to catch this without waiting for the patch

Patching closes the hole. It does nothing to tell you whether you were already hit in the years the hole was open. Those are two separate jobs, and for a bug this old the second one matters as much as the first.

The attacker's own evasion is the signature. The three-to-six-second jitter defeats a volume threshold, but it cannot hide the shape of the access: a single source retrieving files across many different user accounts over WebDAV, often preceded by PROPFIND directory enumeration from that same source. On any normal baseline, one client walking multiple accounts' file trees is anomalous no matter how slowly it moves. That pattern is visible in ownCloud and reverse-proxy access logs today, with no patch required. If you run ownCloud, pull those logs back as far as you retain them and look for it. Hunt.io also published infrastructure indicators, including a staging server at 31.58.209[.]241; block and hunt for it.

This is the same lesson we keep returning to with aging, internet-reachable services, from an 18-year-old Cisco router flaw back under active exploitation to exposed server management interfaces leaking credential hashes: the exposure outlives the news cycle, and detection has to reach back further than the patch does.

What to do now

If you run any of the affected software, treat this as this week's work, not this quarter's:

  • ownCloud: upgrade past 10.13.0 to a current supported release, and set a strong signing key on any deployment that hands out pre-signed URLs so the empty-secret default cannot be abused.

  • WordPress with LiteSpeed Cache: update the plugin to 6.4 or later, which fixes the class of LiteSpeed Cache flaws attackers keep returning to, and restrict or disable xmlrpc.php if you do not need it.

  • Admin accounts: enforce unique passwords and multi-factor authentication, which would have blunted the password-guessing stage entirely.

  • Detection: alert on a single source retrieving files across multiple accounts over WebDAV, and on unexpected new administrator accounts. Both are cheap to watch and expensive to miss.

The bug here is three years dead. The exposure was very much alive, on a network holding nuclear-material records, because self-hosted software does not patch itself and nobody owned the job. State-aligned operators have noticed that the cheapest way into sensitive networks is not a new exploit, it is an old one you never applied. Treat your file-sync and content-management boxes as the sensitive infrastructure they quietly became. The same pattern of state-linked actors living off unpatched management software is not going to slow down.

Topics

Frequently asked questions

What is CVE-2023-49105 in ownCloud?

CVE-2023-49105 is an authentication bypass in ownCloud rated CVSS 9.8. When a deployment has no signing key set, which is the default, an unauthenticated attacker who knows a username can forge signed WebDAV requests and read that account's files. It was fixed in ownCloud 10.13.1.

Is CVE-2023-49105 being actively exploited?

Yes. CISA added it to its Known Exploited Vulnerabilities catalog on August 27, 2026, which confirms real-world exploitation. Threat-intelligence firm Hunt.io reported a suspected Chinese-speaking operator used it to steal data from a Philippine nuclear research body before the listing.

Which ownCloud versions are affected and fixed?

The flaw affects the 10.6.0 line up to and including 10.13.0, and the fix is 10.13.1. Upgrade past 10.13.0 to a current supported release, and set a strong signing key on any deployment that issues pre-signed URLs so the empty-secret default cannot be abused.

How can I detect exploitation of this ownCloud flaw?

Watch your ownCloud and reverse-proxy access logs for a single source retrieving files across many different accounts over WebDAV, often preceded by PROPFIND directory enumeration. The reported campaign paced requests three to six seconds apart to dodge volume alerts, so hunt on the access pattern, not on volume.

Who was behind the Philippine nuclear data theft?

Hunt.io attributes the activity to a suspected Chinese-speaking operator, based on Chinese-language code comments and output folder names for finance, radiation safety, and nuclear-material records. That is an analytic judgment, not a confirmed identity. Hunt.io is the firm that discovered and reported the intrusion, not a victim.

What data was stolen from the nuclear research body?

Hunt.io describes 176 files totaling about 372 MB staged for theft, with a reference file pointing at roughly 9 GB overall. The material included research-reactor component records, fuel inventories, radiation-safety documents, personnel files, passport scans, and encryption-key material from BitLocker and password managers.

Ready to meet the Guardians?

Deploys fast - agentless for monitoring and cloud, a lightweight agent for deep endpoint security. Just Suriq, standing watch.