I Asked How Guests Get Their Identity — and Found a Meeting Logic Flaw

1. The Initial Clue: Understanding How Guests Are Identified

I'm particularly interested in business logic vulnerabilities because they require more than finding an unusual response or injecting a payload into a parameter. I enjoy understanding how an application is structured, how its components depend on each other, and what happens when one component makes an assumption that another component doesn't enforce.

This investigation started with a simple observation about a web application used for online meetings, similar to Google Meet.

The application had a clear access model: authenticated users could create meetings, while unauthenticated guests could only join existing ones.

That immediately raised a question in my mind: How does the application distinguish between guest participants when they don't have authenticated accounts?

A meeting host needs to know who is waiting to join, who has been admitted, and who has been rejected. Without normal user authentication, the application must have another way to track guest identities.

I started by comparing the cookies used by authenticated users and guests. The difference was interesting: authenticated users had a session identifier, while guests had a separate cookie named lobbyParticipantId.

This suggested that the application used a different mechanism to identify unauthenticated participants. I wanted to understand whether that identifier was generated and enforced by the server or whether the client could influence it.

2. Following the Cookie: Who Controls the Participant Identity?

I began modifying the lobbyParticipantId cookie and observing how the server responded.

The server accepted my modified value and returned it as the participant's ID. This was the first important clue: the value I supplied was not simply ignored in favor of an independently generated identifier.

Initially, I explored several attack possibilities, including CRLF injection and XSS, but none of those attempts produced a working vulnerability.

Rather than continuing to focus on injection, I shifted my attention to the role this identifier played in the application's business logic.

I asked myself: What happens if I supply an identifier that the application was never designed to accept?

The application appeared to expect a UUID-like identifier. I therefore replaced the cookie value with an arbitrary string:

Cookie: sessionid=xxxxx; lobbyParticipantId=https://evil.com

Cookie: sessionid=xxxxx; lobbyParticipantId=https://evil.com

The string was only a test value; I did not need to contact the external domain.

The server accepted the value and returned a response similar to:

{
  "status": "waiting",
  "username": "medooooo",
  "id": "https://evil.com"
}

{
  "status": "waiting",
  "username": "medooooo",
  "id": "https://evil.com"
}

This was the turning point. The application had accepted a value outside its expected identifier format and used it as the participant's ID.

At this stage, I had not yet established the full impact. I needed to understand how other parts of the application relied on this identifier.

3. The First Impact: A Participant the Host Couldn't Remove

The next step was to follow the identifier into the meeting's moderation workflow.

The host could normally remove or reject guests waiting in the lobby. I wanted to see whether the application would still handle the participant correctly after I changed the identifier.

I used a separate browser as the meeting host and attempted to remove the guest whose lobbyParticipantId contained the arbitrary string.

The removal operation did not work as expected. The participant could not be properly removed through the host's normal moderation controls because the identifier did not match the format expected by that functionality.

The joining workflow accepted a value that the moderation workflow could not correctly handle (Must be a Valid UUID).

Steps to reproduce: Malformed participant identity

1- Open a meeting as a guest user.

2- Intercept the request sent when requesting entry to the meeting.

3-Modify the cookie named:

4- lobbyParticipantId lobbyParticipantId=https://evil.com

5-Send the request. Example:

Cookie: sessionid=xxxxx; lobbyParticipantId=https://evil.com

6-Observe that the server accepts the attacker-controlled value and uses it as the participant identifier. Server response:

{ "status":"waiting", "username":"medo2", "id":"https://evil.com" }

7-The meeting host/admin can no longer properly remove the malicious participant from the lobby.

8- Repeat the process with different arbitrary values to verify that the behavior is reproducible.

4. Going Deeper: What If the Identifier Belongs to Someone Else?

After identifying the moderation bypass, I wanted to understand whether the problem was limited to malformed values.

The server had accepted an identifier supplied through a client-controlled cookie. That raised another question: What happens if I supply a valid identifier belonging to an existing participant instead of an arbitrary string?

This was a different test of the same underlying trust assumption.

Using two guest sessions in a meeting, I identified the lobbyParticipantId associated with one participant and replaced the other session's cookie value with that identifier.

I then submitted the join request with the modified cookie.

The resulting behavior was more serious: the original participant was removed or replaced, while the second guest joined using the original participant's identity reference.

This demonstrated that the application did not adequately protect the relationship between a participant identifier and the session to which it belonged.

Steps to reproduce: Reusing another participant's identifier

1- Join a meeting as a guest user.

2- Obtain a valid lobbyParticipantId belonging to another participant.

3-Intercept the request sent while requesting entry to the meeting.

4-Replace your own lobbyParticipantId cookie value with the victim's identifier.

5-Send the modified request.

6-Observe that:

The victim participant gets removed/disconnected

7-The attacker joins instead using the victim's identifier

5. Understanding the Full Security Impact

The two tests exposed different consequences of the same underlying weakness.

A. Lobby moderation bypass

By supplying an identifier outside the expected format, a guest can create a lobby entry that the host cannot properly remove through the normal moderation controls.

This undermines the host's ability to control who is waiting to join the meeting.

B. Repeated lobby disruption

The guest can repeat the process using different arbitrary identifiers to create multiple distinct lobby entries from the same session.

This forces the host to deal with repeated entries and can disrupt the meeting's admission process. The demonstrated impact is repeated lobby disruption; a broader denial-of-service claim would require evidence of a larger availability impact.

C. Participant replacement

By reusing a valid participant identifier, a guest can cause the original participant to be removed or replaced and take their place in the participant state.

This affects the victim's availability and the integrity of the meeting's participant list.

6. Evaluation

The First Report :

The Second report closed duplicate to my First Report:

7. Final Takeaway

This finding started with a simple question: How does the application identify guests who don't have accounts?

I compared the cookies of authenticated users and guests, found the lobbyParticipantId, and tested whether I could control it. After discovering that the server accepted arbitrary values, I followed the identifier through the application and found that it could break lobby moderation and allow one participant to replace another.

The main lesson is that you shouldn't stop when you find something you can manipulate. You should understand how the application uses it and what happens when other features depend on it.

A cookie might look like an ordinary piece of data, but if the application trusts it to decide who someone is, changing it can have consequences far beyond that single value.

Instead of asking only, "Can I modify this value?", ask yourself: "What can I do if the application trusts a value it shouldn't?"