Critical Parse.Query.or bug 3.9.0

I think I’ve discovered really important bug in Parse.Query.or implementation.
I’ve 2 Classes - Team and TeamMember:
and here is my cloud code:
const queryEmail = new Parse.Query(“TeamMember”).equalTo(‘email’, email).include(“teamId”);

const queryUserId = new Parse.Query(“TeamMember”).equalTo(‘userId’, user).include(“teamId”);

const teamMemberResult = await Parse.Query.or(queryEmail, queryUserId).ascending(“name”).find({sessionToken: sessionToken});

Now the problem is that in TeamMemberResult I get proper TeamMember record but joined with completely other Team record, and the biggest problem is that that the user doesn’t have have ACL to access that Team record. It’s completely different Role and group. That’s parse 3.9.0 and I think it’s critical. I’m not passing any Master Key and user simply can read other users data without having access to that records. If I’m wrong please let me know why?

Hi, I’ve just made this post unlisted as you seem to be reporting a potential security vulnerability.

I don’t have time to look into this now, it may just be that your acl is setup incorrectly.

@acinader @dplewis @davimacedo - could any of you take a quick look at this to identify if there is a problem or not?

ACLs are properly set, but we use it heavily (each team has it’s own ACL). I think is could be actually related to some caching engine, since we used back4app I’m not sure what was the reason. I can’t repeat that right now but we also had other issue with not showing records from other collection, and simply started to work after some time lapse. I hope it’s caused by some buggy cache engine than to Parse engine itself. We decided to move to Amazon immediately and if the issue reappears I’ll let you know. I like parse a lot and would like to use it to our new great project - I was just really scared after the issue.

Hi,

Would it be possible to write a test case for this to replicate this issue?

Hi. I can help you to figure it out with Back4App team. Have you opened a ticket there? Can you please share your app id with me?

BTW there isn’t any cache in place by default.

It’s really no easy to create a test case. It could be related to 2 users editing/accessing records in the same collection at the same time (only 2 developers). There were actually 2 issues - one wrong join and second missing records from other collection. For both we used Parse.or but I’m not sure it’s because of that. I don’t know how the engine works inside but just can’t imagine how it can return record without checking ACL properly (not speaking about wrong join).
I’m going to monitor it and if it appears again I’ll give you more details - because we can’t simply repeat that on our DB. Our dev discovered it because he got records that he couldn’t edit - so I checked it on my machine and it was exactly the same. Then I removed Parse.or and it worked well.