Forum Discussion
Security loophole in Private Channels?
We came across an interesting use case in our organization today.
We have a Team and a private channel within that Teams team. Within the private channel a subsite was created. I am not an owner or member of the Team nor am I a member or owner of the private channel. However during creation of the subsite I was able to be invited with unique permissions to the subsite and I was successfully able to access it. After the initial creation of the subsite, our admin was not able to add or remove or effect any additional permissions on that subsite.
Is this a loophole? I expected that without being a member of the private channel I would have absolutely zero access to any items associated with the private channel and site. Which has remained true (when I go to the private channel URL I get denied access) except that I do have access to this specific subsite. My instinct is that the reason permissions cannot be changed after the fact is that this is a genuine loophole and permissions weren't intended by Microsoft to be able to be granted at all on the subsite. This is due to the fact it is under the private channel and permissions should only be able to be changed via the admin UI or from the Teams application.
Has anyone come across this in their work? Any guesses or explanations for why the subsite access would be initially available? Is this just genuinely a loophole in the permissions architecture?
1 Reply
This is not the isolation model Microsoft documents for a private channel. A private channel has a SharePoint site; membership is synchronized from Teams, and site permissions cannot be managed independently. Only channel owners and members should have site access.
The subsite appears to have broken inheritance and received a direct grant. SharePoint evaluates that subsite’s unique permissions, explaining why you can reach it while the channel site remains denied. Treat this as a configuration exposure, not proof that private-channel isolation is designed this way.
Have a SharePoint administrator audit the subsite’s unique permissions, sharing links, site-collection administrators, and sharing events. Remove the direct grant and restore inheritance if the content belongs to the channel. If permissions cannot be corrected, open a Microsoft support case before moving data. For content requiring another audience, use a separate SharePoint site with deliberately managed permissions rather than a subsite beneath a private-channel site.