NetXMS Support Forum

Great job, thanks everyone!

Alessio.

Thank you Victor and Alex.  I appreciate the response!

Thanks for the info, after reading the docs about Agent External Metrics I converted the actions to shell form metrics and now it works fine.

(Before I read the docs I tried the format you provided, but that had some issues which didn't trigger an alarm so I have no idea what was wrong with that.)

Version 6.2.5 that is just published should have this fixed.

We just published release 6.2.5, Windows packages now include latest OpenSSL 3.5.

We just published patch release 5 for NetXMS 6.2. Notable changes:
-   New network device drivers for Arista and Mellanox switches, and for Dell OS10 and Force10 (FTOS) switches
-   New web API endpoints for pushing DCI values, getting the last value of table DCIs, and deleting objects; nodes' primary host name or IP address can be changed via web API
-   Web API requests are handled by a thread pool (size is configurable, default 16) instead of a single thread
-   Weather subagent: added Bright Sky provider (DWD open data for Germany)
-   Unnecessary trailing zeros are removed from formatted fractional values
-   Event processing policy editor opens large rule chains faster
-   Data collection scripts are no longer restricted by Scripts.RestrictWriteAccess
-   Windows installers bundle OpenSSL 3.5 LTS instead of 3.0.x, which has reached end of life

And full list of closed issues:
-   #2854 / NX-2651 (Driver support for Arista and Mellanox switches - Port View is Blank)
-   #3423 (New network device driver: Dell Networking OS10 / Force10 (FTOS) switches)
-   #3542 (nxdbmgr upgrade to 62.25 overwrites customized interface event messages)
-   #3550 (Editing attributes of LDAP-synced users: silently overwritten on next sync)
-   #3575 (Object deletion: removeDCI option is mutable between request accept and worker execution)
-   #3609 (WebAPI: collected table DCI data is not reachable)
-   #3610 (Value cache placeholder (empty value, timestamp 1 ms) reported as collected value in current-values)
-   #3612 (AI assistant function ask-user-choice always fails: tool schema declares every parameter as string)
-   #3613 (Web API endpoints for delete objects and modify object primaryName/ipaddress)
-   #3615 (Critical BUG: system crash while create json obj in EEP->action->script)
-   #3616 (Web API for pushdci)
-   #3617 (NXSL JsonArray set()/insert() silently succeed on out-of-range index)
-   #3618 (Connection history generates MAC events for interfaces rejected by Hook::CreateInterface)
-   #3619 (Scripts.RestrictWriteAccess blocks agent command execution in script-origin DCIs with no per-DCI override)
-   #3620 (Denied call under Scripts.RestrictWriteAccess surfaces as an unrelated NXSL error, and the parameter description understates its scope)
-   #3622 (nxmc: create rule editor content lazily in the event processing policy editor)
-   #3623 (Rack images crash the web client)
-   #3630 (File manager subagent ignored read-only restriction for file permission change and move operations)
-   #3631 (Remove trailing zeros if more than 2)
-   #3634 (Physical container rebinding is not serialized; rapid placement changes can leave the object tree on a stale container)
-   #3635 (Weather subagent: Bright Sky provider (DWD open data for Germany))
-   #3636 (Null dereference from unvalidated client input: delegate object in getLastValuesByDciId, element index in DashboardBase)
-   #3637 (Server crash: MySQL/MariaDB drivers alloca the whole field length, overflowing the thread stack on large image library entries)
-   #3638 (AI assistant: questions asked from a delegated skill never reach the user and time out)
-   #3639 (Network discovery discards the SNMP credentials it found; every discovered node is created with community "public")
-   #3640 (Built-in SNMP agent reads SNMP.Agent.Community, but the configured parameter is SNMP.Agent.CommunityString)
-   #3641 (Management console: scrollable dashboards leak a ControlListener on every rebuild, UI thread ends up in a layout loop after hours)
-   #3642 (WebAPI: all REST requests are serialized on a single libmicrohttpd thread)
-   #3643 (Move bundled OpenSSL in Windows installers from 3.0.x (EOL) to 3.5 LTS)

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.