Threat researchers report that a known ownCloud authentication-bypass vulnerability was used to retrieve sensitive files from a Philippine nuclear research organization. Hunt.io says material recovered from an exposed attacker-controlled server included nuclear records, personnel information, a KeePass database, encrypted files and a BitLocker recovery key. The affected organization has not publicly confirmed the incident, so the victim-specific findings remain reported rather than official.
Two underlying facts are confirmed independently of that attribution. ownCloud disclosed CVE-2023-49105 in 2023 and warned that it could permit unauthorized file access, modification or deletion. In August 2026, CISA added the vulnerability to its Known Exploited Vulnerabilities catalog based on evidence of active exploitation.
What the researchers found
Hunt.io says it discovered an open directory on 13 August containing custom scripts, transfer logs, offensive tooling and material taken from two Philippine organizations. The researchers held publication while CERT-PH coordinated notification to the affected organizations.
According to the report, five Python scripts generated pre-signed WebDAV requests using an empty signing secret. That matches the behavior behind CVE-2023-49105: on vulnerable deployments, an attacker who knows a valid username can construct requests accepted as that user without presenting the user's password.
The recovered staging folders reportedly contained 176 files totaling about 372 MB. A separate CSV referenced roughly 9 GB of material, but Hunt.io notes that most of that larger set was not present in the directory it analyzed. The safe conclusion is not that every referenced file was independently recovered; it is that the observed tooling, logs and staged documents support a serious unauthorized-access report.
A recovery key stored beside the protected data is not a separate control
The reported data categories make this incident directly relevant to secret handling. Hunt.io says the staged files included a KeePass database, AxCrypt-encrypted files and a BitLocker recovery key stored as a PDF. Encryption remains valuable, but its protection collapses when the key, recovery material or password database is reachable through the same compromised repository.
Recovery secrets should be isolated from the systems they unlock. That means separate access control, a different administrative trust path, limited custodians and an explicit retrieval record. A shared file platform is convenient for documents; it should not quietly become the universal home for documents, password stores and the keys needed to decrypt them.
What ownCloud administrators should do
- Apply the vendor's current supported update or patch. ownCloud recommends upgrading affected Server deployments to 10.13.3 or later, or applying its specific patch.
- Check the signing configuration. Hunt.io says the observed technique depended on an empty signing secret for pre-signed URLs.
- Review WebDAV activity. Look for unexpected PROPFIND enumeration and file retrieval spanning several user accounts.
- Assume accessed secrets are reusable. Rotate exposed passwords, recovery keys, API credentials and encryption material; do not merely remove the vulnerable endpoint.
- Separate recovery material. Keep disk-recovery keys and credential stores outside the document system they protect.
- Reduce retention and access. Delete obsolete sensitive copies and restrict each repository to people who still need it.
Where Secretus fits
Secretus can be used for a controlled handoff of a recovery password, replacement key or one-time administrative credential without leaving the plaintext in a normal shared folder. Short expiry and one-time access reduce the useful lifetime of a copied transfer; Team Split can keep a critical recovery value from being available to any single holder.
This is one layer of a wider design. Secretus does not replace patching, access reviews, endpoint security or a dedicated enterprise key-management system. If the receiving browser is compromised, a secret can still be captured after decryption. Verify the recipient and use a known-clean device before releasing replacement material.
What is confirmed—and what is not
The vulnerability, vendor remediation and CISA's active-exploitation designation are confirmed. Hunt.io's account is detailed primary research supported by recovered artifacts, but the named victim has not issued a public confirmation. The operator is described as likely Chinese-speaking based on language in scripts and folders; that does not establish a named group or state sponsor.