NetXMS Support Forum

Hi,

Bundled OpenSSL only exists in the Windows builds - the agent, server, client and web UI installers ship libcrypto-3/libssl-3 DLLs. Linux packages link against the system OpenSSL and the Docker images inherit Debian's, so on those platforms your distribution's updates already cover this and there's nothing for us to ship.

None of the 16 are exploitable in NetXMS. They land in code paths we don't use at all - CMS, PKCS#7, DANE, CRMF, OCB/SIV and the RSA KEM. NXCP encryption uses RSA with OAEP padding, and certificate revocation is handled by our own code rather than OpenSSL's CRL machinery. The remaining few need gigabyte-scale inputs that a TLS handshake can't deliver. That includes CVE-2026-45447, the only High on your list: PKCS7_verify() is not called anywhere in the codebase.

The Windows DLLs will still be updated, because version scanners flag them regardless of reachability. It's a bigger change than a patch bump this time: OpenSSL 3.0 reached end of life on 7 September and 3.0.22 is the final release of that branch, so we're moving the Windows build to 3.5 LTS rather than to a newer 3.0. Tracked in https://github.com/netxms/netxms/issues/3643 - no date yet.

If you need it cleared sooner, you can drop newer libcrypto-3/libssl-3 DLLs into the agent's bin directory yourself; OpenSSL keeps ABI stable across the 3.x series, so 3.5 works in place. Two caveats: they'll be overwritten on the next agent upgrade, and they won't carry our code signature.

Got it, thank you very much for your reply!

Any idea when the agents and server will be patched to mitigate openSSL vulnerabilities: CVE-2026-28387, CVE-2026-28388, CVE-2026-28389, CVE-2026-28390, CVE-2026-31789, CVE-2026-31790, CVE-2026-34180, CVE-2026-34182, CVE-2026-42766, CVE-2026-42767, CVE-2026-42770, CVE-2026-45445, CVE-2026-45446, CVE-2026-45447, CVE-2026-7383, CVE-2026-9076

Hi,

Confirmed bug, not a configuration problem - your community is configured in the right place. Filed as https://github.com/netxms/netxms/issues/3639

Discovery does try the communities from Network Credentials and does find the working one, but it is discarded before the node object is created, so every discovered node starts on the default "public". Affects all versions since 6.1.0.

Normally this repairs itself: the configuration poll that runs right after node creation tests "public", fails, falls back to the credentials list and writes the correct community back. It does not repair when the device answers "public" as well - the poll tests the node's current community first and stops as soon as it gets any response. That is most likely what you are hitting, since it happens on every device. Worth confirming on one:

nxsnmpget -v 2c -c public 10.61.200.26 .1.3.6.1.2.1.1.2.0
Anything other than a timeout means the device accepts "public" and the automatic correction will never kick in.

Correcting the community on the node stays the workaround until the fix ships - Node::setSNMPCommunity() is available in NXSL if you want to fix existing nodes in bulk.

Unrelated: SNMP.Agent.CommunityString is the community for the server's own built-in SNMP agent (disabled on your server), not for polling, so it has no effect on discovery.

Hi,

nxmc is already jakarta — it's built against jakarta.servlet-api 6.0 and its web.xml declares Jakarta EE 10, so ee10 in your setup is correct. What's failing is that the file you deployed as nxmc-6.2.4.war is not the web UI, it's the Legacy Web API war (netxms-websvc). That one is still javax/EE8 and under ee10 it fails exactly like this.

Two things in your log point at it: the missing class is javax/servlet/http/HttpServlet, which nxmc has no reference to at all, and the context starts as "NetXMS REST API" — that display name comes from the API war's web.xml, the web UI war has no display name.

Check with:

unzip -p /usr/share/jetty-base/webapps/nxmc-6.2.4.war WEB-INF/web.xml | head -8
The web UI war has xmlns="https://jakarta.ee/xml/ns/jakartaee" and version="6.0". What you have will show <display-name>NetXMS REST API</display-name> and version="2.4".

Re-download nxmc-6.2.4.war from the Web Interface Binaries section — the two files sit next to each other there — and it deploys into your existing ee10 setup unchanged.

Many thanks Alex,

found images and working on them now...

+--------------------------------------+-----------------------------------------------------------------+----------+--------------------+
| guid                                 | name                                                            | category | LENGTH(image_data) |
+--------------------------------------+-----------------------------------------------------------------+----------+--------------------+
| 81652d15-df62-44ca-9f6b-55c68c6d8670 | schema sinottico REALE alimentazione Palma Piani DRAWIO-NOAVV   | Default  |            1824040 |
| 2ffbcbdb-a04e-488b-91ec-54c48de952e6 | mappa_sfondo                                                    | Default  |            1603868 |
| f5440229-8d66-4f32-a12c-1d984a2479bd | schema sinottico REALE alimentazione Trieste DRAWIO-NOAVV       | Default  |            1581020 |
| 9e5a6fdf-cc27-4440-bc3b-364912304f34 | schema sinottico REALE alimentazione CED Palmanova DRAWIO-NOAVV | Default  |            1093976 |
| 4da68704-046f-4a78-afad-cd3ecf417687 | bw_mappa_sfondo                                                 | Default  |             934132 |
| 94249c03-ba41-4fa8-bb61-ec9441bab325 | schema sinottico REALE alimentazione UD-Fiera DRAWIO-NOAVV      | Default  |             805556 |

The backtrace pins it exactly: it's a bug in our MariaDB driver, triggered by an oversized entry in the image library.

Since 6.2 images are stored in the database instead of as files, and the driver allocates the buffer for a field on the stack, sized by the length of that field. Server worker threads get a 1 MB stack by default, so an image over roughly 780 KB overflows it and the process dies the moment anything asks for that image - which is what opening the dashboard does. The upgrade migrates existing image files into the database, so an image that had been fine for years starts crashing the server right after.

Two steps to get you running again.

1) Add to netxmsd.conf and restart the server:

DefaultThreadStackSize=8M
That raises the worker stacks and stops the crash right away.

2) Find the image and replace it with a smaller one:

SELECT guid, name, category, LENGTH(image_data) FROM images ORDER BY LENGTH(image_data) DESC LIMIT 5;
Anything near or above 1000000 is the one. Re-upload a downscaled version through the image library - listing and re-uploading are safe, only fetching the image bytes crashes.

Ticket is https://github.com/netxms/netxms/issues/3637 - the driver should allocate large fields on the heap, not the stack.

Thanks Alex,

here it is:

#0  0x00007ffff74b7b77 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff4fedebf in ?? () from /lib/x86_64-linux-gnu/libmariadb.so.3
#2  0x00007ffff4fef2b0 in ?? () from /lib/x86_64-linux-gnu/libmariadb.so.3
#3  0x00007ffff4fea43e in mysql_stmt_fetch_column () from /lib/x86_64-linux-gnu/libmariadb.so.3
#4  0x00007ffff6050ebe in GetFieldInternal (result=0x7ffff4442920, iRow=<optimized out>, iColumn=4, buffer=0x7fffd8e1a800,
    bufferSize=2187953, utf8=<optimized out>) at mariadb/mariadb.cpp:693
#5  0x00007ffff783cf6e in DBGetFieldUTF8 (hResult=0x7fffde414cc0, row=0, column=4, buffer=<optimized out>, bufferSize=0) at session.cpp:561
#6  0x00007ffff783d87c in DBGetFieldBinary (hResult=hResult@entry=0x7fffde414cc0, row=row@entry=0, column=column@entry=4,
    length=length@entry=0x7fffdf5f9538) at session.cpp:846
#7  0x00007ffff7c618d6 in ClientSession::sendLibraryImage (this=this@entry=0x7ffff4a34000, request=...) at session.cpp:13810
#8  0x00007ffff7c827f9 in ClientSession::processRequest (this=0x7ffff4a34000, request=0x7fffe9141f30) at session.cpp:1651
#9  0x00007ffff7c2cde2 in __ThreadPoolExecute_Wrapper_1<ClientSession, NXCPMessage*> (arg=0x7fffe912aca0)
    at ../../../include/nms_threads.h:1046
#10 0x00007ffff77e41f5 in WorkerThread (threadInfo=0x7fffefc77af0) at tp.cpp:228
#11 0x00007ffff77e532b in ThreadCreate_Wrapper_1<WorkerThreadInfo*> (context=0x7fffefc77a00) at ../../include/nms_threads.h:354
#12 0x00007ffff770dea7 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#13 0x00007ffff7444aef in clone () from /lib/x86_64-linux-gnu/libc.so.6

Hi,

Fastest way to pin this down is to run the server under gdb and let it stop at the crash - the backtrace names the code path directly.

apt install netxms-dbg
systemctl stop netxms-server
gdb /usr/bin/netxmsd
run -D3
# open the dashboard in the client, wait for the crash
bt

Post the bt output here.

netxms-dbg is required - without it the backtrace is just hex addresses and tells us nothing. Without -d or -S netxmsd stays in foreground, which is what we want; it also starts interactive console there, so add -q if that gets in the way of gdb.

Note: Scripts.RestrictWriteAccess has no effect here. Dashboard element scripts run under user security context, not the read-only one that parameter controls, so toggling it changes nothing either way.

Hello,

after updating to version 6.2.4 (server, agent, client...), opening one of our custom dashboards causes the server to crash; how can we identify the cause of the problem?

We tried disabling "Scripts.RestrictWriteAccess", but without success.

Thanks in advance,

Alessio.