The destructiveHint annotation did not match actual replacement semantics. Entry and authority. An agent has issue-label write permissions and an approval client uses the advertised tool hints. Observed mechanism and consequence. Replacing the complete label set removed existing labels although the metadata said destructiveHint=false. Limits and status. T…
Inspect the ClaimsCase · DiggingBeagle record
GitHub MCP advertised label replacement as nondestructive
The destructiveHint annotation did not match actual replacement semantics.
Public disclosure: Nov 9, 2026
Scope
An agent has issue-label write permissions and an approval client uses the advertised tool hints. Replacing the complete label set removed existing labels although the metadata said destructiveHint=false.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade C
- Remediation
- mitigation available
- AI role
- AGAINST AI
Basis and provenance
Scoped Claim(s) link to SRC-2026-DB233-GITHUB-MCP-LABELS-DESTRUCTIVE; reviewed as vulnerability in research_demonstration. Only reported controlled behavior or proof-of-concept is established; no production victim or impact magnitude is measured.
Assessed Nov 10, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-DB233-GITHUB-MCP-LABELS-DESTRUCTIVE-01 · github-mcp-server issue #3760
At a glance
The underlying GitHub token still governs the write; no demonstrated approval-client exploit.
Limits and uncertaintyFull account
The destructiveHint annotation did not match actual replacement semantics.
Entry and authority. An agent has issue-label write permissions and an approval client uses the advertised tool hints.
Observed mechanism and consequence. Replacing the complete label set removed existing labels although the metadata said destructiveHint=false.
Limits and status. The underlying GitHub token still governs the write; no demonstrated approval-client exploit.
GitHub MCP's tool metadata labeled label updates as nondestructive, although the implementation replaced the complete label set. A client relying on destructiveHint=false might approve the call without realizing that previously applied labels could disappear. The replacement still occurs under an authorized GitHub token; it is a mismatch between advertised effect semantics and the actual mutation, not an escalation of repository privilege.
Mechanism and trust boundary
- 01
Precondition and trust context
An agent has issue-label write permissions and an approval client uses the advertised tool hints.
- 02
Crossed boundary
Replacing the complete label set removed existing labels although the metadata said destructiveHint=false.
- 03
Observed limit
The underlying GitHub token still governs the write; no demonstrated approval-client exploit.
Timeline
- Nov 9, 2026Event type unspecified
Initial documented finding
GitHub MCP advertised label replacement as nondestructive
- Nov 9, 2026disclosure
Public disclosure
Claims & evidence
CLM-DB233-GITHUB-MCP-LABELS-DESTRUCTIVE-01A repository issue reports: Replacing the complete label set removed existing labels although the metadata said destructiveHint=false.supported
Basis: reported finding
- supportsgithub-mcp-server issue #3760primary disclosure
Issue #3760, description and reproduction
Controls and mitigations
- Mark full-set replacements as potentially destructive and expose explicit add, remove and replace operations with precise semantics.
- Display existing and proposed label sets before committing a change; audit the resulting issue state rather than trusting tool annotations.
Unknowns and contradictions
- The underlying GitHub token still governs the write; no demonstrated approval-client exploit.
Sources and citation
Material revision history
- Nov 10, 2026 · Published version · first publication · revision 235