CVE-2026-48153 Patch Review: Bandaid Fix in Budibase Object Store Error Handling

Vulnerability

CVE-2026-48153 and the corresponding CVE record describe a Server-Side Request Forgery condition in the Budibase OAuth2 SDK that allows a low-privileged user to trigger server-side requests to internal resources, bypassing central IP blacklist controls. A fix for that class of issue would normally be expected to touch OAuth2 request construction, URL validation, redirect handling, hostname/IP canonicalization, DNS rebinding defenses, or centralized egress filtering enforcement.

The supplied code reference, however, is a commit in backend object-store handling: f960e361f0b8d890e33b97d440605545a629c690. The changed files are limited to packages/backend-core/src/objectStore/objectStore.ts, related tests, and a log message in packages/backend-core/src/middleware/errorHandling.ts. None of the provided diffs show OAuth2 SDK logic, outbound HTTP client restrictions, or SSRF guardrails.

Patch

The patch primarily improves object-store error interpretation and bucket creation behavior for S3-compatible backends. It extends status-code extraction to include SDK v3 metadata, treats only explicit 403 as access denial, attempts bucket creation for other headBucket failures, recognizes BucketAlreadyOwnedByYou via both err.Code and err.name, and ensures promise-map cleanup via finally. It also adds tests covering these object-store cases.

const statusCode =
  err.statusCode || err.$response?.statusCode || err.$metadata?.httpStatusCode

if (statusCode === 403) {
  throw new Error("Access denied to object store bucket." + err)
}

promises[bucketName] = client
  .createBucket({ Bucket: bucketName })
  .catch((err: any) => {
    if (
      err.Code !== "BucketAlreadyOwnedByYou" &&
      err.name !== "BucketAlreadyOwnedByYou"
    ) {
      throw err
    }
  })

try {
  await promises[bucketName]
  return { created: true, exists: false }
} finally {
  delete promises[bucketName]
}

The added tests validate 404 handling through statusCode, $response.statusCode, and $metadata.httpStatusCode, plus fallback behavior for unrecognized or missing status codes. This is consistent with a robustness patch for object-store interoperability, especially Ceph/S3 SDK variants, not an SSRF remediation.

Review

Pros

• Source-grounded improvement in object-store compatibility: the patch now recognizes HTTP status from err.$metadata?.httpStatusCode, which aligns with AWS SDK v3/Ceph-style error objects in the supplied tests.
• Concurrency cleanup is stronger: replacing manual deletion with finally prevents stale entries in the in-flight promises[bucketName] map when createBucket throws.
• Race handling is more portable by accepting both err.Code and err.name for BucketAlreadyOwnedByYou.
• Test coverage is materially improved for the object-store path, including negative and edge cases.

Cons

• The patch is not semantically connected to the reported vulnerability. The CVE describes SSRF in the OAuth2 SDK, but the diff only touches object-store bucket management and a logging string.
• No evidence in the supplied commit shows enforcement of central IP blacklist checks, URL allow/deny validation, loopback/link-local/private-range blocking, redirect validation, or DNS/IP canonicalization for outbound OAuth2-related requests.
• The broadened behavior of attempting bucket creation for any non-403 headBucket failure may improve resilience, but it also changes operational semantics beyond a narrow bug fix and is unrelated to SSRF containment.
• The logging change from 400 to 5xx in errorHandling.ts is cosmetic and does not contribute to SSRF mitigation.

Verdict

Bandaid.

Based on the provided sources, this commit does not fix the root cause or even a visible enforcement point for CVE-2026-48153. It is an object-store robustness patch that improves S3-compatible error handling and test coverage. For an SSRF vulnerability in an OAuth2 SDK, reviewers should expect changes in the code path that accepts or derives remote URLs, resolves hosts, follows redirects, or applies centralized egress restrictions. None of those elements are present in the referenced commit. Therefore, as mapped to the stated CVE, the patch appears mismatched and should not be relied upon as a security remediation for the reported SSRF issue.