Improper link resolution before file access ('link following') in VM Inspector for Azure Virtual Machines allows an unauthorized attacker to elevate privileges over a network.

AAD App Proxy Elevation of Privilege Vulnerability

Azure Pipelines Remote Code Execution Vulnerability

Azure Kubernetes Configuration Service Elevation of Privilege Vulnerability

Azure AI Foundry Elevation of Privilege Vulnerability

Microsoft Exchange Online Remote Code Execution Vulnerability

D365 F&O MCP Server is a Model Context Protocol server for querying Dynamics 365 Finance & Operations X++ code and metadata. Prior to version 1.11.0, the officially documented Azure one-click deployment uses infrastructure/azuredeploy.json and infrastructure/main.bicep to default the apiKey parameter to an empty string and pass it to the App Service APIKEY setting. With APIKEY unset or empty, src/middleware/apiKeyAuth.ts passes requests through without authentication, while src/index.ts binds the HTTP listener to 0.0.0.0 by default. If the deployer leaves the optional key blank and does not add separate network restrictions or upstream authentication, the resulting public App Service allows unauthenticated JSON-RPC tools/call requests to /mcp. The deployment's MCPSERVERMODE=read-only setting does not prevent anonymous access to read/search tools, including search, getobjectinfo, batchgetinfo, extensioninfo, securityinfo, findreferences, and findeventhandlers, exposing indexed proprietary X++ source snippets and metadata. Exposed information can include business logic, extension and event-handler wiring, security-role and privilege structure, and labels originally indexed from PackagesLocalDirectory. Deployments protected by a configured API key, effective upstream authentication, or network restrictions preventing attacker access are outside this unauthenticated exposure scenario. This issue is fixed in version 1.11.0.

A ThreadX module chooses objectsize when it calls txmmoduleobjectallocate. The Module Manager adds its own 16-byte private header to that size and asked the object pool for the result without checking the addition. A size near the top of a ULONG wrapped, the pool served a block far smaller than the header, and the manager then wrote the header past the end of it and into the neighbouring byte-pool block.

The Module Manager's block-pool create dispatcher proved that two ALIGNTYPE words of the extra-parameter array a memory-protected module supplies lay inside the module's data, and then used indices 0 through 3 of that array.

One of the two unproved words is read by the dispatcher's own buffer check, which takes index 1 as the pool start and index 2 as the length to range-check it over. So the out-of-bounds read is performed by the validation code itself, before the kernel service is reached, and the size the caller's pool start is then validated against is a word the manager has not proved the module owns. The other unproved word is read when the service's argument list is built.

Vulnerable function: txmmodulemanagertxblockpoolcreatedispatch, in commonmodules/modulemanager/inc/txmmodulemanagerdispatch.h.

One logical thread of a user-mode ThreadX module costs the Module Manager's shared object pool two allocations, not one. The module asks for a TXTHREAD control block through txmmoduleobjectallocate; txmmodulemanagerthreadcreate then takes a second allocation of TXMMODULEKERNELSTACKSIZE bytes for the privileged kernel stack that thread's system calls run on, and records it in the control block. Both come from txmmodulemanagerobjectpool and both are linked onto the module's allocation list.

The Module Manager's thread-delete dispatcher released only the first. The kernel stack stayed allocated until the whole module was stopped, so a module that creates, terminates and deletes threads in a loop — every state transition valid, every service returning TXSUCCESS — removed a fixed block from a finite pool shared by the manager and by every other loaded module, on every cycle, for as long as it stayed loaded. Once the pool is exhausted, no memory-protected module can create any kernel object and no user-mode module thread can be created anywhere in the system.

Vulnerable function: txmmodulemanagertxthreaddeletedispatch, in commonmodules/modulemanager/inc/txmmodulemanagerdispatch.h.

A ThreadX module reaches a kernel object's delete service through the Module Manager's dispatch layer, which asked one question about the pointer: does the object lie outside the module's own code and data. That is the policy for using an object, and using an object a module does not own is supported and intended — txmmoduleobjectpointergetextended searches the system's created objects by name and hands back objects the application created and objects other modules created, so that a module can send to a shared queue, take a shared semaphore or get a shared mutex.

Destroying one of those is not sharing it. A module could name any object it had a pointer to and have the privileged dispatcher delete it.

A ThreadX module allocates the control blocks of its kernel objects from the Module Manager's object pool, and can ask for that memory back by address with txmmoduleobjectdeallocate. The manager released it whatever was in it, including a control block the kernel was still using. Deallocation is not deletion: the object stays on the created list for its type, a thread stays wherever it was on the ready or suspension lists and stays schedulable, and an active timer stays on the timer list. The byte pool is meanwhile free to hand those same bytes to the next allocation.

The TLS 1.3 Certificate-message parser in NetX Secure decrements the message length to skip a context byte without first establishing that the message has a byte to skip. A zero-length Certificate message therefore wraps the unsigned length to 0xFFFFFFFF, which makes the bounds check that follows vacuous and sends the parser reading past the session packet buffer.

The trigger is a four-byte handshake header and requires no cryptographic validity. It is reachable pre-authentication.

The X.509 parser in NetX Secure accepts an RSA public key of any size, but every signature-verification path decrypts into fixed-size buffers dimensioned for the NXCRYPTOMAXRSAMODULUSSIZE default of 4096 bits. A certificate carrying a larger modulus drives an out-of-bounds write past a file-scope static during ordinary certificate-chain verification.

It is reachable pre-authentication. The issuer used for the crypto operation is looked up in the remote, peer-supplied store before the trusted store, so the attacker supplies the oversized key themselves as an intermediate in the chain they present. It triggers on a TLS or DTLS client verifying a malicious server's chain, and on a server performing client-certificate authentication.

gxmultilinetextviewdisplayinfoget() reads one byte past the end of the application's text buffer when the string it is given ends with a carriage return (\r). The over-read can also cause callers to advance their index past the end of the string, producing a second over-read in gxmultilinetextviewstringtotalrowscompute() and a row of text that is not in the source.

The GUIX software JPEG decoder reads four kinds of marker segment without checking that each is long enough to hold what it reads. A truncated segment is therefore read past the end of the caller's image buffer. Separately, a zero chroma sampling factor makes the block decode loop non-terminating. Both reproduce in the default configuration, in which GXSOFTWAREDECODERSUPPORT is enabled.

The GUIX JPEG software decoder enforces no ordering on JPEG markers. A file that places a second SOF0 frame header after SOS re-runs the frame header parser after the output buffer has already been allocated and its geometry latched. The decoder returns GXSUCCESS and publishes a GXPIXELMAP whose reported dimensions and datasize exceed the allocation behind it.

Any consumer that trusts the returned structure reads out of bounds, including GUIX's own display drivers, reached through the ordinary draw path.

Reproduces in the shipped default configuration; GXSOFTWAREDECODERSUPPORT is enabled by default.

gxbinrespixelmaptableload() in the GUIX binary resource (theme) loader indexes the pixelmap table with a value read verbatim from the resource file and never bounds it against the table size. A crafted theme drives a write of up to roughly 256 KB past the end of the table.

The overflowed buffer is allocated by GUIX itself, through gxsystemmemoryallocator, rather than supplied by the caller, so the loader corrupts its own arena. The public API gxbinresthemeload() takes no size parameter, so no amount of caller diligence prevents this.

Reproduces in the shipped default configuration; GXBINARYRESOURCESUPPORT is enabled by default.

I’ve been through CISA's Known Exploited list for Oct 8-16 and pulled out what matters for small-office and SMB environments.

Patch now: \- Ivanti Connect Secure CVE-2026-104935: auth bypass to RCE. If it's on your edge, patch and assume compromise until you've worked through CISA's guidance. \- Windows Shell CVE-2026-96951: Mark of the Web bypass, fixed in this month's Patch Tuesday. Push it to anything that opens email attachments. \- PAN-OS CVE-2026-0322: urgent if the management interface is reachable from anywhere it shouldn't be. \- Cisco Secure Email Gateway CVE-2026-76519: AMP path. Check your version against Cisco's advisory.

Batch: \- FortiOS CVE-2025-61624: path traversal, but needs admin access first. Roll it into your next window. \- ProFTPD mod\copy CVE-2015-3306: ancient but still being exploited. If FTP is still on anywhere, switch to SFTP.

No KEV hits this week for Proxmox, TrueNAS, UniFi, pfSense, Synology, or QNAP.

Disclosure: I put together a weekly digest of this. Not dropping a link, but happy to answer questions about any of these here.

Heap-based buffer overflow in Microsoft Edge (Chromium-based) allows an unauthorized attacker to execute code over a network.

Heap-based buffer overflow in Microsoft Edge (Chromium-based) allows an unauthorized attacker to execute code over a network.

Heap-based buffer overflow in Microsoft Edge (Chromium-based) allows an unauthorized attacker to execute code over a network.

Double free in Microsoft Edge (Chromium-based) allows an unauthorized attacker to execute code over a network.

Heap-based buffer overflow in Microsoft Office Word allows an unauthorized attacker to execute code over a network.

Microsoft Office Word Remote Code Execution Vulnerability

Heap-based buffer overflow in Microsoft Office Word allows an unauthorized attacker to execute code over a network.

Microsoft Office Word Information Disclosure Vulnerability

Microsoft Office Word Information Disclosure Vulnerability

Microsoft Office Word Remote Code Execution Vulnerability

Heap-based buffer overflow in Microsoft Office Word allows an unauthorized attacker to execute code over a network.