Host permissions are moved to random guest when host left the meeting

Description
Please see steps to reproduce

Which version?
2.6.0

To Reproduce(If applicable)
Steps to reproduce the behavior:

  1. User1 joins meeting as guest from one browser on a machine
  2. User2 joins meeting as guest from another browser on a different machine
  3. User1 presses the claim host button and becomes the host of the meeting
  4. User1 closes the browser/tab
  5. After a few minutes User1 disappears from the participants list and User2 becomes host automatically

I have tested this with 3 or more participants and it seems the host permission is being given to the available person that joined after the host.

Also, host is being given to a guest even if they have closed their browser and they are not longer in the meeting but their username remains in the participants list, and of course once that list refreshes, the host is then being given to another person.

I believe this is a byproduct of a host having to pass the host to someone to leave the meeting. As they don’t have the option of just leaving, but only ending the meeting or passing the host to someone else, even though the meeting allows participants without the host being present, which is funny.

This has been tested on Safari, Chrome, Firefox and Edge, all latest versions and the same thing happens on all of them.

This is quite a big security issue, as you don’t want a random guest from a meeting to become host and be able to control the whole meeting and participants.

You have this issue since 1.8.x and you have mentioned that it will be addressed and yet its still there.
https://devforum.zoom.us/t/host-permissions-are-moved-to-guest-when-host-left-the-meeting/

i have checked the behavior with the non SDK version on zoom.us

Clipboard01

this should be similar in the SDK version, if the host clicks “end”

I will it test tomorrow with the SDK version 2.8.0

Hey @alexbudin , thanks for bringing this up. This is expected behavior for Zoom Meetings and the Meeting SDK (Web, mobile, and desktop platforms). If a meeting is occurring and the host leaves, a host is assigned until an authenticated host rejoins the meeting.

Following the thread in 2020 about 1.8.x, we did introduce a change to re-join/reclaim the meeting host permission using the host signature in the join process of the Web Meeting SDK.

If you assign Co-host or alternate host to a participant, they will receive host permission rather than another participant.

Additionally, in the event that a meeting host ends their session and has not ended the meeting, you can update meeting status using the REST API to update meeting status.

I have reread your post and now I have understand what you found

and the problem is also in SDK version 2.8.0

my Test:

  • guest-1 starts the meeting with setting “Allow participants to join anytime”
  • guest-1 will be host with the host key
  • guest-2 enters the meeting

result: OK

now guest-1 (the host) closes the browser tab

result: OK

wait approx. 2 minutes

result: BIG PROBLEM → Guest-2 is now host without authentication

1 Like

now I have checked the same on the non SDK version on zoom.us → same security problem

closed tab of the host

after 2 minutes waiting

→ Guest-2 is now host without authentication

UPDATE: same will be happen, if the original host don’t close the browser, but has a 2 minutes interuption of his internet connection

UPDATE 2: Someone should test this problem with the Zoom APP (2 minute internet connection failure at the host) → what happens with the host role

1 Like

same happens, if you have an normal host (without guest claim host)

a short message “you are now host” after 2 minutes and the guest will be host without authentication

1 Like

@michael.zoom There is no way this is normal. Hopefully an option is added in the meeting settings that prevents this. A checkbox or something that lets the app creator/admin to not allow the host to be given to anyone else. This is quite a big security problem.

@j.schoenemeyer is right, this appears to be a problem in the recent version as well.

Imagine losing internet access for 2 minutes and a random guest getting admin rights. Not to mention that on the web once there is a host in the meeting, nobody else can see the CLAIM HOST button to become host or get the host from that guest.

Thank you for your feedback @alexbudin and @j.schoenemeyer! As @michael.zoom mentioned, this is expected behavior. However, you can control who is passed host controls (meeting admin rights) and manage the experience if a host loses connection.

To mitigate a random guest getting admin rights, you would assign a Co-host or alternate host to a participant. This way if the host was to lose internet access for 2 minutes and a random guest would not get admin rights. Instead, the designated co-host or alternate host will receive host permission rather than another participant.

Host and co-host controls in a meeting

Additionally, if the host and co-hosts are not present or if they lose connection during a meeting. In the Zoom Web portal, you can select the check box to move participants to the waiting room if the host drops from the meeting unexpectedly. Once the host rejoins, they will regain host permissions and can admit participants all at once. Note, if you select this option, join before the host will be disabled. See our Enabling and customizing the Waiting Room for more details on this feature:

How to configure waiting room options

Additional resource:

Passing host controls to leave the meeting

But this is still a bug. I dont want to use waiting rooms. Imagine having a live stream and the host drops and a guest just gets host and terminates the meeting.

There are legitimate reasons why someone might not want to use a waiting room and its not even default. If you would have this as a default at least i can see you are trying to avoid this.

But all yu have done is offer me a WORKAROUND. This is not a fix.

What you are saying is this is intended but this is how you can avoid losing host access because we can see this happens, but look here where you can have this workaround :))) Which is just not admiting this is a security issues and having a proper fix for a feature that you have and thats to create a meeting WITHOUT a waiting room.

Does it make sense? You are just offering workarounds for a LEGITIMATE SECURITY ISSUE.

Why allow the creation of meetings without waiting rooms when you have this security issue?

Its not intended behavior if you can do it without having a co-host and without a waiting room.

You actually say: “To mitigate a random guest getting admin rights” :slight_smile: which i read as “we clearly have this security issue but here is how to go around it…but hey this issue you are describing…we do this on purpose”

People need to know you have this issue because by default you can create meetings without cohosts and without waiting rooms. There is no warning, there is no fix.

I would rather hear form you guys a plan to fix this, some concrete plans or solutions.

Thank you.

2 Likes

Thank you for taking the time to share your feedback with us, @alexbudin. I understand your point that there are legitimate reasons why someone would want to create a meeting without a waiting room. In this situation, I do see an issue allowing the creation of meetings without waiting rooms. I’ve forwarded this feedback to our developer team and will get back to you.

Feel free to ping us here for updates on this matter and do let us know of any other additional feedback you might have now—we’re here to listen!

You SHOULD allow creation of meetings without a waiting room, but a simple checkbox to not allow the transfer of the host would just fix this where there is no waiting room configured. It should be such a simple fix to do. This is currently a security issue as it stands.

  • is there any way to see in the SDK version, if someone is host or co-cost - the guest, who get the lost host right, is named as (Host, Me) after the 2 minute timeout

  • is there a info page, where the difference between Host and Co-Host is described in detail

just testet on the non SDK version on zoom.us

meeting started by host and two guests, then close browser of the host

after two minutes guest-1 will be host (not co-host) !!!

guest-1 can close meeting for all partipants, which is not allowed for a co-host

1 Like

This seems to be worse than i thought.

i have the assumption that the original host who disappeared makes one of the guests the alternative host - this host role also still exists

@alexbudin , @j.schoenemeyer , I appreciate the detail in testing here and the feedback. We’re working with our Meetings product teams on this, as this does extend outside of the Meeting SDK (which, as the client, is the consumer of the meeting settings here).

I hear your feedback that the meeting host reassignment could cause unintended meeting control in the event that the waiting room option is not workable. Let me circle with some folks and get back.

3 Likes

a simple solution to the problem could be to let the meeting continue without host

meeting without host works fine in zoom (meeting option “Allow participants to join anytime”)

exactly. Just let the meeting continue and not assign the host to anyone else.

1 Like

and maybe as an optimization, if a co-host is present, the host role - in case of host failure - could be handed over to it

2 Likes

Any updates here guys?