Two newly disclosed vulnerabilities in Rockwell Automation’s Verve Asset Manager expose plaintext secrets in retired, optional components — a wake-up call for OT teams that still run legacy modules and for Windows‑centric engineering workstations that serve as gateways into industrial networks.
Verve Asset Manager is a vendor‑neutral operational technology (OT) cybersecurity platform used for asset visibility, vulnerability management, and automated security operations across industrial control systems. Rockwell Automation published a security advisory on January 20, 2026 that documents two related vulnerabilities that result in unencrypted sensitive information being stored in legacy components of Verve: the ADI server and an Ansible playbook runner. CVE‑2025‑14376 concerns the legacy ADI server component where sensitive secrets were stored in environment variables in cleartext. CVE‑2025‑14377 concerns a legacy Ansible playbook component that incorrectly stored secrets as plaintext during playbook execution. Both components were retired and made optional beginning with Verve 1.36 (2024), and Rockwell reports the issues were removed or corrected in Verve 1.42. These flaws are not theoretical footnotes. They create an immediate confidentiality risk in environments where the affected components are still present or where playbooks were run without secure secret management — a realistic situation in many operational networks that lag IT in patch cycles and retain legacy tools for device inventory and automation tasks. Independent CVE trackers and aggregated feeds reflect the vendor’s severity assessments and mirror the advisory details.
Patching closes the door on known faults; modern secrets management, least‑privilege design, and monitoring keep the attackers from returning through the window. The convergence of IT and OT makes this work unavoidable — and urgent.
Source: CISA Rockwell Automation Verve Asset Manager | CISA
Background
Verve Asset Manager is a vendor‑neutral operational technology (OT) cybersecurity platform used for asset visibility, vulnerability management, and automated security operations across industrial control systems. Rockwell Automation published a security advisory on January 20, 2026 that documents two related vulnerabilities that result in unencrypted sensitive information being stored in legacy components of Verve: the ADI server and an Ansible playbook runner. CVE‑2025‑14376 concerns the legacy ADI server component where sensitive secrets were stored in environment variables in cleartext. CVE‑2025‑14377 concerns a legacy Ansible playbook component that incorrectly stored secrets as plaintext during playbook execution. Both components were retired and made optional beginning with Verve 1.36 (2024), and Rockwell reports the issues were removed or corrected in Verve 1.42. These flaws are not theoretical footnotes. They create an immediate confidentiality risk in environments where the affected components are still present or where playbooks were run without secure secret management — a realistic situation in many operational networks that lag IT in patch cycles and retain legacy tools for device inventory and automation tasks. Independent CVE trackers and aggregated feeds reflect the vendor’s severity assessments and mirror the advisory details. Why plaintext secrets in OT tools matter
Industrial environments blend IT and OT responsibilities. When an OT management platform stores secrets in the clear, the consequences are broader than a single web application leak.- Credential theft leads to lateral movement. An attacker who retrieves plaintext credentials from environment variables or ephemeral playbook files can escalate from a compromised engineering host into supervisory systems and controllers.
- Audit and transparency collapse. Playbooks and automation are frequently used to push configuration and firmware changes; if their execution artifacts contain secrets, investigations after an incident become more complex and unreliable.
- Physical safety and availability risk. Confidentiality failures in asset and orchestration platforms can be chained into integrity attacks (unauthorized changes) that affect production and safety systems — a major concern for critical manufacturing sectors where Verve is deployed worldwide.
Technical analysis
CVE‑2025‑14376 — legacy ADI server, environment variables (CWE‑922)
The issue in CVE‑2025‑14376 arises because the retired ADI (Agentless Device Interface) server stored sensitive secrets in environment variables without encryption or appropriate access controls. Environment variables are convenient for processes but are a poor long‑term secret store because they are often visible to any user or process with sufficient local privileges and can be captured in process dumps, logs, or misconfigured container images. Rockwell lists the affected Verve versions as 1.33 through 1.41.3 and says the ADI component is fully removed in 1.42; it was optional since 1.36. Practical exploitation model:- An adversary who already has high local privileges (or a container escape) on a host running the ADI component can read environment variables and extract secrets.
- Those secrets can include API keys, service account credentials, or other tokens that unlock downstream systems.
- The vulnerability is privilege‑dependent but yields high confidentiality and integrity impact once local access is present.
CVE‑2025‑14377 — legacy Ansible playbook runner (CWE‑312)
CVE‑2025‑14377 stems from the way Verve’s legacy Ansible playbook subsystem handled secrets while executing automation tasks. When playbooks run, they often create temporary artifacts or logging output; in this case, secrets were being written to storage in cleartext during execution, where they could be observed by local admins, other processes, or backup/monitoring systems. Rockwell reports the same affected version range and the same remediation path (removal/correction in 1.42), with the Ansible playbook functionality optional since 1.36. Why this is significant:- Ansible is widely used to push configuration changes across devices and hosts; playbooks that momentarily expose secrets can leak credentials into centralized logging, temporary directories, or into artifacts captured by forensic tools.
- Temporary plaintext exposure is often overlooked during post‑incident discovery because ephemeral files are commonly purged — which can frustrate detection and remediation.
Scope, affected versions, and remediation timeline
Rockwell’s advisory enumerates the affected Verve releases: 1.33 through 1.41.3 inclusive are listed as known affected for both CVEs. The vendor states the problematic legacy components were made optional starting with 1.36 (2024) and were fully removed or corrected in 1.42. Rockwell’s guidance is unequivocal: update to 1.42 or later to obtain the fixes. Important operational nuance:- Optional components are often left enabled in production because teams rely on their behavior; optional does not mean harmless. Operators must verify whether the ADI or Ansible components were installed and used, even on builds that permit them to be disabled.
- For environments that cannot immediately upgrade (long maintenance windows, strict change control, legacy integrations), compensating controls and mitigations must be applied until the patch can be scheduled. Federal ICS guidance and community advisories reiterate network isolation, strict access controls, and monitoring as interim measures.
Immediate remediation checklist (operational playbook)
The remediation steps below are prioritized for fast triage and containment, followed by durable fixes. These steps assume operations teams have inventories, change control, and the ability to schedule maintenance. Use them as a practical, sequential plan.- Inventory and confirm:
- Identify all Verve Asset Manager endpoints and versions in production and engineering networks.
- Confirm whether the ADI server and Ansible playbook components are installed or were executed. If you see Verve versions 1.33–1.41.3, treat them as in scope.
- Patch and upgrade (high priority):
- Schedule and deploy Verve Asset Manager 1.42 or later as the authoritative fix. Where possible, use a staged roll‑out (test → pilot → production) and validate automation and integrations in each stage.
- Disable retired/optional components:
- If upgrading is not immediately possible, disable or remove the legacy ADI and Ansible components where they are not required. Confirm removal with process and package scans.
- Rotate secrets and credentials:
- Rotate any credentials, tokens, or keys that may have been stored by the ADI server or used by playbooks. Treat credentials as potentially compromised if they were present on hosts running the affected components.
- Audit local hosts and containers:
- Search for environment variables, temporary files, and playbook artifacts on hosts and containers that ran Verve components. Look for files in /tmp, container volumes, application logs, and backup archives.
- If Docker or container images were used, inspect image layers for embedded secrets and rebuildild images without secrets baked into them.
- Harden secret handling:
- Replace plaintext storage with a secrets manager (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager, or equivalent) and adopt short‑lived credentials and token exchange patterns where supported.
- Rework automation to keep secrets in memory only and never write them to logs or temporary files.
- Apply network compensations:
- Minimize network exposure for all control system and management hosts — place Verve systems behind firewalls, isolate them from business networks, and restrict access to known management jump hosts or bastion servers.
- Monitor, hunt, and log:
- Increase monitoring for suspicious access patterns to Verve APIs, reads of environment variables, unexplained playbook executions, and unusual file access on engineering hosts.
- Collect endpoint telemetry to enable retrospective forensic analysis if needed.
- Validate and document:
- After remediation, validate that secrets are no longer stored in cleartext and that automation runs cleanly without producing temporary artifacts containing secrets.
- Update asset and configuration management records to reflect changes and to ensure future audits catch similar misconfigurations.
Practical examples and Windows‑centric notes
Many Verve deployments interact with Windows engineering workstations and servers. For Windows‑dominated operations:- Check Windows service definitions and scheduled tasks that invoke Verve agents or playbooks. Services sometimes set environment variables in the registry under HKLM\SYSTEM\CurrentControlSet\Services\<service>\Environment; verify these do not contain secrets. This registry path is a common vector for environment variable persistence on Windows hosts.
- Audit temporary directories (%TEMP%, C:\Windows\Temp, configured container bind mounts) for Ansible logs or output files created by automation runs.
- When Verve is deployed in containers on Windows Server or Linux hosts, inspect container images and bind mounts for embedded secrets. Rebuild images that include credentials and redeploy.
- Use Windows Event Forwarding, SIEM ingestion, and EDR tools to centralize logs from engineering workstations so suspicious file reads and process spawns can be correlated with network activity.
Why upgrades alone are not enough: secure design recommendations
Patching to Verve 1.42 is necessary, but architecture and process changes are required to - Secrets management discipline. Use centralized secret stores with strict access policies and auditing. Automation frameworks should fetch secrets at runtime from vaults using short‑lived tokens rather than embedding long‑lived credentials in playbooks or environment variables.- Immutable infrastructure and CI/CD. Build automation images and artifacts in CI pipelines that do not accept secrets as build arguments. Secrets must be injected at runtime, not baked into artifacts.
- Least privilege and ephemeral access. Minimize the privileges assigned to service accounts and rotate keys frequently. Where automation needs elevated access, require just‑in‑time elevation instead of permanent privilege grants.
- Assume breach and enable detection. Instrument hosts for rapid detection of unauthorized reads and credential misuse. If defenders assume a local compromise is possible, controls that limit the utility of stolen secrets (short token TTLs, multi‑factor, scoped tokens) reduce the overall impact.
Risk assessment and prioritization
Operators must triage based on exposure and impact. Consider the following prioritization matrix:- Top priority — Production systems where Verve has credentials for critical services (identity sources, patch/firmware servers, controller orchestration). Patch first, rotate all secrets, and hunt for evidence of compromise.
- High priority — Engineering workstations and jump hosts with Verve clients or where playbooks run. Remove legacy components, rotate secrets, and harden hosts.
- Medium priority — Test, staging, and lab environments. Patch and reconfigure but accept scheduled maintenance windows if operational impact is limited.
- Low priority — Isolated instances with no external network access and no secrets; still schedule remediation to remove technical debt.
Limitations and unverifiable assertions
- Public exploitation status can change rapidly. At the time of the vendor advisory and aggregated CVE entries, no known public exploitation of CVE‑2025‑14376 or CVE‑2025‑14377 had been reported; this is a snapshot and should not be interpreted as permanence. Organizations must assume adversaries will probe for exposed secrets and prioritize accordingly.
- The precise content of the secrets (which credentials, tokens, or keys may have been stored in any given deployment) depends on local configuration and usage of the ADI server and playbook automation. Identifying exactly which secrets were exposed requires host‑level audits and cannot be determined from the advisory alone. Treat all in‑scope secrets as compromised until proven otherwise.
Longer‑term operational recommendations
- Adopt a secrets‑as‑a‑service model across OT tooling, ensuring automation frameworks never persist credentials to disk.
- Implement service account governance with automated rotation and short lifetimes.
- Expand vulnerability scanning and software inventory efforts into OT networks — maintain a canonical map of where optional/legacy components are installed so optional does not mean forgotten.
- Build cross‑functional OT/IT incident response playbooks that include credential rotation and forensic steps for automation systems.
- Use container image signing and software bill‑of‑materials (SBOM) practices to make it harder for outdated or vulnerable components to persist in production.
Conclusion
The Verve Asset Manager plaintext‑storage disclosures (CVE‑2025‑14376 and CVE‑2025‑14377) are a reminder that automation frameworks and OT management tools must treat secrets as high‑value assets. Rockwell’s corrective release, Verve 1.42, removes the offending legacy components and should be deployed as the definitive fix, but every affected organization must also perform host‑level audits, rotate credentials, and harden automation pipelines to prevent similar issues from reappearing.Patching closes the door on known faults; modern secrets management, least‑privilege design, and monitoring keep the attackers from returning through the window. The convergence of IT and OT makes this work unavoidable — and urgent.
Source: CISA Rockwell Automation Verve Asset Manager | CISA
