CVE-2023-44401

Executive Summary

CVE-2023-44401 is a permission bypass vulnerability in the Silverstripe CMS GraphQL Server. The flaw allows an unauthenticated attacker to bypass canView permission checks on ORM data when querying paginated GraphQL results. If the total number of records exceeds the page size, the server may return records that the user should not have access to. This affects both paginated queries and queries with a limit applied. The vulnerability has a CVSS score of 5.3 (Medium) and is classified as CWE-863 (Incorrect Authorization). No public exploit code or PoC is currently available, and the EPSS score is 0.0%, indicating low exploitation likelihood at this time.

Supply Chain & Package Security

This vulnerability affects the Silverstripe CMS ecosystem, specifically the silverstripe/graphql module. Silverstripe is a PHP-based CMS. The vulnerable package is distributed via Composer. Organizations should verify their composer.json for the silverstripe/graphql dependency and ensure it is updated to a patched version. No known malicious packages or typosquatting attempts have been reported in relation to this CVE.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
• Base Score: 5.3 (Medium)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: Low (C:L) – Unauthorized access to ORM data.
• Integrity Impact: None (I:N)
• Availability Impact: None (A:N)

Threat Level: Medium. The vulnerability is easy to exploit remotely without authentication, but the impact is limited to unauthorized data disclosure. The lack of public exploit code and low EPSS score reduce immediate risk, but the potential for data leakage in sensitive applications warrants prompt patching.

Deep Dive & Mechanics

The vulnerability resides in the GraphQL pagination logic of Silverstripe CMS. When a GraphQL query requests paginated results (e.g., using first and offset arguments), the server fetches records from the database in batches. The canView permission check is intended to filter out records the user is not authorized to see. However, due to a flaw in the implementation, the permission check is only applied to the records returned for the current page, not to the entire dataset.

Root Cause: The server fetches a page of records from the database, then applies canView checks. If a record fails the check, it is removed from the page. However, the server does not compensate by fetching additional records from the database to fill the page. This means that if the total number of records exceeds the page size, the server may inadvertently include records from subsequent pages that were not permission-checked. In effect, the permission check is bypassed for records that appear on pages beyond the first.

Example Scenario:

• A user queries for 10 records per page.
• The database has 20 records, but the user should only see 5 (due to canView restrictions).
• The server fetches the first 10 records from the database.
• It applies canView and removes 5, leaving 5 on the page.
• The server then fetches the next 10 records (records 11-20) for the second page.
• It applies canView and removes 5, leaving 5 on the second page.
• However, the user should not have seen any of the records on the second page because they were all unauthorized. The vulnerability allows the user to see those 5 unauthorized records.

Affected Components:

• silverstripe/graphql module versions 4.0.0 to 4.3.6 and 5.0.0 to 5.1.2.
• The CanViewPermission plugin is responsible for the permission check. Disabling this plugin removes the check entirely, which is not recommended.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

// In the pagination resolver
public function resolve($args) {
    $pageSize = $args['first'];
    $offset = $args['offset'];
    $records = DataObject::get()->limit($pageSize, $offset);
    $filtered = [];
    foreach ($records as $record) {
        if ($record->canView()) {
            $filtered[] = $record;
        }
    }
    return $filtered;
}

In this vulnerable version, the server fetches exactly $pageSize records from the database and then filters them. If some records are filtered out, the page may contain fewer records than $pageSize, but the server does not fetch additional records to fill the gap. This allows unauthorized records to appear on subsequent pages.

Patched Code (Conceptual):

// In the pagination resolver
public function resolve($args) {
    $pageSize = $args['first'];
    $offset = $args['offset'];
    $allRecords = DataObject::get(); // Fetch all records
    $filtered = [];
    foreach ($allRecords as $record) {
        if ($record->canView()) {
            $filtered[] = $record;
        }
    }
    // Apply pagination after permission check
    $page = array_slice($filtered, $offset, $pageSize);
    return $page;
}

The patched version fetches all records, applies canView to every record, and then paginates the filtered list. This ensures that only authorized records are returned, and pagination is consistent. Note that this may have performance implications for large datasets, but it is the correct behavior.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A Silverstripe CMS instance running a vulnerable version (e.g., 4.3.6 or 5.1.2).
• The GraphQL endpoint enabled (typically /graphql).
• Knowledge of the GraphQL schema (can be obtained via introspection).

Exploitation Steps:

1. Identify the GraphQL endpoint: Use a tool like curl or GraphQL Playground to query the endpoint.

   curl -X POST http://target.com/graphql -H "Content-Type: application/json" -d '{"query":"{ __schema { types { name } } }"}'
   

2. Find a paginated query: Look for queries that return lists of objects (e.g., allPages, allMembers).
3. Craft a paginated query: Request a small page size and iterate through pages to observe unauthorized data.

   query {
     allPages(first: 5, offset: 0) {
       nodes {
         id
         title
         content
       }
     }
   }
   

4. Iterate through pages: Change the offset value to access subsequent pages. If the total number of records is large, you may see records that should be restricted.
5. Confirm bypass: Compare the results with an authenticated session that has full access. If unauthenticated results include records that require specific permissions, the vulnerability is confirmed.

No public exploit code is available. The above steps are a general methodology.

Blue Team

Detection:

• Monitor GraphQL query logs for unusual pagination patterns, especially requests with large offset values or repeated pagination queries from the same IP.
• Look for queries that return more records than expected for a given user role.
• Enable logging of canView failures and correlate with GraphQL requests.

Hunting:

• Search for GraphQL queries that do not include authentication tokens but still return data.
• Review database query logs for unexpected SELECT statements that fetch large numbers of records.

Mitigation:

• Apply the patch immediately (upgrade to 4.3.7 or 5.1.3).
• If patching is not possible, disable the CanViewPermission plugin as a temporary workaround (note: this removes all permission checks).
• Implement Web Application Firewall (WAF) rules to block suspicious GraphQL queries.

Indicators of Compromise (IOCs)

• Network:
  • Repeated GraphQL queries with varying offset values from the same source IP.
  • GraphQL queries that return data without a valid authentication token.
• Logs:
  • Silverstripe access logs showing /graphql requests with first and offset parameters.
  • Database query logs showing large SELECT statements on ORM tables without corresponding permission checks.
• File:
  • No specific file-based IOCs.

Detection Engineering

YARA Rule

rule CVE_2023_44401_Silverstripe_GraphQL {
    meta:
        description = "Detects Silverstripe GraphQL pagination permission bypass"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2023-44401"
    strings:
        $graphql_endpoint = "/graphql"
        $pagination_param = "first"
        $offset_param = "offset"
    condition:
        all of them
}

Sigma Rule

title: Silverstripe GraphQL Pagination Permission Bypass
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects attempts to exploit CVE-2023-44401 by querying paginated GraphQL endpoints without authentication.
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: access_log
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/graphql'
        cs-uri-query|contains: 
            - 'first'
            - 'offset'
    condition: selection
falsepositives:
    - Legitimate paginated queries from authenticated users
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2023-44401 Silverstripe GraphQL Pagination Bypass"; flow:to_server; content:"POST"; http_method; content:"/graphql"; http_uri; content:"first"; http_client_body; content:"offset"; http_client_body; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Patch: Upgrade to Silverstripe CMS 4.3.7 or 5.1.3. This is the only complete fix.
2. Workaround: If patching is delayed, disable the CanViewPermission plugin by adding the following to your app/_config/graphql.yml:

   SilverStripe\GraphQL\Permission\CanViewPermission:
     enabled: false
   

   Warning: This removes all canView permission checks for GraphQL queries, potentially exposing all data.

Long-term Measures:

• Implement strict access controls on the GraphQL endpoint (e.g., require authentication for all queries).
• Monitor for unusual GraphQL activity.
• Regularly update Silverstripe CMS and its modules.

Valters IT Signature

Report generated by Valters IT DevSecOps Framework CVE-2023-44401 | Silverstripe GraphQL Permission Bypass Classification: Medium | CWE-863 | CVSS 5.3 Patch: Upgrade to 4.3.7 or 5.1.3