If you run ownCloud Classic with the OpenID Connect, S3 Primary Storage, or Dropbox external storage apps enabled, three small patch releases landed on the same day (August 21, 2026), and all three are dependency-only security fixes. None of them touch your configuration or add new behavior. All three are worth a look during your next maintenance window, and one of them (OpenID Connect) is worth prioritizing.
Here’s what actually changed in each, with the CVE detail that the underlying changelogs didn’t spell out.
OpenID Connect 2.3.4: the one to prioritize
The OpenID Connect app bumps phpseclib/phpseclib to 3.0.56, closing out three CVEs at once. This is the app that parses certificates and key material handed to ownCloud by your identity provider during login, so all three matter more here than they would in a library used purely internally.
- CVE-2026-44167 (high, CVSS 7.5) is a denial-of-service issue: a crafted X.509 certificate or JWKS document can trigger uncontrolled resource consumption in phpseclib’s ASN.1 object-identifier decoder. It’s actually a bypass of an older 2024 fix for the same class of bug, patched again in 3.0.52 and later. Because the trigger is IdP-supplied key material, this is reachable through the exact integration point this app exists for.
- CVE-2026-55599 (moderate, CVSS 5.8) turns out to be more interesting than the original changelog entry let on: it’s a server-side request forgery flaw. When phpseclib validates a certificate’s signature, it reads a URL out of the certificate’s Authority Information Access extension and fetches it, with no destination filtering by default. In practice that means a maliciously crafted certificate could cause your server to make outbound requests to internal network resources it shouldn’t be able to reach. Fixed in 3.0.54 and later.
- CVE-2026-40194 (low) is a timing side-channel in phpseclib’s SSH2 packet comparison. It’s real, but SSH2 isn’t part of how the OpenID Connect app talks to an IdP, so it’s along for the ride in this dependency bump rather than something this specific app exposes.
Who should care: any deployment authenticating against an external IdP through this app. The SSRF path in particular is worth flagging to whoever owns your network egress rules: it’s the kind of bug that turns “we trust our IdP” into “we trust our IdP not to be compromised or spoofed,” which is a different and larger assumption.
Upgrade notes: no config changes or migrations. Update through your normal app-update path; there’s nothing else to do.
Primary Storage S3 1.6.2: a critical CVE, with a caveat worth stating plainly
This release bumps mtdowling/jmespath.php to 2.9.2, which the app’s changelog flags as fixing a critical-severity CVE. That’s not an exaggeration: CVE-2026-54133 carries a CVSS score of 9.8, meaning a worst-case exploitation could let an attacker run arbitrary code on the server, under a narrow set of conditions involving how the library evaluates certain expressions.
Here’s the caveat worth stating plainly: that worst-case scenario specifically requires an application to run the library in a particular internal mode against an expression that isn’t fully trusted. jmespath.php is a transitive dependency here, pulled in through the AWS SDK for PHP that this app uses to talk to S3-compatible storage. Whether the AWS SDK’s own use of jmespath.php ever exercises that specific code path isn’t something either the app’s changelog or the upstream advisory confirms one way or the other. In practice, taking the patch costs nothing and removes the question entirely, which is the simplest reason to just update rather than try to reason your way out of it. We’re intentionally not detailing the exact mechanism here; anyone who needs it for patch-verification purposes can find it in the linked upstream advisory in the sources section below.
The same changelog entry also flags something separate and more actionable: the 1.6.x line (the one that supports PHP 7.4 / ownCloud 10) is pinned to an older aws-sdk-php for compatibility reasons, and two other issues, GHSA-27qh-8cxx-2cr5 and CVE-2025-14761, stay open on that line as a result. They’re only resolved by moving to the 1.7.x line, which requires ownCloud 11 and PHP 8.3. If you’re on PHP 7.4, that’s a bigger conversation than this patch, but it’s one this changelog entry puts on the table.
Who should care: any deployment using S3-compatible storage as the primary backend. Upgrade notes: dependency bump only, no migrations.
Files External: Dropbox 2.1.2: routine, but check the details if you rely on host-based filtering
This one bumps Guzzle from 7.15.1 to 7.15.2 for CVE-2026-69246, a high-severity (CVSS 7.2) host-validation bypass. In short, two layers involved in resolving a request’s destination host can be made to disagree about which host is actually being contacted, which can defeat any host-based allowlist or SSRF filter an application has built on top of Guzzle. We’re not walking through the specific crafting technique here since it’s more useful as a reason to patch promptly than as a how-to; it’s documented in the upstream advisory linked in the sources section for anyone doing exposure analysis.
For the Dropbox external storage app specifically, this dependency is only in the request path if Dropbox external storage is configured and mounted. If it isn’t, there’s no functional exposure either way, and the update is routine maintenance.
Who should care: deployments with Dropbox external storage enabled, especially any that layer their own network egress restrictions around outbound app traffic. Upgrade notes: none beyond a normal app update.
The short version, if you’re triaging a maintenance window
- OpenID Connect 2.3.4 — update first if you authenticate against an external IdP. The SSRF path is real and reachable.
- Primary Storage S3 1.6.2 — update regardless; the CVE is critical-rated even though real-world reachability through this specific app is unconfirmed either way.
- Files External: Dropbox 2.1.2 — routine maintenance if Dropbox storage is in use; no action needed if it isn’t.
None of the three require configuration changes, and none carry migration steps. This is as close to a free lunch as security patching gets — the only cost is the update itself.
