Perforce patches six P4 Search flaws including default token scored 10.0

What shipped

Perforce released P4 Search 2026.4.2 on 5 October 2026, a maintenance release that closes six security defects in the search component that operates in front of P4, the source control platform formerly known as Helix Core. According to a post on dev.to, the release carries three critical ratings, one high and two medium. Perforce reports no exploitation in the wild and no public proof of concept for any of the flaws.

The headline flaw: a default service token

The most severe issue is CVE-2026-100103, which scores 10.0 under CVSS 4.0. P4 Search protects privileged operations with a service authentication token, but in the affected official container images the startup process overwrites that token with a fixed default value that also appears in publicly documented material.

The consequence is that anyone able to reach the service over the network can present a credential they can simply look up and receive the highest application privilege the service exposes. The dev.to post stresses that this is not a parsing bug, memory corruption or race condition: the authentication control simply starts in an insecure state. That removes the usual research effort behind exploitation, leaving network reachability as the main requirement — a low bar for an internal search endpoint that developer workstations and build agents routinely query.

The other five vulnerabilities

The release bundles five further fixes:

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

Affected versions and visible exposure

All six defects affect P4 Search 2026.4.1 and earlier. The two most severe issues — the default token and the exposed debug interface — are specific to the official container images. The file-write and ticket-binding flaws apply more broadly, including to deployments already running a non-default service token.

The dev.to post also measured the visible footprint using ZoomEye on 6 October 2026: a query for the Perforce application fingerprint returned 139 matching assets, and a title-based query returned 263. The author notes these figures describe systems identifying themselves as Perforce infrastructure; they are not confirmed P4 Search installations and not confirmed vulnerable hosts, so they serve as a scale indicator rather than an exposure count.

Recommended remediation

The guidance is to upgrade to P4 Search 2026.4.2 and rebuild container deployments from the patched image rather than patching in place. Administrators should replace the service token with a strong, unique value and rotate it after the upgrade. The post also advises keeping P4 Search off the public internet, blocking the debug port at both the container and host firewalls, and reviewing 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 network path to the P4 Server.

Why it matters

Source control infrastructure holds an organisation's complete codebase, and a search tier in front of it that grants top-level privileges for a publicly documented credential is a serious supply-chain style risk. A perfect CVSS score born of a deployment default, rather than exotic memory corruption, is a reminder that packaging choices matter as much as application code. It is also a prompt for platform teams everywhere to audit container images for baked-in secrets, rotate any token that ever existed in a default state, and verify that debug interfaces are never reachable in production. For Perforce shops specifically, this release is not optional: patching, rebuilding the image, and rotating the service token should be treated as one coordinated task.