CVE-2026-90486 in openstatus
Summary
by MITRE • 09/13/2026
A vulnerability has been found in openstatusHQ openstatus up to f04c827112f30a11d571ebdad3892826034d6265. Affected by this vulnerability is an unknown functionality of the file apps/status-page/src/lib/proxy/resolve-custom-domain-rewrite.ts. The manipulation leads to server-side request forgery. The attack may be initiated remotely. This product uses a rolling release model to deliver continuous updates. As a result, specific version information for affected or updated releases is not available. The identifier of the patch is 86f370c9c20074c3c3fdec53a359874b8e670fd4. It is suggested to install a patch to address this issue. This issue got fixed with a silent patch.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/19/2026
The identified vulnerability in openstatusHQ, specifically within the file apps/status-page/src/lib/proxy/resolve-custom-domain-rewrite.ts prior to commit f04c827112f30a11d571ebdad3892826034d6265, represents a critical server-side request forgery flaw. This security defect arises from the application's handling of custom domain configurations within its status page proxying mechanism. The core technical issue lies in the insufficient validation and sanitization of user-supplied input when resolving or rewriting custom domains. By manipulating this specific functionality, an attacker can inject malicious URLs that are subsequently processed by the server-side components of openstatusHQ. This lack of rigorous input verification allows the application to act as a proxy for arbitrary requests directed at internal or external resources controlled by the attacker, thereby facilitating unauthorized network interactions from within the trusted environment of the target system.
The operational impact of this vulnerability is significant due to its remote exploitability and potential for data exfiltration or lateral movement within protected networks. An unauthenticated or authenticated attacker can leverage this server-side request forgery vector to access internal services that are not directly exposed to the public internet, such as database endpoints, administrative interfaces, or cloud metadata services. This capability effectively bypasses network perimeter defenses since the requests originate from a trusted application server. The consequences may include sensitive data disclosure, authentication token theft, or further compromise of backend infrastructure depending on the specific internal resources accessible through the forged requests. Given that openstatusHQ utilizes a rolling release model, determining exact affected versions is challenging as updates are delivered continuously without distinct version markers for every patch level.
From an industry standards perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), which describes flaws where a web server retrieves a specified resource from a user-supplied URL without proper validation of the destination address. This misconfiguration enables attackers to probe internal networks and access restricted services. Furthermore, in terms of tactical classification under the MITRE ATT&CK framework, this vulnerability supports techniques associated with Discovery and Collection phases, particularly those involving network service scanning or data exfiltration via proxy abuse. The silent nature of the patch indicates that while the code change is present at commit 86f370c9c20074c3c3fdec53a359874b8e670fd4, it may not have been accompanied by a formal security advisory or version bump notification for all users.
To mitigate this risk, immediate action is required to update the openstatusHQ instance to include the patch identified at commit 86f370c9c20074c3c3fdec53a359874b8e670fd4 or any subsequent release that incorporates this fix. Organizations should verify their current deployment against the latest available build to ensure the vulnerability is addressed. In addition to patching, implementing network-level controls such as egress filtering can provide a defense-in-depth layer by restricting outbound connections from the application server to only known and necessary destinations. Input validation strategies must also be reinforced on any custom domain input fields to prevent malicious URL injection at the application logic level before it reaches the proxy resolution module.