CVE-2026-103509

Executive Summary

CVE-2026-103509 is an insufficiently protected credentials vulnerability (CWE-310/CWE-1220 lineage) in P4 Search (formerly Helix Search) that causes stored credentials to be returned in cleartext through its configuration API. The flaw is reachable only by users holding administrative privileges on the connected P4 Server, which means it does not by itself bypass authentication — it enables privilege escalation from an already-trusted administrative context into exposure of secrets that should never leave the server's protected store. All deployments running P4 Search 2026.4.2 and earlier are affected; P4 Search 2026.4.3 is the fixed release.

Technical Analysis

P4 Search is a search and indexing layer that operates as a companion service to a Perforce Helix Core (P4) Server. To index and query repository content, it must hold credentials capable of authenticating to the connected P4 Server — typically service or administrative account material. Those credentials constitute a high-value secret because possession of them grants programmatic access to the entire connected depot, not merely to the search UI.

The vulnerability lies in the configuration API of P4 Search. According to the NVD description, that API "returns stored credentials in cleartext" to callers who hold administrative privileges on the connected P4 Server. This is a failure of secret-handling hygiene at the interface boundary: a management endpoint that should either omit secret material entirely, return only a masked/redacted representation, or require an additional scope of authorization, instead serializes the underlying credential value verbatim.

From a vulnerability-class perspective (CWE-1220, "Insufficient Granularity of Access Control," and the closely related inadequate-protection-of-credentials family), the defect is twofold. First, the authorization model conflates two distinct privilege domains: administrative rights on the connected P4 Server are treated as sufficient authority to read the P4 Search service's own secret store. Those are separate trust boundaries — a P4 Server superuser is not necessarily meant to be a P4 Search configuration owner, and certainly should not receive cleartext secrets as a side effect of that role. Second, the response payload lacks output-side redaction, so the credential is transmitted over the wire in a directly usable form rather than as a placeholder or hash.

Attack surface characteristics:

• The exposure is via a network-reachable configuration API, implying the attacker requires authenticated API access rather than pre-authentication network adjacency.
• The precondition is admin privilege on the connected P4 Server, meaning the attacker is either a legitimate privileged insider or an external actor who has already compromised such an account.
• The impact is confidentiality-only at the level of the P4 Search process: the credential material returned is for the downstream P4 Server connection, not for arbitrary unrelated systems.

The precise API path, parameter names, response schema, and the exact credential field returned are not specified in the available NVD description or CNA title. No CVE-specific vendor advisory, patch diff, or commit reference is available from tracked sources; patch confidence remains 0/4. Any claim about specific endpoint paths or JSON field names would be speculation and is deliberately omitted. The mitigation is version-based: upgrade to 2026.4.3.

Exploitation Scenarios

No public PoC, Nuclei template, or exploit code exists for this CVE, and no exploitation has been observed in the wild. The attack chain below is inferred at the vulnerability-class level from the NVD description; it does not rely on any unverified implementation detail.

1. Reconnaissance and target identification. An adversary identifies an exposed P4 Search / Helix Search instance. Because the product is web-reachable and typically identifiable by its title or branding, internet-facing or internally reachable instances can be enumerated with product/title dorks. The adversary next needs to satisfy the precondition: administrative privileges on the connected P4 Server. This is obtained either through legitimate assignment (a malicious or careless insider) or through prior compromise of a P4 Server administrator account — for example via phishing, credential reuse, or an unrelated vulnerability in the surrounding infrastructure.

2. Triggering the flaw class. Holding that administrative context, the adversary authenticates to the P4 Search configuration API and requests configuration data. The API, lacking the granularity to distinguish "P4 Server administrator" from "P4 Search secret custodian," and lacking output redaction, returns the stored credential value in cleartext in its response. The trigger is a single authorized-looking API read; there is no memory corruption, no injection, and no malformed input required — the vulnerability is a design defect in access-control granularity and secret handling.

3. Payload/execution method (class level). The "payload" is simply the configuration API request issued with valid administrative authority. The exploitation primitive is information disclosure via an over-permissive read. No exploit code is required beyond an authenticated API client.

4. Post-exploitation impact. The adversary now possesses cleartext credentials for the connected P4 Server. Depending on the privileges bound to that credential, this enables privilege escalation: the attacker can authenticate directly to the P4 Server and read, modify, or exfiltrate repository content and metadata to the full extent of the harvested account's authorization — bypassing the intended separation between the search service and the source-control server's own access controls. The harvested credential also becomes reusable material for lateral movement and persistent access, and cannot be safely rotated by the victim without also updating the P4 Search configuration (which the attacker may re-read if access is not revoked).

Impact Assessment

Business impact is centered on confidentiality of source code and intellectual property. P4 (Helix Core) is commonly the system of record for an organization's most sensitive assets: proprietary source code, firmware, design documents, and release artifacts. A cleartext P4 Server credential harvested through this flaw hands an attacker direct programmatic access to that repository, enabling large-scale cloning and exfiltration that is difficult to distinguish from legitimate CI/CD traffic.

Because the CVSS vector in the provided data is N/A and no authoritative score is available, subscores below are assessed qualitatively for the report's analytical framing and should not be treated as a ratified CVSS value:

• Attack Vector: Network (the configuration API is reachable over the network).
• Attack Complexity: Low (a single authenticated read).
• Privileges Required: High (administrator on the connected P4 Server is a strict precondition — this materially limits the attacker set).
• User Interaction: None.
• Scope: Unchanged (the vulnerable component and the impacted asset are part of the same authorization chain, though the credential grants access to the adjacent P4 Server).
• Confidentiality: High (cleartext credential disclosure). Integrity/Availability: None from this CVE in isolation, though integrity and availability of the downstream P4 Server are at risk once the credential is used.

Blast radius: every P4 Search 2026.4.2-or-earlier deployment where administrative P4 Server accounts are broadly assigned, shared, or poorly governed. Environments with many P4 Server administrators, or where admin credentials are reused elsewhere, carry elevated risk. The absent EPSS score (not yet scored by FIRST.org), absent CISA KEV listing, and absence of public exploit code mean the immediate opportunistic-exploitation risk is low, but the impact ceiling — full source-of-truth repository compromise — is severe, and the vulnerability is well suited to targeted post-compromise escalation rather than mass scanning.

Detection Guidance

Detection strategy must account for the fact that the malicious request looks like a legitimate administrative API call. High-fidelity detection therefore relies on behavioral context: who is reading P4 Search configuration, from where, and what they do with the P4 Server immediately afterward. The rules below are template logic and should be tuned to the deployment's actual API path, response schema, and log formats, which are not specified in available data.

Sigma Rule

title: Potential P4 Search Configuration API Credential Disclosure (CVE-2026-103509)
id: 3f1c9a72-6d4b-4e18-9c2a-p4search103509
status: experimental
description: Detects access to the P4 Search / Helix Search configuration API by an administrative account, which may indicate exploitation of CVE-2026-103509 to harvest cleartext stored P4 credentials.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-103509
author: valtersit.com
date: 2026
tags:
  - attack.credential_access
  - attack.t1078
  - attack.t1552
logsource:
  category: webserver
  product: p4search
detection:
  selection_method:
    cs-method:
      - GET
      - POST
  selection_path:
    cs-uri-stem|contains:
      - '/config'
      - '/configuration'
      - '/api/config'
  selection_response:
    sc-status: 200
  condition: selection_method and selection_path and selection_response
falsepositives:
  - Legitimate P4 Search administrators viewing configuration
  - Configuration management tooling polling the API
level: medium

YARA Rule

rule CVE_2026_103509_P4Search_Credential_Disclosure
{
    meta:
        description = "Detects configuration API responses or logs containing cleartext P4 credential material associated with P4 Search CVE-2026-103509"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-103509"
        author = "valtersit.com"
        date = "2026"
        severity = "high"

    strings:
        $api1 = "configuration" nocase
        $api2 = "P4 Search" nocase
        $api3 = "Helix Search" nocase
        $api4 = "P4PORT" nocase
        $api5 = "P4USER" nocase
        $api6 = "P4PASSWD" nocase
        $cred1 = "password" nocase
        $cred2 = "credential" nocase
        $cred3 = "ticket" nocase

    condition:
        (any of ($api1, $api2, $api3)) and
        (any of ($api4, $api5, $api6)) and
        (any of ($cred1, $cred2, $cred3))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-103509 P4 Search Configuration API Credential Disclosure Attempt"; flow:to_server,established; http.method; content:"GET"; http.uri; content:"config"; nocase; http.uri; content:"search"; nocase; classtype:attempted-recon; reference:cve,2026-103509; reference:url,https://nvd.nist.gov/vuln/detail/CVE-2026-103509; sid:2026103509; rev:1; metadata:created_at 2026, updated_at 2026;)

Elastic Detection

sequence by user.name, source.ip with maxspan=5m
  [ network where network.protocol == "http" and
      http.request.method in ("GET", "POST") and
      stringContains(url.path, "config") ]
  [ process where event.type == "start" and
      process.name in ("p4", "p4.exe") ]

Splunk SPL Query

index=web OR index=proxy sourcetype=access_combined
    (uri_path="*config*" OR uri_path="*configuration*")
    (cs_uri_query="*search*" OR referer="*search*" OR http_user_agent="*search*")
    status=200
| stats count min(_time) as first_seen max(_time) as last_seen
        values(uri_path) as paths values(src_ip) as source_ips
        by user, host
| where count >= 1
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S"),
       last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
| sort - last_seen

Wazuh OSSEC Rule

<group name="p4search,cve_2026_103509,">
  <rule id="103509" level="10">
    <if_sid>31100</if_sid>
    <match>config</match>
    <match>search</match>
    <description>CVE-2026-103509: Possible P4 Search/Helix Search configuration API access associated with cleartext credential disclosure</description>
    <mitre>
      <id>T1078</id>
      <id>T1552</id>
    </mitre>
    <group>credential_access,</group>
  </rule>
  <rule id="103510" level="12">
    <if_sid>103509</if_sid>
    <match>200</match>
    <description>CVE-2026-103509: P4 Search configuration API returned success - verify administrative credential disclosure</description>
    <group>credential_access,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). Although the NVD description states the issue is fixed in P4 Search 2026.4.3, no vendor advisory, changelog, commit, or patch artifact is available from tracked sources to independently corroborate that fix. Treat this as version-based guidance from the CNA description, not as verified patch evidence.

1. Immediate mitigations (before or independent of upgrade):

• Restrict network reachability of the P4 Search configuration API to a management plane or trusted administrative subnet; it should not be exposed to user segments or to the internet.
• Reduce the population of accounts holding administrative privileges on the connected P4 Server to the strict minimum, and eliminate sharing of those accounts. Because this flaw is gated on that privilege, shrinking the privileged set directly shrinks the attack surface.
• Where feasible, separate the P4 credential used by P4 Search from human-administrative identity, and rotate that service credential on a schedule. Rotation limits the useful lifetime of any credential harvested.
• Audit which accounts can reach the configuration API and review P4 Server access logs for anomalous post-configuration-read activity (large clones, unusual client IPs, off-hours access).

2. Patch / upgrade steps:

• Upgrade P4 Search (formerly Helix Search) to 2026.4.3 or later as stated in the NVD description.
• Confirm the fixed build actually redacts or withholds credential material from the configuration API response before considering the issue closed; because patch evidence is unverified, validate behavior post-upgrade.
• After upgrading, rotate all credentials that the P4 Search configuration may have exposed, on the assumption that any account reaching the pre-patch API could have harvested them.
• Verify the downstream P4 Server for signs of unauthorized access using the rotated-before credentials.

3. Long-term hardening:

• Enforce least-privilege and separation of duties between the source-control server's administrative role and the search/indexing service's configuration ownership; never treat one as authority for the other.
• Adopt a secrets-management policy that forbids APIs from ever returning cleartext secret values — responses should return references, masks, or hashes only.
• Instrument and alert on configuration-API reads, especially by administrative accounts and from unexpected network origins.
• Maintain an inventory of P4 Search / Helix Search deployments and their versions so future advisories can be triaged quickly; given the 0/4 patch confidence here, monitoring the vendor's own advisory channel remains essential.

References

• NVD — CVE-2026-103509: https://nvd.nist.gov/vuln/detail/CVE-2026-103509
• CWE-1220 — Insufficient Granularity of Access Control: https://cwe.mitre.org/data/definitions/1220.html
• CWE-522 — Insufficiently Protected Credentials: https://cwe.mitre.org/data/definitions/522.html
• Perforce P4 Search (formerly Helix Search) product documentation and release notes — consult the vendor's official advisory channel for the 2026.4.3 fix, as no advisory is available from tracked sources at time of writing.
• FIRST.org EPSS — not yet scored for this CVE as of this report: https://www.first.org/epss/
• CISA Known Exploited Vulnerabilities Catalog — CVE-2026-103509 is not listed; no exploit-in-the-wild evidence or attributed threat actor campaign is currently available.