彙總 nhost 相關全部產品的 CVE 與安全漏洞情報，包括 CVSS、EPSS、公開時間與漏洞情報資料。
常見弱點模式包括 路徑處理缺陷，在 生產負載與軟體部署 使用場景中可能帶來 檔案覆寫 等風險。
相關漏洞資料主要來源於公開漏洞披露與安全公告，可用於評估歷史漏洞暴露面與修補優先順序。
| CVE | 摘要 | 來源 | 最高 CVSS | EPSS % | 公開時間 | 更新時間 |
|---|---|---|---|---|---|---|
| CVE-2026-41574 | Nhost is an open source Firebase alternative with GraphQL. Prior to version 0.49.1, Nhost automatically links an incoming OAuth identity to an existing Nhost account when the email addresses match. This is only safe when the email has been verified by the OAuth provider. Nhost's controller trusts a profile.EmailVerified boolean that is set by each provider adapter. The vulnerability is that several provider adapters do not correctly populate this field they either silently drop a verified field | [email protected] | 9.3 | 0.60% | 2026-05-08 | 2026-06-17 |
| CVE-2026-34969 | Nhost is an open source Firebase alternative with GraphQL. Prior to 0.48.0, the auth service's OAuth provider callback flow places the refresh token directly into the redirect URL as a query parameter. Refresh tokens in URLs are logged in browser history, server access logs, HTTP Referer headers, and proxy/CDN logs. Note that the refresh token is one-time use and all of these leak vectors are on owned infrastructure or services integrated by the application developer. This vulnerability is fixed | [email protected] | 2.3 | 0.27% | 2026-04-06 | 2026-06-17 |
| CVE-2026-34200 | Nhost is an open source Firebase alternative with GraphQL. Prior to version 1.41.0, The Nhost CLI MCP server, when explicitly configured to listen on a network port, applies no inbound authentication and does not enforce strict CORS. This allows a malicious website visited on the same machine to issue cross-origin requests to the MCP server and invoke privileged tools using the developer's locally configured credentials. This vulnerability requires two explicit, non-default configuration steps t | [email protected] | 7.7 | 0.36% | 2026-03-31 | 2026-06-17 |
| CVE-2026-33221 | Nhost is an open source Firebase alternative with GraphQL. Prior to version 0.12.0, the storage service's file upload handler trusts the client-provided Content-Type header without performing server-side MIME type detection. This allows an attacker to upload files with an arbitrary MIME type, bypassing any MIME-type-based restrictions configured on storage buckets. This issue has been patched in version 0.12.0. | [email protected] | 2.1 | 0.17% | 2026-03-20 | 2026-06-17 |