汇总 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.81% | 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 |