NOTE: this issue has been disputed by third parties. Microsoft Windows XP, 2000, and 2003 allows local users to kill a writable process by using the CreateRemoteThread function with certain arguments on a process that has been opened using the OpenProcess function, possibly involving an invalid address for the start routine. NOTE: followup posts have disputed this issue, saying that if a user already has privileges to write to a process, then other functions could be called or the process could be terminated using PROCESS_TERMINATE

The Microsoft Windows kernel in Microsoft Windows 2000 Server, Windows XP, and Windows Server 2003 allows remote attackers to cause a denial of service (crash) via crafted Remote Desktop Protocol (RDP) requests.

Buffer overflow in a certain USB driver, as used on Microsoft Windows, allows attackers to execute arbitrary code.

Integer overflow in Microsoft Windows 98, 2000, XP SP2 and earlier, and Server 2003 SP1 and earlier allows remote attackers to execute arbitrary code via a crafted compiled Help (.CHM) file with a large size field that triggers a heap-based buffer overflow, as demonstrated using a "ms-its:" URL in Internet Explorer.

Buffer overflow in Microsoft Step-by-Step Interactive Training (orun32.exe) allows remote attackers to execute arbitrary code via a bookmark link file (.cbo, cbl, or .cbm extension) with a long User field.

Microsoft Agent allows remote attackers to spoof trusted Internet content and execute arbitrary code by disguising security prompts on a malicious Web page.

The IPv6 support in Windows XP SP2, 2003 Server SP1, and Longhorn, with Windows Firewall turned off, allows remote attackers to cause a denial of service (CPU consumption) via a TCP packet with the SYN flag set and the same destination and source address and port, a variant of CVE-2005-0688 and a reoccurrence of the "Land" vulnerability (CVE-1999-0016).

The TCP/IP stack in multiple operating systems allows remote attackers to cause a denial of service (CPU consumption) via a TCP packet with the correct sequence number but the wrong Acknowledgement number, which generates a large number of "keep alive" packets. NOTE: some followups indicate that this issue could not be replicated.