Common Weakness Enumeration

CWE-639

Allowed

Authorization Bypass Through User-Controlled Key

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

3800 vulnerabilities reference this CWE, most recent first.

GHSA-RM4X-93M8-4QCV

Vulnerability from github – Published: 2024-04-09 15:30 – Updated: 2025-02-07 21:30
VLAI
Details

A prompt bypass exists in the secondscreen.gateway service running on webOS version 4 through 7. An attacker can create a privileged account without asking the user for the security PIN. 

Full versions and TV models affected:

webOS 4.9.7 - 5.30.40 running on LG43UM7000PLA webOS 5.5.0 - 04.50.51 running on OLED55CXPUA webOS 6.3.3-442 (kisscurl-kinglake) - 03.36.50 running on OLED48C1PUB   webOS 7.3.1-43 (mullet-mebin) - 03.33.85 running on OLED55A23LA

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-6317"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-09T14:15:07Z",
    "severity": "HIGH"
  },
  "details": "A prompt bypass exists in the secondscreen.gateway service running on webOS version 4 through 7. An attacker can create a privileged account without asking the user for the security PIN.\u00a0\n\nFull versions and TV models affected:\n\nwebOS 4.9.7 - 5.30.40 running on LG43UM7000PLA \nwebOS 5.5.0 - 04.50.51 running on OLED55CXPUA \nwebOS 6.3.3-442 (kisscurl-kinglake) - 03.36.50 running on OLED48C1PUB \u00a0\nwebOS 7.3.1-43 (mullet-mebin) - 03.33.85 running on OLED55A23LA",
  "id": "GHSA-rm4x-93m8-4qcv",
  "modified": "2025-02-07T21:30:51Z",
  "published": "2024-04-09T15:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6317"
    },
    {
      "type": "WEB",
      "url": "https://bitdefender.com/blog/labs/vulnerabilities-identified-in-lg-webos"
    },
    {
      "type": "WEB",
      "url": "https://lgsecurity.lge.com/bulletins/tv#updateDetails"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RM5F-3C25-P4CW

Vulnerability from github – Published: 2026-04-14 18:30 – Updated: 2026-04-16 01:31
VLAI
Summary
Webkul Krayin CRM has Broken Object-Level Authorization (BOLA) in the /Controllers/Lead/LeadController.php
Details

A Broken Object-Level Authorization (BOLA) in the /Controllers/Lead/LeadController.php endpoint of Webkul Krayin CRM v2.2.x allows authenticated attackers to arbitrarily read, modify, and permanently delete any lead owned by other users via supplying a crafted GET request.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "krayin/laravel-crm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-38530"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T01:31:36Z",
    "nvd_published_at": "2026-04-14T16:16:43Z",
    "severity": "HIGH"
  },
  "details": "A Broken Object-Level Authorization (BOLA) in the /Controllers/Lead/LeadController.php endpoint of Webkul Krayin CRM v2.2.x allows authenticated attackers to arbitrarily read, modify, and permanently delete any lead owned by other users via supplying a crafted GET request.",
  "id": "GHSA-rm5f-3c25-p4cw",
  "modified": "2026-04-16T01:31:36Z",
  "published": "2026-04-14T18:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-38530"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TREXNEGRO/Security-Advisories/tree/main/CVE-2026-38530"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/krayin/laravel-crm"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Webkul Krayin CRM has Broken Object-Level Authorization (BOLA) in the /Controllers/Lead/LeadController.php"
}

GHSA-RM67-G9CH-VXFF

Vulnerability from github – Published: 2026-07-24 21:55 – Updated: 2026-07-24 21:55
VLAI
Summary
Poweradmin: Broken access control (IDOR): any zone owner can modify DNS records in zones they do not own
Details

Affected software

  • Product: Poweradmin (web front-end for PowerDNS)
  • Version tested: master, commit 7f28c3a97 (also reachable in the 4.x release line — the record-edit code is the same)
  • Component: record editing (web UI)
  • Vulnerability type: Broken Access Control / Insecure Direct Object Reference

Severity

Any authenticated user who owns at least one zone can tamper with records in every other zone on the server. In a shared/multi-tenant Poweradmin install this is effectively a cross-tenant DNS takeover.

Summary

When you save a record edit, Poweradmin checks whether you're allowed to touch the record by looking at a zone id you send in the POST body, but it then applies the change to a record id you also send in the POST body. Nothing checks that the record id actually belongs to that zone id. So you point the permission check at a zone you legitimately own, point the record id at somebody else's record, and the update goes through.

A low-privilege "Editor" who only owns attacker.example was able to overwrite a record living in victim.example (owned by the admin), even though the same account gets a flat "you do not have permission to access this zone" if it tries to open that zone directly.

Where the bug is

The core mistake is in RecordManager::editRecord() in lib/Domain/Service/Dns/RecordManager.php:

// line 298 – ownership is checked against the zone id from the request
$user_is_zone_owner = UserManager::verifyUserIsOwnerZoneId($this->db, $record['zid']);
...
// line 346 – but the update targets the record id from the request
$this->backendProvider->editRecord(
    $record['rid'], $name, $record['type'], $content, $validatedTtl, $validatedPrio, $record['disabled']
);

$record['zid'] and $record['rid'] are both taken straight from the submitted form. The permission gate uses one, the write uses the other, and they're never tied together.

The backend write has no zone scoping at all — lib/Infrastructure/Service/SqlDnsBackendProvider.php line 235:

$stmt = $this->db->prepare(
    "UPDATE $recordsTable SET name = ?, type = ?, content = ?, ttl = ?, prio = ?, disabled = ? WHERE id = ?"
);
$stmt->execute([$name, $type, $content, $ttl, $prio, $disabled, $recordId]);

It's WHERE id = ? on the record id and nothing else, so any record in the database is fair game.

The validation layer doesn't save it either. DnsRecordValidationService::validateRecord() (lib/Domain/Service/DnsRecordValidationService.php, around line 97) uses the zone id only to look up the zone name for hostname validation. It never verifies the record id lives in that zone.

There are two request paths that reach this same sink:

  1. Multi-record save — EditController::saveRecords() (lib/Application/Controller/EditController.php, ~line 571) loops over $_POST['record'] and hands each entry's rid/zid to editRecord() verbatim. The controller's run() only permission-checks the zone id in the URL (~line 204), not the zone id inside each record row.
  2. Single-record save — EditRecordController::saveRecord() reads $_POST['rid'] and forwards the whole $_POST (including the attacker-chosen zid) into editRecord().

For comparison, the delete path does it correctly. DeleteRecordController (~line 101) derives the zone id from the record id on the server side with getZoneIdFromRecordId() and checks permission against that. EditCommentController also uses the URL zone id for both the check and the write. So this really is an oversight in the edit path, not a deliberate design choice — the safe pattern already exists elsewhere in the same codebase.

Proof of concept

Setup (two accounts, two zones):

  • attacker — a normal user on the "Editor" permission template (zone_content_edit_own_as_client, i.e. can only edit records in zones it owns). Owns attacker.example, which is zone/domain id 3.
  • admin — owns victim.example, which is zone/domain id 2. That zone contains the record www.victim.example A 1.1.1.1 with record id 5.

Steps:

  1. Log in as attacker. Confirm the access control is actually there: browse to /zones/2/edit (victim.example). You get "You do not have permission to access this zone." Good — you genuinely can't edit that zone the normal way.

  2. Open your own zone's edit page, /zones/3/edit, and start a save (change any field and submit) with your intercepting proxy on. Catch the POST /zones/3/edit request. It already carries a valid CSRF _token and a valid serial for your zone, so don't touch those.

  3. Edit the record block in that request so it targets the victim's record while keeping your own zone id:

POST /zones/3/edit HTTP/1.1
Host: localhost:8080
Cookie: PHPSESSID=<your attacker session>
Content-Type: application/x-www-form-urlencoded

_token=<the valid token from step 2>&serial=<the valid serial from step 2>&commit=1
&record[5][rid]=5&record[5][zid]=3
&record[5][name]=pwned&record[5][type]=A&record[5][content]=6.6.6.6
&record[5][ttl]=3600&record[5][prio]=0

The important part: record[5][rid]=5 is the victim's record (in zone 2), and record[5][zid]=3 is your own zone (so the ownership check passes).

  1. Send it. You get HTTP 200.

  2. Check the result. Record 5, which lives in the admin's zone, is now overwritten:

sqlite> SELECT id, domain_id, name, type, content FROM records WHERE id = 5;
5|2|pwned.attacker.example|A|6.6.6.6

Screenshot 2026-07-06 162351

It's still domain_id = 2 (the victim's zone) but its content is now attacker-controlled. You changed a record in a zone you were explicitly denied access to in step 1.

Two practical notes if you're reproducing this:

  • The serial field is Poweradmin's optimistic-lock. It's checked against your own zone's current SOA serial and it bumps by one after every successful save, so grab a fresh one each time (the intercept-and-modify approach in step 2 handles this for you automatically).
  • Record ids are sequential integers, so in a real attack you'd just walk rid = 1, 2, 3, … to hit every record in every zone on the box.

Impact

With one owned zone, an attacker can rewrite content, type, ttl and the disabled flag of any record anywhere in the installation. Concretely that means:

  • Repointing or corrupting other customers' / other departments' DNS records (integrity).
  • Silently disabling records by setting disabled = 1 (availability).
  • A clean, resolvable hijack (victim's name kept intact) when the attacker owns a parent/ancestor zone of the target name — HostnameValidator::normalizeRecordName leaves the name alone if it already ends in the attacker's zone suffix, which is exactly the case in delegated-subzone setups (attacker owns example.com, victim owns delegated sub.example.com).

In the plain sibling-zone case the edited record's name gets forced under the attacker's zone suffix, which still destroys the original record — so at minimum it's cross-zone record deletion, and at most it's full record hijack.

The attacker's own CSRF token and own zone serial satisfy every form-level check, so nothing about the request looks abnormal to the app.

Suggested fix

Stop trusting the zid in the request. In RecordManager::editRecord() (and the EditRecordController path), look the zone up from the record id on the server side and use that for both the ownership check and the hostname normalization — the same thing deleteRecord() already does:

$details = $recordRepository->getRecordDetailsFromRecordId($record['rid']);
if ($details === null) {
    // record doesn't exist – reject
    return false;
}
$realZid = $details['zid'];
// use $realZid for verifyUserIsOwnerZoneId() and for zone-name normalization

Reject the edit if the record doesn't exist, and never let the client decide which zone a record "belongs" to.

Disclosure

Credit: Found by Saif Salah (https://saifsalah.github.io/) Found during a security review of Poweradmin.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "poweradmin/poweradmin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.9.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "poweradmin/poweradmin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "poweradmin/poweradmin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3.0"
            },
            {
              "fixed": "4.3.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T21:55:15Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Affected software\n\n- Product: Poweradmin (web front-end for PowerDNS)\n- Version tested: master, commit 7f28c3a97 (also reachable in the 4.x release line \u2014 the record-edit code is the same)\n- Component: record editing (web UI)\n- Vulnerability type: Broken Access Control / Insecure Direct Object Reference\n\n## Severity\n\nAny authenticated user who owns at least one zone can tamper with records in every other zone on the server. In a shared/multi-tenant Poweradmin install this is effectively a cross-tenant DNS takeover.\n\n## Summary\n\nWhen you save a record edit, Poweradmin checks whether you\u0027re allowed to touch the record by looking at a zone id you send in the POST body, but it then applies the change to a record id you also send in the POST body. Nothing checks that the record id actually belongs to that zone id. So you point the permission check at a zone you legitimately own, point the record id at somebody else\u0027s record, and the update goes through.\n\nA low-privilege \"Editor\" who only owns `attacker.example` was able to overwrite a record living in `victim.example` (owned by the admin), even though the same account gets a flat \"you do not have permission to access this zone\" if it tries to open that zone directly.\n\n## Where the bug is\n\nThe core mistake is in `RecordManager::editRecord()` in `lib/Domain/Service/Dns/RecordManager.php`:\n\n```php\n// line 298 \u2013 ownership is checked against the zone id from the request\n$user_is_zone_owner = UserManager::verifyUserIsOwnerZoneId($this-\u003edb, $record[\u0027zid\u0027]);\n...\n// line 346 \u2013 but the update targets the record id from the request\n$this-\u003ebackendProvider-\u003eeditRecord(\n    $record[\u0027rid\u0027], $name, $record[\u0027type\u0027], $content, $validatedTtl, $validatedPrio, $record[\u0027disabled\u0027]\n);\n```\n\n`$record[\u0027zid\u0027]` and `$record[\u0027rid\u0027]` are both taken straight from the submitted form. The permission gate uses one, the write uses the other, and they\u0027re never tied together.\n\nThe backend write has no zone scoping at all \u2014 `lib/Infrastructure/Service/SqlDnsBackendProvider.php` line 235:\n\n```php\n$stmt = $this-\u003edb-\u003eprepare(\n    \"UPDATE $recordsTable SET name = ?, type = ?, content = ?, ttl = ?, prio = ?, disabled = ? WHERE id = ?\"\n);\n$stmt-\u003eexecute([$name, $type, $content, $ttl, $prio, $disabled, $recordId]);\n```\n\nIt\u0027s `WHERE id = ?` on the record id and nothing else, so any record in the database is fair game.\n\nThe validation layer doesn\u0027t save it either. `DnsRecordValidationService::validateRecord()` (`lib/Domain/Service/DnsRecordValidationService.php`, around line 97) uses the zone id only to look up the zone name for hostname validation. It never verifies the record id lives in that zone.\n\nThere are two request paths that reach this same sink:\n\n1. Multi-record save \u2014 `EditController::saveRecords()` (`lib/Application/Controller/EditController.php`, ~line 571) loops over `$_POST[\u0027record\u0027]` and hands each entry\u0027s `rid`/`zid` to `editRecord()` verbatim. The controller\u0027s `run()` only permission-checks the zone id in the URL (~line 204), not the zone id inside each record row.\n2. Single-record save \u2014 `EditRecordController::saveRecord()` reads `$_POST[\u0027rid\u0027]` and forwards the whole `$_POST` (including the attacker-chosen `zid`) into `editRecord()`.\n\nFor comparison, the delete path does it correctly. `DeleteRecordController` (~line 101) derives the zone id from the record id on the server side with `getZoneIdFromRecordId()` and checks permission against that. `EditCommentController` also uses the URL zone id for both the check and the write. So this really is an oversight in the edit path, not a deliberate design choice \u2014 the safe pattern already exists elsewhere in the same codebase.\n\n## Proof of concept\n\nSetup (two accounts, two zones):\n\n- `attacker` \u2014 a normal user on the \"Editor\" permission template (`zone_content_edit_own_as_client`, i.e. can only edit records in zones it owns). Owns `attacker.example`, which is zone/domain id 3.\n- `admin` \u2014 owns `victim.example`, which is zone/domain id 2. That zone contains the record `www.victim.example  A  1.1.1.1` with record id 5.\n\nSteps:\n\n1. Log in as `attacker`. Confirm the access control is actually there: browse to `/zones/2/edit` (victim.example). You get \"You do not have permission to access this zone.\" Good \u2014 you genuinely can\u0027t edit that zone the normal way.\n\n2. Open your own zone\u0027s edit page, `/zones/3/edit`, and start a save (change any field and submit) with your intercepting proxy on. Catch the `POST /zones/3/edit` request. It already carries a valid CSRF `_token` and a valid `serial` for your zone, so don\u0027t touch those.\n\n3. Edit the record block in that request so it targets the victim\u0027s record while keeping your own zone id:\n\n```\nPOST /zones/3/edit HTTP/1.1\nHost: localhost:8080\nCookie: PHPSESSID=\u003cyour attacker session\u003e\nContent-Type: application/x-www-form-urlencoded\n\n_token=\u003cthe valid token from step 2\u003e\u0026serial=\u003cthe valid serial from step 2\u003e\u0026commit=1\n\u0026record[5][rid]=5\u0026record[5][zid]=3\n\u0026record[5][name]=pwned\u0026record[5][type]=A\u0026record[5][content]=6.6.6.6\n\u0026record[5][ttl]=3600\u0026record[5][prio]=0\n```\n\nThe important part: `record[5][rid]=5` is the victim\u0027s record (in zone 2), and `record[5][zid]=3` is your own zone (so the ownership check passes).\n\n4. Send it. You get HTTP 200.\n\n5. Check the result. Record 5, which lives in the admin\u0027s zone, is now overwritten:\n\n```\nsqlite\u003e SELECT id, domain_id, name, type, content FROM records WHERE id = 5;\n5|2|pwned.attacker.example|A|6.6.6.6\n```\n\n\u003cimg width=\"3363\" height=\"1311\" alt=\"Screenshot 2026-07-06 162351\" src=\"https://github.com/user-attachments/assets/a2013e3b-0993-42ac-9402-7933e6d9331f\" /\u003e\n\n\nIt\u0027s still `domain_id = 2` (the victim\u0027s zone) but its content is now attacker-controlled. You changed a record in a zone you were explicitly denied access to in step 1.\n\nTwo practical notes if you\u0027re reproducing this:\n\n- The `serial` field is Poweradmin\u0027s optimistic-lock. It\u0027s checked against **your own** zone\u0027s current SOA serial and it bumps by one after every successful save, so grab a fresh one each time (the intercept-and-modify approach in step 2 handles this for you automatically).\n- Record ids are sequential integers, so in a real attack you\u0027d just walk `rid = 1, 2, 3, \u2026` to hit every record in every zone on the box.\n\n## Impact\n\nWith one owned zone, an attacker can rewrite `content`, `type`, `ttl` and the `disabled` flag of any record anywhere in the installation. Concretely that means:\n\n- Repointing or corrupting other customers\u0027 / other departments\u0027 DNS records (integrity).\n- Silently disabling records by setting `disabled = 1` (availability).\n- A clean, resolvable hijack (victim\u0027s name kept intact) when the attacker owns a parent/ancestor zone of the target name \u2014 `HostnameValidator::normalizeRecordName` leaves the name alone if it already ends in the attacker\u0027s zone suffix, which is exactly the case in delegated-subzone setups (attacker owns `example.com`, victim owns delegated `sub.example.com`).\n\nIn the plain sibling-zone case the edited record\u0027s name gets forced under the attacker\u0027s zone suffix, which still destroys the original record \u2014 so at minimum it\u0027s cross-zone record deletion, and at most it\u0027s full record hijack.\n\nThe attacker\u0027s own CSRF token and own zone serial satisfy every form-level check, so nothing about the request looks abnormal to the app.\n\n## Suggested fix\n\nStop trusting the `zid` in the request. In `RecordManager::editRecord()` (and the `EditRecordController` path), look the zone up from the record id on the server side and use that for both the ownership check and the hostname normalization \u2014 the same thing `deleteRecord()` already does:\n\n```php\n$details = $recordRepository-\u003egetRecordDetailsFromRecordId($record[\u0027rid\u0027]);\nif ($details === null) {\n    // record doesn\u0027t exist \u2013 reject\n    return false;\n}\n$realZid = $details[\u0027zid\u0027];\n// use $realZid for verifyUserIsOwnerZoneId() and for zone-name normalization\n```\n\nReject the edit if the record doesn\u0027t exist, and never let the client decide which zone a record \"belongs\" to.\n\n## Disclosure\nCredit: Found by Saif Salah (https://saifsalah.github.io/)\nFound during a security review of Poweradmin.",
  "id": "GHSA-rm67-g9ch-vxff",
  "modified": "2026-07-24T21:55:15Z",
  "published": "2026-07-24T21:55:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/security/advisories/GHSA-rm67-g9ch-vxff"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/commit/12651facf49a6d9ebeb38f01e65f4aa5bfbc4da0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/commit/88f443d0bde9812ff8d00c094882c8b8e7303c49"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/commit/e021067157491ea70b8e333dc3f6a1ddf7e8e746"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/poweradmin/poweradmin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/releases/tag/v3.9.11"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/releases/tag/v4.2.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/poweradmin/poweradmin/releases/tag/v4.3.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Poweradmin: Broken access control (IDOR): any zone owner can modify DNS records in zones they do not own"
}

GHSA-RMC6-47CP-M9GJ

Vulnerability from github – Published: 2023-06-14 09:30 – Updated: 2024-04-04 04:49
VLAI
Details

Unauth. IDOR vulnerability leading to PII Disclosure in WooCommerce Stripe Payment Gateway plugin <= 7.4.0 versions.

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-2023-34000"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-14T08:15:09Z",
    "severity": "HIGH"
  },
  "details": "Unauth. IDOR vulnerability leading to PII Disclosure in\u00a0WooCommerce Stripe Payment Gateway plugin \u003c= 7.4.0 versions.",
  "id": "GHSA-rmc6-47cp-m9gj",
  "modified": "2024-04-04T04:49:39Z",
  "published": "2023-06-14T09:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34000"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/articles/unauthenticated-idor-to-pii-disclosure-vulnerability-in-woocommerce-stripe-gateway-plugin?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/woocommerce-gateway-stripe/wordpress-woocommerce-stripe-payment-gateway-plugin-7-4-0-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
    }
  ],
  "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-RMCJ-82CR-27RX

Vulnerability from github – Published: 2026-06-25 18:30 – Updated: 2026-06-30 03:37
VLAI
Details

A flaw was found in Keycloak. A missing authorization check in the GroupResource.addChild() endpoint within the Admin REST API allows an authenticated user with limited administrative privileges to reparent any existing group. When Fine-Grained Admin Permissions v2 (FGAPv2) is enabled, an attacker with management rights over a single low-privilege group can reparent a highly privileged group (such as one possessing the realm-admin role) under their managed group.

Because group permissions follow a hierarchical structure, this action unauthorizedly grants the attacker management and password-reset capabilities over the members of the targeted privileged group. An attacker can exploit this to reset an administrator's password, compromise the account, and achieve a full realm takeover, leading to a complete compromise of confidentiality, integrity, and availability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-9099"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T17:17:03Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in Keycloak. A missing authorization check in the GroupResource.addChild() endpoint within the Admin REST API allows an authenticated user with limited administrative privileges to reparent any existing group. When Fine-Grained Admin Permissions v2 (FGAPv2) is enabled, an attacker with management rights over a single low-privilege group can reparent a highly privileged group (such as one possessing the realm-admin role) under their managed group.\n\nBecause group permissions follow a hierarchical structure, this action unauthorizedly grants the attacker management and password-reset capabilities over the members of the targeted privileged group. An attacker can exploit this to reset an administrator\u0027s password, compromise the account, and achieve a full realm takeover, leading to a complete compromise of confidentiality, integrity, and availability.",
  "id": "GHSA-rmcj-82cr-27rx",
  "modified": "2026-06-30T03:37:14Z",
  "published": "2026-06-25T18:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9099"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30049"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30050"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30083"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30084"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-9099"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2480182"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-9099.json"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RP59-MWR6-M562

Vulnerability from github – Published: 2023-01-19 00:30 – Updated: 2025-04-04 18:30
VLAI
Details

An issue was discovered in OpenText Content Suite Platform 22.1 (16.2.19.1803). The Java application server can be used to bypass the authentication of the QDS endpoints of the Content Server. These endpoints can be used to create objects and execute arbitrary code.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-45927"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-18T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in OpenText Content Suite Platform 22.1 (16.2.19.1803). The Java application server can be used to bypass the authentication of the QDS endpoints of the Content Server. These endpoints can be used to create objects and execute arbitrary code.",
  "id": "GHSA-rp59-mwr6-m562",
  "modified": "2025-04-04T18:30:32Z",
  "published": "2023-01-19T00:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45927"
    },
    {
      "type": "WEB",
      "url": "https://sec-consult.com/vulnerability-lab/advisory/pre-authenticated-remote-code-execution-via-java-frontend-qds-endpoint-opentext-extended-ecm"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/170614/OpenText-Extended-ECM-22.3-Java-Frontend-Remote-Code-Execution.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2023/Jan/13"
    }
  ],
  "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"
    }
  ]
}

GHSA-RP6X-GGW6-8G56

Vulnerability from github – Published: 2023-10-16 09:30 – Updated: 2023-11-14 21:13
VLAI
Summary
Authorization Bypass in Apache InLong
Details

Authorization Bypass Through User-Controlled Key vulnerability in Apache InLong.This issue affects Apache InLong: from 1.4.0 through 1.8.0, 

some sensitive params checks will be bypassed, like "autoDeserizalize","allowLoadLocalInfile"....

.  

Users are advised to upgrade to Apache InLong's 1.9.0 or cherry-pick [1] to solve it.

[1]  https://github.com/apache/inlong/pull/8604

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.inlong:manager-pojo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.0"
            },
            {
              "fixed": "1.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-43668"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-502",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-17T14:23:26Z",
    "nvd_published_at": "2023-10-16T09:15:10Z",
    "severity": "CRITICAL"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in Apache InLong.This issue affects Apache InLong: from 1.4.0 through 1.8.0,\u00a0\n\nsome sensitive params  checks will be bypassed, like \"autoDeserizalize\",\"allowLoadLocalInfile\"....\n\n.\u00a0\u00a0\n\nUsers are advised to upgrade to Apache InLong\u0027s 1.9.0 or cherry-pick [1] to solve it.\n\n[1]\u00a0 https://github.com/apache/inlong/pull/8604 \n\n",
  "id": "GHSA-rp6x-ggw6-8g56",
  "modified": "2023-11-14T21:13:48Z",
  "published": "2023-10-16T09:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43668"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/inlong/pull/8604"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/inlong/commit/46c4e96a84839bd540f47c659c9d8576e393da02"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/inlong"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/16gtk7rpdm1rof075ro83fkrnhbzn5sh"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Authorization Bypass in Apache InLong"
}

GHSA-RP98-9VMX-835H

Vulnerability from github – Published: 2024-01-17 03:30 – Updated: 2025-06-10 18:32
VLAI
Details

An issue in webkul qloapps before v1.6.0 allows an attacker to obtain sensitive information via the id_order parameter.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-36235"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-17T03:15:07Z",
    "severity": "MODERATE"
  },
  "details": "An issue in webkul qloapps before v1.6.0 allows an attacker to obtain sensitive information via the id_order parameter.",
  "id": "GHSA-rp98-9vmx-835h",
  "modified": "2025-06-10T18:32:10Z",
  "published": "2024-01-17T03:30:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36235"
    },
    {
      "type": "WEB",
      "url": "https://github.com/webkul/hotelcommerce/pull/537"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Ek-Saini/security/blob/main/IDOR-Qloapps"
    },
    {
      "type": "WEB",
      "url": "https://qloapps.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RP9M-HFV5-PFVR

Vulnerability from github – Published: 2026-07-06 09:30 – Updated: 2026-07-06 21:30
VLAI
Details

Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel ElasticSearch Rest Client.

The camel-elasticsearch-rest-client component reads several Exchange headers to control its behaviour - SEARCH_QUERY (an advanced query body), OPERATION (which Elasticsearch operation to run), INDEX_NAME, INDEX_SETTINGS and ID. The string values of these header constants, defined in ElasticSearchRestClientConstant, are plain unprefixed names ('SEARCH_QUERY', 'OPERATION', 'INDEX_NAME', 'INDEX_SETTINGS', 'ID') rather than the 'Camel'-prefixed names used by every other Camel component (for example CamelSqlQuery, CamelMongoDbCriteria, CamelCqlQuery). Camel's inbound HTTP header filter, HttpHeaderFilterStrategy, blocks only header names that begin with 'Camel' or 'camel'. Because the Elasticsearch header names do not carry that prefix, they pass through the inbound filter unchanged. When a Camel route exposes an HTTP entry point (for example platform-http) in front of an elasticsearch-rest-client producer, an untrusted HTTP client can set these headers directly on its request and override the query and operation that the route author configured: reading every document in the index (SEARCH_QUERY with a match_all query), deleting documents (OPERATION set to Delete together with ID), or exfiltrating selected fields. No credentials are required and the producer reads the headers unconditionally. This issue affects Apache Camel: from 4.3.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.

Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix renames the camel-elasticsearch-rest-client Exchange header constant string values (ID, SEARCH_QUERY, INDEX_SETTINGS, INDEX_NAME, OPERATION) to carry the Camel prefix (CamelElasticsearchId, CamelElasticsearchSearchQuery, CamelElasticsearchIndexSettings, CamelElasticsearchIndexName, CamelElasticsearchOperation) so that they are blocked by the inbound HttpHeaderFilterStrategy; the Java field names are unchanged. For deployments that cannot upgrade immediately, strip the affected headers from untrusted inbound messages before they reach the producer (for example removeHeader('SEARCH_QUERY'), removeHeader('OPERATION'), removeHeader('INDEX_NAME'), removeHeader('INDEX_SETTINGS') and removeHeader('ID') in front of the elasticsearch-rest-client endpoint), or apply a custom HeaderFilterStrategy that blocks these names.

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-2026-46453"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-06T09:16:36Z",
    "severity": "MODERATE"
  },
  "details": "Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel ElasticSearch Rest Client.\n\nThe camel-elasticsearch-rest-client component reads several Exchange headers to control its behaviour - SEARCH_QUERY (an advanced query body), OPERATION (which Elasticsearch operation to run), INDEX_NAME, INDEX_SETTINGS and ID. The string values of these header constants, defined in ElasticSearchRestClientConstant, are plain unprefixed names (\u0027SEARCH_QUERY\u0027, \u0027OPERATION\u0027, \u0027INDEX_NAME\u0027, \u0027INDEX_SETTINGS\u0027, \u0027ID\u0027) rather than the \u0027Camel\u0027-prefixed names used by every other Camel component (for example CamelSqlQuery, CamelMongoDbCriteria, CamelCqlQuery). Camel\u0027s inbound HTTP header filter, HttpHeaderFilterStrategy, blocks only header names that begin with \u0027Camel\u0027 or \u0027camel\u0027. Because the Elasticsearch header names do not carry that prefix, they pass through the inbound filter unchanged. When a Camel route exposes an HTTP entry point (for example platform-http) in front of an elasticsearch-rest-client producer, an untrusted HTTP client can set these headers directly on its request and override the query and operation that the route author configured: reading every document in the index (SEARCH_QUERY with a match_all query), deleting documents (OPERATION set to Delete together with ID), or exfiltrating selected fields. No credentials are required and the producer reads the headers unconditionally.\nThis issue affects Apache Camel: from 4.3.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.\n\nUsers are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix renames the camel-elasticsearch-rest-client Exchange header constant string values (ID, SEARCH_QUERY, INDEX_SETTINGS, INDEX_NAME, OPERATION) to carry the Camel prefix (CamelElasticsearchId, CamelElasticsearchSearchQuery, CamelElasticsearchIndexSettings, CamelElasticsearchIndexName, CamelElasticsearchOperation) so that they are blocked by the inbound HttpHeaderFilterStrategy; the Java field names are unchanged. For deployments that cannot upgrade immediately, strip the affected headers from untrusted inbound messages before they reach the producer (for example removeHeader(\u0027SEARCH_QUERY\u0027), removeHeader(\u0027OPERATION\u0027), removeHeader(\u0027INDEX_NAME\u0027), removeHeader(\u0027INDEX_SETTINGS\u0027) and removeHeader(\u0027ID\u0027) in front of the elasticsearch-rest-client endpoint), or apply a custom HeaderFilterStrategy that blocks these names.",
  "id": "GHSA-rp9m-hfv5-pfvr",
  "modified": "2026-07-06T21:30:36Z",
  "published": "2026-07-06T09:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46453"
    },
    {
      "type": "WEB",
      "url": "https://camel.apache.org/security/CVE-2026-46453.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/07/05/6"
    }
  ],
  "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-RPC7-GF58-V3X2

Vulnerability from github – Published: 2023-10-13 09:30 – Updated: 2025-03-04 18:23
VLAI
Summary
Magento Open Source allows Incorrect Authorization
Details

Adobe Commerce versions 2.4.7-beta1 (and earlier), 2.4.6-p2 (and earlier), 2.4.5-p4 (and earlier) and 2.4.4-p5 (and earlier) are affected by an improper input validation vulnerability. An authenticated attacker can trigger an insecure direct object reference in the V1/customers/me endpoint to achieve information exposure and privilege escalation.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.7-beta1"
            },
            {
              "fixed": "2.4.7-beta2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.4.7-beta1"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.6"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.5"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.4"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.6-p1"
            },
            {
              "fixed": "2.4.6-p3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.5-p1"
            },
            {
              "fixed": "2.4.5-p5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.4-p1"
            },
            {
              "fixed": "2.4.4-p6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/project-community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-38218"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-04T18:23:33Z",
    "nvd_published_at": "2023-10-13T07:15:40Z",
    "severity": "MODERATE"
  },
  "details": "Adobe Commerce versions 2.4.7-beta1 (and earlier), 2.4.6-p2 (and earlier), 2.4.5-p4 (and earlier) and 2.4.4-p5 (and earlier) are affected by an improper input validation vulnerability. An authenticated attacker can trigger an insecure direct object reference in the `V1/customers/me` endpoint to achieve information exposure and privilege escalation.",
  "id": "GHSA-rpc7-gf58-v3x2",
  "modified": "2025-03-04T18:23:33Z",
  "published": "2023-10-13T09:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38218"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/magento/magento2"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb23-50.html"
    }
  ],
  "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:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Magento Open Source allows Incorrect Authorization"
}
Mitigation
Architecture and Design

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Mitigation
Architecture and Design Implementation

Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Mitigation
Architecture and Design

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list