DEV Community: Max Bayern

OT Security Weekly DACH – KW 41/2026: Edge Devices Under Fire

Max Bayern — Sat, 10 Oct 2026 07:04:17 +0000

The threat level for OT operators in Germany, Austria and Switzerland stays high in KW 41/2026. Once again, the biggest risks did not come through the PLCs. They came through the edge devices and the remote access in front of the control network. A zero-day in Citrix NetScaler was actively exploited, and Cisco Catalyst SD-WAN Manager has a critical authentication bypass with no workaround. Patching alone is not enough this week: if you don't also hunt for signs of compromise, you may miss webshells and backdoors that are already in place.

Key developments this week

1. Citrix NetScaler: SAML zero-day CVE-2026-88779 also hits devices that were already patched (SANS ICS Critical Control: CC4 – Secure Remote Access)
Attackers are targeting NetScaler Gateways with a SAML configuration. Citrix describes the issue as a denial of service. The flaw also affects devices that had been patched shortly before against earlier vulnerabilities. The patch was released early on 04.10., and reboots were also reported on build 14.1-73.37. Check your configuration for add authentication samlAction or samlIdPProfile and update right away to 14.1-73.41 or 13.1-64.28 (FIPS: 14.1-73.41 FIPS or 13.1-37282). After that, hunt for webshells, new local accounts and foreign sessions. Check for nsaaad crashes since 02.10. Reset sessions and credentials. If you find signs of compromise, rebuild the device and cut its access to the control systems until then.
Source: BleepingComputer

2. Cisco Catalyst SD-WAN Manager: auth bypass CVE-2026-76504 (CVSS 9.8), no workaround (CC2 – Defensible Architecture)
The vulnerability allows attackers to bypass authentication, and there is no workaround. Update to the fixed releases listed in the advisory and review your admin accounts. Take the management interface off the internet and allow access only from a dedicated management network.
Source: Cisco Security Advisory

What it means per sector

Power & grids: For energy suppliers in DACH, the main danger came through edge devices again. Remote access and perimeter systems such as NetScaler and Cisco SD-WAN Manager are affected; the NetScaler attacks were broad and not aimed at any specific sector. Grid operators and municipal utilities often run their remote maintenance through such systems. A recent analysis also found control and login systems in European wind and solar parks openly reachable from the internet (Help Net Security). Check your own public IP ranges for exposed systems. Full report (German)

Food & beverage: In KW 41 we found no publicly confirmed cyberattack on a food or beverage manufacturer in DACH. The situation is still tense, because dairies, breweries and bottlers use the same edge devices for remote maintenance, site networking, mail and remote access. Your business impact analysis and emergency plan should cover how production and shipping keep running if cloud, ERP or logistics IT is down for 3–7 days. That means offline recipes, batch lists, manual delivery notes and cold-storage emergency processes. Practice these procedures (CC1). Also agree on reporting channels, recovery times and backups with your service providers in the contract. For OT remote maintenance, allow access only through a separate jump host with MFA. Full report (German)

Machine builders: Machine builders and system integrators often use the same kind of edge devices for remote maintenance that are affected this week. If you provide remote access to customer plants through NetScaler or Cisco SD-WAN, you need to patch this week and rotate credentials. Build remote maintenance sessions only with MFA and customer approval. Separate the mail gateway from the internal network and from development environments. Check whether your OT segments stay isolated even without the SD-WAN policy. Full report (German)

What to do now

Patch the edge right away: NetScaler (14.1-73.41 / 13.1-64.28), Cisco Catalyst SD-WAN Manager (fixed releases per the advisory).
Hunt for compromise after patching: look for webshells, new local and API accounts and suspicious sessions. Check for nsaaad crashes since 02.10. If you find evidence, start incident response according to your plan (CC1).
Reset sessions and credentials: kill all VPN and admin sessions, rotate passwords and enforce phishing-resistant MFA for every remote access path (CC4).
Take management interfaces off the internet: NetScaler, SD-WAN Manager and other edge devices such as firewalls and mail gateways should be reachable only from a dedicated management network (CC2).
Inventory your end-of-life field devices: find field devices running end-of-life firmware and restrict their interfaces until you can upgrade (CC5).

Full sector reports (German)

Max Gilg is an OT cybersecurity consultant based in Rosenheim, Germany (OT-Cyber.de).

AI and Firmware: Architecture Beats Point Solutions

Max Bayern — Wed, 07 Oct 2026 08:15:51 +0000

Firmware no longer stops an attacker just because it is hard to understand. AI tools can speed up reverse engineering of embedded firmware and porting of PLC exploits. In the lab, this still took considerable help from the researchers. This is a summary of my German original. It affects operators and machine builders across DACH whose protection relies mainly on individual products, or whose controllers expose old, unpatched services on the network. What helps now: reduce exposure (segmentation, disable FTP and unnecessary services), monitor the OT network and practice Incident Response. Align all of it with the five SANS ICS Critical Controls and IEC 62443. In short: architecture and process instead of point solutions.

I'm Max Gilg, an OT cybersecurity consultant from Rosenheim. Here I sort out what is actually documented, and what happened in the lab versus in real plants.

How fast can AI build firmware and PLC exploits today?

Two research results are documented. Real attacks of a different kind have also been reported.

Lab result 1: WAGO PLC (Forescout, 01.09.2026). Forescout Vedere Labs used Claude (Sonnet 4.6, then Opus 4.6), Ghidra and real hardware to port a pre-auth exploit for CVE-2021-31886 from the WAGO 750-852 to the 750-831, without source code and without a debugger. CVE-2021-31886 is a pre-authentication buffer overflow in the Nucleus FTP server. The final RCE development stage took 8 hours 32 minutes at 535.74 USD in API costs. Afterwards, according to Forescout, the AI "moved from a harmless payload to multiple working network payloads in minutes". During development of a command-and-control (C2) implant, one payload wrote to flash memory and permanently bricked the PLC. The researchers had to keep guiding the AI out of dead ends (Forescout, SecurityWeek, The Hacker News, Cybersecurity Dive).

Research result 2: PC peripherals (Chaz Schlarp, 23.08.2026). Security researcher Chaz Schlarp had an AI agent (Claude Opus 5) reverse engineer the firmware of five PC peripherals, including a webcam, a monitor and a microphone, in about 13 hours of processing time over two weeks. Most devices had little or no firmware integrity checking; on the one device with signature validation, a single HTTP POST could disable the check (schlarp.com). These are not OT devices. But anyone who looks after edge devices in the field knows the design: microcontroller, update tool and hardly any anti-tamper.

Real attacks. Forescout also points to attacks on exposed PLCs at US water utilities (Forescout).

My assessment: "If AI, guided by experts, makes firmware analysis noticeably faster, the security of your plant must not depend on nobody looking into the firmware."

Why don't individual security products protect anymore?

Many plants in Bavaria, Salzburg and Tyrol have grown over the years: a firewall at the boundary, a remote maintenance box per supplier, a USB sanitization PC in maintenance. Together this is no defense once three assumptions fall apart:

"Our controller is too exotic." Forescout shows that AI also analyzes proprietary embedded firmware. Forescout writes that the assumption that attackers favor engineering protocols over complex PLC exploits "may become less reliable as AI reduces the effort required for exploit development". For now, Forescout still rates such exploits as "less attractive than easier alternatives".
"What isn't on the internet is safe." Firmware enters the plant via service laptops, USB sticks, update tools and remote maintenance.
"The vendor will patch it." The WAGO flaw dates from 2021. Controllers often stay in operation for many years and rarely get Secure Boot retrofitted.

Two different risks are at play: Forescout shows remote code execution through an old network service (a buffer overflow in the FTP server), Schlarp shows firmware that can be modified because integrity checks are missing or can be switched off. Secure Boot and signed updates address the second; only reduced exposure and monitoring address the first. "AI turns a legacy liability on the network into an attack path. If you can't patch a vulnerable PLC, you must make it unreachable and watch it. That is architecture, not a product purchase."

Which steps help right now?

My guide is the Five ICS Cybersecurity Critical Controls from SANS (SANS).

Foundation: know what is on the network. Without an asset inventory you don't know whether affected controllers such as the WAGO 750-831, and in which firmware version, are in your hall. An OT asset inventory, including firmware versions, covers this.

CC2 – Defensible Architecture: Segmentation by zones and conduits per IEC 62443-3-2, with a Security Level (SL-T) per zone. CERT@VDE (VDE-2021-050) recommends allowing no direct access from untrusted networks, disabling DHCP, DNS and FTP port 21, and updating the firmware. For the 750-852 and 750-831, which are based on Nucleus V1, no firmware update is available; CERT@VDE recommends isolating such devices in zones and restricting external communication paths. There, segmentation and disabled services remain the only protection.

CC3 – ICS Network Visibility & Monitoring: Attacks like these often show up on the network before they show up on the device. Forescout recommends monitoring for "unusual protocol use, repeated crashes, unexpected outbound communication"; firmware downloads outside maintenance windows are another warning sign. CERT@VDE also advises monitoring network traffic for anomalies. Attack detection in OT networks can detect this, an antivirus scanner typically cannot.

CC4 – Secure Remote Access: Remote maintenance only through a central jump host with MFA, per-session approval, time-limited and logged. No permanently open VPN tunnels per supplier.

CC5 – Risk-Based Vulnerability Management: Prioritize by reachability, exploitability and impact on the process. "Hard to exploit" is no longer a good reason for postponing. OT vulnerability management can support this.

CC1 – ICS Incident Response: Forescout explicitly recommends practicing Incident Response against AI-assisted OT attack paths. Who decides on shutting down? Where is the golden image of firmware and PLC program, and how long does restart take?

My recommendation: "Don't buy another security box before you know which devices with which firmware you have and who can reach them from outside."

What does this mean for production and maintenance?

For production managers, availability counts. In the lab, a faulty payload permanently bricked a PLC by accident. In my assessment, an attacker could cause the same damage deliberately, and even a "clumsy" attack can lead to a standstill. Clarify which controllers are stocked as spare parts. For maintenance: only load firmware from vendor sources, verify signature or hash, and treat service laptops and USB sticks as their own risk zone. That also protects the service technician.

What do CRA and NIS2 change about the firmware question?

The Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents, and to ensure secure updates and vulnerability handling (EU Commission, EUR-Lex). For machine builders, Secure Boot, signed updates and an SBOM are therefore no longer optional extras. CRA as a Service helps with implementation.

In Germany, NIS2 is being implemented through the NIS2 implementation act (Bundesregierung, DSN Group). Operators must demonstrate risk management, emergency plans and reporting channels, in other words architecture and process. Buyers should put signed firmware, Secure Boot, documented update processes, disableable services and an SBOM into tenders.

Who helps with OT security in Bavaria, Salzburg and Tyrol?

With OT-Cyber.de I support operators and machine builders across DACH, focused on the border region around Rosenheim. The entry point is usually an OT-Security-Beratung on segmentation and remote maintenance. If things are already on fire, the OT emergency help is reachable 24/7.

Sources

Forescout Vedere Labs, 01.09.2026: https://www.forescout.com/blog/can-ai-create-plc-attacks-yes-but-it%E2%80%99s-not-that-easy-yet/
SecurityWeek, 09/2026: https://www.securityweek.com/experiment-porting-a-plc-exploit-with-ai-takes-hours-and-hundreds-of-dollars/
The Hacker News, 09/2026: https://thehackernews.com/2026/09/researchers-use-claude-to-port-pre-auth.html
Cybersecurity Dive: https://www.cybersecuritydive.com/news/frontier-ai-exploit-flaws-water-PLCs-industrial-devices/829307/
Chaz Schlarp, Everything I own, owned, 23.08.2026: https://schlarp.com/posts/everything-i-own-owned/
CERT@VDE, VDE-2021-050: https://certvde.com/en/advisories/VDE-2021-050
SANS, Five ICS Cybersecurity Critical Controls: https://www.sans.org/white-papers/five-ics-cybersecurity-critical-controls/
Regulation (EU) 2024/2847: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
EU Commission, CRA Reporting: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
Pillitteri, CRA reporting obligations: https://pasqualepillitteri.it/en/news/15586/cyber-resilience-act-reporting-obligations-september-11
Bundesregierung, NIS-2: https://www.bundesregierung.de/breg-de/aktuelles/nis-2-richtlinie-deutschland-2373174
DSN Group, NIS2UmsuCG: https://www.dsn-group.de/datenschutz-notizen/das-nis-2-umsetzungsgesetz-ist-in-kraft-getreten-welche-schritte-sind-nun-erforderlich-4457509

If you want a hands-on starting point, see our OT-Security-Beratung.

Original (German): https://ot-cyber.de/blog/ki-knackt-firmware-architektur-schlaegt-einzelloesung.html

Max Gilg is an OT cybersecurity consultant based in Rosenheim, Germany (OT-Cyber.de).

Tanker Hack: What Access to the Propulsion System Means for OT

Max Bayern — Mon, 05 Oct 2026 09:38:59 +0000

On 21 August 2026, the US Coast Guard and the FBI boarded a crude oil tanker. This post is a short English adaptation of my German original and looks at what the incident means for OT, plants and machinery.

What happened

The vessel is the VL Prosperity: 333 meters long, carrying roughly 2.3 million barrels of crude oil, flying the Liberian flag. The trigger was information that "foreign cyber actors" had compromised the onboard networks. The Coast Guard confirms "malicious cyber activity". On 2 October 2026, Bloomberg reported, citing US officials, that investigators had found evidence of temporary access to the propulsion system.

What I want to state explicitly:

The FBI says there are currently no reports of an operational disruption, a danger to the crew or environmental damage.
It is not proven that the attackers changed anything on the propulsion system.
The dramatic accounts (throttled cooling, increased engine speed, 30 hours of radio outage) come from Iranian state media and are unconfirmed.
The engine room images circulating alongside them are fakes, according to an analysis by Cydome.

All confirmed facts, open questions and assessments with sources are in our incident situation report on the VL Prosperity (in German).

Why this is not just a maritime topic

A modern tanker is a floating plant: propulsion, auxiliary systems and cargo monitoring, all connected via controllers and networks. On top of that come satellite communication, remote maintenance by vendors and digital machinery monitoring. The Coast Guard names connectivity as the reason for the vulnerability: "When these vessels are highly connected, they're susceptible to cyber threats." The technical hurdle is "not necessarily that sophisticated".

Replace "ship" with "production line" and "satellite communication" with "remote maintenance router", and you get a fairly accurate description of how many connected production plants are built today.

If the path really led through the onboard IT all the way to the machine, the tanker shows what is possible then. Whether ship or filling line: if you don't know who can reach your controllers from the outside, you have already given up half of your control.

Five lessons for plants and machinery

I map them to the SANS Five ICS Cybersecurity Critical Controls.

Know and control remote access (CC4, Secure Remote Access). On ships as in factories, vendors often have permanent access. Every access path should be inventoried, logged and enabled only when needed, via a jump host with MFA.
Separate IT and the control level (CC2, Defensible Architecture). In an incident like this, a central question is whether the onboard IT was connected to propulsion and navigation. Every operator should be able to answer that question for their own plant.
See what happens in the OT network (CC3, Network Visibility). It is not publicly known how long the attackers were in the system on board. Without detection in the OT network, this is also one of the most common open questions after an incident in production.
Practice manual operation and restart (CC1, Incident Response). According to DNV, most ships have backup systems. In my view, these make the difference between an incident and a casualty. In production, the question is: do operations and maintenance know how to safely keep running or shut down without the control system?
Take legacy systems seriously (CC5, Risk-Based Vulnerability Management). The new cyber requirements for ships (IACS UR E26/E27) only apply to newbuilds with a construction contract from 1 July 2024 – the VL Prosperity dates from 2015. Mechanical engineering is similar: the CRA applies to products newly placed on the market, while existing plants often keep running for many more years.

Lesson six: disinformation belongs in the incident plan

Fake images, unconfirmed accounts from state media, anonymous sources: in this incident, a large part of the reporting was hard to verify. Anyone who has to inform customers, authorities and press in a real emergency needs prepared statements and a clear separation between "confirmed" and "assumed". That is exactly why our incident situation reports work with a counted knowledge scale.

And what about AI?

According to a report by Anthropic from September 2026, an Iran-linked threat actor used AI to compile public data on US naval forces and known vulnerabilities in maritime VSAT terminals and industrial controllers. A connection to the VL Prosperity is not proven. But it shows how quickly attackers can assemble targets and weaknesses today – one more reason to focus on the five controls rather than on point solutions.

Practical takeaways

Inventory every remote access path to your controllers; use a jump host with MFA.
Be able to answer whether your IT network is connected to the control level.
Get visibility and detection in the OT network.
Practice manual operation and restart without the control system.
Plan for legacy systems that will keep running for years.
Prepare statements that separate "confirmed" from "assumed".

How we support

If you want to know which remote accesses point to your controllers, we start with an OT security consulting engagement or an OT asset inventory. For machine builders who build remote maintenance into their products, CRA as a Service is the right entry point. And if things are already on fire: OT incident response. To prepare maintenance and engineering teams, see Cyber awareness for maintenance and engineering.

Original (German): https://ot-cyber.de/blog/tanker-hack-was-der-zugriff-auf-den-antrieb-fuer-ot-bedeutet.html

Max Gilg is an OT cybersecurity consultant based in Rosenheim, Germany (OT-Cyber.de).

OT Security Weekly DACH – KW 40/2026: Edge Zero-Days in Remote Access

Max Bayern — Sun, 04 Oct 2026 07:04:57 +0000

The threat level for OT operators in Germany, Austria and Switzerland stays high in KW 40/2026. Once again the biggest risk comes through edge devices used for remote access and for connecting sites. Citrix NetScaler ADC/Gateway has zero-days under active exploitation, and Cisco Catalyst SD-WAN Manager has a critical flaw. Both sit right at the boundary that many operators rely on to reach their OT.

Key developments this week

1. Citrix NetScaler ADC/Gateway: two RCE zero-days under active exploitation (CVE-2026-88771, CVE-2026-88772)
Both flaws allow unauthenticated Remote Code Execution. CISA has added both to the KEV catalog. Fixed builds are listed in the Citrix security bulletin.
Source: CISA alert · SANS ICS Critical Control: CC4 – Secure Remote Access

2. Cisco Catalyst SD-WAN Manager: critical flaw grants admin rights without authentication (CVE-2026-76504, CVSS 9.8)
A patch is available, but there is no workaround.
Source: Cisco Security Advisory · SANS ICS Critical Control: CC2 – Defensible Architecture

3. MikroTik RouterOS: pre-auth RCE in the web management
Update RouterOS to the fixed version listed in the advisory.
Source: CISA ICS Advisory · SANS ICS Critical Control: CC5 – Risk-Based Vulnerability Management

4. Lantronix G520 LTE gateway: root code execution through an insecure firmware update chain
An attacker can inject firmware that runs with root privileges. Install the fixed firmware version listed in the advisory.
Source: CISA ICS Advisory · SANS ICS Critical Control: CC5 – Risk-Based Vulnerability Management

5. Ransomware: activity against the industrial sector remains high
Source: Industrial Cyber · SANS ICS Critical Control: CC1 – ICS Incident Response

What it means per sector

Power & grids: The biggest risk this week was remote access, meaning the edge devices used for Remote Access and for connecting sites. In our experience, municipal utilities and grid operators commonly use Citrix NetScaler and Cisco SD-WAN to connect service providers for Fernwartung (remote maintenance), as well as control centres and outstations. These devices also enforce segmentation all the way into the OT. If an attacker takes over one of them, they are standing directly in front of the grid control systems. CISA has added the Citrix zero-days to the KEV catalog. Full report (German)

Food & beverage: Many plants route the remote maintenance that machine builders provide for filling, packaging and refrigeration lines through exactly these systems. The same systems often connect plants, bottling sites, warehouses and cold stores. Patches exist for both Citrix and Cisco, but Cisco has no workaround. On top of that come flaws in MikroTik routers and Lantronix cellular gateways. Edge devices like these often sit unnoticed in outlying warehouses, cold stores, collection points and on machines. Ransomware pressure remains high. Full report (German)

Machine builders: Machine and plant builders deliver remote maintenance and connect their sites through exactly the edge devices being targeted. Besides Citrix and Cisco, three other issues matter for remote maintenance:

vulnerabilities in TeamViewer
the MikroTik RouterOS pre-auth RCE
the manipulable firmware update chain in the Lantronix G520

These components are often built into remote maintenance boxes, control cabinets and industrial PCs in plants already delivered to customers. Search your Asset-Inventar and product SBOMs, roll out the updates and tell your customers. In your own products, check that updates only run over TLS with a verified signature. Full report (German)

What to do now

Citrix NetScaler: Before you patch, back up logs and snapshots and hunt for IoCs, including the ones Citrix provides through the NetScaler Console. Then update to the fixed builds listed in the Citrix security bulletin. After patching, kill all sessions and rotate the credentials used through the gateway, especially those of remote maintenance accounts. Hunt for webshells and unexplained gaps in logging. Check which customer or OT systems were reachable through the gateway. If you find signs of compromise, check your reporting obligations under NIS2/BSIG.
Cisco SD-WAN Manager: Patch immediately and make the Manager reachable only from an admin network. Search the Manager's access logs for requests with malformed URI encoding and check the full Cisco advisory for the exact IoCs. If you get hits, start Incident Response. Then compare the SD-WAN configuration against a known-good version to spot unplanned routing changes.
Edge inventory: Use network scans to find MikroTik and Lantronix G520 devices that are missing from the Asset-Inventar. Update MikroTik and the G520 to the fixed versions from the vendor advisories, prioritising by how critical each station is. Expose management interfaces only to a dedicated management network, and install firmware only through a verified path from a trusted source.
Remote access architecture: Route Fernwartung into the OT through a central, logged Jump Host with MFA and approval per session, not directly through the gateway. Remove shadow access via LTE routers.
Incident readiness: Define and rehearse an OT Incident Response playbook for running without MES/ERP. Test restoring PLC programs, HMI projects and MES databases from offline backups at least once a quarter. In Austria, check whether the NISG 2026 applies to you and decide who submits the 24-hour early warning.

Full sector reports (German)

Max Gilg is an OT cybersecurity consultant based in Rosenheim, Germany (OT-Cyber.de).

Securing Citrix NetScaler: A Checklist for Operators, Including OT

Max Bayern — Sat, 03 Oct 2026 15:19:41 +0000

If you run Citrix NetScaler ADC or Gateway, you need to do three things now:

Install the fixed builds (14.1-73.37 or 13.1-64.23, or the corresponding FIPS/NDcPP builds).
Check the appliance for webshells and other traces of compromise.
Separate OT remote access from the corporate gateway.

This affects organizations that run vulnerable NetScaler builds. Mandiant names targeted sectors in North America and Europe. At utilities and industrial companies, NetScaler is often the path service providers use to reach control centers and plants.

What happened?

Since early September 2026, a threat actor has been exploiting two zero-days in NetScaler (CVE-2026-88771, CVE-2026-88772). Mandiant does not attribute the activity to a specific actor. Mandiant knows about the exploitation of CVE-2026-88771 only from vendor information. Mandiant describes an exploitation campaign with reconnaissance and credential theft that uses:

several PHP webshells (including WHIPSHOT)
a tunneling tool (SLAPSHOT)
persistence via handlers in httpd.conf and an SUID bit on /bin/sh
credential theft in the internal network

Citrix has released fixed builds.

My assessment: A patch closes the door, but it doesn't throw out anyone who's already inside. So check every appliance for the traces Mandiant describes, even if it is already patched.

Step 1: Patch the right way

Install the fixed builds (14.1-73.37, 13.1-64.23 or the corresponding FIPS/NDcPP builds) on every ADC and Gateway instance, including test and emergency systems.
My recommendation as general best practice: terminate all active sessions after patching. That way, sessions that may have been stolen lose their validity.
Replace older firmware branches that are out of support. Don't keep running them.

Step 2: Check for compromise

A patch does not remove webshells or backdoors. Check every appliance, even if it's already patched:

File system: Look for unknown PHP files and unexpected .deb or .sig files in the VPN directories, especially under /var/netscaler/gui/vpn/scripts/linux/ (also vista/ and mac/), /netscaler/ns_gui/vpn/media/ and /var/vpn/theme/. Mandiant has published IoCs for this.
Persistence: Check /etc/httpd.conf for unknown AddHandler or AliasMatch entries, check whether /bin/sh has the SUID bit set, and look for /tmp/.uxdport or /tmp/.uxdlock and unexpected Python processes.
Logs: Go back to early September. Watch for NSPPE crashes (ssl_handshake_failure with DTLS, pitboss messages in /var/log/messages) and check the httpaccess and httperror logs for unusual 404 responses with a large body.
Follow-on access: Check whether the NetScaler opened connections into the internal network that aren't part of normal operations.

If you find something, don't just rebuild the appliance. Preserve evidence first, then start incident response and rotate every credential that went through the gateway.

Step 3: Protect your OT

At utilities, municipal utilities (Stadtwerke) and machine builders, NetScaler often fronts more than office IT. Remote maintenance, the control center and service providers' access also run through it. That means:

Secure Remote Access (SANS CC4): Never route OT remote access straight through the corporate gateway. Use a dedicated jump host with MFA and per-session approval.
Defensible Architecture (SANS CC2): Put a firewall with clear rules between IT and OT. A compromised gateway must not be able to reach the control systems.
Network Visibility & Monitoring (SANS CC3): Monitor connections from IT into OT networks. That's where lateral movement shows up first.

If you also use your NetScaler gateway for OT, you've turned an IT problem into a plant problem.

What this means for NIS2 and critical infrastructure (KRITIS)

If you fall under NIS2 and find a compromise, you have reporting obligations with short deadlines. So document the check itself carefully: what you checked, when, and what you found.

Quick checklist

[ ] Fixed builds (14.1-73.37 / 13.1-64.23 or FIPS/NDcPP builds) installed on all ADC/Gateway instances, including test and emergency systems
[ ] All active sessions terminated after patching (best practice)
[ ] Unsupported firmware branches replaced
[ ] VPN directories (/var/netscaler/gui/vpn/scripts/, /netscaler/ns_gui/vpn/media/, /var/vpn/theme/) checked against Mandiant IoCs
[ ] /etc/httpd.conf, SUID bit on /bin/sh, /tmp/.uxd* files and Python processes checked
[ ] Logs reviewed back to early September (NSPPE crashes, httpaccess/httperror, 404 responses with a large body)
[ ] Unexpected outbound connections into the internal network checked
[ ] OT remote access separated from the corporate gateway (jump host, MFA, per-session approval)
[ ] All checks documented for NIS2

Further resources

Live incident tracker (German): Vorfall-Lagebild
Securing remote maintenance for the long term: OT security consulting

Original (German): https://ot-cyber.de/blog/netscaler-absichern-checkliste-fuer-betreiber-in-dach.html

Max Gilg is an OT cybersecurity consultant based in Rosenheim, Germany (OT-Cyber.de).

Monta EV charging flaws: chargers can be impersonated (CVSS 9.4)

Max Bayern — Sat, 03 Oct 2026 07:46:36 +0000

TL;DR: CISA advisory ICSA-26-274-02 (October 1, 2026) lists four vulnerabilities in all versions of the Monta EV charging platform (monta.app), the worst rated CVSS 9.4. The OCPP WebSocket endpoints do not authenticate charging stations, and station IDs are publicly visible. Anyone operating chargers through Monta should enable OCPP 1.6 Security Profile 2 (Basic Auth over TLS) with a unique password per station as soon as possible.

What CISA published

CVE	Weakness	CVSS v3.1
CVE-2026-95102	Missing authentication on OCPP WebSocket endpoints (CWE-306) – attackers can impersonate a charging station	9.4
CVE-2026-97363	No limit on authentication requests (CWE-307) – brute force and denial of service	7.5
CVE-2026-97212	Multiple endpoints can connect with the same session ID (CWE-613) – may allow authenticating as other users	7.3
CVE-2026-93474	Insufficiently protected credentials – charging station identifiers are publicly accessible via web-based mapping platforms	see advisory

CISA lists the Energy and Transportation Systems sectors and worldwide deployment.

Why this is easy to abuse

A charger opens a WebSocket to the backend and identifies itself with its station ID. Without authentication, that ID is the only "secret" – and according to the advisory it is visible on public charging maps. In my assessment, an attacker could potentially connect as that charger with nothing more than a WebSocket client and perform unauthorized actions – and because authentication attempts are not limited, this could also enable denial of service.

Not a one-off

My take: this is likely an industry pattern rather than a one-off. OCPP has had security profiles for years – they just have to be switched on. Charging infrastructure is OT and deserves the same discipline as a substation.

Practical checklist for operators

Mapped to the SANS Five ICS Cybersecurity Critical Controls:

Enable Security Profile 2 (CC4 Secure Remote Access): TLS with server certificate plus Basic Auth for every station, with a long, unique password unrelated to the station ID. Monta states in the advisory that it supports this.
Close unauthenticated access (CC2 Defensible Architecture): Once all chargers are migrated, work with Monta to block unauthenticated connections for your stations. Monta says it will phase them out on a rolling basis – don't wait.
Inventory and firmware (CC5 Risk-Based Vulnerability Management): Which charger talks to which backend, on which firmware? Does the firmware support Profile 2 at all?
Monitor the charging operation (CC3 Network Visibility & Monitoring): Duplicate logins for the same station ID, connection drops and implausible meter values are red flags.
Plan the incident (CC1 ICS Incident Response): Who shuts what down if chargers fail at scale or report false data? Who informs customers and authorities?

Mid-term, move to Security Profile 3 (mutual TLS with client certificates) or OCPP 2.0.1.

Regulatory angle (EU)

Recharging point operators are explicitly listed in Annex I (energy sector) of the NIS2 directive. Whether a specific operator is in scope depends on national law and size thresholds.

Original (German, with regional context for Bavaria, Salzburg and Tyrol): Monta-Lücken: Ladesäulen übernehmbar – was Betreiber tun

Weekly OT threat picture for DACH by sector: ot-cyber.de/berichte · Help with OT vulnerability management: OT-Cyber.de

Max Gilg is an OT cybersecurity consultant based in Rosenheim, Germany (OT-Cyber.de).