Session Chat Has No Memory Protection

[Laid Back Llama]

Session stores your messages and even your private access key in memory without any real protection.

This means any third-party app on your phone or computer can freely read Session’s memory and extract all your messages plus the private access key for your account. I would never trust an app like Session (with such vulnerability) that is even supposed to be specialized in privacy.

This is a basic vulnerability, if they didn't even notice this, it makes you wonder how many other flaws exist in their infrastructure. (I also wouldn’t trust their Tor routing to be honest)

Demonstration:

Ah btw, even when you delete your messages, they still appear in the memory.

 

[compromised]

There's a reasonable point in here, but it lands on the wrong target. Anything that puts plaintext on your screen has to hold it in RAM, key included, so this is closer to a property of decrypting locally than a flaw in Session specifically. On Android the Molly (signal fork) app clears the key on close, but it only helps while the app is shut, since the key is back in ram once you unlock the app. The same thing is true of an unlocked encrypted volume, and it's also why a clean reboot locks everyone out.

On iOS you need a jailbreak and on Android you need root or ADB, so apps can't just read each other. It's really a desktop concern, and even there the usual route is dumping memory with something like Sysinternals, which needs admin privileges, so it isn't every app on the machine that can do it. Once someone can read your memory they can also scrape the database or keylog you, so the key is just one of several ways in.

Keep the OS and browser patched, install less, stick to official stores instead of sideloaded APKs, use a screen lock with disk encryption, and reboot now and then so anything resident gets evicted. On desktop, run a standard user account instead of an admin one, since that alone blocks most memory reads, keep browser extensions to a handful you actually recognize, and put risky things in a VM or a separate profile.

Do that and the memory exposure stops mattering much, because the attacker has to get onto the machine before it can read anything.

 

[Laid Back Llama]

Anything that puts plaintext on your screen has to hold it in RAM, key included, so this is closer to a property of decrypting locally than a flaw in Session specifically

This is wrong, there are many ways where you can protect your memory and any text present in your UI or written down a swell, a basic example is to instead of saving messages/words as strings, you split them into chars (this is a very basic practice, but you can also do a lot of other cool advanced things).

since the key is back in ram once you unlock the app

They definitely need to protect that as well, someone could automate reading that key by simply finding the static pointer in the memory (that is the same for all users).

On iOS you need a jailbreak and on Android you need root or ADB, so apps can't just read each other

Here I have to admit that I am not a professional on mobile devices, but I will explain later the main concerns about my report.

It's really a desktop concern, and even there the usual route is dumping memory with something like Sysinternals, which needs admin privileges, so it isn't every app on the machine that can do it.

You can read the memory of processes even without admin, you don't even need to dump it.

As for the rest, yes, it’s all standard practice that everybody should follow. But the core issue with my report is that people need to feel like their chat app/software is actually protected. The problem right now is that the only way to use Session securely is either with GrapheneOS on a mobile phone or Qubes on a desktop. Not everybody has those, so anyone not using those operating systems is at risk.

The issue isn’t getting malware per se (of course, don’t be dumb enough to get hacked). The real problem is that you cannot trust your operating system. Any Android, iPhone, Windows, etc., cannot be trusted at all. There have been many cases where all of those have been breached by authorities at some point. Imagine if some high-level app or a root-like privileges system app reads your Android sandboxes (because with root-like privileges it could, some core Google service, for example). They can read everything right now and even get access to your private key.

A proper app, even on Android or iPhone, can be much more solid. For example, anti-keylogging is a thing (so external processes are blocked from accessing your keystrokes while you’re typing in the app), along with memory protection, memory encryption, memory erasing, and even anti-debug/tamper systems, obfuscation, etc. I expect all of this to be done by an app like Session, this is a must.

Also, in 2026 I don’t really trust Tor nodes anymore eiher, too much fuckery is going on with authorities creating Tor nodes, and I believe we’ll soon start seeing people being traced directly through Tor nodes.

The only promising project I found right now that could fix the Tor issue: NymVPN: The world's most private decentralized VPN | Nym. (There are many ways to prevent the Tor tracking issues as well, but for this topic, Session runs on Tor and we don't know which nodes it uses and if those nodes will ever be compromised).

 

[compromised]

instead of saving messages/words as strings, you split them into chars

You’re right that using a mutable buffer is better practice than an immutable string, because it lets you overwrite the data after use and reduce leftovers. That said, while the data is actually being used it’s still plaintext in memory, so someone who already has access can still read it. It’s a useful hygiene measure, but it’s not the same as encryption.

memory protection, memory encryption, memory erasing, and even anti-debug/tamper systems, obfuscation

They’re all worthwhile and raise the bar in different ways. What they don’t do is make an ordinary app independent of the operating system it’s running on. Once an attacker controls the environment, they can generally intercept data at the point the app uses it. Extra defences are still valuable; they just don’t fully neutralise a fully compromised OS.

My earlier claim about keys was too absolute. Hardware-backed keys (when the device supports them) can stay inside secure hardware and never enter application memory, that’s good for resisting extraction. The separate issue is that the decrypted messages themselves still have to come back into the app’s address space to be displayed or processed.

You can read the memory of processes even without admin, you don't even need to dump it.

On Windows it depends on the access rights the target process grants and the privileges of the caller. An arbitrary unprivileged process can’t just open any other process and start reading its memory; the necessary rights (like PROCESS_VM_READ) have to be obtainable. So a complete dump isn't always needed, but neither is unrestricted cross-process access the default.

someone could automate reading that key by simply finding the static pointer in the memory

ASLR does change locations between runs, even if there can still be other ways of locating material.

And on the Android side, being a system app doesn’t automatically give unrestricted access to other apps’ memory; the sandbox and SELinux still apply. A fully compromised kernel is a different story, of course.

Session runs on Tor

Finally, a small clarification: Session doesn’t actually use the Tor network. It runs its own onion-routing protocol over Session Nodes (token backed). The concept is similar, but the network and the people running the nodes are different, so concerns that apply to Tor relays don’t automatically transfer.

I’d actually flip the trust model the other way around. To reliably catch or prevent these kinds of issues you need control over the OS and the network in the first place. The environment is what lets you enforce the boundaries. An app is far more ephemeral than the device and operating system it runs on; if the foundation is compromised, no amount of app-level hardening fully compensates. So the primary trust has to sit with the platform and the network.

None of this means Session’s memory handling is perfect or beyond criticism. Finding readable data while an app is actively using it doesn’t by itself prove a vulnerability, and it doesn’t mean only GrapheneOS or Qubes are viable. The useful distinction, I think, is between unnecessary residual exposure of secrets and an attacker who already has the level of access needed to watch the app’s normal operation.

Happy to dig further into any of these points if useful.

 

[Laid Back Llama]

Finally, a small clarification: Session doesn’t actually use the Tor network. It runs its own onion-routing protocol over Session Nodes (token backed). The concept is similar, but the network and the people running the nodes are different, so concerns that apply to Tor relays don’t automatically transfer.

You are so right here, not sure why I always thought they were on Tor 🤣but same concept applies, we will never know if they get compromised or not.