CWE-863
Allowed-with-ReviewIncorrect Authorization
Abstraction: Class · Status: Incomplete
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
7172 vulnerabilities reference this CWE, most recent first.
GHSA-C63C-249M-G37M
Vulnerability from github – Published: 2022-07-02 00:00 – Updated: 2022-07-14 00:00An improper authorization issue in GitLab CE/EE affecting all versions from 13.7 prior to 14.10.5, 15.0 prior to 15.0.4, and 15.1 prior to 15.1.1 allows an attacker to extract the value of an unprotected variable they know the name of in public projects or private projects they're a member of.
{
"affected": [],
"aliases": [
"CVE-2022-2229"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-01T17:15:00Z",
"severity": "HIGH"
},
"details": "An improper authorization issue in GitLab CE/EE affecting all versions from 13.7 prior to 14.10.5, 15.0 prior to 15.0.4, and 15.1 prior to 15.1.1 allows an attacker to extract the value of an unprotected variable they know the name of in public projects or private projects they\u0027re a member of.",
"id": "GHSA-c63c-249m-g37m",
"modified": "2022-07-14T00:00:17Z",
"published": "2022-07-02T00:00:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2229"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1511133"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-2229.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/355738"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C64P-77M6-V4M5
Vulnerability from github – Published: 2022-05-13 01:53 – Updated: 2022-05-13 01:53An improper authorization vulnerability exists In Schneider Electric's 66074 MGE Network Management Card Transverse installed in MGE UPS and MGE STS. The integrated web server (Port 80/443/TCP) of the affected devices could allow a remote attacker to change UPS control and shutdown parameters or other critical settings without authorization.
{
"affected": [],
"aliases": [
"CVE-2018-7245"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-04-18T20:29:00Z",
"severity": "CRITICAL"
},
"details": "An improper authorization vulnerability exists In Schneider Electric\u0027s 66074 MGE Network Management Card Transverse installed in MGE UPS and MGE STS. The integrated web server (Port 80/443/TCP) of the affected devices could allow a remote attacker to change UPS control and shutdown parameters or other critical settings without authorization.",
"id": "GHSA-c64p-77m6-v4m5",
"modified": "2022-05-13T01:53:17Z",
"published": "2022-05-13T01:53:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7245"
},
{
"type": "WEB",
"url": "https://www.schneider-electric.com/en/download/document/SEVD-2018-074-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C65F-X25W-62JV
Vulnerability from github – Published: 2026-04-01 21:12 – Updated: 2026-04-01 21:12Summary
Both standalone servers configure CORS with allow_origins=["*"], allow_credentials=True, allow_methods=["*"], and allow_headers=["*"].
Affected Code
# server/key-server/app/main.py:86-92
# server/telemetry-server/app/main.py:23-29
app.add_middleware(
CORSMiddleware,
allow_origins=settings.cors_origins, # defaults to ["*"]
allow_credentials=True,
allow_methods=["*"],
allow_headers=["*"],
)
The docker-compose file (openssl_encrypt_server/docker-compose.yml:75) also defaults CORS_ORIGINS to *, and .env.example ships with CORS_ORIGINS=*.
Impact
This is the most permissive CORS configuration possible, allowing any website to make fully credentialed cross-origin requests to the API. An attacker's website could make authenticated API calls on behalf of any user who visits it.
Recommended Fix
- Remove wildcard defaults — require explicit origin configuration
- Never combine
allow_origins=["*"]withallow_credentials=True - Update
.env.examplewith placeholder domains instead of*
Fix
Fixed in commit 809416b on branch releases/1.4.x — changed CORS default from ["*"] to [] in both key-server and telemetry-server; added validation rejecting wildcard when debug=False.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "openssl-encrypt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-01T21:12:37Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nBoth standalone servers configure CORS with `allow_origins=[\"*\"]`, `allow_credentials=True`, `allow_methods=[\"*\"]`, and `allow_headers=[\"*\"]`.\n\n### Affected Code\n\n```python\n# server/key-server/app/main.py:86-92\n# server/telemetry-server/app/main.py:23-29\napp.add_middleware(\n CORSMiddleware,\n allow_origins=settings.cors_origins, # defaults to [\"*\"]\n allow_credentials=True,\n allow_methods=[\"*\"],\n allow_headers=[\"*\"],\n)\n```\n\nThe docker-compose file (`openssl_encrypt_server/docker-compose.yml:75`) also defaults `CORS_ORIGINS` to `*`, and `.env.example` ships with `CORS_ORIGINS=*`.\n\n### Impact\n\nThis is the most permissive CORS configuration possible, allowing any website to make fully credentialed cross-origin requests to the API. An attacker\u0027s website could make authenticated API calls on behalf of any user who visits it.\n\n### Recommended Fix\n\n- Remove wildcard defaults \u2014 require explicit origin configuration\n- Never combine `allow_origins=[\"*\"]` with `allow_credentials=True`\n- Update `.env.example` with placeholder domains instead of `*`\n\n### Fix\n\nFixed in commit `809416b` on branch `releases/1.4.x` \u2014 changed CORS default from [\"*\"] to [] in both key-server and telemetry-server; added validation rejecting wildcard when debug=False.",
"id": "GHSA-c65f-x25w-62jv",
"modified": "2026-04-01T21:12:37Z",
"published": "2026-04-01T21:12:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-c65f-x25w-62jv"
},
{
"type": "WEB",
"url": "https://github.com/jahlives/openssl_encrypt/commit/809416b74d2749cdcffb484cd65b057e1685cc13"
},
{
"type": "PACKAGE",
"url": "https://github.com/jahlives/openssl_encrypt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "openssl-encrypt has CORS wildcard with allow_credentials=True in standalone servers"
}
GHSA-C68X-6HMF-XW2P
Vulnerability from github – Published: 2024-10-30 21:30 – Updated: 2024-10-31 18:31Insecure Permissions vulnerability in Ethereum v.1.12.2 allows a remote attacker to escalate privileges via the WaterToken Contract.
{
"affected": [],
"aliases": [
"CVE-2024-51425"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-30T21:15:15Z",
"severity": "HIGH"
},
"details": "Insecure Permissions vulnerability in Ethereum v.1.12.2 allows a remote attacker to escalate privileges via the WaterToken Contract.",
"id": "GHSA-c68x-6hmf-xw2p",
"modified": "2024-10-31T18:31:18Z",
"published": "2024-10-30T21:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51425"
},
{
"type": "WEB",
"url": "https://github.com/Wzy-source/Gala/blob/main/CVEs/WaterToken_0x8890963266f895aca11fbe4679a1f9cc472f6531.md"
}
],
"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-C6CP-7FRC-R847
Vulnerability from github – Published: 2022-05-24 19:20 – Updated: 2022-07-13 00:01SchedMD Slurm 21.08.* before 21.08.4 has Incorrect Access Control. On sites using the new AccountingStoreFlags=job_script and/or job_env options, the access control rules in SlurmDBD may permit users to request job scripts and environment files to which they should not have access.
{
"affected": [],
"aliases": [
"CVE-2021-43337"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-17T06:15:00Z",
"severity": "MODERATE"
},
"details": "SchedMD Slurm 21.08.* before 21.08.4 has Incorrect Access Control. On sites using the new AccountingStoreFlags=job_script and/or job_env options, the access control rules in SlurmDBD may permit users to request job scripts and environment files to which they should not have access.",
"id": "GHSA-c6cp-7frc-r847",
"modified": "2022-07-13T00:01:48Z",
"published": "2022-05-24T19:20:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43337"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5VY34WSSPRPA6MISNYBZWHSGX2SYSEEE"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DUWNGDQTS7AWFI7FIHUWQOYJSD2IQTCG"
},
{
"type": "WEB",
"url": "https://lists.schedmd.com/pipermail/slurm-announce"
},
{
"type": "WEB",
"url": "https://lists.schedmd.com/pipermail/slurm-announce/2021/000068.html"
},
{
"type": "WEB",
"url": "https://www.schedmd.com/news.php"
},
{
"type": "WEB",
"url": "https://www.schedmd.com/news.php?id=256"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C6GW-7J5J-4C6V
Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-05-24 17:42Insufficient access control in some Intel(R) Ethernet E810 Adapter drivers for Linux before version 1.0.4 may allow an authenticated user to potentially enable information disclosure via local access.
{
"affected": [],
"aliases": [
"CVE-2020-24503"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-17T14:15:00Z",
"severity": "MODERATE"
},
"details": "Insufficient access control in some Intel(R) Ethernet E810 Adapter drivers for Linux before version 1.0.4 may allow an authenticated user to potentially enable information disclosure via local access.",
"id": "GHSA-c6gw-7j5j-4c6v",
"modified": "2022-05-24T17:42:29Z",
"published": "2022-05-24T17:42:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24503"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00462.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-C6PF-2V8J-96MC
Vulnerability from github – Published: 2025-03-24 19:36 – Updated: 2026-07-02 20:20Impact
Node based network policies (fromNodes and toNodes) will incorrectly permit traffic to/from non-node endpoints that share the labels specified in fromNodes and toNodes sections of network policies. Node based network policy is disabled by default in Cilium.
Patches
This issue was fixed by https://github.com/cilium/cilium/pull/36657.
This issue affects:
- Cilium v1.16 between v1.16.0 and v1.16.7 inclusive
- Cilium v1.17 between v1.17.0 and v1.17.1 inclusive
This issue is fixed in:
- Cilium v1.16.8
- Cilium v1.17.2
Workarounds
Users can work around this issue by ensuring that the labels used in fromNodes and toNodes fields are used exclusively by nodes and not by other endpoints.
Acknowledgements
The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @oblazek for reporting and fixing this issue.
For more information
If you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and your report will be treated as top priority. Please also address any comments or questions on this advisory to the same mailing list.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cilium/cilium"
},
"ranges": [
{
"events": [
{
"introduced": "1.16.0"
},
{
"fixed": "1.16.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/cilium/cilium"
},
"ranges": [
{
"events": [
{
"introduced": "1.17.0"
},
{
"fixed": "1.17.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-30163"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-24T19:36:21Z",
"nvd_published_at": "2025-03-24T19:15:52Z",
"severity": "LOW"
},
"details": "### Impact\n\n[Node based network policies](https://docs.cilium.io/en/stable/security/policy/language/#node-based) (`fromNodes` and `toNodes`) will incorrectly permit traffic to/from non-node endpoints that share the labels specified in `fromNodes` and `toNodes` sections of network policies. Node based network policy is disabled by default in Cilium.\n\n### Patches\n\nThis issue was fixed by https://github.com/cilium/cilium/pull/36657.\n\nThis issue affects:\n\n- Cilium v1.16 between v1.16.0 and v1.16.7 inclusive\n- Cilium v1.17 between v1.17.0 and v1.17.1 inclusive\n\nThis issue is fixed in:\n\n- Cilium v1.16.8\n- Cilium v1.17.2\n\n### Workarounds\n\nUsers can work around this issue by ensuring that the labels used in `fromNodes` and `toNodes` fields are used exclusively by nodes and not by other endpoints.\n\n### Acknowledgements\n\nThe Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @oblazek for reporting and fixing this issue.\n\n### For more information\n\nIf you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at [security@cilium.io](mailto:security@cilium.io). This is a private mailing list for the Cilium security team, and your report will be treated as top priority. Please also address any comments or questions on this advisory to the same mailing list.",
"id": "GHSA-c6pf-2v8j-96mc",
"modified": "2026-07-02T20:20:36Z",
"published": "2025-03-24T19:36:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cilium/cilium/security/advisories/GHSA-c6pf-2v8j-96mc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30163"
},
{
"type": "WEB",
"url": "https://github.com/cilium/cilium/pull/36657"
},
{
"type": "WEB",
"url": "https://docs.cilium.io/en/stable/security/policy/language/#node-based"
},
{
"type": "PACKAGE",
"url": "https://github.com/cilium/cilium"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Cilium node based network policies may incorrectly allow workload traffic"
}
GHSA-C6W2-J4WQ-MVWG
Vulnerability from github – Published: 2026-08-19 19:32 – Updated: 2026-09-02 15:27Impact
Due to inconsistent authorization checks, a company-scoped user can bypass tenant boundaries to read, mutate, and soft-delete users who do not belong to any company (company_id = null). While direct instance authorization (isCurrentUserHasAccess) correctly denies access to these out-of-scope users, multiple API endpoints and bulk action web routes fail to enforce this restriction, relying instead on class-level permissions or broad scoped queries. Impact:
A malicious user scoped to a specific company (e.g., Company A) can:
Data Leakage: Extract PII and assigned licenses of users outside their tenant via the API (/api/v1/users and /api/v1/users/{id}/licenses).
Data Modification: Mutate out-of-scope user profiles (e.g., changing city, notes) via the /users/bulkeditsave web route.
Data Deletion & Asset Theft: Soft-delete out-of-scope users and transfer their assigned assets to themselves via the /users/merge web route.
Patches
Patched in https://github.com/grokability/snipe-it/commit/fbe05a8df4742729a9b0756c016d45f48246cc7b,
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "snipe/snipe-it"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.6.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55643"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-19T19:32:11Z",
"nvd_published_at": "2026-08-19T19:17:20Z",
"severity": "HIGH"
},
"details": "### Impact\nDue to inconsistent authorization checks, a company-scoped user can bypass tenant boundaries to read, mutate, and soft-delete users who do not belong to any company (company_id = null). While direct instance authorization (isCurrentUserHasAccess) correctly denies access to these out-of-scope users, multiple API endpoints and bulk action web routes fail to enforce this restriction, relying instead on class-level permissions or broad scoped queries.\nImpact: \n\nA malicious user scoped to a specific company (e.g., Company A) can:\n\nData Leakage: Extract PII and assigned licenses of users outside their tenant via the API (/api/v1/users and `/api/v1/users/{id}/licenses)`.\n\nData Modification: Mutate out-of-scope user profiles (e.g., changing city, notes) via the /users/bulkeditsave web route.\n\nData Deletion \u0026 Asset Theft: Soft-delete out-of-scope users and transfer their assigned assets to themselves via the /users/merge web route.\n\n\n### Patches\nPatched in https://github.com/grokability/snipe-it/commit/fbe05a8df4742729a9b0756c016d45f48246cc7b,",
"id": "GHSA-c6w2-j4wq-mvwg",
"modified": "2026-09-02T15:27:32Z",
"published": "2026-08-19T19:32:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/grokability/snipe-it/security/advisories/GHSA-c6w2-j4wq-mvwg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55643"
},
{
"type": "WEB",
"url": "https://github.com/grokability/snipe-it/commit/fbe05a8df4742729a9b0756c016d45f48246cc7b"
},
{
"type": "PACKAGE",
"url": "https://github.com/grokability/snipe-it"
},
{
"type": "WEB",
"url": "https://github.com/grokability/snipe-it/releases/tag/v8.6.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Snipe-IT: Tenant Isolation Bypass in FMCS Floater Mode"
}
GHSA-C6XJ-3C77-G5RG
Vulnerability from github – Published: 2022-05-13 01:19 – Updated: 2022-05-13 01:19In the Linux kernel 4.15.x through 4.19.x before 4.19.2, map_write() in kernel/user_namespace.c allows privilege escalation because it mishandles nested user namespaces with more than 5 UID or GID ranges. A user who has CAP_SYS_ADMIN in an affected user namespace can bypass access controls on resources outside the namespace, as demonstrated by reading /etc/shadow. This occurs because an ID transformation takes place properly for the namespaced-to-kernel direction but not for the kernel-to-namespaced direction.
{
"affected": [],
"aliases": [
"CVE-2018-18955"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-11-16T20:29:00Z",
"severity": "HIGH"
},
"details": "In the Linux kernel 4.15.x through 4.19.x before 4.19.2, map_write() in kernel/user_namespace.c allows privilege escalation because it mishandles nested user namespaces with more than 5 UID or GID ranges. A user who has CAP_SYS_ADMIN in an affected user namespace can bypass access controls on resources outside the namespace, as demonstrated by reading /etc/shadow. This occurs because an ID transformation takes place properly for the namespaced-to-kernel direction but not for the kernel-to-namespaced direction.",
"id": "GHSA-c6xj-3c77-g5rg",
"modified": "2022-05-13T01:19:42Z",
"published": "2022-05-13T01:19:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-18955"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/d2f007dbe7e4c9583eea6eb04d60001e85c6f1bd"
},
{
"type": "WEB",
"url": "https://bugs.chromium.org/p/project-zero/issues/detail?id=1712"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.18.19"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.2"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190416-0003"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K39103040"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3832-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3833-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3835-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3836-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3836-2"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/45886"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/45915"
},
{
"type": "WEB",
"url": "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d2f007dbe7e4c9583eea6eb04d60001e85c6f1bd"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/105941"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C72H-82W6-RQFP
Vulnerability from github – Published: 2026-10-07 13:33 – Updated: 2026-10-07 13:33Summary
Five gym management views in wger apply a flawed gym-scope guard (gym_a != gym_b) that silently passes when both operands are None. A trainer with gym.gym_trainer and gym.add_adminusernote permissions and no gym assignment (gym=None) can read private admin notes, uploaded documents, gym contracts, user configuration, and user permission data for any other unaffiliated user on the instance. The subsequent querysets filter only on the attacker-supplied member_id with no secondary gym-scoped validation, so all records are disclosed.
Details
Files: wger/gym/views/user.py, wger/gym/views/admin_notes.py, wger/gym/views/document.py, wger/gym/views/contract.py, wger/gym/views/user_config.py
The same flawed comparison pattern appears across at least five views:
# VULNERABLE - applied in admin_notes_list, documents_list, contracts_list,
# user_config, and gym_permissions_user_edit
if request.user.userprofile.gym != user.userprofile.gym:
return HttpResponseForbidden()
# After the guard (admin notes example):
notes = AdminUserNote.objects.filter(member=member) # only filtered by member_id
When both request.user.userprofile.gym and user.userprofile.gym are None, Python evaluates None != None as False, and HttpResponseForbidden is never reached. The subsequent queryset applies only the attacker-supplied member (user ID) as a filter — there is no secondary check tying the queryset to the requesting trainer's gym. All private admin notes, documents, and contracts for the target user are returned in the response body.
Affected endpoints:
- GET /en/gym/notes/list/user/<member_pk> -> admin notes list view
- GET /en/gym/documents/list/user/<member_pk> -> documents list view
- GET /en/gym/contract/list/<member_pk> -> contracts list view
- GET /en/gym/user/<member_pk>/config -> user config view
- GET /en/gym/user/<member_pk>/permissions -> permission edit view
Suggested patch:
--- a/wger/gym/views/user.py
+++ b/wger/gym/views/user.py
- if request.user.userprofile.gym != user.userprofile.gym:
- return HttpResponseForbidden()
+ trainer_gym_id = request.user.userprofile.gym_id
+ member_gym_id = user.userprofile.gym_id
+
+ if trainer_gym_id is None or trainer_gym_id != member_gym_id:
+ return HttpResponseForbidden()
# Also tighten the queryset with a gym-scoped secondary filter:
- notes = AdminUserNote.objects.filter(member=member)
+ notes = AdminUserNote.objects.filter(
+ member=member,
+ member__userprofile__gym_id=request.user.userprofile.gym_id,
+ )
Extract a shared helper assert_same_gym(trainer, member) and call it consistently from all five affected views to eliminate future drift.
PoC
Tested on wger/server:latest Docker image. Test users: trainer1 (gym.gym_trainer + gym.add_adminusernote permissions, userprofile.gym=None) and alice (regular user, userprofile.gym=None, has a private admin note pre-seeded).
Step 1 - Authenticate as trainer with required perms and gym=None:
POST /en/user/login HTTP/1.1
Host: target
Content-Type: application/x-www-form-urlencoded
username=trainer1&password=[REDACTED]&csrfmiddlewaretoken=[REDACTED]
-> 302 Found; Set-Cookie: sessionid=[trainer1_session]
Step 2 - Read victim's private admin notes:
GET /en/gym/notes/list/user/2 HTTP/1.1
Host: target
Cookie: sessionid=[trainer1_session]
-> 200 OK
body contains all private admin notes for user 2:
"PRIVATE_NOTE_ABOUT_ALICE_SALARY_50K"
"PHASE4_SECRET_SALARY_100K"
Step 3 - Read victim's documents and contracts (same pattern):
GET /en/gym/documents/list/user/2
GET /en/gym/contract/list/2
-> 200 OK for each; all records disclosed
Step 4 (optional) - Mass enumeration across all gym=None users:
Iterate user PKs 1..N:
GET /en/gym/notes/list/user/{uid}
-> 200 = gym=None victim (notes leaked)
-> 403 = gym-assigned user (check works correctly when gym values differ)
RBAC Disproof Protocol:
- Scenario A (admin, gym=1 -> member gym=1) -> HTTP 200 (expected - same-gym read is a documented feature)
- Scenario B (trainer1, gym=None -> alice gym=None) -> HTTP 200 with PII in body (expected HTTP 403)
- Scenario C (admin, gym=1 -> alice gym=None) -> HTTP 403 (expected - guard works when gyms differ; confirms bypass is None-specific)
Reproducibility: 2/2 runs after clean-baseline database reset.
Impact
An authenticated trainer with gym.gym_trainer + gym.add_adminusernote permissions and userprofile.gym=None can:
- Enumerate and read all private admin notes for every other
gym=Noneuser (notes may contain salary data, medical notes, disciplinary records). - Download all uploaded documents attached to those users (contracts, ID scans, medical forms).
- Read all gym contracts (financial terms, subscription details).
- Read user configuration details.
- Via the permissions endpoint, potentially modify victim permissions (creates a privilege escalation path - not fully explored in this submission but the endpoint is reachable).
Affected deployments: every wger instance where gym.gym_trainer + gym.add_adminusernote are delegated to non-admin users AND any other users exist with gym=None. The gym=None state is the default for newly registered users before manual gym assignment, so every public-registration wger instance is affected.
Severity: High (CVSS 7.1). Network-reachable, low complexity, requires only low privilege (delegated trainer), scope unchanged (same wger authority), high confidentiality loss across all unaffiliated accounts, low integrity impact (permission-edit view reachable).
This is structurally the same bug class as the sibling findings affecting trainer_login and reset_user_password (submitted separately). The root cause - Django ORM object-!= returning False when both sides are None - warrants a shared same_gym() helper applied across all five views.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "wger"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43976"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T13:33:14Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nFive gym management views in wger apply a flawed gym-scope guard (`gym_a != gym_b`) that silently passes when both operands are `None`. A trainer with `gym.gym_trainer` and `gym.add_adminusernote` permissions and no gym assignment (`gym=None`) can read private admin notes, uploaded documents, gym contracts, user configuration, and user permission data for **any other unaffiliated user** on the instance. The subsequent querysets filter only on the attacker-supplied `member_id` with no secondary gym-scoped validation, so all records are disclosed.\n\n### Details\n\n**Files**: `wger/gym/views/user.py`, `wger/gym/views/admin_notes.py`, `wger/gym/views/document.py`, `wger/gym/views/contract.py`, `wger/gym/views/user_config.py`\n\nThe same flawed comparison pattern appears across at least five views:\n\n```python\n# VULNERABLE - applied in admin_notes_list, documents_list, contracts_list,\n# user_config, and gym_permissions_user_edit\nif request.user.userprofile.gym != user.userprofile.gym:\n return HttpResponseForbidden()\n\n# After the guard (admin notes example):\nnotes = AdminUserNote.objects.filter(member=member) # only filtered by member_id\n```\n\nWhen both `request.user.userprofile.gym` and `user.userprofile.gym` are `None`, Python evaluates `None != None` as `False`, and `HttpResponseForbidden` is never reached. The subsequent queryset applies only the attacker-supplied `member` (user ID) as a filter \u2014 there is no secondary check tying the queryset to the requesting trainer\u0027s gym. All private admin notes, documents, and contracts for the target user are returned in the response body.\n\n**Affected endpoints**:\n- `GET /en/gym/notes/list/user/\u003cmember_pk\u003e` -\u003e admin notes list view\n- `GET /en/gym/documents/list/user/\u003cmember_pk\u003e` -\u003e documents list view\n- `GET /en/gym/contract/list/\u003cmember_pk\u003e` -\u003e contracts list view\n- `GET /en/gym/user/\u003cmember_pk\u003e/config` -\u003e user config view\n- `GET /en/gym/user/\u003cmember_pk\u003e/permissions` -\u003e permission edit view\n\n**Suggested patch**:\n\n```diff\n--- a/wger/gym/views/user.py\n+++ b/wger/gym/views/user.py\n- if request.user.userprofile.gym != user.userprofile.gym:\n- return HttpResponseForbidden()\n+ trainer_gym_id = request.user.userprofile.gym_id\n+ member_gym_id = user.userprofile.gym_id\n+\n+ if trainer_gym_id is None or trainer_gym_id != member_gym_id:\n+ return HttpResponseForbidden()\n\n# Also tighten the queryset with a gym-scoped secondary filter:\n- notes = AdminUserNote.objects.filter(member=member)\n+ notes = AdminUserNote.objects.filter(\n+ member=member,\n+ member__userprofile__gym_id=request.user.userprofile.gym_id,\n+ )\n```\n\nExtract a shared helper `assert_same_gym(trainer, member)` and call it consistently from all five affected views to eliminate future drift.\n\n### PoC\n\nTested on `wger/server:latest` Docker image. Test users: `trainer1` (`gym.gym_trainer` + `gym.add_adminusernote` permissions, `userprofile.gym=None`) and `alice` (regular user, `userprofile.gym=None`, has a private admin note pre-seeded).\n\n**Step 1** - Authenticate as trainer with required perms and gym=None:\n\n```\nPOST /en/user/login HTTP/1.1\nHost: target\nContent-Type: application/x-www-form-urlencoded\n\nusername=trainer1\u0026password=[REDACTED]\u0026csrfmiddlewaretoken=[REDACTED]\n\n-\u003e 302 Found; Set-Cookie: sessionid=[trainer1_session]\n```\n\n**Step 2** - Read victim\u0027s private admin notes:\n\n```\nGET /en/gym/notes/list/user/2 HTTP/1.1\nHost: target\nCookie: sessionid=[trainer1_session]\n\n-\u003e 200 OK\nbody contains all private admin notes for user 2:\n \"PRIVATE_NOTE_ABOUT_ALICE_SALARY_50K\"\n \"PHASE4_SECRET_SALARY_100K\"\n```\n\n**Step 3** - Read victim\u0027s documents and contracts (same pattern):\n\n```\nGET /en/gym/documents/list/user/2\nGET /en/gym/contract/list/2\n\n-\u003e 200 OK for each; all records disclosed\n```\n\n**Step 4** (optional) - Mass enumeration across all gym=None users:\n\n```\nIterate user PKs 1..N:\nGET /en/gym/notes/list/user/{uid}\n-\u003e 200 = gym=None victim (notes leaked)\n-\u003e 403 = gym-assigned user (check works correctly when gym values differ)\n```\n\n**RBAC Disproof Protocol**:\n- Scenario A (admin, gym=1 -\u003e member gym=1) -\u003e HTTP 200 (expected - same-gym read is a documented feature)\n- Scenario B (trainer1, gym=None -\u003e alice gym=None) -\u003e **HTTP 200 with PII in body** (expected HTTP 403)\n- Scenario C (admin, gym=1 -\u003e alice gym=None) -\u003e HTTP 403 (expected - guard works when gyms differ; confirms bypass is `None`-specific)\n\nReproducibility: 2/2 runs after clean-baseline database reset.\n\n### Impact\n\nAn authenticated trainer with `gym.gym_trainer` + `gym.add_adminusernote` permissions and `userprofile.gym=None` can:\n\n1. Enumerate and read all private admin notes for every other `gym=None` user (notes may contain salary data, medical notes, disciplinary records).\n2. Download all uploaded documents attached to those users (contracts, ID scans, medical forms).\n3. Read all gym contracts (financial terms, subscription details).\n4. Read user configuration details.\n5. Via the permissions endpoint, potentially **modify victim permissions** (creates a privilege escalation path - not fully explored in this submission but the endpoint is reachable).\n\n**Affected deployments**: every wger instance where `gym.gym_trainer` + `gym.add_adminusernote` are delegated to non-admin users AND any other users exist with `gym=None`. The `gym=None` state is the **default for newly registered users** before manual gym assignment, so every public-registration wger instance is affected.\n\n**Severity**: High (CVSS 7.1). Network-reachable, low complexity, requires only low privilege (delegated trainer), scope unchanged (same wger authority), high confidentiality loss across all unaffiliated accounts, low integrity impact (permission-edit view reachable).\n\nThis is structurally the same bug class as the sibling findings affecting `trainer_login` and `reset_user_password` (submitted separately). The root cause - Django ORM object-`!=` returning `False` when both sides are `None` - warrants a shared `same_gym()` helper applied across all five views.",
"id": "GHSA-c72h-82w6-rqfp",
"modified": "2026-10-07T13:33:14Z",
"published": "2026-10-07T13:33:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/wger-project/wger/security/advisories/GHSA-c72h-82w6-rqfp"
},
{
"type": "PACKAGE",
"url": "https://github.com/wger-project/wger"
},
{
"type": "WEB",
"url": "https://github.com/wger-project/wger/releases/tag/2.6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "wger: cross-tenant admin notes/contracts leak via gym=None bypass (5 views)"
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
No CAPEC attack patterns related to this CWE.