Molly Client Unupdated for Three Months: Signal Fork Security Risks Spark Debate

A Fork's Stagnation Stirs Nerves in the Privacy Community

On Hacker News, a post about Molly quickly garnered 246 upvotes and 150 comments. Molly is an independent fork of Signal that focuses on enhanced privacy and security. However, the community has discovered that it has not been updated for over three months, meaning it cannot keep up with Signal's upstream security patches and protocol changes. For a communication client that sells itself on security, this is almost fatal.

The post title is blunt: "Molly (Signal fork) has not been updated since 3 months and is vulnerable." This is not just an ordinary version lag but a questioning of the fork maintenance model. When the upstream project iterates rapidly, how can downstream forks avoid becoming the weakest link in the security chain?

End-to-End Encryption (E2EE) means that only the communicating parties can decrypt message content; servers or intermediaries cannot read it. Signal implements E2EE based on the Signal protocol, and its security depends on continuous updates to the protocol implementation. When a fork remains unupdated for a long time, it may not only lack patches for known attacks but may also fail to properly negotiate encryption with updated upstream servers due to an outdated protocol version, leading to downgrade attacks or compatibility issues. Therefore, for E2EE communication tools, version lag is not just a functional issue but directly weakens encryption guarantees.

The Double-Edged Sword of the Fork Model

Signal itself is known for end-to-end encryption and privacy protection, and its code is open source, allowing anyone to fork and customize it. Molly leverages this by removing dependence on Google services and adding extra privacy features, attracting users who are wary of mainstream applications.

But forking also means transferring responsibility. Every security fix upstream requires fork maintainers to actively merge, test, and release. Three months is a long time in the security field—enough for attackers to study and exploit known vulnerabilities. According to community discussion, Molly may be missing some recent critical fixes from Signal. Although specific vulnerability details are not elaborated in the post, the word "vulnerable" is enough to raise alarm.

Fork in open-source development refers to copying an independent version from a project's codebase, maintained by another group of developers. Forks are typically used to experiment with new features, remove specific dependencies (such as Molly removing Google services), or adapt to different platforms. A fork shares historical code with the upstream project but then evolves separately: when upstream fixes vulnerabilities, the fork does not automatically receive these fixes and must manually merge or cherry-pick them. This means the security status of a fork depends entirely on the responsiveness and commitment of its maintainers; the more active the upstream, the greater the risk of the fork falling behind.

Community Reactions and Controversy

Among the 150 comments, opinions are not uniform. Some users believe that open-source fork maintenance inherently relies on volunteers, so three months without an update is understandable, and users should assess the risk themselves. Others point out that if a fork cannot guarantee timely security updates, it should not continue to be promoted with a "more secure" label.

Discussion also extends to a broader question: Are ordinary users capable of judging whether a fork is secure? When an app store version remains unupdated for a long time, users often only see the "last updated date" but do not know which patches are missing behind the scenes. This information asymmetry is itself a security risk.

"Upstream synchronization" of security patches refers to downstream forks regularly pulling the latest code from the upstream project, especially security-related commits. Common practices include subscribing to upstream security announcement mailing lists, setting up automated CI to compare differences between upstream and the fork, or using dependency update tools (such as Dependabot) for monitoring. For mobile apps, re-signing and publishing to app stores are also required, making the process more complex than pure code merging. A fork lacking a synchronization mechanism, even if its code has no new vulnerabilities, will be in a "known vulnerable" state due to missing patches already fixed upstream.

Implications for the Privacy Tool Ecosystem

Molly's situation reflects a structural challenge in the privacy tool ecosystem. The official Signal app updates frequently and has ample team resources, while fork projects are often maintained by small teams or even individuals and struggle to sustain investment. Once maintainers lack energy, the fork turns from an "enhanced version" into a "risky version."

For users, when choosing a fork, they need to pay attention to update frequency, maintainer activity, and whether upstream security announcements are synchronized in a timely manner. For fork maintainers, establishing a transparent security update mechanism, or clearly informing users when they cannot keep up, is more important than barely maintaining it.

As of the time of posting, Molly's maintainers had not given an official response in the thread. But this discussion has made more people realize: in the world of security software, stagnation itself is a vulnerability.

One-line Summary

Signal privacy fork Molly has not been updated for three months, exposing the security risks of lagging open-source fork maintenance.

Paragraph Summary

The article reports that Molly, Signal's privacy-enhanced fork, has not been updated for over three months and may be missing upstream security patches, sparking heated discussion on Hacker News with 246 upvotes and 150 comments. The debate focuses on the double-edged sword of the open-source fork model: forks grant customization freedom but transfer responsibility for security updates to volunteer maintainers; once lagging, the fork degrades from an "enhanced version" to a "risky version." The community is divided on whether such forks should continue to be promoted with a "more secure" label, and points out that ordinary users find it difficult to judge the security status of a fork, with information asymmetry itself constituting a risk. The article concludes by calling on fork maintainers to establish transparent security update mechanisms and reminding users to pay attention to update frequency and maintainer activity.