AVEVA’s PI to CONNECT Agent Spills Proxy Credentials into Windows Event Logs

On March 14, 2026, AVEVA and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) issued a coordinated advisory warning that the PI to CONNECT Agent can leak proxy connection details — including full URLs and occasionally plaintext usernames and passwords — directly into Windows event logs. The flaw, tracked in AVEVA bulletin AVEVA-2026-003 and CISA advisory ICSA-26-041-04, means any user with membership in the built-in Event Log Readers group (S-1-5-32-573) can harvest these secrets without elevated privileges. For industrial and OT environments where the agent runs on engineering workstations, jump hosts, and servers, this represents an immediate credential exposure incident.

What Actually Changed: The Vulnerability, Fixed Build, and Exposure Mechanics

The vulnerability resides in how the PI to CONNECT Agent logs proxy configuration and connection attempts. Under certain configurations — specifically when a proxy is configured using a URL that contains an embedded username and password, such as https://user:[email protected]:3128/ — the agent writes the complete URL into its dedicated event log channel. Even when credentials are not embedded in the URL, the proxy endpoint and port are still exposed.

The affected component is the PI to CONNECT Agent, a connector that links AVEVA PI System data to the CONNECT cloud data services platform. Versions prior to v2.5.2790 are vulnerable. AVEVA has released a fixed build — PI to CONNECT Agent v2.5.2790 or later — that stops writing proxy details to newly generated event logs. The fix is available through the CONNECT Data Services Portal. Organizations that have used older versions must not only patch but also treat all existing logs (live, backed up, and archived) as potentially compromised.

Windows event logs are designed to be broadly readable by default. The Event Log Readers group is granted read access to facilitate remote monitoring and SIEM collection. This means an attacker who compromises a low-privileged account in that group — or simply tricks a helpdesk user — can read the logs and extract proxy credentials without needing administrator rights. Because logs are also forwarded to SIEMs, long-term archives, and backups, the exposure can propagate silently across an organization’s data stores.

What It Means for You: Audience-Specific Impact

For OT/ICS Engineers and Administrators

You are on the front line. The PI to CONNECT Agent is typically deployed on engineering workstations, plant historians, and jump servers that bridge IT and OT networks. These hosts often hold project files, network maps, and credentials to multiple systems. A leaked proxy password could allow an attacker to pivot through your proxy into internal networks, cloud services, or even industrial control systems. The urgency is acute: every host running an affected agent must be inventoried, patched, and its logs scrubbed. If you cannot patch immediately due to operational constraints, you must restrict outbound network access from those hosts and harden log access.

For Security Operations and Incident Response Teams

Your SIEM may already be ingesting these logs. You need to run immediate hunts for proxy URL patterns across aggregated log stores. Look for strings like ://, proxy, @, and colons within URL-like strings. Any hits must be preserved in an encrypted forensic repository, then purged or redacted from production systems. Simultaneously, force a credential rotation for any proxy accounts that appear in logs — assume they are compromised. Integrate this incident into your runbooks as a case study for log hygiene and secrets management.

For IT Managers and System Architects

The incident underscores a systemic weakness: applications that log secrets. Review your entire application portfolio for similar patterns. If any software writes connection strings, passwords, or tokens into Windows event logs, demand that the vendor apply log sanitization. In the short term, audit membership of the Event Log Readers group on every host — especially those running engineering software. Remove all non-essential accounts and consider implementing Just-In-Time (JIT) access for log reviews.

PI to CONNECT Agent is part of AVEVA’s strategy to bridge on-premises PI System data with cloud analytics. To traverse corporate networks, the agent often uses an HTTP proxy. Proxy configuration in Windows-based services is notoriously tricky; administrators sometimes resort to embedding credentials directly in the proxy URL to bypass authentication dialogs. This practice, while convenient, creates a ticking time bomb if the URL ever appears in diagnostic output.

The incident is not unique. Similar issues have plagued other industrial and enterprise applications where developers log the full request context without sanitizing secrets. Microsoft’s own guidance for event logging explicitly warns against including sensitive data, but enforcement is left to application developers. In OT environments, logging is often minimal and unmonitored, so when secrets do leak, they can persist in archives for years, easily overlooked.

AVEVA’s coordinated disclosure with CISA reflects growing maturity in industrial security. The advisory provides clear remediation steps, but the burden falls on operators to execute them in environments where downtime must be scheduled weeks in advance.

What to Do Now: A Phased Action Plan

Immediate Triage (0–24 Hours)

Inventory exposed hosts. Use your asset management or configuration management database to list every system with the PI to CONNECT Agent installed. If you lack that, scan for the agent’s service name or installation path.
Lock down the Event Log Readers group. On each host, review the local group membership. Remove all accounts except those strictly required for centralized logging or security monitoring. Audit for any unexpected additions.
Begin log hunting. Query your SIEM for proxy-related strings. Search local event logs with PowerShell: Get-WinEvent -LogName "PI to CONNECT" | Where-Object { $_.Message -match '://|@' } (adjust the log name as needed). Export matches to a secure location.

Short-Term Response (24–72 Hours)

Purge or redact compromised logs. After preserving forensic copies in an encrypted, access-controlled store, delete or sanitize the sensitive entries from production logs. If purging is not feasible, apply strict ACLs and isolate the log files.
Rotate all proxy credentials. Generate new passwords for any proxy account whose credentials may have been logged. Update the agent configuration to use the new credentials, preferably via a managed service account or secrets vault, not an inline URL.
Deploy the vendor fix. Test PI to CONNECT Agent v2.5.2790 in a sandbox, then roll out according to your change control process. Prioritize hosts that are network-exposed or accessed by third parties.

Medium-Term Hardening (1–6 Weeks)

Eliminate inline credentials. Reconfigure all applications that use proxy URLs with embedded passwords. Switch to Windows Integrated Authentication, group-managed service accounts (gMSA), or a centralized secrets management platform like HashiCorp Vault or Azure Key Vault.
Enforce log sanitization. Work with AVEVA and other vendors to ensure future agent versions redact secrets before logging. Implement log filtering in your SIEM pipeline to mask sensitive patterns.
Review backup and archive security. Ensure that backups containing event logs are encrypted and access-controlled. Include log files in incident response scoping.

Ongoing Vigilance

Maintain a vulnerability cross-reference workflow. Do not rely solely on CVE feeds; monitor vendor-specific bulletins and CISA advisories for ICS components.
Exercise incident response playbooks. Incorporate scenarios where credentials leak via logs. Train teams on forensic preservation and log redaction.
Demand better from vendors. During procurement and renewal conversations, ask how the software handles secrets in diagnostic messages. Favor products with built-in log masking.

Outlook: The Path Forward

AVEVA’s patch addresses the immediate leak, but the root cause is cultural: developers too often treat logs as a debugging convenience without considering the sensitivity of the data they emit. Industrial software, in particular, lags behind enterprise IT in secure logging practices. We can expect more coordinated advisories of this kind as researchers and vendors probe the boundary between operational diagnostics and information security.

Operators should use this incident to push for a broader review of logging hygiene across their OT software portfolio. In the long run, secrets management and log sanitization must become standard features, not afterthoughts. Until then, treat your event logs with the same suspicion as you would a plaintext credential file — because, in cases like this, they are.

AVEVA’s PI to CONNECT Agent Spills Proxy Credentials into Windows Event Logs — Here’s How to Respond