GHSA-VGRF-PR28-VF98

Vulnerability from github – Published: 2026-05-04 20:50 – Updated: 2026-05-08 20:14
VLAI?
Summary
CI4MS Vulnerable to Arbitrary Database Table Drop via Theme deleteProcess
Details

Summary

The deleteProcess() action accepts a POST parameter tables[] containing arbitrary table names. These are passed directly to $forge->dropTable() without validating that the tables belong to the theme being deleted.

The deleteConfirm view correctly populates tables[] from the theme's own migration files, but the server-side deleteProcess does not verify the received values against those files. An authenticated admin can craft a POST request with arbitrary table names and drop any table in the database.

This is a real bug even within the admin trust model: the action should be scoped to the theme's own tables. The permission grants delete this theme's data", not "drop any table".

Details

Location

modules/Theme/Controllers/Theme.php :: deleteProcess() ~line 147

Vulnerable Code

public function deleteProcess(string $slug)
{
    $themeName = $slug;
    $activeTheme = setting('App.siteTheme');
    if ($activeTheme === $themeName) {
        return redirect()->route('templateSettings')...;
    }

    $tablesToDrop = $this->request->getPost('tables');  // ← user-supplied, unvalidated
    if (!empty($tablesToDrop) && is_array($tablesToDrop)) {
        $forge = \Config\Database::forge();
        $db    = \Config\Database::connect();
        foreach ($tablesToDrop as $table) {
            if ($db->tableExists($table)) {
                $forge->dropTable($table, true);  // ← no whitelist check
            }
        }
    }

PoC

  1. Authenticate to the backend (any user with theme.delete permission)
  2. POST to /backend/themes/delete-process/<any_non_active_theme_slug>
  3. Include tables[]=<any_table> in POST body
  4. The named tables are dropped without validation

Impact

  • Dropped ci4ms_blog (confirmed in test)
  • Dropped ci4ms_users + ci4ms_auth_identities simultaneously — disables all authentication (confirmed)
  • Any table in the database can be targeted

Additional note

Quick note on the design intent for deleteProcess — I noticed delete_confirm.php scopes the checkboxes to the theme's own migration files, and the CHANGELOG confirms the selective deletion was intentional (admins can choose which tables to keep). The server-side deleteProcess already has all the information it needs to validate the input — deleteConfirm derives the valid table set from the migration files, deleteProcess just needs to do the same before acting on the POST. Happy to clarify if useful.

Severity ?
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.31.7.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "ci4-cms-erp/ci4ms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.31.1.0"
            },
            {
              "fixed": "0.31.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41890"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T20:50:10Z",
    "nvd_published_at": "2026-05-07T04:16:33Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe `deleteProcess()` action accepts a POST parameter `tables[]` containing arbitrary table names. These are passed directly to `$forge-\u003edropTable()` without validating that the tables belong to the theme being deleted.\n\nThe `deleteConfirm` view correctly populates `tables[]` from the theme\u0027s own migration files, but the server-side `deleteProcess` does not verify the received values against those files. An authenticated admin can craft a POST request with arbitrary table names and drop any table in the database.\n\nThis is a real bug even within the admin trust model: the action should be scoped to the theme\u0027s own tables. The permission grants  delete this theme\u0027s data\", not \"drop any table\".\n\n### Details\n\n### Location\n`modules/Theme/Controllers/Theme.php` :: `deleteProcess()` ~line 147\n\n### Vulnerable Code\n```php\npublic function deleteProcess(string $slug)\n{\n    $themeName = $slug;\n    $activeTheme = setting(\u0027App.siteTheme\u0027);\n    if ($activeTheme === $themeName) {\n        return redirect()-\u003eroute(\u0027templateSettings\u0027)...;\n    }\n\n    $tablesToDrop = $this-\u003erequest-\u003egetPost(\u0027tables\u0027);  // \u2190 user-supplied, unvalidated\n    if (!empty($tablesToDrop) \u0026\u0026 is_array($tablesToDrop)) {\n        $forge = \\Config\\Database::forge();\n        $db    = \\Config\\Database::connect();\n        foreach ($tablesToDrop as $table) {\n            if ($db-\u003etableExists($table)) {\n                $forge-\u003edropTable($table, true);  // \u2190 no whitelist check\n            }\n        }\n    }\n```\n\n### PoC\n1. Authenticate to the backend (any user with theme.delete permission)\n2. POST to `/backend/themes/delete-process/\u003cany_non_active_theme_slug\u003e`\n3. Include `tables[]=\u003cany_table\u003e` in POST body\n4. The named tables are dropped without validation\n\n### Impact\n- Dropped `ci4ms_blog` (confirmed in test)\n- Dropped `ci4ms_users` + `ci4ms_auth_identities` simultaneously \u2014 disables all authentication (confirmed)\n- Any table in the database can be targeted\n\n### Additional note\nQuick note on the design intent for deleteProcess \u2014 I noticed delete_confirm.php scopes the checkboxes to the theme\u0027s own migration files, and the CHANGELOG confirms the selective deletion was intentional (admins can choose which tables to keep). The server-side deleteProcess already has all the information it needs to validate the input \u2014 deleteConfirm derives the valid table set from the migration files, deleteProcess just needs to do the same before acting on the POST. Happy to clarify if useful.",
  "id": "GHSA-vgrf-pr28-vf98",
  "modified": "2026-05-08T20:14:36Z",
  "published": "2026-05-04T20:50:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ci4-cms-erp/ci4ms/security/advisories/GHSA-vgrf-pr28-vf98"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41890"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ci4-cms-erp/ci4ms/commit/2f38284281ce6b435ea42003951f14109ac2cea7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ci4-cms-erp/ci4ms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ci4-cms-erp/ci4ms/releases/tag/0.31.8.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "CI4MS Vulnerable to Arbitrary Database Table Drop via Theme deleteProcess"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.