<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 15:44:14 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-68904</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-68904</link>
      <description>&lt;p&gt;node-opcua is an OPC UA implementation for TypeScript and Node.js. From 2.0.0 until 2.170.0, node-opcua clients using the default keepSessionAlive setting can enter a repeated reconnection cycle when an OPC UA server&amp;#39;s clock skew causes BadInvalidTimestamp responses. ClientSessionKeepAliveManager._ping_server treated the server-originated ServiceFault as a network outage and forced a transport reconnect, while ClientTCP_transport._on_ACK_response used socket.end() after failed HEL/ACK negotiation and could leave the connection in FIN-WAIT-2 when the peer did not close. Repetition at the keepAliveInterval accumulates file descriptors and memory until the client process or container can be terminated by resource exhaustion. This issue is fixed in version 2.170.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;node-opcua is an OPC UA implementation for TypeScript and Node.js. From 2.0.0 until 2.170.0, node-opcua clients using the default keepSessionAlive setting can enter a repeated reconnection cycle when an OPC UA server&amp;#39;s clock skew causes BadInvalidTimestamp responses. ClientSessionKeepAliveManager._ping_server treated the server-originated ServiceFault as a network outage and forced a transport reconnect, while ClientTCP_transport._on_ACK_response used socket.end() after failed HEL/ACK negotiation and could leave the connection in FIN-WAIT-2 when the peer did not close. Repetition at the keepAliveInterval accumulates file descriptors and memory until the client process or container can be terminated by resource exhaustion. This issue is fixed in version 2.170.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-68904</guid>
    </item>
    <item>
      <title>GHSA-r2pf-9cw4-5j65 — node-opcua: TCP Socket Leak (FIN-WAIT-2) via keepalive reconnection cycle - Resource Exhaustion</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-r2pf-9cw4-5j65</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: node-opcua-transport, npm: node-opcua-client, npm: node-opcua&lt;/p&gt;
&lt;p&gt;SUMMARY
-------
A combination of bugs in node-opcua causes unlimited TCP socket accumulation (FIN-WAIT-2 state) during automatic reconnection, leading to memory exhaustion and eventual container/process crash (OOM kill). The issue is triggered by the default configuration (keepSessionAlive: true) when the OPC UA server has clock skew relative to the client.&lt;/p&gt;
&lt;p&gt;Affected version: Tested on 2.169.0 (latest as of April 2026).&lt;/p&gt;
&lt;p&gt;ENVIRONMENT
-----------
- Node.js: v24.11.0
- node-opcua: 2.169.0
- OS: Linux (containerized via Podman, slirp4netns networking)
- OPC UA Server: Industrial PLC (opc.tcp endpoint), clock skew of ~50 minutes ahead of client
- Client config: keepSessionAlive: true (default), keepAliveInterval: 3000, securityMode: None, securityPolicy: None&lt;/p&gt;
&lt;p&gt;ROOT CAUSE ANALYSIS
-------------------&lt;/p&gt;
&lt;p&gt;Bug #1 - ClientTCP_transport._on_ACK_response() uses socket.end() instead of socket.destroy()&lt;/p&gt;
&lt;p&gt;File: node-opcua-transport/src/client_tcp_transport.ts, _on_ACK_response() method&lt;/p&gt;
&lt;p&gt;When the HEL/ACK handshake fails during a reconnection attempt, the error handler calls socket.end():&lt;/p&gt;
&lt;p&gt;if (err || !data) {
        externalCallback(err || new Error(&amp;#34;no data&amp;#34;));
        if (this._socket) {
            this._socket.end();   // &amp;lt;- sends TCP FIN, leaves socket in FIN-WAIT-2
        }
    }&lt;/p&gt;
&lt;p&gt;socket.end() sends a TCP FIN and waits for the peer to close its side. If the peer doesn&amp;#39;t respond (common with PLCs), the socket remains in FIN-WAIT-2 state indefinitely, leaking file descriptors and mem…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: node-opcua-transport, npm: node-opcua-client, npm: node-opcua&lt;/p&gt;
&lt;p&gt;SUMMARY
-------
A combination of bugs in node-opcua causes unlimited TCP socket accumulation (FIN-WAIT-2 state) during automatic reconnection, leading to memory exhaustion and eventual container/process crash (OOM kill). The issue is triggered by the default configuration (keepSessionAlive: true) when the OPC UA server has clock skew relative to the client.&lt;/p&gt;
&lt;p&gt;Affected version: Tested on 2.169.0 (latest as of April 2026).&lt;/p&gt;
&lt;p&gt;ENVIRONMENT
-----------
- Node.js: v24.11.0
- node-opcua: 2.169.0
- OS: Linux (containerized via Podman, slirp4netns networking)
- OPC UA Server: Industrial PLC (opc.tcp endpoint), clock skew of ~50 minutes ahead of client
- Client config: keepSessionAlive: true (default), keepAliveInterval: 3000, securityMode: None, securityPolicy: None&lt;/p&gt;
&lt;p&gt;ROOT CAUSE ANALYSIS
-------------------&lt;/p&gt;
&lt;p&gt;Bug #1 - ClientTCP_transport._on_ACK_response() uses socket.end() instead of socket.destroy()&lt;/p&gt;
&lt;p&gt;File: node-opcua-transport/src/client_tcp_transport.ts, _on_ACK_response() method&lt;/p&gt;
&lt;p&gt;When the HEL/ACK handshake fails during a reconnection attempt, the error handler calls socket.end():&lt;/p&gt;
&lt;p&gt;if (err || !data) {
        externalCallback(err || new Error(&amp;#34;no data&amp;#34;));
        if (this._socket) {
            this._socket.end();   // &amp;lt;- sends TCP FIN, leaves socket in FIN-WAIT-2
        }
    }&lt;/p&gt;
&lt;p&gt;socket.end() sends a TCP FIN and waits for the peer to close its side. If the peer doesn&amp;#39;t respond (common with PLCs), the socket remains in FIN-WAIT-2 state indefinitely, leaking file descriptors and mem…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-r2pf-9cw4-5j65</guid>
    </item>
  </channel>
</rss>
