GHSA-F97C-PH8J-8VFF

Vulnerability from github – Published: 2026-08-28 19:05 – Updated: 2026-08-28 19:05
VLAI
Summary
Pimcore: Insufficient Permission Check on Class Definition Creation Endpoint Allows Privilege Escalation
Details

Summary

The Studio API class definition creation endpoint in pimcore/studio-backend-bundle is guarded by the objects permission instead of the classes permission, allowing any standard editor-level user to create class definitions without admin privileges. Class definition creation is a structural admin operation that generates new database tables and PHP class files on the server. Additionally, the API layer performs no format validation on the uid field before passing it to the model layer, relying solely on model-level validation that exists downstream in ClassDefinition::saveClassInternal().

Details

Issue 1 — Incorrect permission guard on CreateController

studio-backend-bundle/src/Class/Controller/DefinitionConfiguration/CreateController.php:

#[IsGranted(UserPermissions::DATA_OBJECTS->value)]

The endpoint POST /pimcore-studio/api/class/definition/configuration-view/detail/create is protected by DATA_OBJECTS (the objects permission), which is a standard editor-level permission granted to content editors for creating and editing data objects. Class definition creation is a structural admin operation equivalent to schema modification, it creates new database tables and generates PHP class files on the server. This operation should require the classes permission, which is the permission Pimcore enforces for class definition management in the Classic Admin.

Any authenticated user with object editing rights can call this endpoint and create new class definitions, bypassing the intended admin-only restriction. The same user cannot perform this action through the Classic Admin UI, confirming the Studio API enforces a weaker permission check than the existing interface.

Correct guard:

#[IsGranted(UserPermissions::CLASSES->value)]

Issue 2 — No UID format validation at the API layer

studio-backend-bundle/src/Class/MappedParameter/CreateClassDefinitionParameters.php:

public function __construct(
    private string $name,
    private string $uid
) {
    if (trim($name) === '' || trim($uid) === '') {
        throw new InvalidArgumentException('Class name and UID cannot be empty.');
    }
}

Only an empty-string check is performed on uid at the API boundary before the value is passed to the model layer. While ClassDefinition::saveClassInternal() now validates the UID format via anchored regex, no equivalent validation exists in CreateClassDefinitionParameters. A malformed UID passes through the API layer without any format check and only fails deep in the model layer, returning an unformatted internal exception to the caller rather than a clean 400 API validation response, which can expose internal stack traces depending on server configuration.

Defense-in-depth requires validation at the API boundary consistent with the model layer. The same regex now applied in ClassDefinition.php should also be enforced here:

if (!preg_match('/^[a-zA-Z0-9][a-zA-Z0-9_]*$/', trim($this->uid))) {
    throw new InvalidArgumentException(
        sprintf('Invalid UID for class definition: %s', $this->uid)
    );
}

Affected files in pimcore/studio-backend-bundle: - src/Class/Controller/DefinitionConfiguration/CreateController.php - src/Class/MappedParameter/CreateClassDefinitionParameters.php

Vulnerable endpoint: POST /pimcore-studio/api/class/definition/configuration-view/detail/create

PoC

Prerequisites: - Pimcore 2026.1.x with Studio API enabled - A user editor with only the objects permission and no classes permission

Step 1 — Authenticate as the editor user:

curl -s -c /tmp/cookies.txt -X POST \
  "https://your-pimcore/pimcore-studio/api/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"editor","password":"password"}'

Expected response:

{"message": "Login successful"}

Step 2 — Confirm the user has no class management access in Classic Admin

Log into Classic Admin as editor. Verify the Classes menu is not visible and the user cannot access Settings > Classes. This confirms the classes permission is not granted to this user.

Step 3 — Create a class definition via the Studio API despite lacking the classes permission:

curl -s -b /tmp/cookies.txt -X POST \
  "https://your-pimcore/pimcore-studio/api/class/definition/configuration-view/detail/create" \
  -H "Content-Type: application/json" \
  -d '{"name":"UnauthorizedClass","uid":"testuid1"}'

Expected response (vulnerable):

{"id": "testuid1", "name": "UnauthorizedClass", ...}

The class definition is created successfully by a user with no classes permission. The Studio API accepts the request where the Classic Admin would deny it entirely.

Expected response (patched):

{"status": 403, "detail": "Access denied."}

Impact

Any authenticated Pimcore user with the standard objects permission can create class definitions via the Studio API, bypassing the classes permission restriction enforced in the Classic Admin. This is a privilege escalation from editor level to a capability that should be restricted to administrators. Class definition creation generates new database tables and PHP class files on the server, giving an unprivileged user the ability to modify the application schema, introduce malformed class structures, and trigger downstream processing outside their permission scope.

The missing API-layer UID validation compounds this by allowing malformed UIDs to reach the model layer, producing unhandled internal exceptions that may expose stack traces depending on server debug configuration.

  • Authentication required from attacker: Yes - valid Pimcore session with objects permission required
  • Authentication required from victim: No - no victim action needed
  • What is accessible: Full class definition creation capability including database table generation and PHP class file creation on the server
Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 2025.4.6"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "pimcore/studio-backend-bundle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "pimcore/studio-backend-bundle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2026.1.0"
            },
            {
              "fixed": "2026.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55212"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-285"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T19:05:25Z",
    "nvd_published_at": "2026-07-09T21:16:56Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nThe Studio API class definition creation endpoint in `pimcore/studio-backend-bundle` is guarded by the `objects` permission instead of the `classes` permission, allowing any standard editor-level user to create class definitions without admin privileges. Class definition creation is a structural admin operation that generates new database tables and PHP class files on the server. Additionally, the API layer performs no format validation on the `uid` field before passing it to the model layer, relying solely on model-level validation that exists downstream in `ClassDefinition::saveClassInternal()`.\n\n### Details\n\n### Issue 1 \u2014 Incorrect permission guard on CreateController\n\n`studio-backend-bundle/src/Class/Controller/DefinitionConfiguration/CreateController.php`:\n\n```php\n#[IsGranted(UserPermissions::DATA_OBJECTS-\u003evalue)]\n```\n\nThe endpoint `POST /pimcore-studio/api/class/definition/configuration-view/detail/create` is protected by `DATA_OBJECTS` (the `objects` permission), which is a standard editor-level permission granted to content editors for creating and editing data objects. Class definition creation is a structural admin operation equivalent to schema modification, it creates new database tables and generates PHP class files on the server. This operation should require the `classes` permission, which is the permission Pimcore enforces for class definition management in the Classic Admin.\n\nAny authenticated user with object editing rights can call this endpoint and create new class definitions, bypassing the intended admin-only restriction. The same user cannot perform this action through the Classic Admin UI, confirming the Studio API enforces a weaker permission check than the existing interface.\n\n**Correct guard:**\n```php\n#[IsGranted(UserPermissions::CLASSES-\u003evalue)]\n```\n\n### Issue 2 \u2014 No UID format validation at the API layer\n\n`studio-backend-bundle/src/Class/MappedParameter/CreateClassDefinitionParameters.php`:\n\n```php\npublic function __construct(\n    private string $name,\n    private string $uid\n) {\n    if (trim($name) === \u0027\u0027 || trim($uid) === \u0027\u0027) {\n        throw new InvalidArgumentException(\u0027Class name and UID cannot be empty.\u0027);\n    }\n}\n```\n\nOnly an empty-string check is performed on `uid` at the API boundary before the value is passed to the model layer. While `ClassDefinition::saveClassInternal()` now validates the UID format via anchored regex, no equivalent validation exists in `CreateClassDefinitionParameters`. A malformed UID passes through the API layer without any format check and only fails deep in the model layer, returning an unformatted internal exception to the caller rather than a clean 400 API validation response, which can expose internal stack traces depending on server configuration.\n\nDefense-in-depth requires validation at the API boundary consistent with the model layer. The same regex now applied in `ClassDefinition.php` should also be enforced here:\n\n```php\nif (!preg_match(\u0027/^[a-zA-Z0-9][a-zA-Z0-9_]*$/\u0027, trim($this-\u003euid))) {\n    throw new InvalidArgumentException(\n        sprintf(\u0027Invalid UID for class definition: %s\u0027, $this-\u003euid)\n    );\n}\n```\n\n**Affected files in `pimcore/studio-backend-bundle`:**\n- `src/Class/Controller/DefinitionConfiguration/CreateController.php`\n- `src/Class/MappedParameter/CreateClassDefinitionParameters.php`\n\n**Vulnerable endpoint:**\n`POST /pimcore-studio/api/class/definition/configuration-view/detail/create`\n\n### PoC\n\n**Prerequisites:**\n- Pimcore 2026.1.x with Studio API enabled\n- A user `editor` with only the `objects` permission and no `classes` permission\n\n**Step 1 \u2014 Authenticate as the editor user:**\n\n```bash\ncurl -s -c /tmp/cookies.txt -X POST \\\n  \"https://your-pimcore/pimcore-studio/api/login\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"username\":\"editor\",\"password\":\"password\"}\u0027\n```\n\nExpected response:\n```json\n{\"message\": \"Login successful\"}\n```\n\n**Step 2 \u2014 Confirm the user has no class management access in Classic Admin**\n\nLog into Classic Admin as `editor`. Verify the Classes menu is not visible and\nthe user cannot access Settings \u003e Classes. This confirms the `classes` permission\nis not granted to this user.\n\n**Step 3 \u2014 Create a class definition via the Studio API despite lacking the classes permission:**\n\n```bash\ncurl -s -b /tmp/cookies.txt -X POST \\\n  \"https://your-pimcore/pimcore-studio/api/class/definition/configuration-view/detail/create\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"name\":\"UnauthorizedClass\",\"uid\":\"testuid1\"}\u0027\n```\n\nExpected response (vulnerable):\n```json\n{\"id\": \"testuid1\", \"name\": \"UnauthorizedClass\", ...}\n```\n\nThe class definition is created successfully by a user with no `classes` permission.\nThe Studio API accepts the request where the Classic Admin would deny it entirely.\n\nExpected response (patched):\n```json\n{\"status\": 403, \"detail\": \"Access denied.\"}\n```\n\n### Impact\nAny authenticated Pimcore user with the standard `objects` permission can create class definitions via the Studio API, bypassing the `classes` permission restriction enforced in the Classic Admin. This is a privilege escalation from editor level to\na capability that should be restricted to administrators. Class definition creation generates new database tables and PHP class files on the server, giving an unprivileged user the ability to modify the application schema, introduce malformed class structures, and trigger downstream processing outside their permission scope.\n\nThe missing API-layer UID validation compounds this by allowing malformed UIDs to reach the model layer, producing unhandled internal exceptions that may expose stack traces depending on server debug configuration.\n\n- **Authentication required from attacker:** Yes - valid Pimcore session with  `objects` permission required\n- **Authentication required from victim:** No - no victim action needed\n- **What is accessible:** Full class definition creation capability including database table generation and PHP class file creation on the server",
  "id": "GHSA-f97c-ph8j-8vff",
  "modified": "2026-08-28T19:05:25Z",
  "published": "2026-08-28T19:05:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/pimcore/security/advisories/GHSA-f97c-ph8j-8vff"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55212"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/studio-backend-bundle/pull/1886"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/studio-backend-bundle/commit/d1a4788c0f159c360d550c34256c8abbbd633ae0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pimcore/pimcore"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/studio-backend-bundle/releases/tag/v2025.4.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/studio-backend-bundle/releases/tag/v2026.1.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Pimcore: Insufficient Permission Check on Class Definition Creation Endpoint Allows Privilege Escalation"
}



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.