CVE-2026-103512

Executive Summary

CVE-2026-103512 is an authentication bypass vulnerability in Perforce P4 Search versions prior to 2026.4.2, caused by the product trusting a client-supplied address when validating certain authentication requests. An attacker who has already obtained a stolen P4 Server ticket can circumvent host-based ticket restrictions and trusted-address controls, then access P4 Search with the full privileges of the ticket's owner. Organizations running unpatched P4 Search instances and exposing them to untrusted networks face unauthorized data access and potential lateral movement within the Perforce environment.

Technical Analysis

The vulnerability is classified as CWE-290 (Authentication Bypass by Spoofing). At its core, the affected P4 Search component performs validation of certain authentication requests by relying on an address value that is supplied by the client rather than deriving the trusted source from a server-side, non-spoofable source such as the actual TCP peer address or a verified transport attribute. Because the client controls the input used in the trust decision, the access-control logic can be satisfied by an attacker who presents a forged or manipulated address matching an expected trusted value.

This weakness is significant because Perforce P4 Server issues "tickets" that act as authentication tokens. Perforce deployments commonly restrict a ticket's validity by host (host-based ticket restrictions) and by a configured list of trusted addresses (trusted-address controls). These controls exist precisely to limit the blast radius of a stolen ticket so that possession of a ticket alone is insufficient if the attacker is connecting from an unauthorized host or network location. CVE-2026-103512 undermines that defense-in-depth layer: by trusting a client-supplied address during the validation of certain authentication requests, the product allows the host/address restrictions to be bypassed.

The direct prerequisite is a stolen P4 Server ticket. With such a ticket in hand, the attacker does not need to defeat the primary credential check; instead they defeat the secondary environmental restriction. The result is that the ticket can be replayed from an arbitrary source address, and the request is accepted as though it originated from a permitted host.

The NVD description does not disclose the specific authentication request type, the header or parameter carrying the client-supplied address, the parsing logic, or the exact comparison performed. These implementation details are not available from the provided data and are deliberately not fabricated here. What can be stated with confidence is the vulnerability class (spoofing-based authentication bypass, CWE-290), the trust-boundary failure (client-controlled value used in a security decision), and the outcome (bypass of host-based ticket restrictions and trusted-address controls, resulting in authenticated access as the ticket's owner).

No public proof-of-concept, exploit code, or Nuclei template was identified for this CVE. The exploit is therefore assessed as not currently weaponized in the public domain, though the underlying technique (ticket replay combined with source-address spoofing/parameter manipulation) is well understood and lowers the barrier to exploitation once a ticket is obtained.

Exploitation Scenarios

The attack chain is inferred from the vulnerability class, since no public PoC is available. The steps below are constrained to what the NVD description supports.

1. Reconnaissance / target identification. The attacker identifies an internet- or network-reachable Perforce P4 Search instance running a version prior to 2026.4.2. Because the flaw concerns authentication request validation, the target must be reachable such that the attacker can submit authentication requests to P4 Search. The attacker also determines that the environment enforces host-based ticket restrictions or trusted-address controls, since these are the controls being bypassed.

2. Obtaining the prerequisite credential. The attack requires a stolen P4 Server ticket belonging to a legitimate user. This could be obtained through unrelated means: theft from a developer workstation, credential/ticket leakage, compromise of a build system, interception, or exfiltration from logs or configuration where tickets are stored inappropriately. This is not a vulnerability in ticket issuance; it is the starting condition.

3. Triggering the flaw. The attacker presents the stolen ticket and initiates a "certain" authentication request to P4 Search. In this request, the attacker supplies an address value—the same class of address the product uses when validating the request—that satisfies the expected trusted value (e.g., matching the ticket owner's permitted host or a configured trusted address). Because P4 Search trusts this client-supplied address during validation rather than an authoritative server-side source, the host-based restriction and trusted-address control are not enforced.

4. Execution / bypass outcome. P4 Search completes authentication and grants access as the ticket's owner. The specific "payload" is not a code-execution payload but the crafted authentication request with the manipulated address value; no memory corruption or injection beyond the logic bypass is required at the vulnerability-class level. No specific function names, endpoints, or parameters are documented for this CVE and none are invented here.

5. Post-exploitation impact. The attacker gains authenticated access to P4 Search with the privileges of the ticket owner. Depending on that user's role, this can mean read (and potentially other) access to indexed project data, repository metadata, or search-accessible content. The bypass of address restrictions also breaks an assumed containment boundary: tickets that administrators believed were usable only from specific hosts can now be replayed from attacker-controlled locations. If the compromised ticket belongs to a privileged user, the impact escalates accordingly.

Success probability is contingent on two things the attacker must achieve: acquiring a valid, unexpired ticket, and successfully spoofing or manipulating the specific address value used in validation. Both are prerequisites, which is why the flaw is best characterized as a restriction bypass rather than a standalone pre-authentication takeover.

Impact Assessment

The primary impact is an authentication and access-control bypass that grants unauthorized access to Perforce P4 Search as the owner of a stolen ticket. This directly defeats two intended security controls: host-based ticket restrictions and trusted-address controls. Those controls are commonly the compensating layer that limits what a leaked ticket can do, so their failure disproportionately increases the severity of any ticket theft.

Confidentiality and integrity impacts are rated high in the representative vector (C:H/I:H/A:N), reflecting that the attacker operates as a legitimate user and can read or alter accessible SCM/search data within that user's authority. Availability impact is not directly implicated by the described mechanism (A:N). The attack is network-based (AV:N) but requires the non-trivial prerequisite of a valid stolen ticket, captured as AC:H. It requires some prior position or privilege to possess a ticket, reflected in PR:L. No user interaction is needed for the bypass itself (UI:N).

Blast radius scales with ticket ownership. A standard developer ticket yields read access to indexed content and metadata across projects the user can see. A privileged or service-account ticket can expose broader repository visibility and administrative surfaces. Because the flaw undermines address-based containment, environments that rely on this restriction to isolate CI/CD, third-party contractors, or remote workers are at elevated risk. There is no indication of CISA KEV listing, active exploitation in the wild, or public exploit availability at this time, so real-world exploitation is currently assessed as limited but non-zero given the low cost of replaying a leaked ticket once address controls are bypassed.

Detection Guidance

Sigma Rule

title: Potential Perforce P4 Search Trusted-Address Bypass Authentication
id: 3f1b7c2a-9d4e-4c6b-8a2f-5e0c1d9b7a44
status: experimental
description: Detects anomalous authentication attempts to Perforce P4 Search where client-supplied address values may be used to bypass host-based ticket restrictions (CVE-2026-103512).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-103512
author: SOC Threat Intelligence
date: 2026/01/01
logsource:
  product: perforce
  service: p4-search
detection:
  selection_action:
    event_type:
      - 'authentication'
      - 'auth_request'
  selection_status:
    status:
      - 'success'
      - 'denied'
  selection_address:
    - client_address|exists: true
    - trusted_address|exists: true
    - forwarded_for|exists: true
  condition: selection_action and selection_status and selection_address
falsepositives:
  - Legitimate reverse proxy deployments that forward client addresses
  - Normal authenticated access from trusted networks
level: medium
tags:
  - attack.t1190
  - cve.2026.103512

YARA Rule

rule CVE_2026_103512_Perforce_P4_Search_Address_Trust
{
    meta:
        description = "Detects strings associated with Perforce P4 Search authentication address handling potentially related to CVE-2026-103512"
        author = "SOC Threat Intelligence"
        date = "2026-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-103512"
        cve = "CVE-2026-103512"

    strings:
        $p4s1 = "P4 Search" ascii wide
        $p4s2 = "p4search" ascii wide
        $p4s3 = "Perforce" ascii wide
        $auth1 = "trusted_address" ascii wide
        $auth2 = "ticket" ascii wide
        $auth3 = "trusted-address" ascii wide
        $ver = /20(1|2)[0-9]\.(1|2|3)\./ ascii wide

    condition:
        (uint16(0) == 0x5A4D or uint32(0) == 0x464C457F or true) and
        any of ($p4s*) and any of ($auth*) and $ver
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-103512 Perforce P4 Search Trusted-Address Authentication Bypass Attempt"; flow:established,to_server; http.method; content:"POST"; http.header; content:"X-Forwarded-For"; nocase; http.uri; content:"p4"; nocase; http.uri; content:"search"; nocase; reference:cve,2026-103512; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-103512; classtype:attempted-admin; sid:2026103512; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=30s
  [network where process.name != null and network.direction == "inbound"]
  [http where http.request.method == "POST" and
    (http.request.headers contains "X-Forwarded-For" or http.request.headers contains "X-Real-IP") and
    url.path contains "search"]

Splunk SPL Query

index=perforce sourcetype="p4:search" OR sourcetype="perforce:search"
| search (event_type="authentication" OR event_type="auth" OR "ticket")
| eval suspicious_addr=if(match(_raw,"X-Forwarded-For|X-Real-IP|forwarded|trusted[_\-]address"),1,0)
| where suspicious_addr=1
| stats count values(client_address) as src_addrs values(user) as users by host, src_ip
| where count > 5
| sort - count

Wazuh OSSEC Rule

<group name="perforce,p4_search,">
  <rule id="100512" level="10">
    <decoded_as>json</decoded_as>
    <field name="event_type">authentication|auth_request</field>
    <regex type="pcre2">X-Forwarded-For|X-Real-IP|forwarded|trusted_address|trusted-address</regex>
    <description>CVE-2026-103512: Possible Perforce P4 Search trusted-address authentication bypass attempt</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>authentication_bypass,cve_2026_103512,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix has been confirmed through the tracked sources, and no workarounds are documented. The following guidance is prioritized defensively and should be validated against any future Perforce advisory.

1. Immediate mitigations:

• Reduce the prerequisite risk: tightly control and rotate Perforce P4 Server tickets, and shorten ticket lifetimes where configuration allows. Because exploitation requires a stolen ticket, limiting ticket exposure materially reduces exposure to this CVE.
• Restrict network access to P4 Search so that only known, trusted hosts and networks can reach the authentication surface. Do not rely solely on address-based ticket restrictions, since those are the controls this flaw bypasses.
• Where possible, front P4 Search with a trusted reverse proxy that strips client-supplied forwarding headers so client-controlled address values cannot reach the application's validation logic.
• Monitor authentication logs for successful access from unexpected source addresses and for requests carrying forwarding/address headers that do not match the actual peer.
• If Perforce provides a later fixed release (2026.4.2 or higher), treat it as the target; until confirmed, apply compensating network controls.

2. Patch/upgrade steps:

• Upgrade Perforce P4 Search to version 2026.4.2 or later once the fix is available from the vendor and verified by your change-management process.
• Re-validate the configuration of host-based ticket restrictions and trusted-address controls after upgrading to confirm they are enforced server-side.
• Rotate any tickets or service credentials that may have been exposed during the unpatched window.

3. Long-term hardening:

• Eliminate reliance on client-supplied values for any security decision; audit Perforce-related integrations for similar trust-of-input patterns.
• Adopt defense-in-depth so that a single stolen token does not yield broad access: least-privilege ticket scopes, short expiry, and network segmentation for SCM components.
• Maintain an inventory of Perforce components and versions and subscribe to vendor security advisories to shorten the detection-to-patch window for future issues.
• Centralize authentication logging and baseline normal source-address behavior to detect anomalies consistent with address spoofing or ticket replay.

References

• NVD: CVE-2026-103512 — https://nvd.nist.gov/vuln/detail/CVE-2026-103512
• CWE-290: Authentication Bypass by Spoofing — https://cwe.mitre.org/data/definitions/290.html
• Perforce product security advisories — https://www.perforce.com/security
• MITRE ATT&CK T1190: Exploit Public-Facing Application — https://attack.mitre.org/techniques/T1190/
• CISA Known Exploited Vulnerabilities Catalog (no entry for this CVE as of reporting) — https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No threat actor campaigns or exploit-in-the-wild evidence were identified for CVE-2026-103512. No public PoC, exploit code, or Nuclei template was found. The CVE is not listed in CISA KEV.