This vulnerability exposes a gap in how collaboration revocation is modeled: the DeleteCollaboration operation reports success while dependent resources it knows nothing about continue functioning. When a collaborator is removed, their webhooks persist and keep firing on push events. The system tells you access is revoked while the exfiltration channel remains open.
The critical failure is the false success signal. A user who executes DeleteCollaboration and sees 'success' has no indication that webhooks created by that collaborator are still active. The operation satisfies its own success criteria (permission removal) without honoring the security guarantee users expect (complete access revocation). This isn't incomplete cleanup — it's a contract that was never correctly specified.
Audit for orphaned webhooks by correlating webhook creation metadata against current collaboration membership. There is no automated detection — you must actively query which webhooks exist and who created them, then verify those users still have active collaboration roles. If you find webhooks from departed collaborators, delete them manually and treat that gap as a finding.
The severity exceeds what CVSS captures. An attacker doesn't need to re-exploit anything — they wait for the victim to 'remediate' by revoking access, and the webhook continues firing. The post-revocation persistence window is a compounding factor the score doesn't weigh.
This pattern recurs: OAuth tokens, deploy keys, SSH keys, and personal access tokens all create capabilities that outlive the access model granting them. Review your other Delete* operations for similar incomplete dependency cleanup. The architectural question isn't whether this specific gap gets patched, but whether your revocation semantics account for dependent resources at all.