NetX Duo's WebSocket client resets the unmasking cursor to the first NXPACKET each time it advances through a chained packet, while the loop's upper bound belongs to the current packet. With the standard contiguous packet-pool layout, a masked server frame split across two packets therefore drives the XOR loop through the first packet's unused payload area and on through the second packet's NXPACKET control block.

The four-byte WebSocket masking key controls the bytes written, so the corruption is attacker-chosen rather than incidental.

In FileX before 6.4.2, the file support module for Eclipse Foundation ThreadX, there was a possible buffer overflow in the FileX RAM disk driver. It could cause a remote execurtion after receiving a crafted sequence of packets

Eclipse Wakaama before snapshot/2026-05-26 contains an unbounded memory allocation vulnerability in the CoAP Block1 handler within coap/block.c that allows unauthenticated remote attackers to exhaust server memory by sending a sequence of Block1 PUT requests with incrementing block numbers. Attackers can target the registration endpoint over UDP without authentication, causing the server to repeatedly reallocate a growing accumulation buffer by appending each block payload without enforcing any maximum total size limit, resulting in denial of service through memory exhaustion.

The open-vsx.org deployment returned Access-Control-Allow-Origin reflecting the requesting origin together with Access-Control-Allow-Credentials: true on the authenticated /user/ endpoints. A page on any origin could therefore issue credentialed requests to the service in a logged-in user's browser and read the responses.

This exposed /user (login name, avatar, homepage, tokens URL), /user/tokens, /user/namespaces, /user/extensions, /user/search/{name} and /user/namespace/{name}/members, and — because /user/csrf was readable the same way — allowed the CSRF protection on write endpoints to be defeated. Chaining the two, an attacker page could call /user/token/create and exfiltrate a personal access token carrying publish and delete rights over the victim's namespaces.

The headers were emitted by the CDN/edge layer, not by the application: the Open VSX software sets allowCredentials(true) in exactly one place, against a single exact origin derived from ovsx.webui.url, and defines no CORS mapping on /user/ beyond it. No configuration of the software produces origin reflection with credentials.

An unauthenticated client can drain the RTSP server's packet pool with a couple of dozen requests

that carry a Session header the parser cannot convert.

The Session branch returns the raw NetX error code instead of an RTSP status code:

c

/ addons/rtsp/nxrtspserver.c:2754 /

status = nxutilitystringtouint(fieldvalueptr, fieldvaluelength, &sessionid);

if (status)

{

return(status); / NXINVALIDPARAMETERS / NXSIZEERROR / NXOVERFLOW /

}

Every other branch of the same function maps its failure to an RTSP status first. The CSeq branch

eighteen lines earlier does exactly that (line 2736 returns NXRTSPSTATUSCODEBADREQUEST). The

raw code then reaches nxrtspservererrorresponsesend (nxrtspserver.c:1234), which does not

recognise it, takes a path that returns without releasing the response packet it already allocated,

and the block never goes back to the pool.

Six requests with an empty Session header against a 22 packet pool:

valid requests: after request 6: pool available = 21, AFTER = 22 / 22

malformed requests: after request 6: pool available = 16, AFTER = 17 / 22

One block per request, not returned when the client disconnects. Twenty six requests take the pool

to zero and the server starts failing allocations, after which it serves nobody. If the pool is

shared with the rest of the application, as it is in the shipped sample, the rest of the stack

stops with it.

Convert the nxutilitystringtouint failure in the Session branch into

NXRTSPSTATUSCODEBADREQUEST the way the CSeq branch does, and release the response packet on

every exit path of nxrtspservererrorresponsesend.

Mounting an attacker-controlled NAND flash image (lxnandflashopen()) triggers an unbounded out-of-bounds heap write in LevelX's NAND flash-translation-layer metadata parser that overwrites a driver function pointer in the control block, giving a demonstrated control-flow hijack — RIP set to a full 8-byte attacker-chosen value (register-verified). Two accompanying OOB reads. All reproduced verbatim under ASan at HEAD 9f1cfdc. (The affected metadata-parser header states "Some portions generated by Copilot (Sonnet 4.6)" — an AI-generated parser with an unchecked on-flash count.)

In Eclipse Theia versions prior to 1.71.0, the AI chat agent processed workspace file and directory names as part of its prompt context without distinguishing them from system instructions. An attacker could craft a malicious repository with adversarial directory or file names that, when analyzed by the AI agent, would cause the agent to follow attacker-controlled instructions (indirect prompt injection). Combined with other AI chat features available in untrusted workspaces, this enabled attack chains leading to data exfiltration via Markdown image rendering or arbitrary command execution via task definitions.

In Eclipse Theia versions prior to 1.71.0, files matching the pattern .prompts/.prompttemplate in a workspace were automatically loaded and could override or extend the AI agent's system prompts. An attacker could craft a malicious repository containing prompt template files that, when the workspace was opened in Theia, replaced the AI's system instructions with attacker-controlled content (indirect prompt injection). Combined with other AI chat features available in untrusted workspaces, this enabled attack chains leading to data exfiltration via Markdown image rendering or arbitrary command execution via task definitions.

The GUIX binary resource (theme) loader sizes its arena and populates it in two separate passes that traverse the resource file with independent cursor arithmetic. Because gxpageheaderdatasize is never validated against the glyph data a page actually contains, the two passes can read different page headers for the same font page, derive different glyph counts, and reserve less than the load pass writes. The excess is written past the end of the arena, with content taken verbatim from the file.

The overflowed buffer is allocated by GUIX itself, through gxsystemmemoryallocator, rather than supplied by the caller. 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.

When Jetty's HttpClient make a request to a server through a forward proxy, the server may reply with a 407 (Proxy Authentication Required).

The client mistakenly interprets the 407 as coming from the proxy, so it re-sends the request with the Proxy-Authentication header, which arrives to the server, that now has access to the proxy credentials.

In Eclipse Foundation NextX Duo before 6.4.4, a module of ThreadX, the nxsecuretlsprocessclienthello() function was missing length verification of certain SSL/TLS client hello message: the ciphersuite length and compression method length. In case of an attacker-crafted message with values outside of the expected range, it could cause an out-of-bound read.

In NetX Duo version before 6.4.4, the component of Eclipse Foundation ThreadX, there was a potential out of bound read in nxsecuretlsprocessclienthello() because of a missing validation of PSK length provided in the user message.

In NetX Duo version before 6.4.4, the component of Eclipse Foundation ThreadX, there was an incorrect bound check resulting it out by two out of bound read.

In NetX Duo version before 6.4.4, the component of Eclipse Foundation ThreadX, there was an incorrect bound check innxsecuretlsprocclienthellosupportedversionsextension() in the extension version field.

In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in nxipv4packetreceive() function when received an Ethernet frame with less than 4 bytes of IP packet.

In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in nxippacketreceive() function when received an Ethernet with type set as IP but no IP data.

In Eclipse Foundation NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in nxipv4optionprocess() when processing an IPv4 packet with the timestamp option.

In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in nxipv4packetreceive() when handling unicast DHCP messages that could cause corruption of 4 bytes of memory.

In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in nxicmpv6validateoptions() when handling a packet with ICMP6 options.

In NextX Duo's snmp addon versions before 6.4.4, a part of the Eclipse Foundation ThreadX, an attacker could cause an out-of-bound read by a crafted SNMPv3 security parameters.

In NetXDuo version before 6.4.4, a networking support module for Eclipse Foundation ThreadX, in the DHCPV6 client there was an unchecked index extracting the server DUID from the server reply. With a crafted packet, an attacker could cause an out of memory read.

Open VSX Registry does not sanitize SVG files uploaded as extension icons prior to storage, and serves them with Content-Type: image/svg+xml without security headers such as Content-Security-Policy or Content-Disposition: attachment. This allows an attacker to publish an extension with a malicious SVG icon and achieve stored cross-site scripting (XSS) when a user navigates directly to the icon URL.

On deployments using local storage, script execution occurs within the Open VSX application origin, enabling session hijacking, authentication token theft, and unauthorized extension publishing. On deployments backed by external storage (such as open-vsx.org with an S3-backed CDN), execution is confined to the storage origin, reducing impact but still permitting phishing attacks and credential harvesting through attacker-crafted pages.

A DHCP server, or anyone on the LAN who answers a DISCOVER first, can make the client read about a

kilobyte past the end of the received message.

The option walk keeps a pointer and an offset in step, and the only bound check uses the offset:

c

/ addons/dhcp/nxddhcpclient.c:7538, 7572 /

while (i < length - 1)

{

... size = (++data); / data moves 1: type -> length byte / data += size + 1; / data moves size + 1 more / i += size + 1; / i moves only size + 1 /

}

A TLV option occupies size + 2 bytes. data is advanced by size + 2 in total, i by size + 1, so

the offset falls one byte behind the real read position for every option the walk skips. After

enough skipped options the check i < length - 1 still holds while data is already past the end

of the message, and the subsequent read of the type and length bytes comes from whatever follows.

A single OFFER carrying a long run of skippable options is enough:

ERROR: AddressSanitizer: heap-buffer-overflow

READ of size 1 at 0x61b000000794 thread T5

#0 nxdhcpsearchbuffer addons/dhcp/nxddhcpclient.c:7541 #1 nxdhcpgetoptionvalue addons/dhcp/nxddhcpclient.c:7082

0x61b000000794 is located 164 bytes to the right of 1648-byte region

A well formed OFFER through the same path is handled normally, the client records the offer and

moves to REQUESTING, so the difference is the option layout rather than the harness.

The read runs in the DHCP client thread while the client is still unconfigured, so it happens on

every boot in reach of a hostile DHCP responder. The values read are used to configure the

interface, which is how the disclosed bytes become observable.

Advance i by size + 2, or derive the bound from data rather than keeping a second counter.

In USBX before 6.4.3, the USB support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in uxhostclassaudiostreamingsamplingget() when parsing a descriptor of an USB streaming device.

In USBX before 6.4.3, the USB support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in uxhostclassaudio10samparsefunc() when parsing a list of sampling frequencies.

In USBX before 6.4.3, the USB support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in uxhostclassaudioalternatesettinglocate() when parsing a descriptor with attacker-controlled frequency fields.

In USBX before 6.4.3, the USB support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in uxhostclasshidreportdescriptorget()  when parsing a descriptor of an USB HID device.

In USBX before 6.4.3, the USB support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in uxhostclassaudiodevicetypeget() when parsing a descriptor of an USB audio device.

End of life: 12/31/2029, Latest version: 21.0.12.1+1

End of life: 12/31/2029, Latest version: 21.0.12.1+1