P4 Search: three CVEs and the 2026.4.2 fix — check tokens and debugging

Three CVE records covering Perforce P4 Search were published on 5 October. The vendor-supplied records give 30 September as the earlier disclosure date and identify 2026.4.2 as unaffected by these vulnerabilities. Today’s publication does not establish that the fix first appeared today or that an attack occurred.

The issues concern the search service and its container images. Teams should assess their P4 Search deployments, network reachability and connection to P4 Server. Using Perforce somewhere in an organisation does not, by itself, confirm exposure.

Three mechanisms documented by the vendor

• CVE-2026-103510: a blank service authentication token allowed access controls to fail open, granting the highest application privilege.
• CVE-2026-100103: container images reset the service token to a publicly documented default, enabling a similar authentication bypass.
• CVE-2026-100102: images exposed an unauthenticated Java JDWP debugging interface, allowing code execution as the service account.

The records cover versions before 2026.4.2 and require attacker network access. Perforce also identifies potential compromise of the connected P4 Server. Service-account privileges do not automatically mean host administrator privileges; assess possible downstream impact against the actual configuration.

What to check before closing the ticket

Breachroad recommends going beyond the image version recorded in a repository. Identify the version of each running instance, its deployed image identifier and the deployment owner. Include test environments, old replicas and jobs that might recreate an earlier container.

Next, draw a short access map: who can reach the service, which ports are exposed and what permissions the P4 Server integration holds. Reachability through a corporate VPN still counts as network access. Use this map and the permission scope to set urgency rather than relying on an “internal” label.

An update and verification plan

1. Reduce exposure. Allow only necessary callers and remove unnecessary access to diagnostic interfaces. This limits risk while the patch is being deployed.
2. Deploy a fixed version. Choose a supported release containing the 2026.4.2 fix. Confirm every instance has been updated, including the configuration used when the service restarts.
3. Check authentication. In a controlled environment, verify that missing and incorrect tokens cause access to be denied. Keep real secrets out of tickets and test logs.
4. Check debugging and integration access. Confirm there is no unnecessary reachability to JDWP and that the account connecting to P4 Server has only the required permissions.
5. Review the earlier period. Examine available connection and operation logs for a defined window. If token exposure is suspected, plan replacement and invalidation of the old token through the incident process.

An absence of unusual entries in limited logs cannot settle whether exploitation occurred. Separate confirmed observations from gaps in visibility when reporting the result.

Training scenario: a current tag, an old replica

In our fictional scenario, an administrator updates the image tag in the deployment template. One old replica remains running, while the recovery configuration retains an earlier token. The ticket is marked resolved even though the running environment does not match the template.

The exercise asks participants to identify evidence of completion: the version of every replica, denial of access without a valid token, and confirmation of the restricted network surface. It does not require reproducing an attack or using production credentials.

Cybersecurity training for technical teams helps administrators, developers and security staff rehearse their responsibilities. Our guide to secrets management and rotation provides supporting background.

Sources and Breachroad conclusions

The mechanisms, affected versions and potential impact come from the three linked CVE records containing Perforce’s data. The access map, verification plan and scenario are Breachroad recommendations. These records alone do not establish active exploitation or an incident affecting a particular user. Sources were checked on 5 October 2026.