Perforce patches three critical flaws that open P4 Search without authentication
On 5 October 2026 Perforce published three critical CVEs in P4 Search, the containerised search engine for Helix Core: a hardcoded authentication token (CVSS 10) and an exposed JDWP debug interface let an unauthenticated network attacker run code right next to the source repository. The fix is a single container-image update to 2026.4.2 plus strict network isolation.
Monday, 5 October 2026. Perforce published three critical CVEs in P4 Search, the search engine for Helix Core: CVE-2026-100103 (CVSS 10.0), CVE-2026-100102 and CVE-2026-103510 (CVSS 9.5 each). No authentication required. All three open the door to an unauthenticated network attacker — and two of them lead to arbitrary code execution with the service’s privileges. Next to the source code. The sensitive part is not the severity but the location: P4 Search typically runs in a container right beside the P4 Server, where the company’s source and history live.
What P4 Search is, and why it sits so close to the code
Helix Core (formerly Perforce) is a centralised version-control system used heavily in game studios, automotive, hardware and finance. P4 Search is its indexing and search engine: it indexes the repository’s files and answers full-text search queries. Long deployed as a sidecar service, it is now shipped as a container image that teams spin up next to the server.
That proximity is what makes the three flaws dangerous. An attacker who runs code inside P4 Search is not just compromising an index: they gain a foothold on the network where the P4 Server sits. Depending on how the network is segmented, the distance to the code repository can be zero — and in many organisations the search service was never included in the hardening perimeter, precisely because it is not seen as an entry point.
The three flaws, from worst to quietest
CVE-2026-100103 (CVSS 10.0) is a hardcoded authentication token. The P4 Search container images shipped with a default service token; an attacker who knows it bypasses authentication, gains full administrative privileges, then executes code. The flaw was reported by researcher Khoa Bui and registered with the CVE program on 25 September 2026, before being disclosed on 5 October.
CVE-2026-100102 (CVSS 9.5) is a JDWP (Java Debug Wire Protocol) debug interface left enabled and exposed. Anyone who can reach the debug port — typically 8000 or 5005 — can attach to it and run code with the privileges of the P4 Search service account.
CVE-2026-103510 (CVSS 9.5) is an authentication bypass: service-token validation fails, letting an unauthenticated attacker reach the same administrative privileges.
Two threads tie the three flaws together. First, they all affect container images older than 2026.4.2 — the fix is the same for all three. Second, two of them are shipping-configuration defects rather than application-logic bugs. A default token and a debug port left open are mistakes you expect in a development image, not one meant for production. Perforce also published other fixes around the same batch — CVE-2026-103507 (CVSS 7.5), CVE-2026-85979 and CVE-2026-89212 (CVSS 8.6) — a sign that the P4 Search review goes beyond the three critical flaws.
Why it is not exploited yet, and why that will not last
As of 5 October 2026, no public exploit is available and the three flaws are not yet in the CISA KEV catalogue. That is the most comfortable window to patch: the flaw is public, the details are known, but nobody has published turnkey attack code.
That window is usually short. A CVSS 10 flaw in a source-control tool quickly attracts two populations: extortionists looking to steal code for leverage, and supply-chain actors who want to inject malicious code into legitimate repositories. Because Helix Core is used by IP-rich organisations, the value of access is high. The 2024 precedent — the global campaign that followed the CVE-2024-27198 authentication flaw in TeamCity — shows how fast a defect in a build tool becomes mass compromise: attackers rarely exploit these flaws by hand, they automate and sweep.
The fix, and how to verify it
The fix is a single action: move every P4 Search container image to version 2026.4.2 or later. That release removes the default token and disables the JDWP interface.
Three checks are worth the effort on top of that:
- Image inventory. Enumerate every P4 Search deployment — including staging environments and sandboxes, which are often forgotten — and confirm the image version on each.
- Network isolation. Restrict access to the service to management subnets; a search instance has no reason to be reachable from the internet.
- Debug-port monitoring. In the logs, watch inbound connections to ports 8000 and 5005, and unexpected child processes under the service account.
# Check the version of an already-deployed P4 Search image
docker images | grep -i p4search
# Confirm no container exposes the JDWP ports (8000/5005)
docker ps --format '{{.Names}} {{.Ports}}' | grep -E '8000|5005' || echo "no debug port exposed"The first command prints the current local image version; the second lists containers exposing a debug port. If either returns an image older than 2026.4.2 or an open 8000/5005 port, the fix is not complete.
Verdict
If you run Helix Core with P4 Search, update the images to 2026.4.2 this week: three critical flaws, one at CVSS 10, are fixed by a single action, and the no-public-exploit window will not stay open long. If you cannot update immediately, isolate the service behind a firewall or security group and remove any public route to it: that neutralises most of the risk until the image is replaced. If you are not sure you use P4 Search, check anyway: the image may have been deployed by a team as a silent dependency of a search tool, without infrastructure ever knowing. The deeper lesson outlives Perforce — a hardcoded token and a debug port left open in a production image are shipping faults, not accidents, and the first place to look for them is your own container delivery pipeline.