P4 Helix Core
Monthly
Cleartext credential disclosure in P4 Search (formerly Helix Search) 2026.4.2 and earlier allows an authenticated administrator on the connected P4 Server to retrieve stored credentials through the product's configuration API, enabling privilege escalation beyond the administrator's intended scope. The defect is rooted in insufficient granularity of access control (CWE-1220): the API exposes secret material that administrators should not be able to read back, and the resulting credential exposure has cross-boundary confidentiality, integrity, and availability consequences per the assessed scope change (S:C). Exploitation is privilege-gated by the PR:H authentication requirement in the CVSS vector, so this is not reachable by anonymous or unprivileged users, and no public exploit code or confirmed active exploitation has been identified at time of analysis. A vendor patch is available in P4 Search 2026.4.3.
Perforce P4 Search before 2026.4.2 fails open when its service authentication token is blank, so an unauthenticated remote attacker with network access to the service can obtain the highest application privilege, potentially compromising both P4 Search and the P4 Server it is connected to (CWE-636). The vendor rates this CVSS 4.0 9.5; our independent assessment is CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H because the attack requires the victim deployment to be running in the blank-token configuration (Attack Requirements: Present), meaning deployments that set a non-blank service authentication token are not exploitable. No public exploit code has been identified at time of analysis, and there is no confirmed actively exploited (CISA KEV) status; the issue is nonetheless a genuine high-priority authentication bypass rather than a CVSS-inflated paper risk, and impact extends to the connected P4 Server.
Arbitrary file write in Perforce P4 Search versions prior to 2026.4.2 allows an attacker who already holds a valid P4 Search service authentication token to dictate the file path used by the logging configuration interface and thereby write files anywhere on the host, which can escalate to code execution under the P4 Search service account. The flaw is a credentialed, privileged operation rather than an unauthenticated internet-facing attack: exploitation requires the service token, network reachability of the configuration interface, and a version older than the fixed 2026.4.2 release. No public exploit code and no confirmed active exploitation were identified at time of analysis; the practical risk is concentrated in environments where the service token is weakly protected or the interface is broadly exposed.
Unauthenticated remote code execution is possible in Perforce P4 Search container images prior to 2026.4.2 due to an exposed Java Debug Wire Protocol (JDWP) interface. An attacker with network access to the JDWP port can execute arbitrary code as the P4 Search service account, potentially compromising the connected P4 Server. No public exploit code has been identified at time of analysis, but the issue is rated critical (CVSS 9.5 in CVSS 4.0, assessed as CVSS 3.1 with scope change) and requires the debug interface to be reachable (attack prerequisite AT:P), making it a genuine high-priority issue rather than a high-CVSS-but-low-risk artifact.
Unauthenticated network attackers can gain the highest application privileges on Perforce P4 Search container images prior to 2026.4.2 because the service authentication token is reset to a publicly documented default value (CWE-1392). Successful exploitation can lead to arbitrary code execution and compromise of any connected P4 Server, but full impact requires that the P4 Search container be network-reachable and that a P4 Server be connected to it. No public exploit identified at time of analysis, yet this is a genuine top-priority vulnerability because the default-token flaw is trivial to exploit once the service is exposed and the potential scope change to the connected P4 Server is severe.
Code injection vulnerability in the Command-Line Client of P4 Server (Helix Core) prior to version 2025.2 Patch 2 allows remote attackers to execute arbitrary code. The vulnerability requires user interaction but no authentication, with a CVSS 7.7 score indicating high impact across confidentiality, integrity, and availability. Perforce has released a patch in version 2025.2 Patch 2.
Arbitrary file write in Perforce P4 Search versions prior to 2026.4.2 allows an attacker who already holds super-user or service-token privileges to write files with attacker-controlled content into the P4 Search installation directory via the extension installation feature, which fails to validate supplied file names (CWE-73). The vulnerability is authenticated and gated by a PR:H requirement, so exploitation is not possible for unauthenticated or low-privileged users; the realistic risk is confined to malicious insiders, abused service tokens, or an attacker who has already compromised a privileged account. The vendor rates it CVSS 4.0 base 5.1 (VC:N/VI:L/VA:L), and no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis.
Host-based authentication controls in Perforce P4 Search prior to 2026.4.2 can be bypassed because the service trusts a client-supplied address when validating certain authentication requests, allowing a holder of a stolen P4 Server ticket to defeat ticket host-binding and trusted-address restrictions and obtain access to P4 Search as that ticket's owner. The flaw is authenticated in nature (CVSS:4.0 vector shows PR:L and the independent assessment concurs), so it does not grant access on its own - the attacker must already possess a valid but stolen ticket, and the bypass is only meaningful in deployments that rely on host-binding or trusted-address controls; where those controls are absent, the stolen ticket already grants the same access. Severity is moderate (CVSS 5.3, independent CVSS:3.1 base 5.3) with low confidentiality and integrity impact confined to the single compromised ticket's permissions; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV), so this is best treated as a medium-severity defense-in-depth gap rather than a standalone critical issue.
Cleartext credential disclosure in P4 Search (formerly Helix Search) 2026.4.2 and earlier allows an authenticated administrator on the connected P4 Server to retrieve stored credentials through the product's configuration API, enabling privilege escalation beyond the administrator's intended scope. The defect is rooted in insufficient granularity of access control (CWE-1220): the API exposes secret material that administrators should not be able to read back, and the resulting credential exposure has cross-boundary confidentiality, integrity, and availability consequences per the assessed scope change (S:C). Exploitation is privilege-gated by the PR:H authentication requirement in the CVSS vector, so this is not reachable by anonymous or unprivileged users, and no public exploit code or confirmed active exploitation has been identified at time of analysis. A vendor patch is available in P4 Search 2026.4.3.
Perforce P4 Search before 2026.4.2 fails open when its service authentication token is blank, so an unauthenticated remote attacker with network access to the service can obtain the highest application privilege, potentially compromising both P4 Search and the P4 Server it is connected to (CWE-636). The vendor rates this CVSS 4.0 9.5; our independent assessment is CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H because the attack requires the victim deployment to be running in the blank-token configuration (Attack Requirements: Present), meaning deployments that set a non-blank service authentication token are not exploitable. No public exploit code has been identified at time of analysis, and there is no confirmed actively exploited (CISA KEV) status; the issue is nonetheless a genuine high-priority authentication bypass rather than a CVSS-inflated paper risk, and impact extends to the connected P4 Server.
Arbitrary file write in Perforce P4 Search versions prior to 2026.4.2 allows an attacker who already holds a valid P4 Search service authentication token to dictate the file path used by the logging configuration interface and thereby write files anywhere on the host, which can escalate to code execution under the P4 Search service account. The flaw is a credentialed, privileged operation rather than an unauthenticated internet-facing attack: exploitation requires the service token, network reachability of the configuration interface, and a version older than the fixed 2026.4.2 release. No public exploit code and no confirmed active exploitation were identified at time of analysis; the practical risk is concentrated in environments where the service token is weakly protected or the interface is broadly exposed.
Unauthenticated remote code execution is possible in Perforce P4 Search container images prior to 2026.4.2 due to an exposed Java Debug Wire Protocol (JDWP) interface. An attacker with network access to the JDWP port can execute arbitrary code as the P4 Search service account, potentially compromising the connected P4 Server. No public exploit code has been identified at time of analysis, but the issue is rated critical (CVSS 9.5 in CVSS 4.0, assessed as CVSS 3.1 with scope change) and requires the debug interface to be reachable (attack prerequisite AT:P), making it a genuine high-priority issue rather than a high-CVSS-but-low-risk artifact.
Unauthenticated network attackers can gain the highest application privileges on Perforce P4 Search container images prior to 2026.4.2 because the service authentication token is reset to a publicly documented default value (CWE-1392). Successful exploitation can lead to arbitrary code execution and compromise of any connected P4 Server, but full impact requires that the P4 Search container be network-reachable and that a P4 Server be connected to it. No public exploit identified at time of analysis, yet this is a genuine top-priority vulnerability because the default-token flaw is trivial to exploit once the service is exposed and the potential scope change to the connected P4 Server is severe.
Code injection vulnerability in the Command-Line Client of P4 Server (Helix Core) prior to version 2025.2 Patch 2 allows remote attackers to execute arbitrary code. The vulnerability requires user interaction but no authentication, with a CVSS 7.7 score indicating high impact across confidentiality, integrity, and availability. Perforce has released a patch in version 2025.2 Patch 2.
Arbitrary file write in Perforce P4 Search versions prior to 2026.4.2 allows an attacker who already holds super-user or service-token privileges to write files with attacker-controlled content into the P4 Search installation directory via the extension installation feature, which fails to validate supplied file names (CWE-73). The vulnerability is authenticated and gated by a PR:H requirement, so exploitation is not possible for unauthenticated or low-privileged users; the realistic risk is confined to malicious insiders, abused service tokens, or an attacker who has already compromised a privileged account. The vendor rates it CVSS 4.0 base 5.1 (VC:N/VI:L/VA:L), and no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis.
Host-based authentication controls in Perforce P4 Search prior to 2026.4.2 can be bypassed because the service trusts a client-supplied address when validating certain authentication requests, allowing a holder of a stolen P4 Server ticket to defeat ticket host-binding and trusted-address restrictions and obtain access to P4 Search as that ticket's owner. The flaw is authenticated in nature (CVSS:4.0 vector shows PR:L and the independent assessment concurs), so it does not grant access on its own - the attacker must already possess a valid but stolen ticket, and the bypass is only meaningful in deployments that rely on host-binding or trusted-address controls; where those controls are absent, the stolen ticket already grants the same access. Severity is moderate (CVSS 5.3, independent CVSS:3.1 base 5.3) with low confidentiality and integrity impact confined to the single compromised ticket's permissions; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV), so this is best treated as a medium-severity defense-in-depth gap rather than a standalone critical issue.