An authenticated command injection vulnerability exists in Security Center related to file upload processing. An attacker could exploit this issue by uploading a specially crafted file, potentially resulting in arbitrary command execution on the underlying operating system.

Microsoft UFO open-source framework for intelligent automation across devices and platforms. Prior to 3.0.8, createmobiledatacollectionserver and createmobileactionserver in ufo/client/mcp/httpservers/mobilemcpserver.py exposed Streamable HTTP MCP services on TCP ports 8020 and 8021 without authentication, allowing an unauthenticated remote attacker to invoke capturescreenshot, getuitree, tap, swipe, typetext, launchapp, presskey, and clickcontrol against an ADB-connected Android device, disclose screen and device data, and modify device state. This issue is fixed in version 3.0.8.

Deserialization of untrusted data in Microsoft High Performance Computing (HPC) Pack allows an unauthorized attacker to execute code over a network.

Heap-based buffer overflow in Windows iSCSI Target Service allows an unauthorized attacker to execute code over a network.

Use after free in Windows Deployment Services allows an unauthorized attacker to execute code over a network.

Improper neutralization of input during web page generation ('cross-site scripting') in Microsoft Office SharePoint allows an unauthorized attacker to perform spoofing over a network.

Azure Storage Explorer Elevation of Privilege Vulnerability

Stack-based buffer overflow in Windows DNS allows an unauthorized attacker to execute code over a network.

Microsoft QUIC Remote Code Execution Vulnerability

Improper limitation of a pathname to a restricted directory ('path traversal') in Microsoft Teams for Android allows an unauthorized attacker to execute code over a network.

Azure SRE Agent Elevation of Privilege Vulnerability

Copilot Cowork Elevation of Privilege Vulnerability

Microsoft Teams Elevation of Privilege Vulnerability

Improper authentication in Microsoft Teams allows an authorized attacker to elevate privileges over a network.

Azure Active Directory Elevation of Privilege Vulnerability

Azure SQL Database Elevation of Privilege Vulnerability

Microsoft Planetary Computer Pro Elevation of Privilege Vulnerability

Azure SQL Managed Instance Elevation of Privilege Vulnerability

Azure Confidential Ledger Remote Code Execution Vulnerability

'.../...//' in Microsoft Entra Provisioning Service (SyncFabric) allows an authorized attacker to elevate privileges over a network.

Azure Logic Apps Information Disclosure Vulnerability

Improper verification of cryptographic signature in Microsoft 365 Admin Center allows an unauthorized attacker to elevate privileges over a network.

Azure Service Bus Remote Code Execution Vulnerability

Improper neutralization of input during web page generation ('cross-site scripting') in Microsoft Office SharePoint allows an unauthorized attacker to perform spoofing over a network.

Microsoft Azure Kubernetes Service Elevation of Privilege Vulnerability

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: fmidi: cancel pending IN work before freeing the midi object

The fmidi driver embeds a work item (midi->work) whose handler, fmidiinwork(), dereferences the enclosing struct fmidi through containerof(). This work is armed from two sites: fmidicomplete(), on a normal IN-endpoint completion, and fmidiintrigger(), on an ALSA rawmidi output-stream start.

Neither fmididisable() nor fmidiunbind() cancels midi->work. fmididisable() only disables the endpoints and drains the inreqfifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object.

The midi object is reference-counted (midi->freeref) and is freed in fmidifree() only once both the usbfunction reference and the rawmidi privatedata reference have been dropped. In fmidiunbind(), fmididisable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach fmidiintrigger() and queue midi->work again after fmididisable() has returned. A work item armed this way may still be pending when the last reference drops and fmidifree() proceeds to kfree(midi), letting fmidiinwork() dereference the struct after it has been freed, a use-after-free.

For this reason cancelling midi->work in fmididisable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released.

Fix this by calling cancelworksync(&midi->work) in the refcount-zero block of fmidifree(), before the embedded workstruct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancelworksync() under it is permitted, and the handler takes midi->transmitlock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish.

This issue was found by an in-house static analysis tool.

In the Linux kernel, the following vulnerability has been resolved:

Input: ims-pcu - fix heap-buffer-overflow in imspcuprocessdata()

The imspcuprocessdata() processes incoming URB data byte by byte. However, it fails to check if the readpos index exceeds IMSPCUBUFSIZE.

If a malicious USB device sends a packet larger than IMSPCUBUFSIZE, readpos will increment indefinitely. Moreover, since readpos is located immediately after readbuf, the attacker can overwrite readpos itself to arbitrarily control the index.

This manipulated readpos is subsequently used in imspcuhandleresponse() to copy data into cmdbuf, leading to a heap buffer overflow.

Specifically, an attacker can overwrite the cmddone.wait.head located at offset 136 relative to cmdbuf in the imspcuhandleresponse(). Consequently, when the driver calls complete(&pcu->cmddone), it triggers a control flow hijack by using the manipulated pointer.

Fix this by adding a bounds check for readpos before writing to readbuf. If the packet is too long, discard it, log a warning, and reset the parser state.

[dtor: factor out resetting packet state, reset checksum as well]

In the Linux kernel, the following vulnerability has been resolved:

sctp: don't free the ASCONF's own transport in DEL-IP processing

sctpprocessasconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctprcv()). For an ASCONF located through its Address Parameter by sctprcvasconflookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address.

sctpprocessasconfparam() rejects a DEL-IP for the packet source address (ADDIP D8, SCTPERRORDELSRCIP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order:

[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]

where L differs from the source. The DEL-IP for L passes the D8 check and calls sctpassocrmpeer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctpassocsetprimary() and sctpassocdelnonprimarypeers(): setprimary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primarypath / activepath, and delnonprimarypeers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transportcount of 0 and primarypath/activepath pointing at freed memory.

Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.

In the Linux kernel, the following vulnerability has been resolved:

KVM: nVMX: Hide shadow VMCS right after VMCLEAR

freenested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loadedvmcsclear(), the vCPU might migrate before the pointer is cleared and loadedvmcsclear() may then execute VMCLEAR.

The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.

Adobe Campaign Classic (ACC) is affected by an Improper Neutralization of Special Elements Used in a Template Engine vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could exploit this vulnerability to execute arbitrary code. Exploitation of this issue does not require user interaction. Scope is changed.