Teams meeting audio and roster data remain accessible via ACS Call Automation connectCall after a participant is removed from the meeting

[Jacob Greenway <jagreenway12 () gmail com>]

Hi Full Disclosure team,

I'm not a traditional security researcher by background - I found this
while working with the ACS and Teams SDKs and followed it through to a full
writeup and PoC. I've done my best to be accurate and responsible
throughout (reporting to MSRC first, giving advance notice of this
disclosure date, and only testing against meetings/tenants I own), but if
anything here is imprecise or doesn't match community conventions, I
apologize in advance and welcome corrections.






*Vendor: MicrosoftProduct: Azure Communication Services (Call Automation) /
Microsoft TeamsVulnerability class: Improper Access Control (CWE-284 /
CWE-863) - missing re-authorization after a privilege/session-revoking
eventReported to vendor: 2026-08-19MSRC case number: VULN-213672Public
disclosure date: 2026-09-15*

--- Description ---

Azure Communication Services (ACS) Call Automation's connectCall operation
can attach an independent media/control session to an in-progress Microsoft
Teams meeting using only the meeting's serverCallId. This identifier is
available to any current participant in the meeting - it's surfaced by both
the Teams desktop and web clients, and by the ACS Calling SDK's own
call.info.getServerCallId() API (used here purely as a clean, reproducible
capture method, not because ACS is a privileged or required path to the
value).

As long as the target meeting's lobby is disabled, possession of the
serverCallId alone is treated as sufficient authorization for connectCall
to keep delivering:
- Live audio, via Call Automation media streaming, and
- Participant/roster metadata, via ParticipantsUpdated events

to the caller's own ACS resource - which can belong to a completely
different Azure subscription/tenant than the meeting organizer's.

Critically, this access is never revalidated against the caller's current
membership in the meeting. If a participant who previously captured the
serverCallId and established a connectCall session is later explicitly
removed ("kicked") from the meeting by the organizer, that removal has no
effect on the independent connectCall session: live audio and roster
metadata continue to be delivered to the attacker's ACS resource for the
remainder of the meeting.

Affected component: Azure Communication Services - Call Automation API,
connectCall operation; the Microsoft Teams meeting authorization boundary
(lobby / admission control / participant removal).

Impact: An unauthorized party can continue listening to live meeting audio
and tracking every participant's presence/roster changes after having been
explicitly removed by the meeting organizer - undermining the one control
Teams gives hosts to enforce "this person is no longer part of the
meeting." This affects the confidentiality of every participant in the
meeting, not just the removed attacker, since their live audio and presence
data keeps flowing to a third party the organizer explicitly tried to
exclude.

--- Steps to reproduce ---

Full harness source, setup instructions, and screenshots are in the repo
linked below (poc/README.md). Summary:

1. The attacker joins the target Teams meeting, which has its lobby
disabled, as a normal participant and retrieves the meeting's internal
server call identifier using a documented capability of the Azure
Communication Services calling SDK.
2. The attacker starts a Call Automation media server and instructs Azure
Communication Services to attach an independent session to the meeting
using that captured identifier, requesting live audio streaming. Azure
immediately begins delivering live audio and participant roster updates to
the attacker's own communication resource, confirmed by the connection and
streaming-started notifications it sends back.
3. The meeting organizer removes the attacker's original participant from
the meeting using Teams' built-in "Remove from meeting" action.
4. Observed result: the attacker's original Teams client session
disconnects as expected, but the independent session from step 2 is not
torn down. Live audio and roster metadata continue to arrive at the
attacker's communication resource for the remainder of the meeting, with no
corresponding disconnection notification for that session.

--- Disclosure timeline ---

2026-08-19 - Reported to Microsoft (MSRC case VULN-213672).
2026-08-27 - MSRC acknowledged the report (automated response: reviewing,
next steps pending).
2026-09-01 - I requested a status update on reproduction on Microsoft's
side, then confirmed an intended public disclosure date of 2026-09-14.
2026-09-13 - I notified MSRC that public disclosure would follow the next
day and offered to delay if MSRC responded within ~24 hours.
2026-09-15 - No further response received from MSRC. Public disclosure, as
previously stated and with prior notice given.

Full writeup, PoC source, and screenshots:
https://github.com/Tryptophan/teams-meeting-audio-vulnerability

Please let me know if you have any questions!

Best,
Jacob Greenway
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/