CVE-2026-27546: Pepperl+Fuchs ICE Authentication Bypass
Critical CVSS (9.8) reachable over network.
TL;DR - CVE-2026-27546 is a CVSS 9.8 authentication bypass affecting Pepperl+Fuchs ICE2-* and ICE3-* devices. - Unauthenticated remote attackers may obtain administrative access through the
_account_logfunction. - No confirmed exploitation or verified public PoC was identified in the reviewed sources. - Restrict management exposure, identify affected firmware, and obtain vendor remediation guidance immediately.
Vulnerability at a Glance
| Field | Details |
|---|---|
| CVE ID | CVE-2026-27546 |
| Severity | Critical |
| CVSS base score | 9.8 |
| CVSS vector | Not provided in the reviewed NVD result |
| Attack vector | Remote, according to the NVD description |
| Authentication required | None |
| Privileges required | None stated; the flaw permits unauthenticated access |
| Affected products | Pepperl+Fuchs ICE2-* and ICE3-* device families |
| Affected versions | Exact firmware range not identified in the reviewed sources |
| Patch available | Not confirmed |
| Fixed version | Not identified in the reviewed sources |
| CISA KEV status | Not listed at the time of lookup |
| Exploitation status | No verified in-the-wild exploitation identified |
| Public PoC | No verified public proof of concept located |
CVE-2026-27546 was published on September 16, 2026. The available NVD description identifies an authentication bypass in the _account_log function. An unauthenticated remote attacker can reportedly use the condition to log in as an administrator even when accounts are correctly configured.
The immediate operational concern is exposure. Industrial devices may have management interfaces reachable from engineering networks, remote-access systems, or poorly segmented operational technology environments. If an ICE2 or ICE3 device is reachable from an untrusted network, treat it as a high-priority asset until its firmware status and exposure are verified.
For background on identifying and prioritizing security telemetry, see our detection engineering glossary.
Analyst’s Take: Start with reachability and inventory rather than waiting for exploit evidence. The reviewed sources do not identify a fixed firmware version, but they do describe unauthenticated administrative access, making exposed management interfaces the first containment priority.
What Is This Vulnerability?
The reported root cause is an authentication-bypass condition in the device’s _account_log function. The function appears to participate in account or login processing, and the vulnerability allows a request from an unauthenticated remote attacker to be handled as a valid administrative login. The available sources do not provide enough implementation detail to identify the exact input, state-transition error, or request sequence involved.
This distinction matters for incident response. The issue is not described as a weak default password or a failure to enforce a particular password policy. Properly configured accounts can still be bypassed. Administrators should not rely on password rotation alone as a compensating control; network reachability, firmware remediation, and review of administrative activity are more directly relevant.
Successful exploitation could provide administrative control over device settings. Depending on the device’s role and connected environment, an attacker may be able to alter configuration, disrupt communications, change operational parameters, create or modify accounts, or use the device as a foothold for further activity.
The broader CERT@VDE advisory also discusses multiple vulnerabilities affecting the product families, including issues described as potentially enabling code execution. However, the available material does not establish that CVE-2026-27546 itself provides code execution.
Technical Notes
The vulnerable function named in the available description is:
_account_log
The NVD description characterizes the condition as follows:
An unauthenticated remote attacker can exploit an authentication bypass
in the _account_log function to log in as an admin, even when accounts are
properly configured.
No safe, complete exploit sequence or protocol-level technical specification was available in the reviewed sources. Defenders should not infer that the absence of published exploit mechanics reduces the risk of an Internet-exposed management interface.
Who Is Affected?
The affected product families identified by CERT@VDE advisory VDE-2026-014 are:
- Pepperl+Fuchs ICE2-*
- Pepperl+Fuchs ICE3-*
The wildcard notation identifies product families rather than a complete firmware inventory. The reviewed NVD and CERT@VDE content did not expose a definitive table of affected device models, firmware builds, or release branches. Consequently, it is not possible to responsibly state that every device carrying an ICE2 or ICE3 designation is affected, nor can a specific minimum vulnerable firmware version be quoted.
Organizations should inventory exact model numbers and installed firmware versions for every ICE2-* and ICE3-* device. Include devices in production, laboratories, staging environments, maintenance inventories, and remote sites. Collect firmware versions from the device interface, authorized management tooling, or vendor-supported inventory processes rather than inferring them from the product family name.
No fixed firmware version was identified in the reviewed sources. Treat that absence as an information gap, not evidence that no update exists. Contact Pepperl+Fuchs or an authorized support channel with the exact model and firmware information, and request the security remediation matrix for CVE-2026-27546.
Technical Notes
A useful inventory record should include at least:
site
asset owner
device model
serial number
installed firmware version
management IP or hostname
reachable networks
internet exposure
remote-access path
last administrative login
vendor remediation status
Prioritize any device whose management interface is reachable from the public Internet, a shared enterprise network, a vendor remote-access path, or an OT segment with broad workstation access.
CVSS Score Breakdown
CVE-2026-27546 has a reported CVSS base score of 9.8, classified as Critical. The reviewed NVD result did not provide the complete CVSS vector string. The individual metric values should not be presented as confirmed facts.
The score is consistent with a vulnerability that can be exploited remotely without authentication and without prior privileges, with potentially significant impact to confidentiality, integrity, and availability. The reported behavior supports the conclusion that attack complexity may be low, but the exact CVSS metric assignment cannot be independently reconstructed from the supplied record.
For risk decisions, combine the score with deployment context. A device isolated behind strong segmentation and reachable only through a controlled jump host presents a different practical exposure than an identical device with a public management address.
The lack of a CISA KEV listing does not neutralize the severity of an unauthenticated administrative-access flaw. Organizations should also review their broader industrial control systems security procedures when assessing exposure and remediation priority.
Technical Notes
The confirmed scoring information is limited to:
CVSS base score: 9.8
Severity: Critical
CVSS vector: Not provided in the reviewed NVD result
Do not populate vulnerability-management records with an assumed vector. Preserve the score while marking the vector as unavailable, and update the record when the vendor or NVD publishes the complete metric string.
Exploitation Status
No confirmed in-the-wild exploitation was identified in the reviewed primary-source material. CVE-2026-27546 was not listed in the CISA Known Exploited Vulnerabilities catalog at the time of lookup. As a result, there is no CISA date-added value, due date, required action, or ransomware-campaign designation for this CVE in the available data.
No verified public proof-of-concept repository or exploit publication was located through the searches performed. This status is not proof that no exploit exists privately or outside the sources reviewed. It means defenders should describe the public evidence accurately: exploitation is not confirmed, and a verified public PoC was not found.
The absence of known exploitation should not justify delaying containment. Industrial device vulnerabilities can be exploited opportunistically once exposed assets are identified, and authentication bypasses are particularly valuable because they remove the need to obtain or guess credentials.
Technical Notes
Track exploitation status using explicit evidence categories:
CISA KEV: not listed at time of lookup
Confirmed in-the-wild exploitation: none identified in reviewed sources
Verified public PoC: none identified in searches performed
Vendor advisory evidence of exploitation: not identified in retrieved content
Recheck CISA KEV, vendor advisories, relevant threat-intelligence feeds, and internal telemetry during the remediation window. A future KEV listing or credible exploit publication should trigger accelerated response and emergency change procedures.
Prioritize Secure Remote Access
If administrators or vendors need remote access to ICE2 or ICE3 management interfaces, route that access through a controlled jump host or zero-trust access workflow. Avoid exposing device interfaces directly to the Internet or placing them behind broad, shared VPN access.
Review user identity, device posture, session logging, least-privilege permissions, and time-limited vendor access. Remote-access controls reduce exposure but do not replace firmware remediation or investigation of prior administrative activity.
How to Detect CVE-2026-27546
Detection should begin with exposure discovery. Identify ICE2-* and ICE3-* devices in network scans, asset-management systems, firewall objects, passive OT monitoring, and vendor management platforms. Do not scan sensitive control networks aggressively without an approved safety and change-management process.
The most valuable host-level signal is an unexpected successful administrative login, especially one originating from a user workstation, remote-access concentrator, Internet address, or network that normally has no administrative relationship with the device. Review subsequent configuration changes, account modifications, firmware operations, and unusual outbound connections.
Because the reviewed material does not provide a protocol-specific request signature, defenders should not claim a reliable network IDS signature for the vulnerability itself. Detection engineering should instead focus on authentication and management activity, while coordinating with Pepperl+Fuchs or a monitoring vendor for product-specific telemetry.
Technical Notes
If device logs are forwarded to a SIEM, begin with a generic query that can be adapted to the product’s actual field names:
index=ot OR index=network
("ICE2" OR "ICE3" OR "Pepperl+Fuchs")
("login" OR "authentication" OR "admin" OR "account")
| search action IN ("success", "accepted", "authenticated")
| stats count min(_time) as first_seen max(_time) as last_seen
by src_ip, dest_ip, user, action
| sort - count
For environments using a normalized authentication schema:
DeviceLogonEvents
| where Timestamp > ago(30d)
| where DeviceName has_any ("ICE2", "ICE3")
| where AccountName =~ "admin" or LogonType has "Remote"
| summarize Attempts=count(), FirstSeen=min(Timestamp), LastSeen=max(Timestamp)
by DeviceName, RemoteIP, AccountName, ActionType
| order by LastSeen desc
These queries are starting points, not vendor-confirmed signatures. Adapt them to the device’s actual log format. Investigate successful administrative access from unusual sources, repeated failures followed by success, logins outside maintenance windows, newly created accounts, and configuration changes immediately after authentication.
Mitigation and Patching
The exact affected firmware range and fixed version were not identified in the reviewed NVD and CERT@VDE material. No responsible fixed version number can be quoted. Obtain the applicable firmware or security update directly from Pepperl+Fuchs or its authorized support channel using the exact ICE2 or ICE3 model and installed firmware version.
Until the vendor confirms the remediation path, remove management interfaces from the public Internet. Restrict access through firewalls, OT segmentation, VPNs, and allowlists containing only approved administrative hosts. Do not assume that a password change addresses the vulnerability, because the reported condition bypasses authentication even when accounts are properly configured.
If a device was exposed to an untrusted network, review logs before and after containment. Look for unexpected successful administrative logins, account changes, configuration modifications, firmware changes, and unusual communications. Preserve relevant logs and configuration snapshots. If compromise is suspected, follow the organization’s OT incident-response process and coordinate recovery with the asset owner and vendor.
Technical Notes
Because a fixed version was not confirmed, do not automate an invented firmware target. Use a vendor-provided package and documented upgrade procedure. A generic maintenance workflow is:
1. Record the exact device model, serial number, current firmware, and configuration.
2. Obtain the vendor-approved firmware package for that exact model.
3. Validate the package through the vendor’s documented integrity-check process.
4. Back up configuration using the supported device procedure.
5. Place the device in an approved maintenance state.
6. Apply the firmware update according to Pepperl+Fuchs instructions.
7. Confirm the resulting firmware version and management configuration.
8. Test required operational functions with the system owner.
9. Review administrative and network logs after the upgrade.
Where no update is yet available, implement compensating controls at the network layer. For example, a firewall policy should allow management only from approved administration hosts:
deny source any destination <ICE_DEVICE_SUBNET> management-services
allow source <OT_ADMIN_JUMP_HOST> destination <ICE_DEVICE_SUBNET> management-services
allow source <VENDOR_VPN_POOL> destination <ICE_DEVICE_SUBNET> management-services
deny source any destination <ICE_DEVICE_SUBNET> management-services
Replace the placeholders with the device’s actual management services and approved network ranges. Avoid relying on a generic port list because the affected service and protocol were not specified in the reviewed sources.
References
- CERT@VDE VDE-2026-014: Pepperl+Fuchs ICE2-* and ICE3-* are affected by multiple security vulnerabilities
- CERT@VDE VDE-2026-027
- CERT@VDE VDE-2026-028
- NIST National Vulnerability Database
- CISA Known Exploited Vulnerabilities Catalog
The available evidence supports the CVE identifier, CVSS score, authentication-bypass description, vulnerable function name, affected product families, and unauthenticated remote attack condition. Exact affected firmware ranges, a fixed version, the CVSS vector, confirmed exploitation, and a public PoC remain unconfirmed in the reviewed sources.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.