Veille CVE

Recherche « Microsoft Windows Security App »

5 CVE

Critique 0 Élevée 3 Moyenne 2 Faible 0 Non évaluée 0 Exploitées (KEV) Tri : plus récentes « Microsoft Windows Security App » ✕
  1. CVE-2026-69979 5.5 Moyenne

    Microsoft Windows 10 Version 21H2 · Microsoft Windows 10 Version 22H2 · Microsoft Windows 11 Version 23H2 · Microsoft Windows 11 Version 24H2

    Improper protection of alternate path in Windows AppX Deployment Service allows an authorized attacker to bypass a security feature locally.

  2. CVE-2026-105725 7.0 Élevée

    Microsoft Windows Security App

    Use after free in Windows Security App allows an authorized attacker to elevate privileges locally.

  3. CVE-2026-105007 8.8 Élevée

    Microsoft Windows 10 Version 1607 · Microsoft Windows 10 Version 1809 · Microsoft Windows 10 Version 21H2 · Microsoft Windows 10 Version 22H2

    An elevation of privilege vulnerability exists in the Network Driver Interface Specification (NDIS) when ndis.sys fails to check the length of a buffer prior to copying memory to it. To exploit the vulnerability, in a local attack scenario, an attacker could run a specially crafted application to elevate the attacker's privilege level. An attacker who successfully exploited this vulnerability could run processes in an elevated context. However, an attacker must first gain access to the local system with the ability to execute a malicious application in order to exploit this vulnerability. The security update addresses the vulnerability by changing how ndis.sys validates buffer length.

  4. CVE-2026-78457 7.0 Élevée

    Microsoft Windows 11 Version 24H2 · Microsoft Windows 11 Version 25H2 · Microsoft Windows 11 version 26H1 · Microsoft Windows Server 2022

    Use after free in Windows Security App allows an authorized attacker to elevate privileges locally.

  5. CVE-2026-46139 5.5 Moyenne

    Linux · Linux linux kernel

    In the Linux kernel, the following vulnerability has been resolved: smb: client: use kzalloc to zero-initialize security descriptor buffer Commit 62e7dd0a39c2d ("smb: common: change the data type of num_aces to le16") split struct smb_acl's __le32 num_aces field into __le16 num_aces and __le16 reserved. The reserved field corresponds to Sbz2 in the MS-DTYP ACL wire format, which must be zero [1]. When building an ACL descriptor in build_sec_desc(), we are using a kmalloc()'ed descriptor buffer and writing the fields explicitly using le16() writes now. This never writes to the 2 byte reserved field, leaving it as uninitialized heap data. When the reserved field happens to contain non-zero slab garbage, Samba rejects the security descriptor with "ndr_pull_security_descriptor failed: Range Error", causing chmod to fail with EINVAL. Change kmalloc() to kzalloc() to ensure the entire buffer is zero-initialized. [1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/20233ed8-a6c6-4097-aafa-dd545ed24428