Molly update gap raises security concerns over an older Signal calling library

Molly has gone three months without a listed stable release, raising questions about whether its additional protections come with delayed security fixes. The Molly update gap deserves scrutiny because its July release declares an older calling library than the version addressing a published call-termination vulnerability.

As of November 2, 2026, the public evidence supports concern about an aging release and a potentially affected dependency. It does not establish that attackers have exploited Molly users. Nor does it settle whether Molly’s customized library contains an equivalent fix.

The central tension is between additional security features and timely maintenance. Signal supplies the upstream code, meaning the original software Molly adapts. Molly’s users depend on another release process to receive those changes. A security-focused fork, an independently maintained software variant, must keep that process dependable alongside its own protections.

What the Molly update gap actually shows

Molly’s public GitHub release list identifies v8.19.2-4, dated July 31, as its latest release. Its notes describe a fix for a DNS leak, an unintended disclosure of domain lookups, when a configured proxy was used. That places the visible stable release more than three months behind this article’s reporting date. The release history supports the central timing claim.

The release gap is verifiable; the security consequences require a separate examination.

That distinction matters because release dates answer a narrower question than headlines often suggest. They establish when a project published a package through a particular channel. They do not automatically reveal every change inside that package.

An older release can contain a selectively imported security fix. Developers call that a backport: applying a later correction without adopting the entire newer release. Conversely, a recently published package can retain an outdated dependency.

For readers, the useful question is therefore more specific than whether Molly looks inactive. It is whether the installed application contains the correction for the vulnerability being discussed.

The public concern surfaced through a community post supplied with this story’s brief. Its title alleges both a three-month update pause and vulnerability. Those claims should travel separately through verification, even when they appear together in a discussion headline.

The release list substantiates the first claim. Establishing the second requires matching the application’s components against a documented flaw, then checking for equivalent corrections.

That approach also limits what can responsibly be said about the project itself. A quiet release page does not establish that its maintainers have abandoned development. It does not explain their availability, internal testing, or release obstacles.

No verified explanation for the pause is established here. Assigning one would turn an observable maintenance problem into speculation about the people responsible.

Still, users do not need an explanation before recognizing that the available package is aging. A private development effort provides no deployed protection until a corrected application reaches their devices.

That is why the gap matters now. The practical question concerns the software people can install, rather than the intentions behind work they cannot inspect.

For anyone following the story, the July date should be the starting point of the investigation. The dependency record supplies the next, more consequential piece of evidence.

An older calling dependency makes the concern concrete

The source associated with Molly v8.19.2-4 declares its Android RingRTC dependency as im.molly:ringrtc-android:2.69.5-1. RingRTC is the software library that handles Signal-related calling functionality. The tagged calling dependency provides a specific component to examine.

A published vulnerability record, CVE-2026-113380, identifies a call-termination problem in upstream RingRTC versions before 2.72.0. A CVE is a public identifier used to track a disclosed vulnerability. The record describes interference with hang-up processing when another call participant saturates an internal queue. Audio, and perhaps video, can remain involved. The call-termination advisory was published October 20.

The declared dependency gives this story a technical basis beyond the age of the application.

However, the Molly dependency uses the project’s own package namespace and version suffix. That creates an important verification boundary. Its number places it below the upstream fixed version, but the number alone does not prove identical source contents.

A conclusive assessment would inspect the exact library used to build the distributed application. It would determine whether the relevant correction, or a functionally equivalent change, is present.

This article has not completed that artifact-level examination. An artifact is the actual distributed software file, rather than the source listing describing how to build it.

The evidence therefore supports a potentially affected dependency and a need for clarification. It does not support presenting a successful Molly-specific attack as independently demonstrated.

The distinction is useful for users considering sensitive calls. They need an answer about the component running on their phones. A general reassurance about encryption would not answer that question.

End-to-end encryption, which protects content between communicating endpoints, does not by itself determine whether an endpoint stops transmitting when instructed. A call can remain encrypted while behaving contrary to the participant’s expectations.

Consider a hypothetical researcher ending an interview before discussing confidential material with someone nearby. The privacy boundary is the moment the microphone stops sending audio.

If that boundary fails, strong protection during transmission does not restore the user’s intended control. This scenario illustrates the significance of the reported flaw; it is not a documented Molly incident.

The same distinction matters for workplace calls, source interviews, and personal conversations. Users make decisions based on whether participation has ended, often without inspecting the underlying application state.

For developers, the immediate burden is specific. Demonstrating the presence of the correction would resolve more uncertainty than comparing application version numbers or repeating broad security claims.

Additional hardening still depends on maintenance

Molly describes itself as a security-focused Signal variant. Its documentation lists database passphrase protection, automatic locking, memory wiping, and alternatives for receiving notifications. The same documentation says routine updates arrive every two weeks, with security patches applied when available. These are the project’s stated features and maintenance commitments, rather than independent verification of their effectiveness. Its security commitments establish the standard users are being asked to trust.

Additional protections and timely fixes address different risks, and users need both evaluated separately.

Hardening means adding measures intended to reduce exposure or limit damage. A database lock, for example, concerns access to information stored on a device. A calling-library correction concerns behavior while communicating.

Success in one area does not establish safety in the other. A feature list cannot answer whether a particular vulnerable component has been corrected.

This is the central tradeoff in the Molly vs Signal discussion. Users choosing a modified client can gain controls they value while accepting another project’s integration and distribution process.

That dependency does not make forks inherently unsafe. It means their security case includes ongoing operational work, alongside the design of their additional features.

An upstream correction must be reviewed, integrated, built, tested, signed, and delivered. Signing attaches a publisher identity to a software package so devices can recognize authorized updates.

Each stage can be reasonable on its own. Together, those stages determine how long users wait before a published correction becomes an installed protection.

The cost is especially relevant when modifications touch the same areas as upstream development. Developers must preserve their changes while checking that new code behaves correctly with them.

That work should not be dismissed as administrative overhead. Release engineering forms part of the product’s security boundary because users depend on the resulting package.

For a person asking “is Molly Signal safe,” the answer therefore depends on the risk being considered. Protection against casual access to stored messages is different from reliable handling of hostile call participants.

A useful evaluation asks which protections matter, which version is installed, and what evidence supports its maintenance status. A single adjective cannot combine those answers responsibly.

Mainline Signal provides a reference point because it maintains the original application and calling library. That relationship removes a downstream integration step, although it does not imply freedom from vulnerabilities.

Molly, meanwhile, must justify the additional maintenance dependency through the benefits its users actually require. That justification becomes harder when component status remains uncertain.

The fair comparison concerns present, verifiable behavior. It should avoid assuming that a modified client is safer because it adds controls, or that an original client is flawless.

The immediate pressure falls on Molly’s release process. Its stated maintenance expectations make the visible pause consequential, regardless of the reasons behind it.

The upstream fix changes how call termination takes priority

Signal’s linked RingRTC correction adds a separate termination-request flag and checks termination independently of ordinary queue processing. A flag is a stored state marker that code can inspect directly. The change also introduces bounded waiting and allows cleanup to continue after certain errors. These details appear in the upstream termination fix.

The technical significance is the separation between requesting an end to a call and waiting behind other work. The correction makes termination less dependent on the queue progressing normally.

A user’s decision to stop participating needs reliable enforcement even when another participant generates unexpected activity.

A queue is a structure that holds work until software processes it. Queues are common and useful, but their ordering can become consequential when urgent local actions share processing with remotely influenced events.

In this case, the security question concerns who effectively controls the delay. The local participant expects the application to obey the hang-up action, even under abnormal conditions.

That makes the issue different from an ordinary usability defect. A delayed animation is inconvenient. Delayed enforcement of a privacy decision can expose information the participant intended to withhold.

The broader lesson is an engineering inference from this correction. Controls that end sensitive activity deserve explicit treatment when software handles competing or hostile inputs.

That principle applies beyond messaging. A stop-recording command, session revocation, or permission withdrawal can carry similar expectations. Each requires its own implementation review; this vulnerability does not establish defects in those other systems.

For this story, the lesson remains focused on calling. The relevant question is whether Molly’s distributed library contains the termination behavior introduced by the correction.

A newer application interface would not settle that question. Neither would successful ordinary calls, since normal operation does not necessarily exercise the failure condition under discussion.

Useful validation needs to examine the abnormal condition itself. It should establish that the local termination request results in completed cleanup when ordinary processing stalls or becomes overloaded.

That is why a source change, build record, and targeted regression check would be persuasive together. A regression check verifies that a previously identified failure does not return.

These forms of evidence answer different questions. The source establishes intended behavior. The build record connects that source to the package. Testing examines whether the relevant behavior works.

Users should not have to perform all that analysis personally. A maintainer statement identifying the correction and affected releases would give them a practical basis for deciding what to install.

The mechanism also explains why calendar age matters only indirectly. Time creates an opportunity for divergence, but the presence or absence of the correction determines this particular technical concern.

What remains unverified about Molly’s exposure

The available record leaves several questions open. This review has not independently reproduced CVE-2026-113380 against Molly v8.19.2-4. It has not established whether Molly’s customized calling library contains an equivalent backport.

It also has not established a successful attack against a Molly user. A vulnerability warning, an affected-component inference, and evidence of exploitation are different findings.

The strongest supported conclusion is a documented release gap with a specific unresolved component concern.

That conclusion is serious enough to justify scrutiny without expanding into unsupported claims. Saying every Molly user has been monitored would go far beyond the evidence.

Likewise, this calling issue does not establish that stored message histories have been decrypted. The reported mechanism concerns termination of an active communication session.

Keeping the scope precise helps users make proportionate decisions. Someone reviewing call privacy needs different information from someone investigating message storage or account access.

The advisory’s description involves another participant in a call. It does not describe arbitrary strangers remotely activating every installed microphone without an existing interaction.

That boundary should remain visible whenever the story is summarized. Removing attack conditions can make a warning sound more dramatic while making it less useful.

The absence of a reproduced Molly-specific exploit should not become reassurance either. Users do not need to wait for public harm before expecting evidence that a relevant correction has shipped.

This is where a cautious answer to “is Molly Signal safe” must resist a binary verdict. The evidence identifies a question about a particular release and component, not a permanent judgment about the project.

There is also no verified basis here for attributing the delay to negligence, funding, illness, or abandonment. Those explanations require statements or records that establish them.

Maintainers can face legitimate constraints, but users still experience the consequences of delayed delivery. Understanding a cause and assessing a release are separate tasks.

The Molly vs Signal comparison should remain equally disciplined. Upstream ownership does not guarantee perfect security, while additional hardening does not excuse uncertainty about known corrections.

For organizations, this argues for evaluating exact application builds in sensitive workflows. An approved product name is insufficient when different clients and releases contain different software.

For individuals, it argues for checking the actual application and update channel before making assumptions. A reassuring icon or familiar contact list does not identify the underlying dependency.

The strongest response would narrow uncertainty with evidence. A documented backport would weaken the affected-component inference. A reproducible failure would strengthen it. Both would improve the discussion.

Three signals will determine whether confidence recovers

The Molly update gap will become easier to assess when public records connect the relevant correction to software users can obtain. Another debate about general privacy preferences will not resolve that connection.

The next useful developments are a corrected release, an explicit technical explanation, and evidence of sustained delivery.

The first signal is a publicly available Molly package with a clearly documented calling-library correction. Upstream RingRTC version 2.72.0 provides a reference release for that investigation. An equivalent backport can also matter, provided its contents are documented.

That would strengthen confidence in the specific package by addressing the component question directly. A new version without relevant dependency information would leave more work for reviewers.

Distribution matters alongside publication. Users need the corrected package through the channel they actually use, with enough information to recognize that the relevant change is included.

The second signal is a maintainer explanation identifying affected builds and the correction’s status. Such a statement would be most useful if it connected source changes, release identifiers, and any available validation.

A statement confirming an existing backport would materially weaken the inference that the July package retains this flaw. A statement confirming exposure would clarify which users need action.

Either outcome would improve the public record. Technical specificity is more valuable than a broad assurance that security remains a priority.

The third signal is what happens after the immediate issue is addressed. Over the coming months, regular releases and explicit handling of security changes would show whether delivery has become dependable again.

One catch-up release can resolve an urgent problem. It cannot, by itself, establish how the project will handle the next correction.

Repeated delays would strengthen concern about the maintenance dependency. Consistent delivery would weaken the argument that users must accept prolonged uncertainty to retain Molly’s additional controls.

This final signal matters because trust involves expectations about future behavior. Users cannot inspect tomorrow’s code today, but they can assess whether a project communicates clearly and delivers corrections predictably.

For developers maintaining other security-focused forks, the same evidence offers a practical benchmark. Explain component status, identify affected packages, and make the path from correction to installation visible.

For readers, keep the decision anchored to evidence you can check: your installed version, its documented components, and the status of relevant corrections. Avoid treating a feature list as a substitute for that record. If calling privacy matters to your work or personal safety, give unresolved maintenance questions appropriate weight when choosing a client. Follow the next release and its technical notes, then revisit the decision when those records change. The Molly update gap raises a concrete question that deserves a concrete answer: does the application on your device contain the correction needed to end a call reliably?