CVE-2026-49217

The CVSS 7.5 rating masks a more serious architectural failure: the missing authorization check doesn't just expose data—it enables an unauthenticated attacker to retroactively weaken the security posture of existing tokens by removing IP restrictions. This is fundamentally different from direct data access. An IP-restricted API token becomes freely exploitable after a single unauthenticated request, and the attacker doesn't need to know the token's secret, only its existence. The downstream risk depends entirely on what those tokens authorize. If an administrator configured IP restrictions specifically because the token accesses sensitive functions—user management, DNS changes, relay configuration—removing those restrictions enables lateral movement the administrator explicitly tried to prevent. The CVSS captures the technical gap but not the trust violation: administrators who believed they had hardened their deployment via IP restrictions were operating under false assumptions. This vulnerability also creates a compounding blast radius. A single attacker with knowledge of token IDs can simultaneously invalidate every IP restriction across potentially dozens of tokens. The presence of IP restrictions likely deterred probing of the token space itself; now every token is a live target, and the attacker has to do the reconnaissance work they previously avoided. The non-default status of the REST API actually amplifies the severity rather than reducing it. Organizations that enabled it made a deliberate tradeoff, likely for automation needs. Those deployments are precisely the ones with complex, high-value token configurations—not casual users who left defaults intact. Advising them to simply disable the API ignores that real workflows depend on this feature. The comment field modification capability compounds the risk: an attacker changing token comments to misleading values can set up social engineering or audit manipulation for long-term persistence. Audit all tokens with IP restrictions immediately. Treat any token that previously had IP restrictions as potentially compromised and rotate it. Verify the patch adds proper authorization checks to all endpoints that modify token security controls, not just the IP restriction endpoint. Review token comments for unexpected modifications indicating pre-positioning for follow-on attacks. The vulnerability is scored as a technical authorization gap, but the actual risk is a trust violation against administrators who explicitly hardened their deployment.

Reviewed through automated stages and approved by a human before publication.