CVE-2026-90486: OpenStatus SSRF Vulnerability

CVE-2026-90486 Overview

CVE-2026-90486 is a server-side request forgery (SSRF) vulnerability in openstatusHQ OpenStatus, an open-source status page platform. The flaw resides in the apps/status-page/src/lib/proxy/resolve-custom-domain-rewrite.ts file. Attackers can manipulate the custom domain rewrite logic to coerce the server into issuing unintended HTTP requests. The issue is remotely exploitable and requires user interaction. OpenStatus follows a rolling release model, so no discrete affected version identifiers exist. The patch is tracked under commit 86f370c9c20074c3c3fdec53a359874b8e670fd4 and was delivered as a silent fix. The weakness is classified under CWE-918: Server-Side Request Forgery.

Critical Impact
Successful exploitation allows a remote attacker to induce the OpenStatus server to make arbitrary outbound HTTP requests, potentially reaching internal services, metadata endpoints, or other resources not intended to be reachable from the internet.

Affected Products

openstatusHQ OpenStatus (rolling release, up to commit f04c827112f30a11d571ebdad3892826034d6265)
Self-hosted OpenStatus status page deployments using the custom domain proxy feature
Any downstream fork that includes apps/status-page/src/lib/proxy/resolve-custom-domain-rewrite.ts

Discovery Timeline

2026-09-12 - CVE-2026-90486 published to NVD
2026-09-15 - Last updated in NVD database

Technical Details for CVE-2026-90486

Vulnerability Analysis

The vulnerability affects the custom domain rewrite proxy used by OpenStatus status pages. The resolveCustomDomainRewrite function accepted host-derived input and used it to construct rewrite targets without adequate validation of the destination. Because the proxy path is invoked during request handling, an attacker who controls or influences the resolved host segment can steer the server toward attacker-chosen upstream endpoints.

The fix, referenced in Pull Request #2551, removes the vulnerable resolver from compose-page-action.ts and introduces applyPageSlugPrefix. The new function rebuilds the rewrite path from the resolved route locale and the page slug, rather than trusting the raw host-derived prefix. Cookie-scoped identifiers such as secured-${page.slug} now derive from the page slug, closing the trust gap that the SSRF relied on.

Root Cause

The root cause is unsafe use of externally influenced host and prefix data during rewrite path construction in resolve-custom-domain-rewrite.ts. getValidSubdomain returned the full host on custom-domain requests, and downstream logic used that value directly in rewrite composition. Missing allow-list validation on the resolved destination enabled the SSRF condition.

Attack Vector

The attack is network-based and requires user interaction. A remote actor crafts a request targeting an OpenStatus deployment with a manipulated custom domain or host header that traverses the rewrite path. When the proxy resolves the request, the server issues an outbound HTTP call to a location controlled or chosen by the attacker.

typescript

// Patch: introduces applyPageSlugPrefix, replacing the vulnerable resolver.
// Source: https://github.com/openstatusHQ/openstatus/commit/86f370c9c20074c3c3fdec53a359874b8e670fd4
import type { Page } from "@openstatus/db/src/schema";

import type { ResolvedRoute } from "../resolve-route";

/**
 * Swaps the resolved prefix for the page slug. Custom-domain requests resolve
 * `prefix` to the domain itself (`getValidSubdomain` returns the full host), but
 * the `[domain]` segment must be the slug — the login cookie key is derived from
 * it client-side and compared against `secured-${page.slug}` in the middleware.
 *
 * Rebuilds `rewritePath` from `route.locale` rather than string-replacing, so it
 * commutes with `applyPageLocaleOverride`.
 */
export function applyPageSlugPrefix(
  route: ResolvedRoute,
  page: Pick<Page, "slug">,
): ResolvedRoute {
  if (route.prefix === page.slug) return route;

  // resolveRoute always builds rewritePath as ["", prefix, locale, ...rest]
  const [, , , ...rest] = route.rewritePath.split("/");
  return {
    ...route,
    prefix: page.slug,
    rewritePath: `/${page.slug}/${route.locale}${rest.length ? `/${rest.join("/")}` : ""}`,
  };
}

The removal of the vulnerable import from compose-page-action.ts confirms that the resolver is no longer invoked in the request pipeline:

typescript

// Source: https://github.com/openstatusHQ/openstatus/commit/86f370c9c20074c3c3fdec53a359874b8e670fd4
-import { resolveCustomDomainRewrite } from "./resolve-custom-domain-rewrite";
 import { resolveDefaultRewrite } from "./resolve-default-rewrite";
 import { resolveEmailDomainAction } from "./resolve-email-domain-action";
 import { resolveIpRestrictionAction } from "./resolve-ip-restriction-action";

Detection Methods for CVE-2026-90486

Indicators of Compromise

Outbound HTTP requests from OpenStatus hosts to internal address ranges such as 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or 169.254.169.254.
Unexpected Host header values or custom domain values in status page proxy access logs that do not correspond to registered tenants.
Proxy activity referencing resolve-custom-domain-rewrite.ts code paths on unpatched builds.

Detection Strategies

Correlate reverse-proxy and application logs to identify status page requests that trigger outbound connections to non-public destinations.
Alert on OpenStatus egress traffic to cloud metadata services (169.254.169.254, metadata.google.internal).
Compare deployed OpenStatus commit hashes against the patched commit 86f370c9c20074c3c3fdec53a359874b8e670fd4 to flag vulnerable instances.

Monitoring Recommendations

Enable structured egress logging on the OpenStatus service account and forward events to a central analytics platform for long-term retention.
Monitor DNS resolutions performed by OpenStatus workloads for suspicious internal or private lookups.
Track configuration changes to custom domain settings and validate they map to legitimate tenant hostnames.

How to Mitigate CVE-2026-90486

Immediate Actions Required

Update self-hosted OpenStatus deployments to a build that includes commit 86f370c9c20074c3c3fdec53a359874b8e670fd4 or later.
Audit reverse-proxy and firewall rules to restrict OpenStatus egress to only the destinations required for status monitoring.
Review recent custom domain configurations and access logs for anomalous host values or outbound activity.

Patch Information

The fix is available in the OpenStatus repository via commit 86f370c9c20074c3c3fdec53a359874b8e670fd4, delivered through Pull Request #2551. Because OpenStatus uses a rolling release model, operators must rebuild or redeploy from a repository state that includes this commit. Additional metadata is available at the VulDB entry for CVE-2026-90486.

Workarounds

Place OpenStatus behind an egress proxy that enforces an allow-list of permitted outbound destinations, blocking private and link-local ranges.
Disable the custom domain feature until the patched commit can be deployed, if the feature is not required.
Apply network segmentation so that OpenStatus workloads cannot reach cloud metadata endpoints or sensitive internal services.

bash

# Example egress restriction using iptables to block cloud metadata and RFC1918 destinations
iptables -A OUTPUT -m owner --uid-owner openstatus -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner openstatus -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner openstatus -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner openstatus -d 192.168.0.0/16 -j REJECT