Active exploitation and ICS flaws raise operational risk concerns

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Cyble's report: Active exploitation of about 20 vulnerabilities and 54 ICS flaws shows that internet-facing web platforms, AI workflow tools and industrial devices are being targeted at the same time.

Why it matters: IAM, NHI and OT teams need the same lesson from this reporting: weak credentials, exposed services and poor segmentation let routine exploitation become cross-domain operational risk.

Context

Weekly vulnerability reporting is most useful when it separates exploit activity from advisory volume, because those two signals drive different response priorities. Cyble’s sensor data points to active probing of exposed services, while CISA’s industrial advisories show where industrial software and firmware still carry severe weaknesses. That combination matters because patch planning, access hardening and segmentation cannot be treated as separate workstreams.

The identity angle appears in the credential and access patterns behind the exploitation. Default passwords, hardcoded keys, unauthenticated endpoints and exposed administrative interfaces all turn systems into reachable targets. In operational environments, that means machine and human access controls need to be considered together, not as isolated governance layers.

Key questions

Q: How do active exploits change vulnerability prioritisation?

A: Active exploitation should move a vulnerability to the front of the queue even when its score is lower than other issues. Practitioners should combine severity with exploitability, external exposure and asset criticality, then remediate the vulnerabilities that are already being scanned or weaponised first. That approach reduces the chance that a known issue becomes an incident while it is still in the backlog.

Q: Why do hardcoded credentials create more risk than many teams expect?

A: Hardcoded credentials create risk because they are easy to copy, hard to inventory, and often survive long after the system that used them changes. Once embedded in code or scripts, they can be reused outside intended scope and are difficult to revoke everywhere at once. That makes the real problem lifecycle persistence, not just initial exposure.

Q: How do teams secure internet-exposed industrial controllers?

A: Teams secure internet-exposed industrial controllers by removing direct exposure where possible, placing them behind VPNs, jump hosts or industrial DMZs, and restricting management to allowlisted source addresses. They should disable default credentials, require strong authentication for remote access, segment OT and IT networks, log administrative sessions, and keep firmware, firmware settings and engineering workstations under strict change control.

Q: What is the best way to stop brute-force attacks on remote services?

A: Use MFA, rate limiting, account lockout, IP reputation controls and logging on the remote authentication surface. Limit password-based access where possible, prefer key or certificate-based authentication, and disable exposed management ports for SSH, VPN and RDP. Brute-force attacks rely on repeated guesses, so throttling and strong authentication reduce their success and detection time.

Technical breakdown

Why exposed services draw fast exploitation

Internet-facing services are usually the first place attackers test newly disclosed flaws because they can be reached at scale and validated quickly. When a vulnerability allows unauthenticated access, command execution or SQL injection, the barrier to exploitation is low and scanning traffic rises fast. The report also shows that old bugs remain attractive because they are predictable, widely deployed and often left unpatched in embedded or edge systems. The security problem is not only the flaw itself, but the fact that exposed services make it immediately reachable from the internet. See the Vulnerability Management Guide.

Practical implication: Reduce attackable surface first by inventorying exposed services and removing unnecessary external access before remediation windows stretch out.

How credential exposure turns into administrative access

Hardcoded credentials, default passwords and leaked API keys collapse authentication because the attacker does not need to break the control, only reuse it. Once credentials are accepted by a target service, the attacker can move from probing to administrative actions, including cluster access, report extraction or token theft. This is especially damaging when secrets are embedded in workflows, plugins or sensor data because the credential boundary is no longer tied to a known owner or lifecycle.

Practical implication: Treat exposed credentials as an access incident, not a configuration issue, and revoke or rotate them as soon as they are discovered.

Why OT firmware integrity failures create multi-stage risk

Industrial gateways, cameras and terminal systems often sit in environments where physical inspection is hard and firmware trust is assumed rather than verified. A signature verification flaw or similar integrity failure means an attacker can tamper with device software without obvious local signs. Once that happens, the path from initial compromise to persistent control becomes easier because the device itself may now trust altered code, malicious updates or unauthorized functions. That is why firmware integrity is not a niche concern; it is a prerequisite for trustworthy field-device operation. See the OT and ICS Identity and Access Guide.

Practical implication: Verify firmware signatures and isolate remote field devices so that a single compromised gateway cannot become a durable control point.

Threat narrative

Attacker objective: The attacker wants reliable remote control, data access or operational disruption with the least possible effort from exposed systems and reused credentials.

1. Entry occurs through exposed internet-facing services, batch endpoints, weak authentication or vulnerable plugins that can be reached without local access.
2. Credential access follows when hardcoded keys, default passwords or exposed API tokens are extracted from reports, files or management interfaces.
3. Escalation and lateral movement happen when attackers reuse those credentials or exploit administrative flaws to gain broader control of application, workflow or industrial systems.
4. Impact is theft, unauthorized command execution, service disruption or persistent control of enterprise and OT assets.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Exploitability now outranks severity in operational decision-making. A critical rating matters, but active exploitation matters more when teams are triaging limited remediation capacity. The Cyble data shows how quickly newly disclosed flaws are targeted, while older embedded-device bugs keep generating traffic because they remain reachable and reliable. Practitioners should treat exploitability and exposure as the first sorting filter, not just the CVSS score.

Credential reuse is the hidden bridge between enterprise IT and OT risk. The report ties brute-force attacks, default passwords and exposed API keys to systems ranging from cloud workflow tools to industrial gateways. That means identity governance cannot stop at user accounts: machine credentials, firmware trust and remote access paths need the same ownership and lifecycle discipline. Agent frameworks guide is relevant here because workflow platforms now behave like credential-bearing systems, not just applications.

Firmware integrity failure is an access-control problem in disguise. When a device accepts unauthorized firmware or trusts a bad signature, the attacker is no longer fighting a network perimeter alone. They are inheriting the device’s authority over sensors, gateways or process data. That is why industrial control governance has to include code trust, remote update validation and segmentation as part of a single control story, not as separate tasks.

Legacy exposure keeps turning yesterday’s bugs into today’s incident paths. The mix of years-old router and TCP/IP stack flaws with newer web and AI platform issues shows that attack calendars are layered, not sequential. Old vulnerabilities do not disappear when new ones arrive; they stay in rotation wherever patching, ownership or device visibility is weak. The practical conclusion is to govern exposure by asset class and reachability, not by disclosure date alone.

What this signals

Exposure management is becoming a control strategy, not a reporting exercise. When active exploitation and legacy device weaknesses appear in the same weekly view, teams need a way to rank what is reachable, what is credentialed and what can actually be used for pivoting. The practical shift is to treat exposure as a live governance problem, not a periodic scan result.

Credential-bearing workflows deserve the same governance as privileged accounts. Workflow platforms, plugins and automation services now carry secrets, tokens and administrative access that attackers can harvest if the surrounding controls are weak. That means security teams should manage them as operational identities, with ownership, isolation and revocation tied to the services that use them.

ICS programmes need compensating controls when patches are absent or delayed. The most exposed industrial products in this report show why segmentation, update validation and access restriction remain critical when vendor fixes lag. In practice, resilience depends on whether the environment can absorb a vulnerable device without allowing it to become a foothold.

For practitioners

• Patch active-exploitation targets first Prioritise internet-facing WordPress, Solr, Langflow and other externally reachable services that appear in active attack traffic before lower-risk backlog items.
• Remove default and hardcoded credentials Search for default usernames, embedded secrets and hardcoded API keys in plugins, workflow platforms and device configurations, then revoke or rotate them immediately.
• Restrict exposed remote access ports Limit or block VNC, RDP, SSH, Telnet and database ports from untrusted networks, and require segmentation or jump-host access for any remaining exposure.
• Verify firmware trust before rollout Check signature validation and update integrity for cellular gateways, cameras and other field devices, especially where remote management is the only practical path.
• Segment IT, OT and management planes Separate administrative access, telemetry and process networks with firewalls and DMZs so a compromise in one zone does not become cross-environment movement.

Key takeaways

• Active exploitation and advisory volume are different signals, and the former should drive immediate remediation priorities.
• Default credentials, hardcoded keys and exposed services continue to provide attackers with low-friction entry paths across IT and OT environments.
• Where fixes are unavailable or delayed, segmentation, update validation and credential rotation become the controls that limit blast radius.

Related NHI Mgmt Group resources: Vulnerability Management Guide · Securing Agent Frameworks Guide · OT and ICS Identity and Access Guide

Key terms

• Hardcoded Credential: A secret such as a password, API key, or token embedded directly in source code rather than retrieved from a secure vault at runtime. Hardcoded credentials are one of the most common and dangerous NHI vulnerabilities.
• Default Credential: A default credential is a factory-set or preset username, password, or secret that remains unchanged after deployment. In NHI environments, it is a high-risk failure because it creates predictable access to privileged systems and often survives into production unless ownership and hardening are explicitly enforced.
• Firmware Integrity: Firmware integrity is the assurance that device code has not been changed, corrupted, or replaced by an unauthorized party. It is commonly enforced through signature checks, cryptographic hashes, and secure boot validation. Without integrity checks, devices may accept untrusted firmware and execute attacker-controlled code.
• Remote Code Execution (RCE): Remote Code Execution (RCE) is a vulnerability or exploit condition that lets an attacker run commands or code on a target system from afar. It is often the end result of input handling flaws, deserialisation bugs or unsafe file processing, so defenders prioritise patching, isolation and least privilege.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect credential lifecycle controls to broader security and resilience programmes.