CVE-2026-20805

Published Jan 13, 2026

Last updated 6 months ago

Exploit knownCVSS medium 5.5
Desktop Windows Manager
VDI
Zero-day
Business logic
Tunneling protocol
Database
Msrpc

Overview

Description
Exposure of sensitive information to an unauthorized actor in Desktop Windows Manager allows an authorized attacker to disclose information locally.
Source
secure@microsoft.com
NVD status
Analyzed
Products
windows_10_1607, windows_10_1809, windows_10_21h2, windows_10_22h2, windows_11_23h2, windows_11_24h2, windows_11_25h2, windows_server_2012, windows_server_2016, windows_server_2019, windows_server_2022, windows_server_2022_23h2, windows_server_2025

Risk scores

CVSS 3.1

Type
Secondary
Base score
5.5
Impact score
3.6
Exploitability score
1.8
Vector string
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Severity
MEDIUM

Known exploits

Data from CISA

Vulnerability name
Microsoft Windows Information Disclosure Vulnerability
Exploit added on
Jan 13, 2026
Exploit action due
Feb 3, 2026
Required action
Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.

Weaknesses

secure@microsoft.com
CWE-200

Social media

Hype score
Not currently trending

  1. CVE-2025-21333/21334 + CVE-2026-20805: Hyper-V zero-days → SYSTEM access. DWM leaks memory to fuel exploit chains. 157 CVEs, 8 zero-days, one Patch Tuesday. CISA deadline expired today. Your critical servers run Hyper-V. Assume compromised if unpatched. Sweet dreams.

    @CisoRaging77913

    4 Feb 2026

    57 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. Top 5 Trending CVEs: 1 - CVE-2026-21509 2 - CVE-2026-20805 3 - CVE-2024-3094 4 - CVE-2024-1234 5 - CVE-2010-5139 #cve #cvetrends #cveshield #cybersecurity https://t.co/4Fua3CAN6W

    @CVEShield

    3 Feb 2026

    10 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. Microsoft、Windowsの定例アップデートで3件のゼロデイ 脆弱性を修正(CVE-2026-20805/21265/CVE-2023-31096) https://t.co/pQkjWZas36 #セキュリティ対策Lab #セキュリティ #Security

    @securityLab_jp

    14 Jan 2026

    221 Impressions

    1 Retweet

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. 🚨 Microsoft January 2026 Patch Tuesday Fixes 115 Flaws, Including an Actively Exploited Zero-Day Microsoft’s January 2026 Patch Tuesday ships 115 fixes (8 Critical), including three zero-days: CVE-2026-20805 (DWM info leak) confirmed exploited in the wild, CVE-2023-31096 (Ag

    @ThreatSynop

    14 Jan 2026

    80 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  5. Microsoft patches critical Desktop Window Manager flaws, incl. zero-day CVE-2026-20805 and EoP CVE-2025-55681, letting local users read memory and gain SYSTEM on Windows 10-11. Apply Jan 13 updates. #Windows https://t.co/DsbDcq5TDM

    @threatcluster

    14 Jan 2026

    12 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. 🚨 Microsoft January 2026 Patch Tuesday Fixes 114 Flaws, Including 3 Zero-Days Microsoft’s January 2026 Patch Tuesday addresses 114 vulnerabilities, including three zero-days (CVE-2026-20805 DWM info-disclosure, CVE-2026-21265 Windows Digital Media EoP, and CVE-2023-31096) wi

    @ThreatSynop

    14 Jan 2026

    64 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

Configurations

Related CVEs

  1. socat versions 1.8.0.0 through 1.8.1.1 contain a heap-based buffer overflow vulnerability that allows a malicious SOCKS5 proxy server to overwrite adjacent heap memory by exploiting a sign-extension flaw in the DOMAINNAME reply parser. During connection setup, the domain name length byte is read through a signed char field causing a negative bytes_to_read value that is implicitly converted to size_t, resulting in an unbounded heap write into the 262-byte reply buffer with attacker-controlled size and content.•CVE-2026-56123
  2. In the Linux kernel, the following vulnerability has been resolved: Revert "wireguard: device: enable threaded NAPI" This reverts commit 933466fc50a8e4eb167acbd0d8ec96a078462e9c which is commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e upstream. We have had three independent production user reports in combination with Cilium utilizing WireGuard as encryption underneath that k8s Pod E/W traffic to certain peer nodes fully stalled. The situation appears as follows: - Occurs very rarely but at random times under heavy networking load. - Once the issue triggers the decryption side stops working completely for that WireGuard peer, other peers keep working fine. The stall happens also for newly initiated connections towards that particular WireGuard peer. - Only the decryption side is affected, never the encryption side. - Once it triggers, it never recovers and remains in this state, the CPU/mem on that node looks normal, no leak, busy loop or crash. - bpftrace on the affected system shows that wg_prev_queue_enqueue fails, thus the MAX_QUEUED_PACKETS (1024 skbs!) for the peer's rx_queue is reached. - Also, bpftrace shows that wg_packet_rx_poll for that peer is never called again after reaching this state for that peer. For other peers wg_packet_rx_poll does get called normally. - Commit db9ae3b ("wireguard: device: enable threaded NAPI") switched WireGuard to threaded NAPI by default. The default has not been changed for triggering the issue, neither did CPU hotplugging occur (i.e. 5bd8de2 ("wireguard: queueing: always return valid online CPU in wg_cpumask_choose_online()")). - The issue has been observed with stable kernels of v5.15 as well as v6.1. It was reported to us that v5.10 stable is working fine, and no report on v6.6 stable either (somewhat related discussion in [0] though). - In the WireGuard driver the only material difference between v5.10 stable and v5.15 stable is the switch to threaded NAPI by default. [0] https://lore.kernel.org/netdev/CA+wXwBTT74RErDGAnj98PqS=wvdh8eM1pi4q6tTdExtjnokKqA@mail.gmail.com/ Breakdown of the problem: 1) skbs arriving for decryption are enqueued to the peer->rx_queue in wg_packet_consume_data via wg_queue_enqueue_per_device_and_peer. 2) The latter only moves the skb into the MPSC peer queue if it does not surpass MAX_QUEUED_PACKETS (1024) which is kept track in an atomic counter via wg_prev_queue_enqueue. 3) In case enqueueing was successful, the skb is also queued up in the device queue, round-robin picks a next online CPU, and schedules the decryption worker. 4) The wg_packet_decrypt_worker, once scheduled, picks these up from the queue, decrypts the packets and once done calls into wg_queue_enqueue_per_peer_rx. 5) The latter updates the state to PACKET_STATE_CRYPTED on success and calls napi_schedule on the per peer->napi instance. 6) NAPI then polls via wg_packet_rx_poll. wg_prev_queue_peek checks on the peer->rx_queue. It will wg_prev_queue_dequeue if the queue->peeked skb was not cached yet, or just return the latter otherwise. (wg_prev_queue_drop_peeked later clears the cache.) 7) From an ordering perspective, the peer->rx_queue has skbs in order while the device queue with the per-CPU worker threads from a global ordering PoV can finish the decryption and signal the skb PACKET_STATE_CRYPTED out of order. 8) A situation can be observed that the first packet coming in will be stuck waiting for the decryption worker to be scheduled for a longer time when the system is under pressure. 9) While this is the case, the other CPUs in the meantime finish decryption and call into napi_schedule. 10) Now in wg_packet_rx_poll it picks up the first in-order skb from the peer->rx_queue and sees that its state is still PACKET_STATE_UNCRYPTED. The NAPI poll routine then exits e ---truncated---•CVE-2026-52945
  3. n8n is an open source workflow automation platform. Prior to 2.24.0, an authenticated user with workflow edit access could supply a malicious filter value in the MongoDB node's Find And Replace operation. The value was not validated before being passed to MongoDB as a query filter, allowing unintended documents to be matched and overwritten with attacker-controlled content. This vulnerability is fixed in 2.24.0.•CVE-2026-54313
  4. libssh2 through 1.11.1, fixed in commit 7acf3df contains an out-of-bounds write vulnerability in ssh2_transport_read() that fails to enforce upper bounds on packet_length field. Remote attackers can send crafted SSH packets with excessively large packet_length values to corrupt heap memory and achieve remote code execution.•CVE-2026-55200
  5. Impact: When using Socks5ProxyAgent, undici reuses a single connection pool across different origins without verifying that the pool's origin matches the requested origin. All requests are dispatched through the pool connected to the first origin, regardless of the intended destination. This causes cross-origin request routing: credentials and request data intended for origin B are sent to origin A, responses from the wrong origin are trusted, and HTTPS requests may be silently downgraded to HTTP. Impacted users are applications that use Socks5ProxyAgent (directly or via setGlobalDispatcher) and make requests to more than one origin. This was introduced in undici 7.23.0 via PR #4385 and affects all versions through 8.1.0. Patches: Upgrade to undici v7.26.0 or v8.2.0. Workarounds: Use a separate Socks5ProxyAgent instance per origin, or avoid using Socks5ProxyAgent with multiple origins.•CVE-2026-6734

References

Sources include official advisories and independent security research.