Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-2xm2-xj2q-qgpj
No affected components available
Original Message: Hi,
I create objects with one client with an ACL of all users with a specific column value. Thats working so far.
Then I deleted the session object from one user to look if he can receive subscription objects and he can receive them. The client with the deleted session cant create new objects, which Parse restricts right.
The LiveQueryServer doesnt detect deleted sessions after the websocket connection was established. There should be a mechanism that checks in an specific interval if the session exists. I dont know if its true with expired sessions.
Any solutions?
Parse version: 4.3.0 Parse js SDK version: 2.17
Solution: Hi guys.
I've found and fixed the problem. It happens because there are two caches in place for the session token:
- at Parse Server level, which, according with the docs, should be changed via cacheTTL option and defaults to 5 seconds;
- at Parse Live Query level, which, according with the docs, should be changed via liveQueryServerOptions.cacheTimeout and defaults to 30 days.
But there are three problems:
- cacheTTL has currently no effect over Live Query Server;
- cacheTimeout also has currently no effect over Live Query Server;
- cacheTimeout actually defaults to 1h.
So, currently, if you wait 1 hour after the session token was invalidated, the clients using the old session token are not able to receive the events.
What I did:
- Added a test case for the problem;
- Fixed cacheTTL for Live Query Server;
- Fixed cacheTimeout for Live Query Server;
- Changed the cacheTimeout to default 5s;
- Changed the docs to reflect the actual 5s default for cacheTimeout.
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker needs basic access or low-level privileges. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a low impact on the confidentiality of the information.
Exploitation attempts have been detected. Elevated vigilance and prompt remediation are advised.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard