LOW 3.9

CVE-2026-55592: Dashy URL Scheme Validation Bypass in Workspace View

Dashy, a self-hosted dashboard application, contains a vulnerability in its workspace feature that allows attackers to inject malicious links. When a logged-in user clicks a specially crafted workspace link, it can execute JavaScript code within the user's browser session. This code runs with the same permissions as the Dashy application itself, potentially exposing sensitive data or allowing unauthorized actions. The vulnerability has been patched in version 4.3.7.

Source data · NVD / CISA · public domain

CVSS
3.1 · 3.9 LOW · CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N
Weaknesses (CWE)
CWE-79
Affected products
0 configuration(s)
Published / Modified
2026-07-07 / 2026-07-08

NVD description (verbatim)

Dashy is a self-hostable personal dashboard. Prior to 4.3.7, Dashy's workspace view trusts the url query parameter and assigns it directly to an iframe source without scheme validation. If a logged-in user opens a crafted workspace link containing a javascript: URL, JavaScript runs on the Dashy origin and can read same-origin browser data, interact with the Dashy DOM, and send requests as the victim. This issue is fixed in version 4.3.7.

4 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

Dashy versions prior to 4.3.7 fail to validate URL schemes when processing the workspace query parameter. The application directly assigns user-supplied input to an iframe's src attribute without sanitization or scheme validation, enabling JavaScript protocol handlers (javascript:) to execute in the context of the Dashy origin. This allows attackers to bypass same-origin policy protections and access the DOM, session data, and perform authenticated requests as the victim user. The vulnerability is classified as CWE-79 (Improper Neutralization of Input During Web Page Generation).

Business impact

The primary risk is unauthorized access to workspace data and potential manipulation of user sessions. Since the attack requires the victim to click a malicious link while logged in, the exposure is contextual rather than universal. However, if Dashy is used to manage sensitive infrastructure dashboards or contains authentication tokens, an attacker could escalate the impact by extracting credentials or performing administrative actions. The low CVSS score reflects the requirement for user interaction and local attack vector, but does not diminish the sensitivity of potential data exposure.

Affected systems

Dashy versions before 4.3.7 are vulnerable. The vulnerability specifically affects the workspace view functionality. Only logged-in users who interact with a crafted link are at risk; unauthenticated users are not impacted. Self-hosted Dashy instances are the primary targets, as the attack relies on social engineering to deliver the malicious link to existing users.

Exploitability

Exploiting this vulnerability requires user interaction—the victim must click a crafted link while authenticated to Dashy. There is no remote code execution or automatic exploitation mechanism. An attacker would need to social engineer a victim into clicking the malicious link, making this a targeted attack vector rather than a mass exploitation scenario. The local attack vector and requirement for prior login further constrains the threat landscape.

Remediation

Upgrade Dashy to version 4.3.7 or later, which implements URL scheme validation for iframe sources. Organizations running self-hosted instances should prioritize this update as part of regular maintenance cycles. If immediate patching is not possible, restrict access to Dashy instances to trusted networks or implement web application firewalls that block suspicious query parameters.

Patch guidance

Apply the patch by upgrading to Dashy 4.3.7 or newer. Consult the Dashy project release notes and official documentation for version-specific upgrade instructions, as self-hosted applications may have dependencies on the deployment environment. Verify the upgrade by confirming the running version and testing workspace functionality with benign links to ensure normal operations are restored.

Detection guidance

Monitor for suspicious workspace query parameters in access logs, particularly those containing 'javascript:' or 'data:' schemes. Review user authentication logs for access patterns that precede unexpected API calls or data exports. If Dashy logs are retained, search for iframe source assignments that bypass expected URL patterns. Consider implementing browser-based monitoring or endpoint detection to identify JavaScript execution from unexpected origins within the Dashy application context.

Why prioritize this

While the CVSS score is low, this vulnerability should not be ignored. The combination of data exposure risk, authentication requirement for exploitation, and the fact that Dashy often manages sensitive operational dashboards warrants moderate prioritization. Organizations heavily invested in Dashy deployments for infrastructure management should prioritize the patch over less critical updates, while those using Dashy for less sensitive purposes can incorporate the upgrade into standard maintenance windows.

Risk score, explained

The CVSS 3.1 score of 3.9 (LOW) reflects a local attack vector, low complexity, requirement for user interaction, and limited scope. The vulnerability requires a logged-in user to click a malicious link, which significantly reduces the probability of successful exploitation at scale. However, the impact—confidentiality and integrity violations through same-origin JavaScript execution—is non-negligible for sensitive deployments. Organizations should weigh the technical CVSS rating against their specific risk tolerance and the sensitivity of data within their Dashy instances.

Frequently asked questions

Can this vulnerability be exploited without user interaction?

No. The vulnerability requires a logged-in user to click a crafted workspace link. Unauthenticated users are not at risk, and there is no mechanism for automatic or remote exploitation without social engineering.

What data can an attacker access if they successfully exploit this vulnerability?

An attacker can read data accessible within the same origin as Dashy, including the DOM, stored session tokens, local storage, and can send HTTP requests as the authenticated user. The specific impact depends on what sensitive information is stored within the Dashy application and which backend services it communicates with.

Is this vulnerability present in cloud-hosted Dashy instances?

The vulnerability applies to all versions of Dashy prior to 4.3.7, regardless of deployment model. However, since Dashy is primarily a self-hosted application, the risk profile may differ if managed by the vendor rather than an organization's own infrastructure.

What is the recommended timeline for patching?

Organizations using Dashy in production should upgrade to 4.3.7 as soon as practical within their maintenance windows. Given the user interaction requirement and low CVSS score, organizations can coordinate the patch with regular update cycles rather than treating it as an emergency, but should not defer indefinitely.

This analysis is based on the official CVE description and CVSS vector provided. Organizations should verify all patch versions, affected product editions, and deployment-specific implications against official vendor advisories before implementing remediation. Exploit code and weaponized proof-of-concept details are not provided in this analysis. Risk assessment should account for the sensitivity of data within your specific Dashy deployment and your organization's exposure to social engineering attacks. Source: NVD (public-domain), retrieved 2026-08-16. Analysis generated by SEC.co (claude-haiku-4-5).