Signal Fixes Critical SGX Flaws that Could Expose Contact Discovery Data

Last updated: August 28, 2026 Reading time: 5 minutes
Disclosure
Share
Signal Fixes Critical SGX Flaws that could Expose Contact Discovery Data
  • V12 found two flaws in Signal’s Contact Discovery Service that could break the security boundary around its Intel SGX enclave.
  • The bugs let a hostile server host read protected enclave memory and run code inside the trusted environment.
  • Signal fixed both flaws. The attacks required control of the server host and did not break Signal’s end-to-end message encryption.

Security researchers at V12 found two critical flaws in Signal’s Contact Discovery Service, or CDSI. They tested the attacks on real Intel SGX hardware that matched the Azure machine type Signal uses in production.

One bug gave the host an arbitrary memory-read capability. The second lets the host control the enclave’s register state. It then let the host run code inside it.

V12 used both flaws to extract the enclave’s 32-byte Noise responder private key. That key could let a compromised host impersonate the enclave. It could then decrypt protected contact discovery queries.

That does not mean attackers could read Signal messages. The research targeted the server-side system that handles contact discovery. It didn’t break the end-to-end encryption Signal uses for chats or calls.

Why Signal Uses an Enclave for Contact Discovery

Signal needs to find which people in a user’s address book also use Signal. On a normal server, that process could expose the contact list.

Signal designed CDSI to process contact matching inside an Intel Software Guard Extensions, or SGX, enclave. The enclave protects the data while the server handles the request. SGX creates a protected area in the processor. Its memory stays hidden from software on the host.

Signal also uses Oblivious RAM, or ORAM, to help hide database access patterns. This adds another layer of privacy during contact matching. Signal says its private contact discovery system was built to let users find contacts without revealing their social graph to the service.

Ring’s TAKE encryption uses rotating keys to protect video footage while enabling AI features like Smart Alerts. Keys expire after 24 hours, balancing stronger privacy with camera functionality.

The system is important because Signal’s privacy model does not depend only on trusting its own servers. But SGX does not remove the need for secure code. The server still controls things such as memory mapping and thread scheduling. V12 found that those controls could be abused to trigger bugs inside the enclave.

The First Flaw Turned a Race into an Arbitrary Read

The first bug involved workers that process contact database requests. CDSI divides its database work across shards. Each shard has a queue and a long-running worker. A lookup request goes into the queue, followed by a wait request. With one worker, the wait confirms that the lookup has finished.

The enclave allowed the host to start a worker for a shard. It did not check whether another worker already existed. A hostile host could therefore start a second worker for the same shard. The second worker could consume the wait request while the first worker still handled the lookup.

The enclave could then free the lookup result too early. The first worker would later write the result into freed memory. V12 turned that stale write into an arbitrary memory-read capability. The proof of concept extracted the 32-byte Noise responder private key from enclave memory.

The Second Flaw Enabled Code Execution

The second flaw involved how CDSI handled client objects. The enclave first checked whether a client object was valid. It then marked the object as in use. Because those actions happened separately, a short race window existed between them.

V12 used the host’s control over page faults to pause an enclave thread during that gap. The host then freed the valid object and placed attacker-controlled data at the same address. When the thread resumed, the enclave treated the replacement as a valid client object.

The replacement could control function pointers used by the Noise encryption code. V12 used those pointers to control the enclave’s CPU register state and execute code inside the trusted environment.

The researchers again extracted the Noise private key and also demonstrated code execution inside the protected environment. This was a full compromise of the enclave’s confidentiality and integrity, according to V12.

The Attacks Required Server Host Control

Neither flaw was an ordinary remote attack that anyone could launch against Signal users over the internet. The attacker needed control of the host machine running the enclave.

Signal uses an enclave because the host is not supposed to gain access to protected contact data. A compromised or malicious host is part of the threat that SGX is meant to address.

V12 validated both exploits on real SGX hardware. The hardware matched the Azure machines used by Signal. There is no indication in V12’s disclosure that either flaw had been exploited in the wild.

Signal Fixed Both Vulnerabilities

Signal fixed both issues in its enclave code. The first fix enforces one worker per shard inside the trusted boundary. The second combines the client validity check and its in-use state into one atomic value. This closes the gap behind the TOCTOU attack.

Signal’s public ContactDiscoveryService-Icelake repository contains both the host-side service and SGX-side C code. Users do not need to reset their Signal accounts. They also do not need to change their Signal settings because of these flaws.

The vulnerabilities affected server-side enclave code. Signal fixed them on its infrastructure. No special client update is required for these specific bugs.

The incident shows why trusted hardware does not replace secure software. SGX can protect data from the host, but the code inside the enclave must still handle memory, threads, and object lifetimes safely. In this case, two race conditions were enough to undermine that protection.

Share this article

About the Author

Rebecca James is an IT consultant with forward thinking approach toward developing IT infrastructures of SMEs. She writes to engage with individuals and raise awareness of digital security, privacy, and better IT infrastructure.

More from Rebecca James

Related Posts