- Spegnimento
- 5 settembre 2026 alle ore 07:25 UTC
- Autore
- Kamo
- Impegno
- 5355b88
Due difetti sul /settings/integrations/member endpoints, entrambi vivi ed entrambi raggiungibile da qualsiasi membro sottoscritto. L'id era l'unico controllo di accesso. Ogni punto finale ha preso integrazione id direttamente dal percorso e non ha chiesto altro, quindi un membro potrebbe aggiornare la riga di un altro membro -- incluso sovrascrivere le credenziali su di esso -- eliminarlo, testarlo o pubblicare un trigger di sincronizzazione per esso. Un UUID non è un controllo dell'autorizzazione: ids viaggiare in registri, filetti di supporto e cronologia del browser, e la riga che viene indirizzata contiene una mailbox credenzialial. èMembersOwn ora cancelli tutto quattro, rispondendo 404 piuttosto che 403 in modo che affrontare la fila di qualcun altro fa non confermare che esiste, e logging il tentativo perché uno reale è o cliente rotto o qualcuno che cammina ids. Una riga di livello ORG è di proprietà di nessuno e così non è mai un membro, che conta perché questa è la fila che tiene l'intero La borsa di studio dell'organizzazione. E le risposte dei membri hanno restituito l'entità. cbc238a ha preso le credenzialiJson fuori dei due endpoint ORG e lasciato i quattro membri che lo riportano, che è lo stesso blob crittografato negli stessi corpi di risposta, cache del browser e registri proxy - solo sui sentieri che non avevo guardato. Tutti e quattro passano attraverso la stessa vista ora, riferire solo WHETHER una credenziale è sul file. Lo schermo che li chiama è irraggiungibile oggi (non importa niente PersonalProviderSezione, e chiede un GET /member/{id} che non è mappato), così né il difetto è stato esercitato. Questo non è un motivo per lasciarne uno: gli endpoint sono mappati, curati e serviti.