Executive Summary
CVE-2026-0311 is a server-side request forgery flaw in Palo Alto Networks Checkov by Prisma Cloud that allows a local unauthenticated user to coerce the host into issuing network requests to internal services. In OT environments where Checkov runs inside infrastructure-as-code validation pipelines, this converts a build or scan host into a relay for reaching segmented engineering and management networks.
Technical Exposure Breakdown
Checkov is a static analysis tool for infrastructure-as-code. It parses Terraform, CloudFormation, Kubernetes manifests, and similar artifacts and checks them against policy. The grounding data describes a server-side request forgery condition reachable by a local unauthenticated user that causes the host to make unauthorized network requests from the host to internal services.
The important detail is the actor model. A local unauthenticated user implies that triggering the condition does not require credentials to the Checkov service itself. In practice this fits the way the tool is run. Checkov consumes untrusted input files. If a crafted policy file, module reference, or external resource definition can direct the scanner to resolve or fetch a URL under attacker influence, the scanning host becomes the request origin. The host then speaks to internal services using whatever network position the scanner occupies.
No CVSS score is present in the grounding data, and patch status is listed as unknown. Do not wait on a severity number to scope this. The risk is a function of where the scanner sits on your network, not of a published metric.
The standard SSRF targets apply: cloud metadata endpoints, internal web consoles, management interfaces, and any service that trusts requests based on source address rather than authentication. In an OT context the higher value targets are historians, engineering workstations exposing web services, HMI gateways, and the management planes of network and security appliances.
OT Impact and Compliance Risk
Infrastructure-as-code scanning tools are increasingly embedded in OT change management, particularly for operators building out virtualized SCADA, cloud-connected historians, and containerized edge workloads. Those pipelines often run on hosts that straddle corporate IT and the OT DMZ, which is exactly the network position that makes SSRF dangerous. A build host that can both ingest external code and reach internal OT management services is a pivot point.
The physical consequence is indirect but real. SSRF does not directly command a controller. It gives an attacker reachability to the services that configure and monitor controllers. Enumeration of internal management interfaces, extraction of configuration data, or manipulation of services that trust intra-zone requests can degrade the integrity of the control environment.
Compliance exposure: this is a software supply chain and segmentation problem. IEC 62443 zone and conduit requirements are undermined when a scanning host can reach across conduits using forged requests. NERC CIP-005 and CIP-007 obligations around electronic security perimeters and ports and services are implicated if the scanner host sits inside or adjacent to a defined perimeter. For pipeline operators, TSA SD-02C expectations around network segmentation and access control cover exactly the lateral reachability this flaw enables. For water and wastewater utilities under AWIA 2018, the same segmentation and risk assessment logic applies to any tooling bridging business and process networks.
Compensating Controls
Treat the scanning host as a semi-trusted node and restrict what it can reach. Do not rely only on a vendor fix whose status is currently unknown.
- Enforce egress filtering on the host running Checkov. Deny access from that host to cloud metadata endpoints and to internal OT management services by default. Permit only the specific registries and repositories the scanner legitimately needs.
- Run the scanner in an isolated network segment or ephemeral container with no route into the OT DMZ or process networks. The build host should not be able to speak to a historian or engineering workstation at all.
- Treat all input files to the scanner as untrusted. Review and constrain module sources and external references rather than allowing arbitrary remote resolution.
- Virtual patch concept: deploy a monitoring rule to alert on outbound HTTP requests from the scanner host toward RFC 1918 management ranges and known metadata IP addresses, flagging unexpected destinations originating from the scanner process context.
- Do not run active scanners against production OT assets. Active probing of industrial components can brick them. Keep validation tooling confined to engineering and test environments with no path to live control systems.
BreachSpider tracks exploitation signals and patch availability for CVE-2026-0311 and related OT supply chain exposures, with continuous monitoring available through Intel by BreachSpider.