- Shipped
- 5 de agosto de 2026 às 07:24 UTC
- Author
- Kamo
- Commit
- c7cb180
A revisão adversa de 6df0008 confirmou 24 achados. Os mais importantes: CRÍTICA — qualquer membro pode apagar o correio de um colega. Os identificadores de correio de voz das equipas foram composto como "{mailbox}'{graphMessageId}", e mark-read / delete / fetch split the id fornecido pelo chamador e usou a sua caixa de correio como /users/{mailbox} no org's aplicativo token — que pode chegar a cada caixa de correio no inquilino. A os pares de mensagens foram distribuídos por GET /instances/{id}/voicemails, então Nem sequer foi um jogo de adivinhação. A caixa de correio é agora resolvido exclusivamente a partir da chamada conexão própria do membro Microsoft e não é derivable de qualquer coisa um cliente envia; o trabalho de org-scoped (sync, health) não resolve nenhuma caixa de correio e não lê nenhuma. Isso. também pára a sincronização de instância andando a caixa de correio de cada colega no token do aplicativo. Largar a caixa de correio do id corrige mais dois defeitos confirmados gratuitamente: o ids foram ~190-240 caracteres contra uma coluna VARCHAR(128) (cada persistência falhou), e o ''' fez Tomcat rejeitar o URL com um 400 antes do roteamento da primavera, então mark-read, arquivo e delete nunca chegou ao servidor. IDs de extensão mover para '~' para a mesma razão, e o sufixo de roteamento das equipes (+1425...;ext=1234, 21 chars) é agora Aparado para caber no VARCHAR(20) de EXTENSION NUMBER em vez de falhar na sincronização. ALTA — a história do chamado estava silenciosamente vazia para a maioria dos membros. getPstnCalls é um ração em todo o locatário sem filtro por usuário, e o código capotou o fetch em 2000 linhas ANTES de filtragem, então em qualquer inquilino com mais de ~2000 chamadas PSTN em 90 dias A tampa foi consumida pelas fileiras de outras pessoas. Filtragem agora acontece durante o paging e pára assim que a página solicitada estiver cheia. ALTO — As notificações dos gráficos foram processadas em linha na linha de resposta: N Gráfico sequencial idas e voltas contra um orçamento de reconhecimento de três segundos. Passado 15% de respostas lentas em dez minutos Gráfico marca o ponto final "queda" e descarta notificações durante dez minutos. A validação permanece em linha; o trabalho move- se para um Executador de chamadas limitado. HIGH — o Estado membro-conector transportava um membro, mas nada o ligava ao pessoa completando o login, para que um membro pudesse entregar sua URL de conexão a um colega e acabar com a identidade das equipas do colega em sua própria linha. Auto... conectar agora requer o login da Microsoft para corresponder ao e-mail Kamo do membro; conectar-se em nome de alguém permanece permitido e é gravado no estado. HIGH — MemberVoipConfigController confiou no caminho memberId sem verificação de org GET ou PUT, e nada a montante forneceu um: um IDOR cross-tenant sobre cada configuração VOIP do membro, agora incluindo seu ID de objeto Entra. Pré-existente, mas isto Commit é o que coloca uma identidade nessa carga útil. Além disso: TeamsNeedsReconnectException retornou 500 em vez de 409 para o esperado estado "ainda não conectado"; o endpoint do SCA foi configurado pelo operador sem validação que a delegada chamada token foi POST para (agora esquema- e host-pined); concorrente a manutenção da assinatura poderia órfão uma assinatura Graph contra o 100-por-org quota; e o acsEndpoint é editado porque os operadores colam toda a conexão Enganá-lo. Verificado: teste mvn — 136 testes, 0 falhas.