Geph Security Incident Report: September 11, 2026

中文版本

Summary

On September 11, 2026, an attacker used a database password that had been accidentally published on GitHub in 2021 to copy most of Geph's PostgreSQL account database.

For the vast majority of users, no sensitive personal information was leaked. Geph never asks for contact information to register, and we never store browsing history, card numbers, or Alipay / WeChat Pay accounts. As long as you never bought or received a gift card (and didn't use a legacy username containing your email address), the leaked data contains no email address, name, or other identifying information about you. The only thing you need to do is replace your account secret (see below).

• When: from 01:28 UTC until the credential was revoked at 03:57 UTC.
• What was exposed: account secrets, legacy password hashes, payment records (amounts, timestamps, and transaction IDs, not card numbers or Alipay / WeChat Pay accounts), and 1,053 gift card recipient email addresses.
• What was not exposed: browsing history, traffic encryption keys, and payment card details, because Geph never stores them.
• Service impact: the export triggered a database-locking failure that disrupted the broker service from 01:58 to 03:44 UTC.
• Action required: update to Geph 5.9.0 and replace your account secret. Plus users who replace their secret receive 7 days of extra Plus time as compensation.

What information was leaked?

From database logs, we know for certain the following information was leaked. However, during the unauthorized access, queries that took under a second to fulfill were not logged, so the attacker could have accessed other small pieces of information without our knowledge.

See What we never stored for the information that could not have leaked.

Most notably, the following information was leaked:

• Account credentials:
  • Account secrets: all account secrets, in plaintext, and linked internal account IDs.
  • Authentication tokens linked to account IDs.
  • Legacy usernames, password hashes, and associated account IDs.
• Account metadata: login timestamps, and subscription tiers with start and end times.
• Payment invoices: purchase amounts, timestamps, payment methods, and transaction references, linked to Geph accounts.
  • Note: "payment records" here means internal billing data like invoice and transaction IDs only. It does not include bank card numbers, bank transaction numbers, credit card details, or Alipay / WeChat Pay accounts or transaction numbers. We never stored those, so they could not have leaked.
• Gift card information:
  • All 1,053 unique recipient email addresses.
  • Gift card codes, sender names, purchasing accounts, and redemption data.
• Obsolete infrastructure secrets for Geph 4: none of the leaked legacy credentials were active except for bridge_secret, the broker's bridge-registration token. This token has since been replaced.

What we never stored

The following information was not leaked because it was never stored in our database:

• VPN browsing histories or encryption keys: Geph never stores per-user browsing history or tunnel encryption keys.
• User contact information: email, phone number, address, etc. Geph does not ask for any contact information to register an account, so there is none to store. Exceptions: gift card recipients' emails, and legacy usernames that contained the user's email address.
• Identifying payment details: bank account numbers, credit card details, and Alipay / WeChat Pay payment accounts are never stored.

What users should do

Geph account secrets generally does not allow the attacker to access any sensitive information. However, the attacker could log in with any existing user account at any time and consume users' bandwidth and devices limit.

But as long as you replace your account secret before the attacker does, your account will be secure from the attacker. We've designed a feature in version 5.9.0 that automates this process:

Replace your account secret

1. Update Geph to version 5.9.0. Geph will prompt you to replace your account secret:
   

   

   image840×1600 106 KB

   Geph asks you to replace your account secret.

2. Save your new secret, confirm, and continue. Your old secret stops working, and your other devices will not continue to function.
   

   

   image840×1600 103 KB
   
   Your new secret. (The secret shown is an example.)

3. On each of your other devices, log in with your new secret. Geph detects that the old secret was replaced; choose "I replaced it on another device" and enter your new secret.
   

   

   image840×1600 86.2 KB
   
   Geph notices the old secret no longer works.
   

   image840×1600 48.3 KB
   
   Log in with the new secret from your first device.

4. If you have a legacy username and password, they stop working once you replace your account secret. If you used that password on any other service, change it there.

Plus users: as compensation for the inconvenience, replacing your account secret adds 7 days of extra Plus time to your account.

If someone else replaced your secret

We currently do not detect any malicious account-manipulation behavior. However, if the attacker replaces your secret before you do, you will be logged out and not be able to log back in. If Geph shows "This secret was already replaced" and you did not replace it yourself, choose "I didn't do this", then:

• Free users: log out and create a new account.
• Plus users: create a new account, then email support@geph.io to transfer your remaining Plus time. Include:
  1. Your old account secret
  2. Your new account secret
  3. Proof of payment for your Plus plan

How it happened

How did the database credentials leak?

We discovered that the leaked credentials were accidentally uploaded to GitHub in this website billing source code file back in 2021.

image916×591 46.9 KB

The database credentials did not change over the past 5 years; however, the September 11, 2026 intrusion is the only known unauthorized access of the Geph database.

What exactly happened?

The logs show unauthorized database access from two IP addresses.

One client seemed to be Navicat (a common database-management tool) and queried the database interactively, including a completed read from the legacy secrets table.

Another identified itself as pg_dump and attempted to export the entire database. Both authenticated with the administrative database credential. We do not know whether the two addresses were operated by the same person.

The export then caused a broker outage:

1. The long-running whole-database export held a read lock on the exit-registry table.
2. A few minutes later, the broker started a routine VACUUM FULL maintenance operation on that table. It requested an exclusive lock and waited behind the export.
3. Subsequent broker reads and writes queued behind the waiting maintenance operation.
4. The blocked requests filled the broker's upstream connection capacity. Failures and retries rose sharply, producing large numbers of short-lived HTTPS connections.
5. The host's network connection-tracking table filled, and the kernel began dropping packets.

Our team first noticed the full connection-tracking table and increased that table's capacity; this reduced the network symptoms but did not resolve the database lockup.

image824×613 131 KB

During the outage:

• New connections, reconnections, and other broker-dependent operations were disrupted.
• Established tunnels continued forwarding traffic.
• Plus connections could have experienced reduced speeds, because bandwidth credits could not be replenished.

Terminating the waiting maintenance session at 03:40 UTC released the broker queries, and the export was terminated at 03:42. The broker had recovered by 03:44.

Who was responsible?

We only know that the attacker accessed the database from 2 Hong Kong IP addresses, one belonging to Alibaba Cloud and the other to StarCloud. These are cloud hosting addresses, so their location does not indicate where the attacker is. We refer to "the attacker" throughout this report, but we do not know whether one or more people were involved.

Timeline

All times below are UTC on September 11, 2026.

Remediation

Containment

• Removed the attacker's access. The database admin credentials were revoked at 03:57 UTC. We also disabled all non-admin database credentials, since they were accessible with admin privileges.
• Revoked the compromised bridge registration key, so that the attacker cannot insert false bridges to spy on users' traffic.
• Temporarily disabled user deletion, to prevent the attacker from sabotaging user accounts. So far we have not seen any malicious account manipulation. We will re-enable user deletion once most users have replaced their account secret.
• Account secret replacement in Geph 5.9.0 (see What users should do).

Hardening

• Account secrets are now stored hashed instead of in plaintext, so a future database compromise would not leak all account secrets like this time.
• Database access is restricted by IP whitelist.
• Legacy username/password login is being retired, as many user-created passwords are weak and their hashes are easily brute-forced.

Lessons we learned

This was the first intrusion into the Geph system that we are aware of. Three failures on our part made this possible:

1. We published our main database admin credentials to a public GitHub repository, and did not discover it for 5 years.
2. We stored account secrets in plaintext instead of hashing them. (We made this choice because account secrets are high-entropy and unguessable, removing one reason why password hashing is used)
3. We did not restrict database access by IP address, which would have blocked access from all unauthorized IP addresses.

Because of our long-standing policy to collect as little data as possible (like not collecting any contact info at registration), and then minimally log whatever data we do collect, the database did not contain registration contact details, browsing history, or payment card information.

We sincerely apologize for the data leak, and all the trouble that replacing the account secret will cause all our users. We hope that by maintaining maximal transparency about what leaked and how everything was compromised, we can give our users the most clarity and best learn from past mistakes ourselves. We are continuing to improve our database practices and system-wide defense to make Geph a more secure VPN.

-- @nullchinchilla + @thisbefruit, the Geph team

迷雾通安全事件报告：2026 年 9 月 11 日

摘要

2026 年 9 月 11 日，攻击者利用一个于 2021 年被意外发布到 GitHub 上的数据库密码，复制了迷雾通 PostgreSQL 账户数据库的大部分内容。

对于绝大多数用户，没有任何敏感个人信息被泄露。 注册迷雾通账户无需提供任何联系方式，我们也从不存储浏览记录、银行卡号或支付宝/微信账号。只要您没有购买或收到过礼品卡（也没有使用包含电子邮件地址的旧版用户名），泄露的数据中就不包含您的电子邮件、姓名或其他可识别身份的信息。您唯一需要做的，是更换账户密钥（见下文）。

• 时间： 从 UTC 01:28 起，直至 UTC 03:57 该凭据被吊销。
• 泄露的信息： 账户密钥、旧版密码哈希、支付记录（金额、时间和交易编号等，不含卡号或支付宝/微信账号），以及 1,053 个礼品卡收件人电子邮件地址。
• 未泄露的信息： 浏览记录、流量加密密钥和支付卡信息，因为迷雾通从不存储这些信息。
• 服务影响： 数据导出引发了数据库锁定故障，导致中介服务器（broker）在 UTC 01:58 至 03:44 期间服务中断。
• 需要您采取的行动： 将迷雾通更新至 5.9.0 版本，并更换您的账户密钥。Plus 用户更换密钥后，将额外获赠 7 天 Plus 时长作为补偿。

泄露了哪些信息？

根据数据库日志，我们可以确定以下信息已被泄露。但在未授权访问期间，耗时不到一秒的查询没有被记录，因此攻击者可能在我们不知情的情况下获取了其他少量信息。

未被泄露的信息请参见我们从未存储的信息。

最主要的泄露信息如下：

• 账户凭据：
  • 账户密钥：所有账户密钥（明文）及其关联的内部账户 ID。
  • 与账户 ID 关联的身份验证令牌。
  • 旧版用户名、密码哈希及关联的账户 ID。
• 账户元数据：登录时间戳，以及订阅等级及其开始和结束时间。
• 支付账单：与迷雾通账户关联的购买金额、时间戳、支付方式和内部使用的的交易编号。
  • 请注意： 这里的“支付记录”仅指订单/发票编号、交易编号这类账单数据，不包括银行卡号、信用卡信息或支付宝/微信账号或单号——这些信息我们从未存储，因此也不可能泄露。
• 礼品卡信息：
  • 全部 1,053 个不重复的收件人电子邮件地址。
  • 礼品卡兑换码、赠送人姓名、购买账户和兑换数据。
• 迷雾通 4 旧版基础设施密钥：泄露的旧版凭据中，除 bridge_secret（中介服务器的网桥注册令牌）外均已失效。该令牌现已更换。

我们从未存储的信息

以下信息没有泄露，因为我们的数据库从未存储过它们：

• VPN 浏览记录或加密密钥：迷雾通从不存储任何用户的浏览记录或隧道加密密钥。
• 用户联系方式：电子邮件、电话号码、地址等。注册迷雾通账户无需提供任何联系方式，因此我们没有可存储的联系信息。例外： 礼品卡收件人的电子邮件，以及包含用户电子邮件地址的旧版用户名。
• 可识别身份的支付信息：我们从不存储银行账号、信用卡信息以及支付宝/微信支付账户。

用户需要做什么

迷雾通账户密钥通常无法让攻击者获取任何敏感信息。但是，攻击者可以随时登录任何现有账户，消耗用户的流量和设备数量限额。

只要您在攻击者之前更换账户密钥，您的账户就不会受到攻击者的影响。我们在 5.9.0 版本中设计了一项功能，可自动完成这一过程：

更换您的账户密钥

1. 将迷雾通更新至 5.9.0 版本。 迷雾通会提示您更换账户密钥：
   

   

   image840×1600 102 KB
   
   迷雾通提示您更换账户密钥。

2. 保存新密钥，确认后继续。 旧密钥将失效，您的其他设备也将无法继续使用。
   

   

   image840×1600 97.8 KB
   
   您的新密钥。（图中显示的密钥仅为示例。）

3. 在您的每台其他设备上，使用新密钥登录。 迷雾通会检测到旧密钥已被更换；请选择“我在其他设备上更换了”，然后输入新密钥。
   

   

   image840×1600 81.3 KB
   
   迷雾通检测到旧密钥已失效。
   
   

   image840×1600 44.3 KB
   
   使用第一台设备上显示的新密钥登录。

4. 如果您有旧版用户名和密码，更换账户密钥后它们将失效。如果您在其他服务中也使用了该密码，请在那些服务中修改密码。

Plus 用户： 为补偿给您带来的不便，更换账户密钥后，您的账户将额外获赠 7 天 Plus 时长。

如果有其他人更换了您的密钥

目前我们尚未发现任何恶意篡改账户的行为。但是，如果攻击者在您之前更换了您的密钥，您将被退出登录且无法重新登录。如果迷雾通显示“此密钥已被更换”，而您并没有自己更换密钥，请选择“不是我操作的”，然后：

• 免费用户： 退出登录并创建新账户。
• Plus 用户： 创建新账户，然后发送邮件至 support@geph.io，将剩余的 Plus 时长转移到新账户。邮件中请提供：
  1. 您的旧账户密钥
  2. 您的新账户密钥
  3. Plus 套餐的付款凭证

事件经过

数据库凭据是如何泄露的？

我们发现，泄露的凭据于 2021 年被意外上传到了 GitHub 上的这个网站计费源代码文件中。

image916×591 46.9 KB

过去 5 年间，数据库凭据从未更改；但 2026 年 9 月 11 日的入侵是已知唯一一次对迷雾通数据库的未授权访问。

具体发生了什么？

日志显示，有两个 IP 地址对数据库进行了未授权访问。

其中一个客户端似乎是 Navicat（一款常见的数据库管理工具），它以交互方式查询了数据库，其中包括对旧版 secrets 表的一次完整读取。

另一个客户端自称为 pg_dump，试图导出整个数据库。两者都使用了数据库管理员凭据进行身份验证。我们不知道这两个地址是否由同一人操作。

随后，这次导出导致了中介服务器服务中断：

1. 长时间运行的全库导出在出口服务器注册表上持有读锁。
2. 几分钟后，中介服务器对该表启动了例行的 VACUUM FULL 维护操作。该操作请求排他锁，并排在导出之后等待。
3. 此后，中介服务器的读写操作都排在这个等待中的维护操作之后。
4. 被阻塞的请求占满了中介服务器的上游连接容量。失败和重试急剧增加，产生了大量短时 HTTPS 连接。
5. 主机的网络连接跟踪（conntrack）表被占满，内核开始丢弃数据包。

我们的团队首先注意到连接跟踪表已满，并扩大了该表的容量；这缓解了网络症状，但没有解决数据库锁死的问题。

image824×613 131 KB

服务中断期间：

• 新建连接、重新连接以及其他依赖中介服务器的操作受到影响。
• 已建立的隧道继续转发流量。
• 由于流量额度无法补充，Plus 连接可能出现降速。

UTC 03:40 终止等待中的维护会话后，中介服务器的查询恢复执行；导出会话于 03:42 被终止。中介服务器在 03:44 前恢复正常。

攻击者是谁？

我们只知道攻击者从 2 个香港 IP 地址访问了数据库，一个属于阿里云，另一个属于 StarCloud。这些是云主机地址，其所在地并不代表攻击者的实际位置。本报告通篇使用“攻击者”一词，但我们并不知道涉及的是一人还是多人。

时间线

以下时间均为 2026 年 9 月 11 日的 UTC 时间。

补救措施

遏制

• 清除了攻击者的访问权限。 数据库管理员凭据已于 UTC 03:57 被吊销。由于非管理员数据库凭据可通过管理员权限获取，我们也停用了所有非管理员数据库凭据。
• 吊销了已泄露的网桥注册密钥，使攻击者无法注入虚假网桥来监视用户流量。
• 暂时停用了删除用户功能，以防攻击者破坏用户账户。目前我们尚未发现任何恶意篡改账户的行为。待大多数用户更换账户密钥后，我们将重新启用该功能。
• 迷雾通 5.9.0 中的账户密钥更换功能（参见用户需要做什么）。

加固

• 账户密钥现以哈希形式存储，不再使用明文，因此即使数据库今后再次遭到入侵，也不会像这次一样泄露全部账户密钥。
• 数据库访问已通过 IP 白名单进行限制。
• 旧版用户名/密码登录方式正在逐步停用，因为许多用户设置的密码强度较弱，其哈希很容易被暴力破解。

经验教训

这是我们所知的首次针对迷雾通系统的入侵。以下三项失误导致了这次事件：

1. 我们将主数据库管理员凭据发布到了公开的 GitHub 仓库中，并且 5 年来一直没有发现。
2. 我们以明文形式存储账户密钥，而没有进行哈希处理。（我们当初这样选择，是因为账户密钥熵值高、无法猜测，这消除了使用密码哈希的理由之一）
3. 我们没有按 IP 地址限制数据库访问，否则本可以阻止所有未授权 IP 地址的访问。

由于我们长期坚持尽可能少地收集数据（例如注册时不收集任何联系方式），并对所收集的数据尽量少做记录，数据库中不包含注册联系信息、浏览记录或支付卡信息。

对于此次数据泄露，以及更换账户密钥给所有用户带来的不便，我们深表歉意。我们希望通过对泄露内容和入侵经过保持最大程度的透明，让用户尽可能清楚地了解情况，同时也让我们自己更好地从过去的错误中吸取教训。我们将继续改进数据库管理实践和全系统的安全防御，让迷雾通成为更安全的 VPN。

-- @nullchinchilla + @thisbefruit，迷雾通团队

好的，有没有什么补偿福利措施？比如说送一个月的那个 pass。请加快上 play store 版商店，版本适配好一些。

目前的单独一个密钥的登录方式，是不是应该改一下呢？应该改成用户标识 + 可随时变化的密钥的登录方式吧。给每个用户一个用户标识（随机生成的，不能变化）和一个密钥，登录时，两个都要输入。密钥是随机生成的，但是可以随时重新随机生成。这样才合理嘛。如果是这样，之后再出现这种情况（希望不要再出现），就直接让大家点一下按钮，重新生成密钥，就可以了。

我认为还应该获得一些经验：
根据互相对比能够判定用户身份的数据不要跟账户凭据&元数据放一块，和/或存放那些信息不要明文，甚至要不要考虑干脆不存那些，又或者给用户选择（为了获得更高安全性，可以选“丢了就连客服也找不回”这样就不存能根据支付宝一对比就定位到人的信息）。

生成的数字密钥，与加密钱包的提示词类似，安全性很差，不如自己设置的密码。
自己设置的密码能记住，而生成的密钥／提示词很难记住，要“抄下来保存”。
我会加密之后保存，而不懂技术的人基本只能保存明文，构成薄弱环节。
有人设置的密码太弱，在输入时提示一下就好了。

貌似旧密钥已登录旧软件的系统上，在未登出前继续有效，尽管在另外设备上已安装V5.9.0、更新密钥。
（第二台）Win下安装V5.9.0之前注销了迷雾通管理器，删除了旧版的缓存与数据 C:\ProgramData\geph 与 AppData\Roaming\EBWebView 俩文件夹，也就只有输入新密钥，V5.9.0不再有其它相关密钥的选项显示了。。。

所以如果这次攻击者是条子，用微信支付的是不是又危了？

旧版用户名和密码失效的意思是删除吗？有没有方法查看旧版用户名和密码？因为我忘记我使用了什么密码，而这关系到我要更换多少个在其他地方使用的相同密码

的确，如果是警察的话，支付账单暴露，基本上就是个人已经被特定。既然攻击来自香港的服务器，即使不是警察，是中国人的可能性也很大。我也刚好在处于这个被特定风险的范围之中。

这个写的有点不太清楚，我改了一下，事实上泄露的是我们，还有一些第三方支付（比如 Stripe）内部使用的单号，并不是支付宝或微信那边能轻易查到的任何记录。

另外，我刚才想到一个问题：如果黑客攻击了楼主的服务器，自己编译了一个 APK 文件上传到网站上，普通用户该怎么样防范呢？

也就是说，普通用户该怎么样判断，这个 APK 文件到底是楼主发的，还是黑客攻击了楼主的服务器之后发出的？

也许这次攻击是geph变得树大招风的信号。希望geph团队能注意自己的个人的身份信息不要被发现。 许多中国境内的vpn停止运营往往是以作者被抓被结束的。绝对不要认为和中国网络维稳团队的对抗只局限于技术较量。请运营团队当心！

虽然这么做大大降低了风险 但逻辑上还是可以分开的 或是不存明文的 毕竟运行主体业务必须的信息就只是“用户是有效免费付费类” 其他都是辅助支撑性的 虽然那样分开式的设计麻烦 但这是因为业务比较特殊所以涉及用户安全的值得繁琐一点不是吗

期待开发apple tv版本

服务器并没有被黑，只有存储账户信息的 PostgreSQL 数据库。

而且可以检查下载的文件的数字签名

image834×247 21.4 KB

image844×249 21.3 KB

同一电脑上，同一谷歌浏览器版本的两个便携版、同时运行，同一网络代理（迷雾通+V2rayN），一个伊朗德黑兰，一个伊朗马什哈德。。。

煞笔一样的登录验证设计，几十年前的系统都能自己修改密码，几十年前的系统密码都不会明文保存。到现在还他妈没解决codex无法使用的问题。