Executive Summary 

In this article, we disclose our latest findings we made on Perforce protocol P4 (Helix Core) between command line client and server, and reveal how a threat actor could leverage it to conduct attacks. 

This security issue affects P4 (Helix Core)  before P4 (Helix Core) 2025.2 Patch 2, was patched and was attributed a CVSS score of 7.7 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L). See our recommendation section and the Perforce advisory for more information. 

Perforce Helix Client  

Perforce Helix Client is a version control system often used for large projects and teams that work with many files or large assets. 

While Git and SVN are great for many projects, Perforce shines in environments with massive codebases or large binary files, like game development or VFX. It handles millions of files efficiently, lets teams lock files to prevent merge conflicts on non-text assets, and supports partial checkouts so developers don’t need the entire repository locally. 

Architecture 

Perforce operates on a centralized client-server architecture model, where the command-line client (p4) communicates directly with a centralized Perforce server responsible for managing the repository, metadata, and access controls. This communication can be established through Perforce’s native protocol (default port 1666) or wrapped into HTTPS to ensure encrypted data transmission.  

Fig. 1: Basic single server architecture  

• p4 info: typically one of the first commands executed to verify server connectivity and retrieve essential information, including server version, root directory…  
• The p4 client command creates and manages workspace specifications, defining the local root directory, depot paths, and the client view mapping that determines file accessibility.
• The p4 login command establishes authenticated sessions with the server, generating temporary tickets that allow subsequent commands to execute without re-entering credentials.
• The p4 sync, add, submit, revert … commands enable developers to manage the lifecycle of files in their workspace (synchronization, modification, addition, submission, and undoing changes). 

Eventually, whenever the P4CONFIG variable is set (usually .p4config), the client automatically loads configuration variables such as P4USER, P4PORT, P4CLIENT and P4PASSWD from the designated config file discovered in the current directory or home directory. This hierarchical configuration resolution applies within the scope of P4CLIENTPATH, allowing workspace-specific configurations to override global system settings. 

Details 

The Perforce client-server communication relies on a custom binary protocol, in which each message carries a set of parameters and a handler name designating the operation to be executed by the receiver. Multiple messages can be chained within a single exchange. 

Fig. 2: Extract from a clear traffic dump of a p4 info request 

This communication can be secured by SSL while the fingerprint of the server is added into a trust local file located at P4TRUST (itself defined in the p4 config file). 

During our investigation, we recorded the server traffic of several sensitive responses (triggering SSO response, writing files with arbitrary content to arbitrary location, etc. ) and observed that no validation of server response exists in the client side: 

1. No expiration timeout exists, as our recorded responses could work even days after they were generated. 
2. No session id is used during a connection. Therefore, we recorded the traffic between our client and server; and used the exact same response bytes in the dockerized POC that we shared with Perforce security team.  
3. The client doesn’t verify if the server response matches the request it initiated. 

Beyond the risk of replay attacks, the last point makes the following scenario possible:  

1. A threat actor shares the details of an unknown server to the victim. 
2. Upon initial connection to the server, it immediately responds with an instruction to write a malicious line into a configuration file ( ~/.p4enviro or .p4config for instance). The expression, P4LOGINSSO=<malicious shell command>, will be executed by any new p4 command. 

Indeed, the P4LOGINSSO environment variable is designed for SSO integrations: when set, the p4 client executes its value as a shell command to obtain authentication credentials.  

Fig. 3: Illustration of the first attack scenario 

Another scenario we presented was the following: 

• A threat actor shares a project including a hidden .p4config file with specially crafted P4PORT and P4LOGINSSO variables. 
• The victim executes any legitimate p4 command. 
• This command is sent to the malicious server defined in P4PORT that returns a “client-sso” instruction, immediately executed on the client side. 

Fig. 4: Illustration of the second scenario 

Post Exploitation 

Once exploited, this flaw enables attackers to achieve arbitrary code execution under the victim’s user account: the same context in which the p4 command runs.  

This grants full local control, allowing theft of sensitive data (e.g., source code, intellectual property, credentials), modification of files or configurations for persistence or further compromise, and disruption of workflows through file deletion or system resource exhaustion.  

In environments handling high-value assets, such as game development studios, VFX pipelines, or large-scale software projects, the business impact can be substantial, including IP loss, production delays, and potential downstream effects on team collaboration or supply chain integrity. 

Mitigation 

Following the reception of our report, Perforce security team requested an embargo until the release of v2026.1 (May 2026) to give them time to patch this issue.  

The fix introduced a built-in protection in the client that prevents syncing or submitting files matching Perforce configuration file names (.p4enviro, .p4config, etc.), regardless of workspace settings. The P4_SYSTEMIGNORE variable can be used to extend this list. However, this does not address the lack of binding between client requests and server responses, nor the absence of a replay timeout or session id. 

Recommendations  

Update your system to the latest available version. 

Organizations using Perforce command line client should treat this issue seriously and adopt the following guidelines: 

• Prevent exchange of configuration files from unvetted sources. 
• Educate users on the dangers of connecting to unknown or shared Perforce endpoints and encourage verification of server authenticity before executing any commands. 
• Enforce encrypted connections to reduce exposure to man in the middle attacks. 
• Monitor for unusual p4 activity, including unexpected server connections or configuration sourcing. 

Conclusion 

This vulnerability in the Perforce Helix Client highlights how widely used version control systems can contain overlooked risks in their core client-server communication, assumptions that the server is always trustworthy or responses are inherently safe. 

In environments with massive, distributed asset pipelines, such protocol-level gaps can quietly expose teams to compromise through everyday interactions like querying server info or loading shared configurations. 

As development tools evolve toward greater automation, integration, and reliance on external or unvetted endpoints, these subtle trust boundaries deserve renewed scrutiny. This finding is a reminder that supply chain attacks do not require compromising a central registry: embedding a malicious configuration file in a shared project artifact could be sufficient to achieve code execution across an entire team. 

Timeline 

October 20 2025 – Disclosure sent to Perforce security team.

October 21 2025 – Report acknowledged by the Perforce security team.

March 9 2026 – Patch released for 2025.2 and backported to prior supported versions. 

May 18 2026 – Release of 2026.1 and publication of the security advisory.