OP 14 February, 2026 - 07:56 PM
I've been doing some digging into the Session chat app and came across an interesting behavior. It seems possible to send requests to users without triggering a visible message thread specifically by using reactions and targeting their user ID.
For example, using the Session.js library:
https://sessionjs.github.io/docs/reactions/
Normally, this type of interaction doesn't generate a visible message in the chat UI. However, the client still appears to process it, which makes it a fairly subtle way to interact with a target.
What caught my attention is whether this could be abused. In theory, an attacker could flood a target with these reaction requests, forcing their client to process them continuously. My concern is whether this could lead to a DoS-type situation maybe not on a network level, but potentially crashing or lagging the client itself if enough requests are thrown at it.
That said, I'm not totally convinced this is a serious vulnerability without significant resources behind it. But it still seems worth documenting and discussing.
If anyone here has dug deeper into Session's architecture, explored similar quirks, or has thoughts on whether this could be amplified, feel free to jump in. Always interested in building on these kinds of observations.
For example, using the Session.js library:
https://sessionjs.github.io/docs/reactions/
Code:
session.addReaction({ messageTimestamp: random-timestamp, messageAuthor: target-session-id, emoji: '?' })Normally, this type of interaction doesn't generate a visible message in the chat UI. However, the client still appears to process it, which makes it a fairly subtle way to interact with a target.
What caught my attention is whether this could be abused. In theory, an attacker could flood a target with these reaction requests, forcing their client to process them continuously. My concern is whether this could lead to a DoS-type situation maybe not on a network level, but potentially crashing or lagging the client itself if enough requests are thrown at it.
That said, I'm not totally convinced this is a serious vulnerability without significant resources behind it. But it still seems worth documenting and discussing.
If anyone here has dug deeper into Session's architecture, explored similar quirks, or has thoughts on whether this could be amplified, feel free to jump in. Always interested in building on these kinds of observations.
![[Image: pepeglad.png]](https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fstatic.cracked.st%2Fimages%2Fsmilies%2Fpepeglad.png)