Unauthenticated pairing-API denial of service

1. Summary

The pairing API request handler in the Windows Device Portal framework built into Microsoft HoloLens 1 and HoloLens 2 processes pairing requests with no rate limiting or request cap [1][3]. An attacker on the same or an adjacent network, requiring neither authentication nor user interaction, can flood the pairing endpoint with repeated requests [1][3]. The handler responds to each request by spawning a new pairing-PIN overlay while driving CPU utilization up, so the flood renders the head-worn AR device unusable — the overlays block the wearer’s view, the device overheats, and gesture/voice recognition degrades — for as long as the request stream continues [3]. A public PowerShell proof-of-concept exists and can be scheduled to resume automatically when the device rejoins the network [3][4]; sources [3] and [4] conflict on whether the disruption ends when the flood stops or the device itself remains unresponsive after reboot, so the recovery behavior remains unresolved [3][4].

2. Affected products & versions

3. The vulnerability in detail

The defect lives in the pairing API request handler of the Windows Device Portal framework — the built-in, web-based administration interface that ships on every HoloLens 1 and HoloLens 2 device [1][7]. The Device Portal is the same subsystem an operator uses to configure, inspect, and pair a headset over the network; on HoloLens it also drives the pairing-PIN overlay that the wearer sees inside the AR view when a new device requests to pair [3][7]. The vulnerable surface is the /api/pairing endpoint, exposed on ports 10080 (HTTP) and 10443 (HTTPS) [7]. That exact path and those port numbers are named only by the CVE.news press source and are not confirmed by the primary advisories, so they should be treated as strong context rather than authoritative [7].

The root cause is an absence, not a logic error: the handler allocates and processes each incoming pairing request without any per-IP rate limiting and without any cap on the total number of requests within a short timeframe [1][3]. This is precisely the pattern captured by CWE-770, “Allocation of Resources Without Limits or Throttling” [1][2][5]. CWE-770 describes software that lets a client cause the server to allocate a resource — here CPU cycles and the rendering of a fresh pairing-PIN overlay per request — without bounding how much of that resource a single actor can consume [1][5]. Because nothing throttles the caller, a stream of otherwise well-formed requests becomes a resource-exhaustion weapon: the device keeps dutifully honoring each request until it is saturated [3]. The researchers explicitly recommend adding per-IP rate limiting and per-timeframe request caps as the fix, which confirms the missing control is the actual defect [3].

It is worth being precise about why a single unthrottled endpoint is enough to disable the whole device. Each pairing request is not a cheap no-op: the handler responds by initiating a pairing exchange, which on HoloLens means rendering a new pairing-PIN overlay into the wearer’s AR field of view and holding the associated request-processing work [3]. The exact per-request internal cost (memory, threads, timers) is not documented beyond the CWE-770 characterization, so the precise allocation profile is inferred from the observed symptoms rather than confirmed [3]. What the sources do establish empirically is the aggregate effect: sustained requests drive CPU utilization to very high levels (enough to overheat the device), stack continuous PIN overlays that occlude the display, and degrade the gesture- and voice-recognition pipelines the headset depends on for input [3]. Because a single request already forces UI rendering plus request handling, and nothing caps the request rate, the amplification from “one request” to “device saturated” is trivial for the attacker to achieve [3].

The preconditions are modest [1][3]. The target HoloLens must (a) have network/internet access, (b) have the Device Portal enabled, and (c) be reachable by the attacker on the same or an adjacent network — this last point is what the CVSS vector encodes as AV:A (adjacent) [1][3]. Critically, no authentication and no user interaction are required (PR:N/UI:N) [1][3].

The discovery-and-trigger mechanism is what makes this practical rather than theoretical [3][4]. An attacker who reaches the Device Portal login and enters three incorrect login attempts is redirected to a page that offers to request a new pairing [4]. Inspecting that redirect page’s network traffic in ordinary browser developer tools reveals the underlying pairing API request in full — its body and its headers [3][4]. Because that request needs no authentication, it can be copied and replayed verbatim from any tool [3]. The attacker has now recovered everything needed to reproduce the request at will, without ever holding valid credentials [3][4]. This is the crux of the finding: a control that looks like a login-protected admin surface exposes a fully replayable, credential-free request path as a side effect of its own lockout/redirect behavior.

The exploitation chain then proceeds as follows [3][4][7]:

1. The attacker joins the same or an adjacent network as a target HoloLens that has the Device Portal enabled and network access [3].
2. The attacker scans the network to locate the HoloLens IP and its Device Portal (ports 10080/10443 per the press source) [7].
3. The attacker reaches the Device Portal login and enters three incorrect attempts, triggering the redirect to the “request a new pairing” page [4].
4. Using browser dev tools, the attacker inspects that page and captures the pairing API request (body + headers) [3][4].
5. The attacker replays/replicates that request in a separate tool, confirming it requires no authentication [3].
6. The attacker runs a PowerShell PoC that sends pairing requests in a continuous loop, ignoring errors [3].
7. The unthrottled handler allocates a fresh pairing-PIN overlay per request and drives CPU utilization to overheating levels while the gesture- and voice-recognition pipelines degrade [3].
8. Optionally, the attacker registers the script with New-ScheduledTask to run at startup in the background, so the request stream resumes automatically whenever the HoloLens reconnects to the network [3][4]. Note this is attacker-driven re-attack on reconnection; a separate source instead reports the device itself remaining unresponsive after restart attempts, and the two claims are not the same [3][4].

Proof-of-concept status: a public PoC exists. The researchers published a PowerShell script in the NVD-referenced repository (github.com/tania-silva/Hololens) and a companion repo (github.com/tania-silva/CVE-2024-57972); it floods the pairing API, ignores errors, and can be scheduled to run at startup [3][4].

4. Discovery & timeline

The vulnerability was discovered and disclosed by Tânia Silva, António Pinto, Pedro Pinto, and Sara Paiva, who published the researcher writeup and PoC at github.com/tania-silva/Hololens and github.com/tania-silva/CVE-2024-57972 [3][4]. MITRE is the assigning CNA of record [1][2]. The CVE was reserved 2025-02-20, published 2025-03-06, and last updated 2025-03-07 [1][2].

A coordinated-disclosure timeline with Microsoft and any specific vendor patch date are not documented in the available sources [6]. The press coverage points readers generically to the Microsoft Security Update Guide but names no fixed build [7].

5. Technical reference

• CVE: CVE-2024-57972 [1][2]
• CWE: CWE-770 — Allocation of Resources Without Limits or Throttling [1][2][5]
• CVSS v3.1 (MITRE CNA): 6.5 MEDIUM — AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H [1][2]. Key metrics in context: AV:A the attacker must be on the same/adjacent network (not internet-wide); AC:L the attack is low-complexity and reliably reproducible; PR:N/UI:N no credentials and no wearer action required; S:U the impact stays within the same security scope; C:N/I:N no data is read or altered; A:H availability impact is high — the device is rendered unusable.
• CVSS v2 (per Tenable): 6.1 — AV:A/AC:L/Au:N/C:N/I:N/A:C [6]
• Exploitation probability (low, from two different metrics/sources): the two figures below are not the same measurement and should not be read as a range — they are distinct estimators that happen to agree on “low.”
• EPSS ~0.0129 (~1.29%) per Tenable [6] — the FIRST EPSS model’s probability of observed exploitation activity in the next 30 days.
• ~2.413% at roughly the 82nd percentile per the GitHub Advisory [5] — a separately curated 30-day exploit-probability estimate. Both characterize exploitation likelihood as low; the small numeric difference reflects different models/sources, not disagreement about severity.
• GitHub Advisory: GHSA-xfr2-g2r2-vf88 — rates it Moderate/6.5, adjacent-network, no-auth/no-UI, CWE-770 [5]
• Code / PoC refs: github.com/tania-silva/Hololens (NVD-referenced) and github.com/tania-silva/CVE-2024-57972 [3][4]. No vendor commit/patch reference is documented.

6. Consequence & CFSE path analysis

Real-world consequence: an unauthenticated attacker within network reach can, at will, render a HoloLens headset unusable mid-use — the wearer’s AR view is buried under continuous pairing-PIN overlays, the device overheats, and gesture/voice input degrades — and the effect lasts at least as long as the flood continues, or (per the PoC’s scheduled-task variant) resumes automatically on reconnection [3][4]. Whether it further persists through a full device reboot is contradicted across sources and is left open here [3][4]. HoloLens is deployed in healthcare, manufacturing, and lab settings where the headset delivers real-time guidance [7], so an unusable overlay is not a cosmetic glitch — it interrupts the exact task the wearer is depending on the device for, amounting to a targeted denial of the operator’s working tool [7]. The impact is explicitly bounded to availability: there is no data theft, no code execution, and no lateral movement, and the CVSS confidentiality and integrity metrics are both N [1]. It is pure availability denial.

Why the CFSE Path Score diverges from CVSS. The published CVSS v3.1 baseline is 6.5 MEDIUM. The CFSE decomposition models this record as a single risk path — DEVICE_AVAILABILITY — and scores it in the CRITICAL band, designating it the dominant path (it reaches the record’s highest band). The direction is UNDER, meaning the published CVSS baseline of 6.5 MEDIUM sits below the CFSE assessment — i.e., CFSE judges the record as more severe than CVSS scored it, not less. The divergence comes from CFSE weighting the reachability and ease of the availability denial against a critical-use device more heavily than CVSS’s generic base metrics do. The path models an unauthenticated, network-reachable HTTP flood of the Device Portal pairing API — RE:4, EC:4, EX:4 — that exhausts device resources and disables the head-worn AR overlay mid-use for as long as the flood continues (and, per the scheduled-task PoC, resuming on reconnection); whether the device recovers on reboot remains unresolved because the sources conflict.

The impact is explicitly bounded, and the CFSE bands reflect that ceiling rather than inflating it:

• PH:2 — an availability / situational-awareness nuisance to the AR overlay, with no actuation and no persistent physical injury.
• DP:0 — no confidentiality or integrity impact.
• AT:0 — pure resource exhaustion; no authority or session is gained.
• CH:1 — availability loss is not a reusable cross-domain authority bridge.

Scale and recovery are moderate:

• SR:2 — the technique is reusable across the device class, but no shared secret is captured.
• SX:3 — a scriptable sweep can hit many reachable headsets, but the effect is transient per device, not fleet-scale.
• OR:1 — recovery is routine and local (stop the flood; where reboot suffices, reboot); no fleet reprovisioning or key rotation is required. Note the reboot-recovery premise is itself a source conflict, so this band assumes the recoverable reading.

The overall path_verdict is CRITICAL with no cap and no systemic uplift applied. The verdict summary: the entry decomposes the vulnerability into a single risk path, DEVICE_AVAILABILITY, scored in the CRITICAL band and designated dominant. It models an unauthenticated, network-reachable HTTP flood of the HoloLens Device Portal pairing API (RE:4, EC:4, EX:4) that exhausts device resources and renders the head-worn AR overlay unusable mid-use for as long as the flood continues, and — per the scheduled-task PoC — resuming automatically on network reconnection; whether the device itself recovers on reboot remains unresolved because the sources conflict. Impact is bounded: PH:2, DP:0, AT:0, CH:1. Scale/recovery are moderate: SR:2, SX:3, OR:1. Overall CRITICAL, no cap or systemic uplift; direction UNDER, meaning the published CVSS v3.1 baseline of 6.5 MEDIUM sits below the CFSE assessment.

7. Remediation & mitigations

Researcher-recommended code fix (addresses the root cause directly): add per-IP rate limiting on pairing requests and cap the total number of requests within a short timeframe [3]. The researchers explicitly note that a single-IP-only control is insufficient because IP spoofing could bypass it, so throttling should combine per-IP limits with an aggregate per-timeframe cap [3]. Concretely for this bug, the throttle must sit in front of the pairing-PIN overlay rendering path so that repeated pairing requests cannot each force fresh overlay work — the rate limit, not just request rejection, is what prevents the CPU/overheating and display-occlusion symptoms [3].

Operational mitigations grounded in this bug’s preconditions:

• Network isolation of the Device Portal: use firewalls/VLANs so unauthorized users cannot reach the Device Portal (ports 10080/10443 per the press source), which removes the adjacent-network (AV:A) reachability the attack depends on [7].
• Apply Microsoft security updates via the Microsoft Security Update Guide [7]. Note: no specific fixed HoloLens build is documented in any available source, so operators cannot currently confirm a patched version by number [1][6].
• Disable the Device Portal when not needed. This directly removes precondition (b) — Device Portal enabled — and therefore the attack surface entirely. It is a logical hardening step implied by the “Device Portal enabled” precondition but is not explicitly stated by the sources — flagged as inference.

No generic SOC boilerplate applies; the effective controls are specifically the missing throttling control on the pairing/overlay path and removing network reachability to the pairing endpoint.

8. Sources

[1] NVD - CVE-2024-57972 — NVD (NIST) — https://nvd.nist.gov/vuln/detail/CVE-2024-57972 — Canonical CVE record: DoS in the pairing API handler via the Device Portal framework, affected versions, CVSS v3.1 6.5 vector, CWE-770, sole reference to the researcher repo. Credibility: primary-advisory.

[2] CVE-2024-57972 — CVE.org / MITRE CVE Services record (cveawg API JSON) — MITRE (CVE Program CNA) — https://cveawg.mitre.org/api/cve/CVE-2024-57972 — Authoritative CNA-of-record JSON confirming MITRE as assigning CNA, version ranges, CWE-770, CVSS vector, and PoC reference, independent of NVD’s presentation. Credibility: primary-advisory.

[3] GitHub - tania-silva/Hololens (original researcher writeup / PoC) — Tânia Silva et al. — https://github.com/tania-silva/Hololens — The exact repo cited by NVD; documents preconditions, attack method, PowerShell flood PoC, observed effects (PIN overlays, CPU overheating, input degradation), and the per-IP rate-limiting recommendation. Credibility: researcher-primary.

[4] GitHub - tania-silva/CVE-2024-57972 (researcher CVE writeup) — Tânia Silva et al. — https://github.com/tania-silva/CVE-2024-57972 — Companion repo adding the discovery vector (three failed logins → redirect to “request a new pairing” page → inspect/replay requests) and confirming persistence across restarts. Credibility: researcher-primary.

[5] GitHub Advisory Database - GHSA-xfr2-g2r2-vf88 — GitHub Security Advisory Database — https://github.com/advisories/ghsa-xfr2-g2r2-vf88 — Curated advisory mirroring the CVE: version range, Moderate/6.5, CWE-770, adjacent-network no-auth/no-UI characterization, and a curated exploit-probability estimate. Credibility: primary-advisory.

[6] Tenable - CVE-2024-57972 — Tenable — https://www.tenable.com/cve/CVE-2024-57972 — Vulnerability-intelligence view adding CVSS v2 (6.1) and v3.1 (6.5) scores and an EPSS score (~0.0129), plus confirmation that no in-the-wild data or specific patch version is documented. Credibility: reputable-press.

[7] CVE-2024-57972 - How a Simple API Flood Can Bring Down Microsoft HoloLens Devices — CVE.news — https://www.cve.news/cve-2024-57972/ — Technical press analysis naming the /api/pairing endpoint and ports 10080/10443, real-world impact context (healthcare/manufacturing/lab), and firewall/VLAN + patching remediation. Credibility: reputable-press.