🤝 Open to acquisition: what is built, what runs, and what a buyer inherits · 📉 Corrections record: AI mistakes, counted by class and fed back into the next run · 📢 New post: Same Software, New Nameplate: Langflow's Sixth KEV Entry Arrives Under a Different Vendor · 📝 Also fresh: The Sibling You Didn't Patch: ownCloud CVE-2023-49105 and a Clock That Started 1,010 Days Late · 🚦 Beacon — the FedRAMP 20x KSI emitter — see what it emits ✨ · 🆕 20x Hub: program reference, kept current · 🧪 Free tool: KSI Quick Check — paste, run, get the verdict
← Blog
FedRAMPConMonCISAVulnerability Management

The Sibling You Didn't Patch: ownCloud CVE-2023-49105 and a Clock That Started 1,010 Days Late

On August 27 CISA added three entries to the Known Exploited Vulnerabilities catalog. One of them has a 2023 CVE ID.

CVE-2023-49105, ownCloud Improper Authentication Vulnerability, CWE-287, federal remediation due August 30 — a three-day clock on a bug that published on November 21, 2023 and was fixed by the vendor that same week. Known ransomware campaign use: unknown.

A KEV entry arriving late is not by itself a story; we've written about the gap between when the risk starts and when the obligation does before. What makes this one worth an afternoon is the shape of the lateness. CISA did not overlook ownCloud in 2023. It listed ownCloud in 2023 — a different CVE, from the same advisory batch, published the same day, fixed by a different piece of software. The remediation ticket that closed cleanly in December 2023 almost certainly did not touch the code this entry is about.

The bug, and why its precondition is the default

ownCloud's WebDAV API accepts pre-signed URLs: time-limited links that carry their own authorization, signed with the file owner's signing key. The flaw is what happens when the owner has no signing key. In the vendor's description of the fix, the signing routine still ran — against an empty secret — so a URL signed with nothing verified against nothing and came back valid.

The practical consequence is in CISA's own one-liner: an attacker can access, modify, or delete any file without authentication if the username of the victim is known. Not a session to hijack, not a credential to phish. A username, which is not a secret in any deployment that also runs email.

The precondition sounds narrow until you read the vendor advisory, which notes that having no signing key configured is the default. This is the inverted-conditional pattern that makes advisories easy to misjudge: "only affects instances where X is not configured" reads as an edge case, and describes the majority of installs.

Version boundaries are unambiguous, which is a mercy:

  • Affected: ownCloud core 10.6.0 through 10.13.0
  • Fixed: 10.13.1

NVD carries a NIST primary base score of 9.8 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), and the MITRE secondary score agrees exactly — a rarer alignment than the scoring disagreements we've had to untangle elsewhere. Worth noting only as a curiosity: NVD classes the weakness as CWE-287, improper authentication, while the vendor advisory files it under CWE-665, improper initialization. Both are describing the empty key. The vendor is describing the cause; NVD is describing what the attacker gets.

One advisory, two clocks

ownCloud published three advisories on November 21, 2023. Set them side by side, because the fix artifacts are the whole point:

CVE Component Fixed in KEV listing
CVE-2023-49103 graphapi app 0.2.1 / 0.3.1 2023-11-30, due 2023-12-21
CVE-2023-49104 oauth2 app 0.6.1 never listed
CVE-2023-49105 owncloud/core 10.13.1 2026-08-27, due 2026-08-30

CVE-2023-49103 was the loud one — a bundled GetPhpInfo.php exposing the PHP environment, which in containerized deployments meant admin credentials in environment variables. It went on the catalog nine days after disclosure, was widely scanned for within hours, and generated a great deal of remediation work in December 2023.

That work was an app update. Removing or upgrading graphapi closes CVE-2023-49103 completely and does nothing whatsoever for CVE-2023-49105, which lives in core. An organization whose vulnerability program is triggered by the KEV catalog got a ticket in 2023 that said ownCloud graphapi, did exactly what the ticket said, verified the fix, and closed it. Core stayed below 10.13.1.

This is the failure mode that a catalog-driven program cannot see from the inside, because from the inside it looks like success. The row was cleared on time. The evidence was real. The scope of the remediation was set by the scope of the row, and the row named one app out of a batch of three.

If you are reconstructing this today, the question to ask your 2023 record is not "did we remediate the ownCloud KEV item" — you did — but what version did core end up on, and when. Those are different fields, and only one of them answers today's deadline.

CISA had it as actively exploited in 2023

Here is the part that changes the forensics work rather than the patching work.

NVD carries CISA's SSVC decision for CVE-2023-49105, and it is timestamped November 27, 2023:

  • Exploitation: active
  • Automatable: yes
  • Technical impact: total

Every value in the top band, recorded three days before the sibling CVE went on the catalog and 1,004 days before this one did. Under BOD 26-04's risk-sorted tiers, that combination is the shape that earns the shortest clock — which is presumably why the due date is three days rather than three weeks.

The required action for this entry names CISA's Forensics Triage Requirements, and that is where the date matters. A triage scoped to "since the KEV listing" looks at a 2026 window. The evidence window this bug actually implies opens at the CVE's publication in November 2023, or at the November 27 assessment if you want a defensible floor — and either way it is longer than most WebDAV access-log retention by a couple of orders of magnitude.

The public confirmation of what that window contained arrived the day after the listing. On August 28, threat researchers at Hunt.io published an analysis of an operation against an internet-facing ownCloud instance run by a Philippine nuclear research organization, recovering five purpose-built Python scripts that forged pre-signed WebDAV requests and rate-limited themselves with randomized sleeps to stay under alerting thresholds. Roughly 372 MB was staged for exfiltration, including material records, employee data, and credential stores holding BitLocker keys and KeePass databases. Simplified Chinese appeared throughout the tooling.

That is what "exploitation: active" looked like in practice, and it explains why a CVE from 2023 suddenly acquired a three-day federal deadline.

What the mechanism leaves behind

Before writing the triage section, ask whether the bug leaves an anomaly at all — the answer differs sharply by weakness class, and it determines whether hunting is worth the hours.

A deserialization RCE leaves something out of place — a crafted payload, or a process running under an identity that had no reason to spawn one. An authentication bypass leaves a well-formed request. A forged pre-signed URL is not malformed, does not trigger an auth failure, and is attributed in the logs to a real user who did nothing. Detection keyed on "unauthenticated access attempt" never fires, because from the server's perspective the access was authorized.

So the hunt is for misplaced trust rather than for intrusion, and it is narrow enough to actually run:

  • WebDAV requests carrying pre-signed URL parameters for owners who have no signing key configured. That combination has no legitimate producer. It is the single highest-signal query available here.
  • Reads and deletes attributed to accounts with no corresponding session. A pre-signed request arrives without a login; a user who "downloaded" 40 GB while never authenticating that week is the tell.
  • Access patterns paced to evade thresholds — slow and complete rather than bursty. The reported tooling deliberately spaced requests by a few seconds.
  • Whether the logs still exist for late 2023 at all. If they do not, say so in the record. "Retention did not cover the assessed exposure window" is a finding you can write down and act on; silence is not.

Scoping: is it even in your boundary?

Self-hosted file sync is a recurring guest on this blog's least-favourite list, alongside the network fabric nobody scoped and the edge device that turned out to be in scope after all. It arrives the same way each time: a team needed to move large files with people outside the org, stood up something that worked, and it kept working — accumulating documents that would be classified well above whatever the instance's control set assumes.

For a FedRAMP boundary, the questions between now and the deadline:

  • Is there an ownCloud instance in the inventory, and is that the only one? The one that costs you the deadline is the one that isn't on the diagram.
  • What core version is it on, produced from a query rather than from someone's recollection? 10.13.1 or later is the answer; anything from 10.6.0 up is exposed, and "we patched ownCloud in 2023" is not a version.
  • Is it internet-reachable? The required action puts asset exposure evaluation on the operator explicitly. The reported incident was against an internet-facing instance.
  • If it can't be patched inside the window, the vendor's own mitigation — refuse pre-signed URLs when the file owner has no signing key — is documentable as a compensating control with a date on it. The required action's alternative is blunt: follow BOD 26-04 guidance for cloud services, or discontinue use of the product where mitigation is unavailable.
  • Then decide about the data, not just the software. If a vulnerable instance was reachable during a window that has been assessed as actively exploited since 2023, the credentials stored in it are rotation candidates. The reported operation went after credential stores specifically, which makes this the practical rather than theoretical branch.

What we keep coming back to

The KEV item changes every few weeks and the lesson refuses to move: know what you run before you're asked to account for it under a clock. This entry sharpens it in a way we haven't hit before — the version you're being asked about may be one you already believe you handled. There was a ticket. It was closed on time, with evidence, by someone competent. It was about a different component in the same product, and the catalog row that drove it never mentioned core.

That's the gap the Novaprospect audit engine is built to close: component-level inventory where the version and the reachability live on the asset rather than being reconstructed under deadline, and a remediation record that ties the fix to the artifact it actually changed rather than to the advisory that prompted it. So when a 2023 CVE lands with a three-day clock, the answer is a query against what you're running now — not an archaeology project in last year's ticket queue.

The question this one leaves us with: for every finding you closed on a KEV deadline, can you name the artifact that changed and the version it reached? If the record only names the CVE, you know how completely the fix landed only until someone lists the sibling.

Reference