Molly 업데이트 공백, 오래된 Signal 통화 라이브러리를 둘러싼 보안 우려 제기

Molly는 등록된 안정 버전 릴리스 없이 3개월이 지나면서, 추가 보호 기능의 대가로 보안 수정이 지연되는 것 아니냐는 의문을 낳고 있다. Molly의 7월 릴리스가 공개된 통화 종료 취약점을 해결한 버전보다 오래된 통화 라이브러리를 명시하고 있어, 이 업데이트 공백은 면밀한 검토가 필요하다.

2026년 11월 2일 기준 공개 증거는 오래된 릴리스와 잠재적으로 영향을 받을 수 있는 의존성에 대한 우려를 뒷받침한다. 하지만 공격자가 Molly 사용자를 악용했다는 사실을 입증하지는 않는다. Molly가 맞춤화한 라이브러리에 동등한 수정이 포함됐는지도 확정하지 못한다.

핵심 긴장은 추가 보안 기능과 시의적절한 유지보수 사이에 있다. Signal은 Molly가 수정·적용하는 원본 소프트웨어인 업스트림 코드를 제공한다. Molly 사용자는 이러한 변경 사항을 받기 위해 별도의 릴리스 프로세스에 의존한다. 독립적으로 유지되는 소프트웨어 변형인 보안 중심 포크는 자체 보호 기능과 함께 이 프로세스 역시 신뢰할 수 있도록 유지해야 한다.

Molly 업데이트 공백이 실제로 보여주는 것

Molly의 공개 GitHub 릴리스 목록에 따르면 최신 릴리스는 7월 31일자 v8.19.2-4이다. 릴리스 노트는 구성된 프록시 사용 시 발생하는 의도치 않은 도메인 조회 노출인 DNS 유출을 수정했다고 설명한다. 이는 이 기사의 보도 기준일보다 공개된 안정 릴리스가 3개월 이상 뒤처져 있음을 의미한다. 릴리스 기록은 핵심적인 시점 관련 주장을 뒷받침한다.

릴리스 공백은 검증할 수 있지만, 보안상 결과는 별도로 검토해야 한다.

이 구분은 중요하다. 릴리스 날짜는 헤드라인이 흔히 시사하는 것보다 더 좁은 질문에만 답하기 때문이다. 특정 채널을 통해 프로젝트가 패키지를 게시한 시점을 보여줄 뿐, 그 패키지 내부의 모든 변경 사항을 자동으로 드러내지는 않는다.

오래된 릴리스에도 선택적으로 가져온 보안 수정이 포함될 수 있다. 개발자는 이를 백포트라고 부른다. 전체 최신 릴리스를 채택하지 않고도 나중의 수정 사항을 적용하는 방식이다. 반대로 최근 게시된 패키지에도 오래된 의존성이 남아 있을 수 있다.

따라서 독자에게 유용한 질문은 Molly가 비활성 상태로 보이는지보다 더 구체적이다. 설치된 애플리케이션에 논의 중인 취약점의 수정 사항이 포함돼 있는지다.

공개적인 우려는 이 기사 브리프와 함께 제공된 커뮤니티 게시물에서 제기됐다. 해당 제목은 3개월간의 업데이트 중단과 취약점을 모두 주장한다. 두 주장이 토론 제목에서 함께 등장하더라도, 검증 과정에서는 각각 따로 다뤄져야 한다.

릴리스 목록은 첫 번째 주장을 뒷받침한다. 두 번째 주장을 확인하려면 애플리케이션 구성 요소를 문서화된 결함과 대조한 뒤, 동등한 수정 사항이 있는지 점검해야 한다.

이 접근 방식은 프로젝트 자체에 대해 책임 있게 말할 수 있는 범위도 제한한다. 조용한 릴리스 페이지가 유지관리자가 개발을 포기했다는 증거는 아니다. 또한 그들의 가용성, 내부 테스트 또는 릴리스 장애물도 설명하지 않는다.

여기서는 공백에 대한 검증된 설명이 확인되지 않았다. 설명을 단정하는 것은 관찰 가능한 유지보수 문제를 담당자에 대한 추측으로 바꾸는 일이다.

그럼에도 사용자는 제공되는 패키지가 노후화되고 있음을 인식하기 전에 설명을 기다릴 필요가 없다. 수정된 애플리케이션이 기기에 도달하기 전까지 비공개 개발 노력은 배포된 보호 기능을 제공하지 못한다.

이것이 지금 이 공백이 중요한 이유다. 실질적인 질문은 확인할 수 없는 작업의 의도보다 사람들이 설치할 수 있는 소프트웨어에 관한 것이다.

이 사안을 추적하는 사람에게 7월 날짜는 조사의 출발점이 되어야 한다. 의존성 기록은 다음으로 더 중요한 증거를 제공한다.

오래된 통화 의존성이 우려를 구체화한다

Molly v8.19.2-4와 연결된 소스는 Android RingRTC 의존성을 im.molly:ringrtc-android:2.69.5-1로 선언한다. RingRTC는 Signal 관련 통화 기능을 처리하는 소프트웨어 라이브러리다. 태그된 통화 의존성은 검토할 수 있는 구체적인 구성 요소를 제공한다.

공개된 취약점 기록 CVE-2026-113380은 업스트림 RingRTC 2.72.0 이전 버전에 통화 종료 문제가 있다고 명시한다. CVE는 공개된 취약점을 추적하는 데 사용되는 공개 식별자다. 이 기록은 다른 통화 참여자가 내부 큐를 포화시킬 때 통화 종료 처리에 간섭할 수 있다고 설명한다. 오디오와 경우에 따라 비디오도 계속 관련될 수 있다. 통화 종료 권고문은 10월 20일 공개됐다.

선언된 의존성은 애플리케이션의 노후화만을 넘어 이 기사에 기술적 근거를 제공한다.

다만 Molly 의존성은 프로젝트 고유의 패키지 네임스페이스와 버전 접미사를 사용한다. 이는 중요한 검증 경계를 만든다. 그 번호는 업스트림 수정 버전보다 낮지만, 번호만으로 동일한 소스 내용을 증명하지는 못한다.

결론적인 평가는 배포된 애플리케이션을 빌드하는 데 사용된 정확한 라이브러리를 검사해야 한다. 관련 수정 사항 또는 기능적으로 동등한 변경이 존재하는지 판단해야 한다.

이 기사는 아직 아티팩트 수준의 검토를 완료하지 않았다. 아티팩트는 빌드 방법을 설명하는 소스 목록이 아니라 실제로 배포되는 소프트웨어 파일이다.

따라서 이 증거는 잠재적으로 영향을 받는 의존성과 해명 필요성을 뒷받침한다. 그러나 Molly에 특화된 공격이 독립적으로 입증됐다고 제시할 근거는 되지 않는다.

이 구분은 민감한 통화를 고려하는 사용자에게 유용하다. 이들은 자신의 휴대전화에서 실행되는 구성 요소에 관한 답을 필요로 한다. 암호화에 대한 일반적인 안심은 그 질문에 답하지 못한다.

통신 종단 간의 콘텐츠를 보호하는 종단 간 암호화는, 명령을 받았을 때 엔드포인트가 전송을 중단하는지를 그 자체로 결정하지 않는다. 통화는 암호화된 상태를 유지하면서도 참여자의 기대와 다르게 작동할 수 있다.

가령 연구자가 근처에 다른 사람이 있는 상황에서 기밀 자료를 논의하기 전에 인터뷰를 종료한다고 가정해 보자. 개인정보 보호 경계는 마이크가 오디오 전송을 멈추는 시점이다.

그 경계가 실패하면 전송 중의 강력한 보호도 사용자가 의도한 통제권을 되돌려 주지 못한다. 이 시나리오는 보고된 결함의 중요성을 보여주는 예시일 뿐, 문서화된 Molly 사고는 아니다.

같은 구분은 업무 통화, 취재원 인터뷰, 개인 대화에도 중요하다. 사용자는 대개 기본 애플리케이션 상태를 확인하지 않은 채 참여가 종료됐는지에 따라 결정을 내린다.

개발자에게 당장의 부담은 구체적이다. 수정 사항이 포함됐음을 입증하는 일은 애플리케이션 버전 번호를 비교하거나 광범위한 보안 주장을 반복하는 것보다 더 많은 불확실성을 해소할 것이다.

추가 강화 기능도 유지보수에 의존한다

Molly는 자신을 보안 중심의 Signal 변형으로 설명한다. 문서에는 데이터베이스 암호문 보호, 자동 잠금, 메모리 삭제, 알림 수신 대안이 나열돼 있다. 같은 문서는 정기 업데이트가 2주마다 제공되며, 보안 패치는 제공될 때 적용된다고 밝힌다. 이는 효과에 대한 독립적 검증이 아니라 프로젝트가 밝힌 기능과 유지보수 약속이다. 보안 약속은 사용자에게 신뢰를 요청하는 기준을 제시한다.

추가 보호 기능과 시의적절한 수정은 서로 다른 위험을 다루며, 사용자는 둘 모두를 별도로 평가할 필요가 있다.

강화는 노출을 줄이거나 피해를 제한하려는 조치를 추가하는 것을 뜻한다. 예를 들어 데이터베이스 잠금은 기기에 저장된 정보에 대한 접근과 관련된다. 통화 라이브러리 수정은 통신 중의 동작과 관련된다.

한 영역의 성공이 다른 영역의 안전을 입증하지는 않는다. 기능 목록만으로 특정 취약 구성 요소가 수정됐는지 답할 수 없다.

이것이 Molly와 Signal 논의의 핵심적인 상충 관계다. 수정된 클라이언트를 선택하는 사용자는 자신이 중요하게 여기는 제어 기능을 얻을 수 있지만, 다른 프로젝트의 통합 및 배포 프로세스를 받아들이게 된다.

이 의존성이 포크를 본질적으로 안전하지 않게 만드는 것은 아니다. 다만 추가 기능 설계와 함께 지속적인 운영 작업도 보안 근거에 포함된다는 뜻이다.

업스트림 수정 사항은 검토, 통합, 빌드, 테스트, 서명, 배포되어야 한다. 서명은 소프트웨어 패키지에 게시자 신원을 연결해 기기가 승인된 업데이트를 인식할 수 있게 한다.

각 단계는 그 자체로 합리적일 수 있다. 그러나 이 단계들이 함께 사용자들이 공개된 수정 사항이 설치된 보호 기능이 되기까지 기다리는 시간을 결정한다.

수정 사항이 업스트림 개발과 같은 영역을 건드릴 때 비용은 특히 중요하다. 개발자는 새 코드가 기존 변경 사항과 함께 올바르게 작동하는지 확인하면서 자신의 변경 사항을 유지해야 한다.

이 작업을 행정적 부담으로 치부해서는 안 된다. 사용자가 그 결과물인 패키지에 의존하기 때문에 릴리스 엔지니어링은 제품의 보안 경계를 구성한다.

“Molly Signal은 안전한가”라고 묻는 사람에게 답은 고려하는 위험에 따라 달라진다. 저장된 메시지에 대한 일상적 접근 방지는 악의적인 통화 참여자를 신뢰성 있게 처리하는 것과 다르다.

유용한 평가는 어떤 보호 기능이 중요한지, 어떤 버전이 설치돼 있는지, 그리고 유지보수 상태를 뒷받침하는 증거가 무엇인지를 묻는다. 하나의 형용사로 이러한 답을 책임 있게 결합할 수는 없다.

메인라인 Signal은 원본 애플리케이션과 통화 라이브러리를 유지하므로 기준점이 된다. 이 관계는 다운스트림 통합 단계를 제거하지만, 취약점으로부터 자유롭다는 뜻은 아니다.

한편 Molly는 사용자가 실제로 필요로 하는 이점으로 추가 유지보수 의존성을 정당화해야 한다. 구성 요소 상태가 불확실하게 남아 있을 때 그 정당화는 더 어려워진다.

공정한 비교는 현재의 검증 가능한 동작을 다룬다. 수정된 클라이언트가 제어 기능을 추가한다는 이유만으로 더 안전하다고 가정하거나, 원본 클라이언트가 결함이 없다고 가정해서는 안 된다.

즉각적인 압박은 Molly의 릴리스 프로세스에 가해진다. 그 이유와 무관하게, 프로젝트가 밝힌 유지보수 기대치는 눈에 보이는 공백을 중대하게 만든다.

업스트림 수정은 통화 종료 우선순위를 바꾼다

Signal에 연결된 RingRTC 수정은 별도의 종료 요청 플래그를 추가하고, 일반적인 큐 처리와 독립적으로 종료를 확인한다. 플래그는 코드가 직접 검사할 수 있는 저장된 상태 표시다. 이 변경은 제한된 대기 시간도 도입하고 특정 오류 이후에도 정리가 계속되도록 한다. 이러한 세부 사항은 업스트림 종료 수정에 나타난다.

기술적 의미는 통화 종료 요청과 다른 작업 뒤에서 대기하는 일을 분리한 데 있다. 이 수정은 종료가 큐가 정상적으로 진행되는 데 덜 의존하도록 한다.

다른 참여자가 예기치 않은 활동을 생성하는 상황에서도 사용자가 참여를 중단하기로 한 결정은 신뢰성 있게 집행되어야 한다.

큐는 소프트웨어가 처리할 때까지 작업을 보관하는 구조다. 큐는 흔하고 유용하지만, 긴급한 로컬 작업이 원격의 영향을 받는 이벤트와 처리 과정을 공유할 때 그 순서가 중요해질 수 있다.

이 경우 보안상 질문은 누가 실질적으로 지연을 통제하는지에 관한 것이다. 로컬 참여자는 비정상적인 조건에서도 애플리케이션이 통화 종료 동작을 따르기를 기대한다.

이는 일반적인 사용성 결함과는 성격이 다릅니다. 애니메이션이 지연되면 불편합니다. 하지만 개인정보 관련 결정의 집행이 지연되면 참여자가 감추려 했던 정보가 노출될 수 있습니다.

더 넓은 교훈은 이번 수정에서 도출되는 공학적 추론입니다. 소프트웨어가 상충하거나 적대적인 입력을 처리할 때, 민감한 활동을 종료하는 제어 기능은 명시적으로 다뤄져야 합니다.

이 원칙은 메시징을 넘어 적용됩니다. 녹음 중지 명령, 세션 해지 또는 권한 철회에도 유사한 기대가 따를 수 있습니다. 각각은 별도의 구현 검토가 필요하며, 이 취약점이 그러한 다른 시스템의 결함을 입증하는 것은 아닙니다.

이 이야기에서 교훈은 통화에 집중됩니다. 핵심 질문은 Molly의 분산 라이브러리에 이번 수정으로 도입된 종료 동작이 포함되어 있는지입니다.

더 새로운 애플리케이션 인터페이스만으로는 이 질문에 답할 수 없습니다. 일반적인 통화가 성공한다고 해서 마찬가지로 충분하지 않습니다. 정상 작동이 반드시 여기서 논의하는 실패 조건을 실행하는 것은 아니기 때문입니다.

유의미한 검증은 비정상 조건 자체를 살펴봐야 합니다. 일반 처리 과정이 멈추거나 과부하될 때 로컬 종료 요청이 완전한 정리 작업으로 이어지는지 확인해야 합니다.

그래서 소스 변경, 빌드 기록, 대상 회귀 검사가 함께 있으면 설득력이 있습니다. 회귀 검사는 이전에 식별된 실패가 재발하지 않는지 확인합니다.

이러한 증거 형태는 서로 다른 질문에 답합니다. 소스는 의도된 동작을 보여 줍니다. 빌드 기록은 그 소스를 패키지와 연결합니다. 테스트는 관련 동작이 실제로 작동하는지 살펴봅니다.

사용자가 이 모든 분석을 직접 수행할 필요는 없어야 합니다. 수정 사항과 영향을 받는 릴리스를 식별하는 유지관리자 설명이 있다면, 사용자는 무엇을 설치할지 결정할 실질적인 근거를 얻을 수 있습니다.

이 메커니즘은 달력상 경과 시간이 간접적으로만 중요한 이유도 설명합니다. 시간은 차이가 발생할 기회를 만들지만, 이 특정 기술적 우려를 결정하는 것은 수정 사항의 존재 여부입니다.

Molly의 노출 가능성에 대해 아직 확인되지 않은 사항

현재 उपलब्ध 기록에는 몇 가지 열린 질문이 남아 있습니다. 이 검토에서는 Molly v8.19.2-4를 대상으로 CVE-2026-113380을 독립적으로 재현하지 않았습니다. 또한 Molly의 맞춤형 통화 라이브러리에 동등한 백포트가 포함되어 있는지도 확인하지 못했습니다.

Molly 사용자에 대한 성공적인 공격 역시 확인되지 않았습니다. 취약점 경고, 영향받는 구성 요소에 대한 추론, 실제 악용의 증거는 서로 다른 발견 사항입니다.

가장 강하게 뒷받침되는 결론은 특정 구성 요소에 관한 해결되지 않은 우려가 있는 문서화된 릴리스 공백입니다.

이 결론은 근거 없는 주장으로 확대하지 않으면서도 면밀한 검토를 정당화할 만큼 심각합니다. 모든 Molly 사용자가 감시당했다고 말하는 것은 증거를 훨씬 넘어서는 주장입니다.

마찬가지로 이 통화 문제만으로 저장된 메시지 기록이 복호화되었다고 볼 수는 없습니다. 보고된 메커니즘은 활성 통신 세션의 종료와 관련됩니다.

범위를 정확히 유지하면 사용자가 상황에 맞는 결정을 내리는 데 도움이 됩니다. 통화 개인정보 보호를 검토하는 사람에게 필요한 정보는 메시지 저장이나 계정 접근을 조사하는 사람에게 필요한 정보와 다릅니다.

권고문의 설명은 통화 중인 다른 참여자와 관련됩니다. 기존 상호작용 없이 임의의 낯선 사람이 설치된 모든 마이크를 원격으로 활성화하는 상황을 설명하는 것은 아닙니다.

이 경계는 이 이야기를 요약할 때마다 분명히 유지되어야 합니다. 공격 조건을 제거하면 경고가 더 극적으로 들릴 수 있지만, 유용성은 떨어집니다.

Molly에 특화된 재현 가능한 공격이 없다는 사실도 안심의 근거가 되어서는 안 됩니다. 사용자는 관련 수정이 배포되었다는 증거를 기대하기 전에 공개적인 피해가 발생할 때까지 기다릴 필요가 없습니다.

이 지점에서 “Molly Signal은 안전한가”라는 질문에 대한 신중한 답변은 이분법적 판정을 피해야 합니다. 증거가 가리키는 것은 특정 릴리스와 구성 요소에 관한 질문이지, 프로젝트에 대한 영구적 판단이 아닙니다.

지연의 원인을 과실, 자금 부족, 질병 또는 방치로 돌릴 검증된 근거도 여기에는 없습니다. 그러한 설명에는 이를 뒷받침하는 진술이나 기록이 필요합니다.

유지관리자는 정당한 제약에 직면할 수 있지만, 사용자는 여전히 지연된 배포의 결과를 경험합니다. 원인을 이해하는 일과 릴리스를 평가하는 일은 별개의 과제입니다.

Molly와 Signal의 비교도 마찬가지로 엄격하게 다뤄야 합니다. 업스트림 소유권이 완벽한 보안을 보장하지는 않으며, 추가적인 강화 조치가 알려진 수정 사항에 대한 불확실성을 정당화하지도 않습니다.

조직의 경우, 이는 민감한 업무 흐름에서 정확한 애플리케이션 빌드를 평가해야 한다는 뜻입니다. 서로 다른 클라이언트와 릴리스에는 서로 다른 소프트웨어가 포함되므로, 승인된 제품명만으로는 충분하지 않습니다.

개인의 경우, 이는 가정하기 전에 실제 애플리케이션과 업데이트 채널을 확인해야 한다는 뜻입니다. 안심시키는 아이콘이나 익숙한 연락처 목록은 기반 의존성을 식별해 주지 않습니다.

가장 강력한 대응은 증거를 통해 불확실성을 좁히는 것입니다. 문서화된 백포트는 영향받는 구성 요소라는 추론을 약화할 것입니다. 재현 가능한 실패는 그 추론을 강화할 것입니다. 두 가지 모두 논의를 개선할 수 있습니다.

신뢰 회복 여부를 결정할 세 가지 신호

관련 수정 사항과 사용자가 얻을 수 있는 소프트웨어를 공개 기록이 연결하면 Molly 업데이트 공백을 평가하기가 더 쉬워질 것입니다. 일반적인 개인정보 보호 선호에 관한 또 다른 논쟁으로는 그 연결을 해결할 수 없습니다.

다음으로 유의미한 진전은 수정된 릴리스, 명시적인 기술 설명, 그리고 지속적인 배포의 증거입니다.

첫 번째 신호는 명확히 문서화된 통화 라이브러리 수정 사항을 포함한 공개 Molly 패키지입니다. 업스트림 RingRTC 버전 2.72.0은 해당 조사에 참고할 수 있는 릴리스입니다. 내용이 문서화되어 있다면 동등한 백포트도 중요할 수 있습니다.

이는 구성 요소 문제를 직접 해결함으로써 특정 패키지에 대한 신뢰를 높일 것입니다. 관련 의존성 정보가 없는 새 버전은 검토자에게 더 많은 작업을 남깁니다.

공개와 함께 배포도 중요합니다. 사용자는 자신이 실제로 사용하는 채널을 통해 수정된 패키지를 받아야 하며, 관련 변경 사항이 포함되었음을 알아볼 충분한 정보가 필요합니다.

두 번째 신호는 영향받는 빌드와 수정 상태를 식별하는 유지관리자 설명입니다. 이러한 설명은 소스 변경, 릴리스 식별자 및 가능한 검증 정보를 연결할 때 가장 유용합니다.

기존 백포트를 확인하는 설명은 7월 패키지에 이 결함이 남아 있다는 추론을 실질적으로 약화할 것입니다. 노출을 확인하는 설명은 어떤 사용자가 조치해야 하는지 명확히 해 줄 것입니다.

어느 쪽 결과든 공개 기록을 개선합니다. 보안이 여전히 우선순위라는 광범위한 확언보다 기술적 구체성이 더 가치 있습니다.

세 번째 신호는 즉각적인 문제가 해결된 뒤의 상황입니다. 앞으로 몇 달 동안 정기적인 릴리스와 보안 변경 사항의 명시적 처리는 배포가 다시 신뢰할 만해졌는지를 보여 줄 것입니다.

한 번의 따라잡기 릴리스로 긴급한 문제는 해결할 수 있습니다. 그러나 그것만으로 프로젝트가 다음 수정 사항을 어떻게 처리할지는 입증할 수 없습니다.

반복되는 지연은 유지관리 의존성에 대한 우려를 강화할 것입니다. 일관된 배포는 Molly의 추가 제어 기능을 유지하려면 사용자가 장기간의 불확실성을 감수해야 한다는 주장을 약화할 것입니다.

이 마지막 신호가 중요한 이유는 신뢰에는 미래 행동에 대한 기대가 포함되기 때문입니다. 사용자는 오늘 내일의 코드를 검사할 수 없지만, 프로젝트가 명확하게 소통하고 수정 사항을 예측 가능하게 배포하는지는 평가할 수 있습니다.

다른 보안 중심 포크를 유지관리하는 개발자에게도 같은 증거는 실용적인 기준을 제공합니다. 구성 요소 상태를 설명하고, 영향을 받는 패키지를 식별하며, 수정에서 설치까지의 경로를 눈에 보이게 하십시오.

독자는 확인할 수 있는 증거에 판단을 고정해야 합니다. 설치된 버전, 문서화된 구성 요소, 관련 수정 사항의 상태가 그것입니다. 기능 목록을 그러한 기록의 대체물로 취급하지 마십시오. 통화 개인정보 보호가 업무나 개인 안전에 중요하다면, 클라이언트를 선택할 때 해결되지 않은 유지관리 문제에 적절한 비중을 두십시오. 다음 릴리스와 기술 노트를 확인한 뒤, 그 기록이 바뀌면 결정을 다시 검토하십시오. Molly 업데이트 공백은 구체적인 답을 필요로 하는 구체적인 질문을 제기합니다. 기기에 설치된 애플리케이션에 통화를 안정적으로 종료하는 데 필요한 수정 사항이 포함되어 있습니까?