{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "Teams meeting audio",
          "vendor": "unknown",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Jacob Greenway"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Hi Full Disclosure team,\n\nI\u0027m not a traditional security researcher by background - I found this\nwhile working with the ACS and Teams SDKs and followed it through to a full\nwriteup and PoC. I\u0027ve done my best to be accurate and responsible\nthroughout (reporting to MSRC first, giving advance notice of this\ndisclosure date, and only testing against meetings/tenants I own), but if\nanything here is imprecise or doesn\u0027t match community conventions, I\napologize in advance and welcome corrections.\n\n\n\n\n\n\n*Vendor: MicrosoftProduct: Azure Communication Services (Call Automation) /\nMicrosoft TeamsVulnerability class: Improper Access Control (CWE-284 /\nCWE-863) - missing re-authorization after a privilege/session-revoking\neventReported to vendor: 2026-08-19MSRC case number: VULN-213672Public\ndisclosure date: 2026-09-15*\n\n--- Description ---\n\nAzure Communication Services (ACS) Call Automation\u0027s connectCall operation\ncan attach an independent media/control session to an in-progress Microsoft\nTeams meeting using only the meeting\u0027s serverCallId. This identifier is\navailable to any current participant in the meeting - it\u0027s surfaced by both\nthe Teams desktop and web clients, and by the ACS Calling SDK\u0027s own\ncall.info.getServerCallId() API (used here purely as a clean, reproducible\ncapture method, not because ACS is a privileged or required path to the\nvalue).\n\nAs long as the target meeting\u0027s lobby is disabled, possession of the\nserverCallId alone is treated as sufficient authorization for connectCall\nto keep delivering:\n- Live audio, via Call Automation media streaming, and\n- Participant/roster metadata, via ParticipantsUpdated events\n\nto the caller\u0027s own ACS resource - which can belong to a completely\ndifferent Azure subscription/tenant than the meeting organizer\u0027s.\n\nCritically, this access is never revalidated against the caller\u0027s current\nmembership in the meeting. If a participant who previously captured the\nserverCallId and established a connectCall session is later explicitly\nremoved (\"kicked\") from the meeting by the organizer, that removal has no\neffect on the independent connectCall session: live audio and roster\nmetadata continue to be delivered to the attacker\u0027s ACS resource for the\nremainder of the meeting.\n\nAffected component: Azure Communication Services - Call Automation API,\nconnectCall operation; the Microsoft Teams meeting authorization boundary\n(lobby / admission control / participant removal).\n\nImpact: An unauthorized party can continue listening to live meeting audio\nand tracking every participant\u0027s presence/roster changes after having been\nexplicitly removed by the meeting organizer - undermining the one control\nTeams gives hosts to enforce \"this person is no longer part of the\nmeeting.\" This affects the confidentiality of every participant in the\nmeeting, not just the removed attacker, since their live audio and presence\ndata keeps flowing to a third party the organizer explicitly tried to\nexclude.\n\n--- Steps to reproduce ---\n\nFull harness source, setup instructions, and screenshots are in the repo\nlinked below (poc/README.md). Summary:\n\n1. The attacker joins the target Teams meeting, which has its lobby\ndisabled, as a normal participant and retrieves the meeting\u0027s internal\nserver call identifier using a documented capability of the Azure\nCommunication Services calling SDK.\n2. The attacker starts a Call Automation media server and instructs Azure\nCommunication Services to attach an independent session to the meeting\nusing that captured identifier, requesting live audio streaming. Azure\nimmediately begins delivering live audio and participant roster updates to\nthe attacker\u0027s own communication resource, confirmed by the connection and\nstreaming-started notifications it sends back.\n3. The meeting organizer removes the attacker\u0027s original participant from\nthe meeting using Teams\u0027 built-in \"Remove from meeting\" action.\n4. Observed result: the attacker\u0027s original Teams client session\ndisconnects as expected, but the independent session from step 2 is not\ntorn down. Live audio and roster metadata continue to arrive at the\nattacker\u0027s communication resource for the remainder of the meeting, with no\ncorresponding disconnection notification for that session.\n\n--- Disclosure timeline ---\n\n2026-08-19 - Reported to Microsoft (MSRC case VULN-213672).\n2026-08-27 - MSRC acknowledged the report (automated response: reviewing,\nnext steps pending).\n2026-09-01 - I requested a status update on reproduction on Microsoft\u0027s\nside, then confirmed an intended public disclosure date of 2026-09-14.\n2026-09-13 - I notified MSRC that public disclosure would follow the next\nday and offered to delay if MSRC responded within ~24 hours.\n2026-09-15 - No further response received from MSRC. Public disclosure, as\npreviously stated and with prior notice given.\n\nFull writeup, PoC source, and screenshots:\nhttps://github.com/Tryptophan/teams-meeting-audio-vulnerability\n\nPlease let me know if you have any questions!\n\nBest,\nJacob Greenway\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-284",
              "description": "CWE-284",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-863",
              "description": "CWE-863",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-02T04:57:33Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/43"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Sep/43"
        },
        {
          "url": "https://github.com/Tryptophan/teams-meeting-audio-vulnerability"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Sep/43"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "Teams meeting audio and roster data remain accessible via ACS Call Automation connectCall after a participant is removed from the meeting",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0419",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/43",
            "automated": true,
            "contentSha256": "2d6b8b4b8347d43b845ba976b026289406c9c3cc7c154974fde1f391eb9daefb",
            "evidenceScore": 10,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Sep/43",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-09-16T05:58:27Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-10-02T04:57:33Z",
    "dateUpdated": "2026-10-02T04:57:33Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0419"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}