Advisory · CVE-2026-94510
Microsoft Bookings authorization bypass lets attackers elevate privileges with a crafted key
An authorization bypass via a user-controlled key in Microsoft Bookings let unauthenticated attackers elevate privileges over the network, rated critical at CVSS 9.9.
- Vendor
- Microsoft
- Product
- Microsoft Bookings
- Identifier / CWE
- CVE-2026-94510
CWE-639 - Action timing
- Immediate
Explain it like I’m five
Bookings let callers pick their own ticket numbers, and a higher ticket number meant more access. An attacker just printed the highest ticket.
- 01Attacker sends request
An unauthenticated attacker sends a network request to Microsoft Bookings with a crafted key value.
- 02Key trusted
The service uses the attacker-controlled key in its authorization decision instead of validating it.
- 03Privileges elevated
The attacker gains elevated privileges with high integrity impact across the service scope.
What happened
Microsoft disclosed CVE-2026-94510 in Microsoft Bookings on October 8, 2026. The service trusted a user-controlled key when making authorization decisions, allowing an unauthenticated attacker to elevate privileges over the network. It scores 9.9 on CVSS 3.1 (network, low complexity, no privileges or user interaction required, changed scope, high integrity impact). NVD marks the entry as exclusively a hosted-service issue, so the fix lands on Microsoft’s side.
What to do
- No customer patch exists to apply; Microsoft remediates the service.
- Review Bookings administrator and service roles in your tenant; confirm no unexpected privilege grants appeared around October 8, 2026.
- Check audit logs for anomalous bookings administration or policy changes.
- If elevated Bookings access touched customer data, assess what that access could have reached.
- Watch for a Microsoft post-incident notice with exposure details.
Management note
A 9.9 in a consumer-facing scheduling app sounds odd until you remember authorization bugs don’t respect product boundaries: the key pattern is the lesson. Verify your tenant’s roles are still what you configured, and use this as the example when teams ask why trust boundaries get audited separately from features.