P4 Search shipped a default service token: inside CVE-2026-100103

Summary

Perforce published P4 Search 2026.4.2 on 5 October 2026, closing six security defects in the search service that runs in front of Perforce P4, the source control platform formerly known as Helix Core. The release carries three critical ratings, one high and two medium. The top score belongs to CVE-2026-100103, rated 10.0 under CVSS 4.0, and it exists because the official container images reset the service authentication token to a publicly documented default value. Perforce reports no exploitation in the wild and no public proof of concept.

What the defect is

P4 Search guards privileged calls with a service authentication token. In the affected container images, startup overwrites that token with a fixed default that also appears in public material. Anyone who can reach the service on the network can offer a credential they already possess and receive the highest application privilege the service exposes. There is no parsing bug, no memory corruption and no race to win. The control simply begins in the wrong state.

Why a default credential is not a minor oversight

Exploitation normally requires an attacker to find a weakness and then build a reliable way to reach it. A published default token removes that work. The remaining requirement is network reachability, which is common for an internal search endpoint that developers query from workstations and build agents. That combination explains the 10.0 score: the confidentiality, integrity and availability consequences are complete, and the attack needs no specialised skill.

The rest of the release

The patch set is broader than one flaw. CVE-2026-100102, rated 9.5, exposes an unauthenticated Java Debug Wire Protocol interface in the same images, and reaching it allows execution of arbitrary code as the P4 Search service account. CVE-2026-103510, again 9.5, is a fail-open condition in which a blank service token grants full privileges to unauthenticated callers. CVE-2026-103507, at 7.5, lets a token holder write arbitrary files through the logging configuration path, which can be turned into code execution. CVE-2026-103511, at 5.1, allows file writes through the extension installer, and CVE-2026-103512, at 5.3, lets a stolen P4 Server ticket bypass host-based restrictions by spoofing a client address.

Affected versions and scope

All six defects affect P4 Search 2026.4.1 and earlier. The two most severe issues apply to the official container images, which is where the default token and the debug interface come from. The file-write and ticket-binding flaws apply more widely, including to deployments that already use a non-default token.

Exposure measured with ZoomEye

On 6 October 2026 a ZoomEye query for the Perforce application fingerprint returned 139 matching assets, and a title-based query returned 263. These numbers describe systems that identify themselves as Perforce infrastructure. They are not confirmed P4 Search installations and not confirmed vulnerable hosts, so they act as a scale indicator rather than an infection count.

Remediation

Upgrade P4 Search to 2026.4.2 and rebuild container deployments from the patched image instead of patching in place. Replace the service token with a strong, unique value and rotate it after the upgrade. Keep P4 Search off the public internet, block the debug port at the container and host firewall, and review P4 Server tickets for signs of misuse. Teams that must keep an older build online in the short term should treat the search service as untrusted and isolate it from the P4 Server network path.

References

• SecurityOnline report on the six P4 Search vulnerabilities (collected source).
• ZoomEye search for app="Perforce" and title="Perforce", recorded 6 October 2026.