Security Update: Configuration of the Neuron running in Docker containers
During configuration of the IoT Gateway, there existed a vulnerability (prior to build 2026-09-08) that made it possible to hijack the configuration of the Neuron from the local area network, if the Neuron ran in a Docker container (or similar environment). This vulnerability does not affect Neurons that are already installed, or Neurons that are being installed in non-container environments. This vulnerability has been fixed in build 2026-09-08.
During configuration of the Neuron (or Gateway) the operator uses the localhost interface to make initial configurations. In a Docker container, such an interface is not available, and so access to the Neuron (or Gateway) was permitted, if the request came from the local area network (non-public IP addresses), at least until the initial configuration had been made. During this time-frame (from container start until initial configuration completed), a malicious actor in the local area network could access the Neuron and perform the configuration steps itself. This has been fixed as is described in the following paragraphs.
First, the vulnerable implementation has been removed, and been replaced with a new machanism based on a random token being generated during initial configuration. This token needs to be provided as a query parameter in the URL, appending
?StartupToken=...or&StartupToken=...as appropriate.Information about the startup token is made available both in the log (which gets displayed on the console), viewable in the Docker log, and also as a text file in the application data folder, which should reside on a volume, also accessible to the operator.
The token is only available during configuration, and is removed afterward. The method of accessing the Neuron (or Gateway) using startup tokens is only available if running in a container, and only during initial configuration.
After successful configuration, all sessions are removed from the web server, forcing the operator to login again.
If the token is used from an endpoint, it cannot then be used from another endpoint. If a malicious actor is first, the operator cannot enter (unless from the same IP), and immediately learns of the compromise. If the operator enters first, and a malicious actor tries, the malicious actor cannot enter (unless from the same IP as the operator). A malicious actor can therefore only enter undetected, if the computer (or network) of the operator is already compromised, and the malicious actor has access to the communication between the operator and gateway, and knows how to login after the operator has logged in already, or access to the Docker logs.
Note: During the configuration phase, an actor cannot navigate pages freely: Only the current configuration page is available. This is true for both the operator and any hypothetical malicious actor. (This is controlled by the ResourceOverride property on the HttpServer). Once configuration has been performed, this hard routing to configuration pages is removed, but so are all sessions and log-ins, and any user, including malicious actors, cannot use such a token to login again.
Note 2: An additional protection mechanism has been added: The Neuron (or Gateway) will only accept one Remote Endpoint to use the startup token. If the operator configuring the Neuron (or Gateway), and any hypothetical malicious actor, access the Neuron (or Gateway) from different IP addresses, only one will be granted access, even if both have access to the startup token.
This vulnerability was found and reported, together with a proposed solution by Furkan Arslan. Much appreciated.