CVE-2023-22836

Executive Summary

CVE-2023-22836 is a low-severity information disclosure vulnerability affecting Palantir Foundry's Linter service in multi-tenant deployments. The flaw allows a tenant user who renames a group from its default value to inadvertently expose that renamed value to other tenants on the same stack. This is a cross-tenant data leak that violates the multi-tenant isolation model. The vulnerability has a CVSS score of 3.5 (Low) and an EPSS score of 0.0%, indicating very low exploitation likelihood. No public proof-of-concept or exploit code exists. The vendor has not confirmed a patch status.

Supply Chain & Package Security

This vulnerability is not related to any open-source package (NPM, PyPI, Go, Ruby). It is a proprietary SaaS configuration issue within Palantir Foundry.

CVSS Breakdown & Threat Level

• CVSS Score: 3.5 (Low)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
• Attack Vector: Network (AV:N) – The attack is performed over the network.
• Attack Complexity: Low (AC:L) – No special conditions required.
• Privileges Required: Low (PR:L) – Attacker needs a valid tenant user account.
• User Interaction: None (UI:N) – No user action required.
• Scope: Unchanged (S:U) – The vulnerable component and impacted component are the same.
• Confidentiality Impact: Low (C:L) – Limited information disclosure (group names).
• Integrity Impact: None (I:N) – No data modification.
• Availability Impact: None (A:N) – No service disruption.

Threat Level: Low. The vulnerability requires an authenticated tenant user and only leaks group names, not sensitive data. However, in multi-tenant environments, group names may reveal organizational structure or project names.

Deep Dive & Mechanics

The vulnerability resides in Palantir Foundry's Linter service, which is used for code quality and policy enforcement. In a multi-tenant stack, each tenant has isolated resources, including groups. When a tenant user renames a group from its default name (e.g., "default-group" to "project-alpha"), the Linter service fails to properly scope the renamed group to the tenant's namespace. Instead, the renamed value becomes visible to other tenants on the same stack.

Root Cause: The Linter service likely caches or stores group metadata in a shared namespace without proper tenant isolation. When a group is renamed, the update is propagated to a global cache or database that is accessible by all tenants. The service does not enforce a tenant-specific prefix or access control check when returning group names.

Attack Scenario:

1. Attacker (tenant A) logs into Foundry and accesses the Linter service.
2. Attacker renames a group from its default name (e.g., "default-group") to a custom name (e.g., "secret-project").
3. Victim (tenant B) uses the Linter service and sees the renamed group name "secret-project" in their list of available groups.
4. Victim can infer that tenant A is working on a project named "secret-project".

Vulnerable vs. Patched Code

Since no patch details are available, we can only hypothesize the vulnerable and patched code patterns.

Vulnerable Code (Hypothetical):

# Vulnerable: Group name stored without tenant isolation
def rename_group(group_id, new_name):
    group = db.groups.find_one({"_id": group_id})
    group["name"] = new_name
    db.groups.save(group)
    # Cache updated globally
    cache.set(f"group_name_{group_id}", new_name)

Patched Code (Hypothetical):

# Patched: Group name stored with tenant isolation
def rename_group(tenant_id, group_id, new_name):
    group = db.groups.find_one({"tenant_id": tenant_id, "_id": group_id})
    group["name"] = new_name
    db.groups.save(group)
    # Cache updated with tenant-specific key
    cache.set(f"tenant_{tenant_id}_group_name_{group_id}", new_name)

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• Valid user account on a multi-tenant Palantir Foundry stack.
• Access to the Linter service.
• Ability to rename a group.

Steps:

1. Log in to Foundry as a tenant user.
2. Navigate to the Linter service.
3. Identify a group with a default name (e.g., "default-group").
4. Rename the group to a distinctive name (e.g., "my-secret-project").
5. Switch to another tenant account (or collaborate with another tenant user) and access the Linter service.
6. Observe that the renamed group name is visible in the group list.

Proof-of-Concept (No exploit code available):

# No public exploit code exists. This is a configuration-based attack.
# Steps are manual via the Foundry UI.

Blue Team (Defender)

Detection:

• Monitor for group rename events in audit logs.
• Look for cross-tenant access patterns in Linter service logs.
• Alert on group names that appear in multiple tenant contexts.

Mitigation:

• Ensure tenant isolation is enforced at the application layer.
• Implement strict access control checks when returning group metadata.
• Use tenant-specific prefixes or namespaces for all cached data.

Lab Setup:

• Deploy a multi-tenant Palantir Foundry instance (if available).
• Create two tenant accounts.
• Use the Linter service to rename a group from one tenant and verify visibility from the other.

Indicators of Compromise (IOCs)

• Log Entries: Group rename events in audit logs without tenant context.
• Network Traffic: API calls to /linter/groups/rename or similar endpoints.
• Behavioral: A group name appearing in multiple tenant contexts in Linter service responses.

Example IOC (Log Entry):

{
  "event": "group_rename",
  "user": "tenant_a_user",
  "group_id": "g-12345",
  "old_name": "default-group",
  "new_name": "my-secret-project",
  "tenant_id": "tenant_a"
}

Detection Engineering

YARA Rule

rule CVE_2023_22836_GroupRenameLeak {
    meta:
        description = "Detects group rename events that may indicate CVE-2023-22836 exploitation"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2023-22836"
    strings:
        $rename_event = "group_rename" nocase
        $linter_service = "linter" nocase
        $tenant_context = "tenant_id" nocase
    condition:
        $rename_event and $linter_service and not $tenant_context
}

Sigma Rule

title: CVE-2023-22836 - Cross-Tenant Group Name Leak
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects group rename events without tenant context in Palantir Foundry Linter service
author: Valters IT
date: 2025-04-10
logsource:
    product: palantir_foundry
    service: linter
detection:
    selection:
        event: "group_rename"
    filter:
        tenant_id: null
    condition: selection and filter
falsepositives:
    - Legitimate group renames in single-tenant stacks
level: low

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2023-22836 - Cross-Tenant Group Name Leak"; flow:to_server; content:"/linter/groups/rename"; http_uri; nocase; content:"new_name"; http_client_body; nocase; pcre:"/tenant_id[^}]*null/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Isolate Tenant Data: Ensure all group metadata is stored with tenant-specific keys or namespaces.
2. Audit Logs: Review audit logs for group rename events and verify tenant isolation.
3. Access Controls: Implement strict access control checks when returning group names to ensure only the owning tenant can see them.

Long-Term Fix:

• Apply vendor patch if available. Contact Palantir support for guidance.
• Implement a tenant-aware caching layer that prefixes all keys with the tenant ID.
• Conduct a security review of multi-tenant isolation in all Foundry services.

Workarounds:

• Disable group renaming functionality if not required.
• Restrict Linter service access to trusted users only.

Valters IT Signature: This report was generated by Valters IT DevSecOps AI. For questions, contact security@valters-it.com.