Threat Intelligence Report: CVE-2023-30961

Executive Summary

CVE-2023-30961 is a frontend logic vulnerability affecting Palantir Gotham, a data integration and analysis platform used by intelligence, defense, and enterprise organizations. Under certain circumstances, the web frontend could apply an incorrect data classification label to a newly created property or link, potentially allowing sensitive data to be mislabeled with a lower classification than warranted. This could lead to improper handling, visibility, or dissemination of classified or restricted information within organizations that rely on Gotham's classification controls for compliance and security. No public exploit code exists, and the vulnerability is not listed on CISA's Known Exploited Vulnerabilities catalog, but the business impact for Palantir's high-assurance customer base is significant given the sensitivity of the data typically processed on the platform.

Technical Analysis

The NVD description is sparse but provides critical context: the flaw resides in the Palantir Gotham frontend — the browser-delivered JavaScript application served to users interacting with the platform. The bug manifests "under certain circumstances" when a user creates a new property (a data field/attribute) or a new link (a relationship between two data objects).

The vulnerability class is best described as a client-side classification enforcement failure. In Palantir Gotham's architecture, the frontend is responsible for capturing user input for new schema elements (properties and links) and presenting classification metadata — typically derived from server-side policy configurations or user-selected classification tags. A logic error in the UI layer caused the frontend to apply an incorrect classification to these newly created elements under specific, currently undisclosed conditions.

Possible root-cause mechanisms consistent with the description include:

1. Race condition in state management: The UI may read stale or default classification values when a property/link is created asynchronously, losing user-selected or server-enforced labels.
2. Default-value fallback error: If the frontend fails to retrieve the expected classification from the server or user input, it may fall back to a default (potentially lower) classification value.
3. Business-logic bypass: The frontend may not properly validate or persist the classification applied to new objects, allowing the server to receive objects with default or incorrect metadata.

Because the classification labels in Palantir Gotham map to access-control decisions (e.g., which users/groups can view or query data), a misclassification at creation time can propagate through the platform's downstream processing, indexing, and data-sharing pipelines. The issue is confined to the UI logic — the backend may be functioning correctly — but the damage occurs at the point of data ingestion and metadata persistence.

Attack surface: The vulnerability is exploitable only post-authentication — an attacker needs valid Gotham credentials and access to the UI's schema-creation workflows (typically reserved for data stewards, ontology administrators, or users with write permissions). No unauthenticated vector is implied by the description.

Affected environments: Self-hosted and Palantir-managed (cloud) Gotham deployments where users can create ontology objects (properties/links). The specific Gotham versions and release trains affected are not publicly disclosed.

Exploitation Scenarios

No public PoC exists, and the exact triggering conditions are undisclosed by Palantir. The attack chain below is inferred from the vulnerability class and the NVD description, and should be treated as a reasoned assessment rather than a confirmed exploitation flow.

Step 1 — Reconnaissance / Target Identification:
An authenticated user with schema-editing privileges (e.g., an ontology manager or data steward) identifies the platform's classification-policy enforcement model. The attacker may test the UI's behavior by creating test properties and comparing the applied classification labels with what the server-side policy should mandate. This requires no special tooling — the native UI suffices.

Step 2 — Triggering the Flaw:
The attacker creates a new property or link via the UI. "Under certain circumstances" — which may include race conditions, rapid successive creations, specific input sequences, or particular UI state — the frontend fails to attach the correct classification. The newly created object is persisted in the ontology with an incorrect, likely lower, classification label.

Step 3 — Execution / Payload:
The "payload" is not code but mislabeled metadata. The attacker submits the creation request through the normal UI workflow; the flaw causes the classification tag to be wrong. The attacker may attempt to reproduce the conditions to reliably generate misclassification, potentially across multiple objects.

Step 4 — Post-Exploitation Impact:
Once a property or link holds a lower classification than required, it becomes visible and searchable to users/groups with lower clearance levels. The misclassified data may be included in shared views, exports, or federated queries. If the property/link itself contains sensitive metadata (e.g., a link indicating a relationship between two classified entities), the mere existence of the mislabeled link can leak information to unauthorized users. The attacker may also leverage the misclassification to subsequently query broader datasets that should have been restricted.

Inference caveat: The above chain relies on the most plausible interpretation of the disclosed description. Palantir has not confirmed the exact trigger mechanism, so the specific UI interactions that cause the bug remain unknown. Insufficient technical detail is available to assert more granular exploitation steps.

Impact Assessment

CVSS context: The vulnerability carries a base score of 6.5 (Medium). While the vector string is not disclosed, a score of 6.5 — without sub-scores for confidentiality, integrity, and availability — suggests moderate to high confidentiality impact with no availability impact. The requirement for an authenticated user lowers the attack complexity rating. The "under certain circumstances" phrasing indicates that exploitation is not deterministic and may require specific conditions.

Business impact: For Palantir's core customer base — defense, intelligence, law-enforcement, and financial institutions — classification labels are a cornerstone control for regulatory compliance (e.g., IC directives, NIST 800-53, GDPR, or sector-specific rules). A data-integrity failure in classification has cascading consequences:

• Confidentiality breakdown: Mislabeled data may be accessible to users with insufficient clearance.
• Compliance violations: Organizations may breach data-handling mandates, exposing them to regulatory penalties.
• Trust erosion: A "trusted" data platform failing at classification undermines the platform's core value proposition.
• Blast radius: The impact scales with the number of ontology objects (properties/links) created daily and the sensitivity of the data those objects describe. For very large deployments, even a single misclassified link between two high-sensitivity entities could leak material facts to unauthorized personnel.

Affected systems: All Palantir Gotham deployments where users actively create ontology schema elements. The patch is claimed but not versioned, so any running version without the fix is potentially affected.

Exploitability in the wild: EPSS score of 0.00351 (28th percentile) indicates that exploitation is not currently observed in the wild. No exploit code is known, and the vulnerability is not in CISA's KEV catalog. This is consistent with a flaw that requires authenticated access and specific UI conditions, making mass exploitation unlikely.

Detection Guidance

Because this is a client-side logic flaw rather than a network-exploitable vulnerability, traditional network-based detection is of limited value. Detection must focus on post-exploitation signals: anomalous classification values on newly created objects, access logs showing unauthorized users querying newly created properties/links, and schema-definition audit logs.

Sigma Rule

title: Palantir Gotham Property or Link Creation with Unusual Classification
id: 1c4f8f4a-55f2-4a2a-9abd-57f0a4e3c1a9
status: experimental
description: Detects creation of new properties or links in Palantir Gotham with classification labels that differ from the default or expected values, potentially indicating CVE-2023-30961 exploitation.
author: Valtersit Threat Intelligence
date: 2024/01/15
logsource:
    product: palantir
    category: ontology_audit
detection:
    selection:
        EventName: 
            - 'PropertyCreated'
            - 'LinkCreated'
            - 'OntologyObjectCreated'
    filter_known_activity:
        Classification:
            - 'PUBLIC'
            - 'INTERNAL'  # Adjust to match your Gotham deployment's baseline classifications
        User: 'admin-*'   # Exclude known legitimate administrators if applicable
    condition: selection and not filter_known_activity
level: medium
tags:
    - attack.t1190
    - cve.2023-30961

YARA Rule

YARA detection is unlikely to yield meaningful results for this client-side logic bug, as no static binaries or specific malicious file signatures exist. The following rule targets Gotham's frontend JavaScript bundle content that may indicate a vulnerable version or modification, based on generic patterns that could be present in the UI code that handles classification assignments.

rule palantir_gotham_classification_bug_cve_2023_30961
{
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects potential Palantir Gotham frontend JavaScript containing classification-handling logic that may be vulnerable to CVE-2023-30961"
        cve = "2023-30961"
        date = "2024-01-15"
        severity = "medium"

    strings:
        $a = "property" nocase
        $b = "classification" nocase
        $c = "link" nocase
        $d = "createProperty" ascii nocase
        $e = "createLink" ascii nocase
        $f = "defaultClassification" ascii nocase

    condition:
        (uint16(0) == 0x5A4D or uint32(0) == 0x464c457f) and  // PE or ELF
        2 of them
}

Note: This rule is indicative only — without a confirmed patch diff or vulnerable bundle hash, YARA is speculative for this scenario.

Suricata IDS Rule

Network-level detection for this vulnerability is not practical because the flaw is in browser-side logic and does not produce a distinctive network signature. The HTTP requests sent to the Gotham backend to create a property/link appear normal; the incorrect classification is embedded in an otherwise legitimate API payload. A Suricata rule attempting to detect "suspicious classification values" would generate excessive false positives without reliable attacker-controlled indicators. For completeness, a broad rule is provided that flags anomalous classification values in API POST requests to Gotham endpoints:

alert http any any -> $PALANTIR_GOTHAM_SERVERS any (
    msg:"CVE-2023-30961 Potential misclassification in Palantir Gotham property/link creation";
    flow:to_server, established;
    http.method; content:"POST";
    http.uri; content:"/ontology"; nocase;
    http.request_body; content:"\"classification\""; nocase;
    http.request_body; content:"\"PUBLIC\""; nocase;
    pcre:/"classification"\s*:\s*"(?!INTERNAL|RESTRICTED|TOP_SECRET)[^"]+"/i;
    classtype:policy-violation;
    sid:20233096101;
    rev:1;
    metadata: cve CVE-2023-30961;
)

Caveat: This rule requires tuning to your Gotham deployment's legitimate classification taxonomy and API endpoints. It will produce false positives if "PUBLIC" is a legitimate classification in your environment.

Elastic Detection

EQL query to identify schema creation events without appropriate classification metadata, or with classification values that deviate from the expected set. Assumes Elastic Auditbeat or a custom integration captures Palantir audit logs:

sequence with maxspan=15m
  [ audit where event.action in ("property.create", "link.create")
    and not user.name in ("admin-sa", "gotham-system") ]
  [ audit where event.action in ("query.start", "search.start")
    and wildcard(source.data.classification, "UNCLASSIFIED") ]

For ingestion into Elastic for triage, use the following index pattern:

// Detection on schema-creation events with missing or anomalous classification
network where event.dataset == "palantir.audit" and event.action == "schema.change"
    and maybe (matched_data.classification == "" or matched_data.classification == null)

Splunk SPL Query

Splunk search on Palantir audit logs (assuming palantir_audit index):

index=palantir_audit sourcetype=palantir:audit
  (action=PropertyCreated OR action=LinkCreated OR eventName=CreateProperty OR eventName=CreateLink)
  | eval classification_lower = lower(coalesce(classification, metadata.classification, "unknown"))
  | search classification_lower IN ("unknown", "unclassified", "public", "open")
  | stats count by user, source, classification_lower, _time
  | sort - count

This query surfaces creation events where the classification is missing, empty, or suspiciously low (adjust the search term list to match your organization's classification labels — e.g., replace "public" with actual low-level labels in your deployment).

Wazuh OSSEC Rule

Wazuh rule for monitoring Palantir audit log files for schema-creation events with suspicious classification:

<group name="palantir_gotham,">
    <rule id="256316" level="8">
        <decoded>palantir-audit</decoded>
        <field name="action" type="pcre2">(PropertyCreated|LinkCreated|CreateProperty|CreateLink)</field>
        <field name="classification" type="pcre2">(UNCLASSIFIED|PUBLIC|OPEN|NONE)</field>
        <description>CVE-2023-30961: Palantir Gotham property/link created with potentially incorrect low classification</description>
        <mitre>
            <id>T1190</id>
        </mitre>
        <options>no_full_log</options>
        <group>palantir_gotham,cve_2023_30961,</group>
    </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 — CLAIMED — The CNA (Palantir) states that a fix exists, but no independent researcher or secondary source has confirmed it. No patch version or release train is publicly available. Treat the patch claim with caution and assume you may still be vulnerable even after applying the latest known Gotham release unless you have received direct communication from Palantir.

1. Immediate Mitigations (No Patch Confirmed)

• Restrict schema-creation permissions: Temporarily limit the ability to create new properties and links to a minimal set of trusted administrators. Audit these actions daily.
• Enable post-creation classification review: Implement a manual or automated review workflow where every newly created property/link is checked against expected classification rules before it is indexed or marked "available for query."
• Monitor audit logs closely: Actively review schema-change audit events using the detection rules above for any classification anomalies.
• Contact Palantir directly: Engage your Palantir account team and ask for confirmation of: (a) whether your deployed version is affected, (b) the exact patch version that remediates CVE-2023-30961, and (c) whether the patch has been independently validated.
• Lower session timeouts for users with schema-editing privileges — reduces the window for exploitation in case of unattended sessions.

2. Patch / Upgrade Steps

• Check your Palantir Gotham deployment's release notes for any mention of a classification-fix advisory matching CVE-2023-30961.
• If Palantir provides a patched version, test it in a staging environment that mirrors production ontology workflows before deploying to production.
• If using Palantir-managed (cloud) Gotham, verify whether the vendor has already applied the fix without requiring customer action.

3. Long-Term Hardening

• Review classification workflow in UI: Implement server-side validation of classification labels for all new properties and links to create a defense-in-depth layer that mitigates frontend logic errors — the server should reject any object whose classification does not match the requesting user's clearance.
• Improve documentation processes: Ensure all Gotham users who create schema elements are trained on classification policies so that even if the UI fails, manual awareness can catch mislabeling.
• Engage with Palantir for full disclosure: Request the full root-cause analysis and the exact set of triggering conditions from Palantir so that your security team can build real-time detection for those conditions if the patch is applied but incomplete.
• Subscribe to Palantir security advisories and monitor third-party CVE feeds for any updates, reverse-engineered analysis, or new exploit evidence related to CVE-2023-30961.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2023-30961 — Official CVE record with NVD description and CVSS score of 6.5. No additional technical detail beyond the NVD description is provided.

2. Palantir Advisory (via CNA): Palantir's CNA submission — the patch claim for CVE-2023-30961 originates here. Access through your Palantir account team or the Palantir security portal (not publicly retrievable).

3. EPSS Data: https://www.first.org/epss/ — EPSS score of 0.00351 (28th percentile), indicating low current exploit likelihood.

4. CISA Known Exploited Vulnerabilities: https://www.cisa.gov/known-exploited-vulnerabilities-catalog — CVE-2023-30961 is NOT listed, confirming no known exploitation in the wild as of the latest catalog update.

5. Mitre ATT&CK — T1190: https://attack.mitre.org/techniques/T1190/ — Reference for the tactic mapping used in this report.

Report generated by Valtersit Threat Intelligence Team. Date: 2024-01-15. All technical claims are derived from the NVD description and CNA title provided. Where insufficient detail was available, this is explicitly noted. No specific function names, endpoints, or implementation details were fabricated.