{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.57.9"
      },
      "package": {
        "ecosystem": "npm",
        "name": "hfs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.57.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1022"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-12T00:13:03Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\nWhen adding a \"web link\" to the HFS virtual filesystem, the frontend opens it with `target=\"_blank\"` but without the `rel=\"noopener noreferrer\"` attribute. This allows the opened page to use the `window.opener` property to change the location of the original HFS tab.\n\n### Details\nWhile most modern browsers have fixes already implemented for this `target=\"_blank\"` exploit at the browser level, users on outdated browsers remain vulnerable. This means that if an admin of the HFS instance adds a link to an external third-party service (that they believe is safe at the time) and that service they added later becomes compromised, the malicious page could replace the original HFS tab\u0027s content with a phishing page. This does not require the admin account itself to be compromised, only that a legitimate linked site turns malicious.\n\n### Impact\nAffected users (people using old browsers without the browser level fix) could be misled into entering their HFS credentials or other sensitive information into a fake site controlled by an attacker. This vulnerability is fixed in most modern browsers, but adding `rel=\"noopener noreferrer\"` remains a best practice to protect legacy environments.\n\n\n### PoC\n\nFirstly, in the HFS admin page, under the filesystem (/~/admin/#/fs) press \"Add\" then \"web link\" then set the link to take the user to to an HTML file that exploits this vulnerability, here is an example of a malicious HTML file\u0027s code:\n\n```\u003chtml\u003e\n \u003cbody\u003e\n  \u003cscript\u003e\n    window.opener.location = \"https://example.org\";\n  \u003c/script\u003e\n\u003cb\u003eError loading...\u003c/b\u003e\n \u003c/body\u003e\n\u003c/html\u003e\n```\n\nNow, in the HFS folder you placed this web link in, open HFS and click the web link, if you aren\u0027t on a modern browser that fixed this vulnerability on the browser level, then switch back to the HFS tab that opened it, and you should be taken to \"https://example.org\" if you tried the code I provided, or whatever other page you tried.",
  "id": "GHSA-xcxh-6cv4-q8p8",
  "modified": "2025-08-12T20:23:55Z",
  "published": "2025-08-12T00:13:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rejetto/hfs/security/advisories/GHSA-xcxh-6cv4-q8p8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rejetto/hfs/commit/6531bcd2ab285af88f91831e30d8a03f5b9fe20d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rejetto/hfs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "HFS user adding a \"web link\" in HFS is vulnerable to \"target=_blank\" exploit"
}