CWE-288
AllowedAuthentication Bypass Using an Alternate Path or Channel
Abstraction: Base · Status: Incomplete
The product requires authentication, but the product has an alternate path or channel that does not require authentication.
1183 vulnerabilities reference this CWE, most recent first.
GHSA-7CQG-GQ5X-QR9Q
Vulnerability from github – Published: 2026-07-01 06:31 – Updated: 2026-07-01 12:31In Modem, there is a possible information disclosure due to improper input validation. This could lead to remote information disclosure, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01811421; Issue ID: MSV-6788.
{
"affected": [],
"aliases": [
"CVE-2026-20460"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-01T04:17:15Z",
"severity": "MODERATE"
},
"details": "In Modem, there is a possible information disclosure due to improper input validation. This could lead to remote information disclosure, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01811421; Issue ID: MSV-6788.",
"id": "GHSA-7cqg-gq5x-qr9q",
"modified": "2026-07-01T12:31:34Z",
"published": "2026-07-01T06:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20460"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/July-2026"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7CVP-JG2X-QVQG
Vulnerability from github – Published: 2024-07-25 18:32 – Updated: 2024-08-26 18:33Positron Broadcast Signal Processor TRA7005 v1.20 is vulnerable to an authentication bypass exploit that could allow an attacker to have unauthorized access to protected areas of the application.
{
"affected": [],
"aliases": [
"CVE-2024-7007"
],
"database_specific": {
"cwe_ids": [
"CWE-288",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-25T17:15:11Z",
"severity": "HIGH"
},
"details": "Positron Broadcast Signal Processor TRA7005 v1.20 is vulnerable to an authentication bypass exploit that could allow an attacker to have unauthorized access to protected areas of the application.",
"id": "GHSA-7cvp-jg2x-qvqg",
"modified": "2024-08-26T18:33:32Z",
"published": "2024-07-25T18:32:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7007"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-24-207-02"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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-7GP3-R9H9-V4J9
Vulnerability from github – Published: 2026-05-29 12:31 – Updated: 2026-06-01 21:30Nozomi Networks Labs identified a CWE-288: Authentication Bypass Using an Alternate Path or Channel in the Console WebUI in Waterfall WF-500 TX and RX Hosts in version 7.9.1.0 R2502171040 that allows remote unauthenticated attackers to bypass authentication of the Console web application and perform actions as an authenticated user.
{
"affected": [],
"aliases": [
"CVE-2025-41273"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-29T12:16:23Z",
"severity": "CRITICAL"
},
"details": "Nozomi Networks Labs identified a CWE-288: Authentication Bypass Using an Alternate Path or Channel in the Console WebUI in Waterfall WF-500 TX and RX Hosts in version 7.9.1.0 R2502171040 that allows remote unauthenticated attackers to bypass authentication of the Console web application and perform actions as an authenticated user.",
"id": "GHSA-7gp3-r9h9-v4j9",
"modified": "2026-06-01T21:30:41Z",
"published": "2026-05-29T12:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41273"
},
{
"type": "WEB",
"url": "https://www.nozominetworks.com/labs/vulnerability-advisories-cve-2025-41273"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/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-7J72-F6WG-CXW6
Vulnerability from github – Published: 2026-09-03 21:22 – Updated: 2026-09-03 21:22CVE: This vulnerability corresponds to CVE-2026-68584.
Summary
SiYuan's publish mode defines a "protected" access level: a document that is publicly listed but requires a password to read (per the product's own UI help text, protected = "Publicly visible, requires password to access"). The password is enforced on the primary content path (getDoc, via FilterContentByPublishAccess).
Several other content-returning endpoints getHeadingChildrenDOM, getHeadingDeleteTransaction/getHeadingLevelTransaction/ getHeadingInsertTransaction, and getBacklinkDoc/getBackmentionDoc return rendered block DOM with no password check at all. Combined with reader-reachable endpoints that leak a protected document's internal block IDs, an anonymous reader can retrieve the full body of a password-protected document without the password. This has been reproduced end-to-end on a live instance.
Details
The password control and where it is enforced. Publish access has five levels encoded in visible/password/disable: public, protected (password), hidden, private (password), forbidden. getDoc correctly enforces the password for protected/private documents via FilterContentByPublishAccess. The bug is that other content endpoints do not.
Content endpoints with no password check (all CheckAuth-only):
- getHeadingChildrenDOM returns rendered DOM of a heading subtree.
- getHeadingDeleteTransaction/getHeadingLevelTransaction/getHeadingInsertTransaction return rendered heading DOM in the computed transaction payload (no mutation occurs on this path).
- getBacklinkDoc/getBackmentionDoc return rendered DOM of referencing blocks.
None of these invokes the publish-password check that getDoc applies. Each converts a block ID into full rendered content regardless of the containing document's protected/password status.
The ID-leak that removes the precondition. A protected document is, by design, publicly listed (listDocsByPath filters on visible, and protected documents are visible), so an anonymous reader obtains the document's root ID. The document's internal block/heading IDs are then obtainable from reader-reachable endpoints notably the searchEmbedBlock endpoint (reported separately), whose post-query filter FilterEmbedBlocksByPublishAccess replaces the content string but retains the block ID. So the "filtered" search still yields the protected document's internal heading IDs. (Other reader-reachable endpoints also leak block IDs, the vulnerability does not depend on any single ID source.)
The chain, reproduced on a live instance. Against a real protected document (password set), an anonymous reader on port 6808 with no token and no password:
getDoc(protectedDoc)→ returns the password-required placeholder (correctly blocked).searchEmbedBlockwith a statement selecting heading blocks for the document's root ID → returns the heading IDs (content filtered, IDs retained).getHeadingChildrenDOM(headingId)→ returns the full rendered body of the protected document, including its protected content.
The password gate that step 1 enforces is entirely bypassed by step 3.
Proof of Concept
Reproduced on a local instance (SiYuan running locally, publish mode enabled on port 6808, publish Basic Auth disabled). Setup: a document marked "protected" with password, whose body contains the unique marker TOP_SECRET_CRITICAL_123.
1. Confirm the password gate blocks the primary path (anonymous, port 6808):
POST http://127.0.0.1:6808/api/filetree/getDoc
{"id":"PROTECTED_DOC"}
Returns the password-required placeholder correctly blocked.
2. Leak the protected document's heading ID (anonymous, port 6808):
POST http://127.0.0.1:6808/api/search/searchEmbedBlock
{"stmt":"SELECT * FROM blocks WHERE root_id='PROTECTED_DOC' AND type='h'"}
Returns heading blocks with their IDs; the content field is filtered but the block ID is retained.
3. Retrieve the protected content without the password (anonymous, port 6808):
POST http://127.0.0.1:6808/api/block/getHeadingChildrenDOM
{"id":"HEADING_ID"}
Returns HTTP 200 with the rendered body of the protected document, including TOP_SECRET_CRITICAL_123 retrieved with no token and no password.
getHeadingDeleteTransaction/getHeadingLevelTransaction/getHeadingInsertTransaction and getBacklinkDoc/ getBackmentionDoc provide the same password-free content retrieval given a block ID from the protected document.
Impact
An anonymous reader (publish mode with auth disabled) or any publish RoleReader can read the full content of a password-protected published document without the password, defeating the "protected" access control the product documents as a password gate. The core defect is that these content-returning endpoints perform no publish-password check; the ID-leak endpoints (multiple sources) supply the block IDs that make the bypass reachable anonymously and untargeted. Impact is confidentiality-only (content disclosure); no modification occurs on these paths. Encrypted notebooks are out of scope.
Suggested fix
Apply the publish-password/publish-access check that getDoc uses (FilterContentByPublishAccess/IsReadOnlyRoleContext plus the password-cookie check) to every content-returning endpoint: getHeadingChildrenDOM, the three getHeading*Transaction handlers, and getBacklinkDoc/getBackmentionDoc. Separately, FilterEmbedBlocksByPublishAccess should omit filtered blocks entirely rather than blanking the content while retaining the ID, so that filtered results cannot be used to enumerate a protected document's internal block IDs. The durable fix is to enforce the publish boundary in the shared render/DOM path rather than per-handler, since any content endpoint that omits the check reintroduces this class.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260721020826-2d069dce84a2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-03T21:22:42Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "**CVE:** This vulnerability corresponds to [CVE-2026-68584](https://nvd.nist.gov/vuln/detail/CVE-2026-68584).\n\n### Summary\n\nSiYuan\u0027s publish mode defines a \"protected\" access level: a document that is publicly listed but requires a password to read (per the product\u0027s own UI help text, protected = \"Publicly visible, requires password to access\"). The password is enforced on the primary content path (`getDoc`, via `FilterContentByPublishAccess`).\n\nSeveral other content-returning endpoints `getHeadingChildrenDOM`, `getHeadingDeleteTransaction`/`getHeadingLevelTransaction`/ `getHeadingInsertTransaction`, and `getBacklinkDoc`/`getBackmentionDoc` return rendered block DOM with **no password check at all**. Combined with reader-reachable endpoints that leak a protected document\u0027s internal block IDs, an anonymous reader can retrieve the full body of a password-protected document without the password. This has been reproduced end-to-end on a live instance.\n\n### Details\n\n**The password control and where it is enforced.** Publish access has five levels encoded in `visible`/`password`/`disable`: public, protected (password), hidden, private (password), forbidden. `getDoc` correctly enforces the password for protected/private documents via `FilterContentByPublishAccess`. The bug is that other content endpoints do not.\n\n**Content endpoints with no password check (all `CheckAuth`-only):**\n- `getHeadingChildrenDOM` returns rendered DOM of a heading subtree.\n- `getHeadingDeleteTransaction`/`getHeadingLevelTransaction`/`getHeadingInsertTransaction` return rendered heading DOM in the computed transaction payload (no mutation occurs on this path).\n- `getBacklinkDoc`/`getBackmentionDoc` return rendered DOM of referencing blocks.\n\nNone of these invokes the publish-password check that `getDoc` applies. Each converts a block ID into full rendered content regardless of the containing document\u0027s protected/password status.\n\n**The ID-leak that removes the precondition.** A protected document is, by design, publicly listed (`listDocsByPath` filters on `visible`, and protected documents are visible), so an anonymous reader obtains the document\u0027s root ID. The document\u0027s internal block/heading IDs are then obtainable from reader-reachable endpoints notably the `searchEmbedBlock` endpoint (reported separately), whose post-query filter `FilterEmbedBlocksByPublishAccess` **replaces the content string but retains the block ID**. So the \"filtered\" search still yields the protected document\u0027s internal heading IDs. (Other reader-reachable endpoints also leak block IDs, the vulnerability does not depend on any single ID source.)\n\n**The chain, reproduced on a live instance.** Against a real protected document (password set), an anonymous reader on port 6808 with no token and no password:\n\n1. `getDoc(protectedDoc)` \u2192 returns the password-required placeholder (correctly blocked).\n2. `searchEmbedBlock` with a statement selecting heading blocks for the document\u0027s root ID \u2192 returns the heading IDs (content filtered, IDs retained).\n3. `getHeadingChildrenDOM(headingId)` \u2192 returns the full rendered body of the protected document, including its protected content.\n\nThe password gate that step 1 enforces is entirely bypassed by step 3.\n\n### Proof of Concept\n\nReproduced on a local instance (SiYuan running locally, publish mode enabled on port 6808, publish Basic Auth disabled). Setup: a document marked \"protected\" with password, whose body contains the unique marker `TOP_SECRET_CRITICAL_123`.\n\n**1. Confirm the password gate blocks the primary path (anonymous, port 6808):**\n```\nPOST http://127.0.0.1:6808/api/filetree/getDoc\n{\"id\":\"PROTECTED_DOC\"}\n```\nReturns the password-required placeholder correctly blocked.\n\n**2. Leak the protected document\u0027s heading ID (anonymous, port 6808):**\n```\nPOST http://127.0.0.1:6808/api/search/searchEmbedBlock\n{\"stmt\":\"SELECT * FROM blocks WHERE root_id=\u0027PROTECTED_DOC\u0027 AND type=\u0027h\u0027\"}\n```\nReturns heading blocks with their IDs; the content field is filtered but the block ID is retained.\n\n**3. Retrieve the protected content without the password (anonymous, port 6808):**\n```\nPOST http://127.0.0.1:6808/api/block/getHeadingChildrenDOM\n{\"id\":\"HEADING_ID\"}\n```\nReturns HTTP 200 with the rendered body of the protected document, including `TOP_SECRET_CRITICAL_123` retrieved with no token and no password.\n\n`getHeadingDeleteTransaction`/`getHeadingLevelTransaction`/`getHeadingInsertTransaction` and `getBacklinkDoc`/ `getBackmentionDoc` provide the same password-free content retrieval given a block ID from the protected document.\n\n### Impact\n\nAn anonymous reader (publish mode with auth disabled) or any publish `RoleReader` can read the full content of a password-protected published document without the password, defeating the \"protected\" access control the product documents as a password gate. The core defect is that these content-returning endpoints perform no publish-password check; the ID-leak endpoints (multiple sources) supply the block IDs that make the bypass reachable anonymously and untargeted. Impact is confidentiality-only (content disclosure); no modification occurs on these paths. Encrypted notebooks are out of scope.\n\n### Suggested fix\n\nApply the publish-password/publish-access check that `getDoc` uses (`FilterContentByPublishAccess`/`IsReadOnlyRoleContext` plus the password-cookie check) to every content-returning endpoint: `getHeadingChildrenDOM`, the three `getHeading*Transaction` handlers, and `getBacklinkDoc`/`getBackmentionDoc`. Separately, `FilterEmbedBlocksByPublishAccess` should omit filtered blocks entirely rather than blanking the content while retaining the ID, so that filtered results cannot be used to enumerate a protected document\u0027s internal block IDs. The durable fix is to enforce the publish boundary in the shared render/DOM path rather than per-handler, since any content endpoint that omits the check reintroduces this class.",
"id": "GHSA-7j72-f6wg-cxw6",
"modified": "2026-09-03T21:22:42Z",
"published": "2026-09-03T21:22:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-7j72-f6wg-cxw6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68584"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/commit/2d069dce84a25c959ef0093c72c98e05778ef218"
},
{
"type": "PACKAGE",
"url": "https://github.com/siyuan-note/siyuan"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/siyuan-before-authentication-bypass-via-content-endpoints"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "SiYuan: Anonymous publish-password authentication bypass via getHeadingChildrenDOM / getHeading*Transaction / getBacklinkDoc (publish mode)"
}
GHSA-7J8H-2P3W-MMHX
Vulnerability from github – Published: 2026-06-15 21:30 – Updated: 2026-06-15 21:30Unauthenticated Broken Authentication in Email Marketing for WooCommerce by Omnisend <= 1.18.0 versions.
{
"affected": [],
"aliases": [
"CVE-2026-42668"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-15T21:16:56Z",
"severity": "HIGH"
},
"details": "Unauthenticated Broken Authentication in Email Marketing for WooCommerce by Omnisend \u003c= 1.18.0 versions.",
"id": "GHSA-7j8h-2p3w-mmhx",
"modified": "2026-06-15T21:30:47Z",
"published": "2026-06-15T21:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42668"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/omnisend-connect/vulnerability/wordpress-email-marketing-for-woocommerce-by-omnisend-plugin-1-18-0-broken-authentication-vulnerability?_s_id=cve"
}
],
"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-7JGQ-6QW7-J88F
Vulnerability from github – Published: 2024-05-14 18:30 – Updated: 2024-07-03 18:40An issue was discovered on certain Nuki Home Solutions devices. An attacker with physical access to this JTAG port may be able to connect to the device and bypass both hardware and software security protections. This affects Nuki Keypad before 1.9.2 and Nuki Fob before 1.8.1.
{
"affected": [],
"aliases": [
"CVE-2022-32503"
],
"database_specific": {
"cwe_ids": [
"CWE-288",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-14T10:43:41Z",
"severity": "HIGH"
},
"details": "An issue was discovered on certain Nuki Home Solutions devices. An attacker with physical access to this JTAG port may be able to connect to the device and bypass both hardware and software security protections. This affects Nuki Keypad before 1.9.2 and Nuki Fob before 1.8.1.",
"id": "GHSA-7jgq-6qw7-j88f",
"modified": "2024-07-03T18:40:03Z",
"published": "2024-05-14T18:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32503"
},
{
"type": "WEB",
"url": "https://latesthackingnews.com/2022/07/28/multiple-security-flaws-found-in-nuki-smart-locks"
},
{
"type": "WEB",
"url": "https://nuki.io/en/security-updates"
},
{
"type": "WEB",
"url": "https://research.nccgroup.com/2022/07/25/technical-advisory-multiple-vulnerabilities-in-nuki-smart-locks-cve-2022-32509-cve-2022-32504-cve-2022-32502-cve-2022-32507-cve-2022-32503-cve-2022-32510-cve-2022-32506-cve-2022-32508-cve-2"
},
{
"type": "WEB",
"url": "https://www.hackread.com/nuki-smart-locks-vulnerabilities-plethora-attack-options"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7JM8-GRV9-RQQX
Vulnerability from github – Published: 2024-10-26 03:30 – Updated: 2024-10-26 03:30The Wux Blog Editor plugin for WordPress is vulnerable to authentication bypass in versions up to, and including, 3.0.0. This is due to missing validation on the token being supplied during the autologin through the plugin. This makes it possible for unauthenticated attackers to log in to the first administrator user.
{
"affected": [],
"aliases": [
"CVE-2024-9931"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-26T03:15:04Z",
"severity": "CRITICAL"
},
"details": "The Wux Blog Editor plugin for WordPress is vulnerable to authentication bypass in versions up to, and including, 3.0.0. This is due to missing validation on the token being supplied during the autologin through the plugin. This makes it possible for unauthenticated attackers to log in to the first administrator user.",
"id": "GHSA-7jm8-grv9-rqqx",
"modified": "2024-10-26T03:30:43Z",
"published": "2024-10-26T03:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9931"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wux-blog-editor/tags/3.0.0/External_Post_Editor.php#L675"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/494ef738-c900-4d00-8739-3b261586d4ff?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7M7M-MM9G-Q3CC
Vulnerability from github – Published: 2026-08-18 21:31 – Updated: 2026-08-20 15:33An Authentication Bypass vulnerability exists in EPSON EH-TW5350 EPSON 150075647YWWV110, which could let a remote malicious user cause a Denial of Service via specially crafted series of HTTP..
{
"affected": [],
"aliases": [
"CVE-2021-43718"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-18T19:16:42Z",
"severity": "MODERATE"
},
"details": "An Authentication Bypass vulnerability exists in EPSON EH-TW5350 EPSON 150075647YWWV110, which could let a remote malicious user cause a Denial of Service via specially crafted series of HTTP..",
"id": "GHSA-7m7m-mm9g-q3cc",
"modified": "2026-08-20T15:33:36Z",
"published": "2026-08-18T21:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43718"
},
{
"type": "WEB",
"url": "https://github.com/dpfkdlemtp/epson-eh-tw5350-advisories/blob/master/CVE-2021-43718.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-7PC7-CRJ3-6P7V
Vulnerability from github – Published: 2023-11-03 12:30 – Updated: 2026-04-08 18:32The MStore API plugin for WordPress is vulnerable to Unauthorized Account Access and Privilege Escalation in versions up to, and including, 4.10.7 due to improper implementation of the Apple login feature. This allows unauthenticated attackers to log in as any user as long as they know the user's email address. We are disclosing this issue as the developer has not yet released a patch, but continues to release updates and we escalated this issue to the plugin's team 30 days ago.
{
"affected": [],
"aliases": [
"CVE-2023-3277"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-03T12:15:08Z",
"severity": "CRITICAL"
},
"details": "The MStore API plugin for WordPress is vulnerable to Unauthorized Account Access and Privilege Escalation in versions up to, and including, 4.10.7 due to improper implementation of the Apple login feature. This allows unauthenticated attackers to log in as any user as long as they know the user\u0027s email address. We are disclosing this issue as the developer has not yet released a patch, but continues to release updates and we escalated this issue to the plugin\u0027s team 30 days ago.",
"id": "GHSA-7pc7-crj3-6p7v",
"modified": "2026-04-08T18:32:23Z",
"published": "2023-11-03T12:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3277"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/mstore-api/trunk/controllers/flutter-user.php#L821"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=2988788%40mstore-api%2Ftrunk\u0026old=2985882%40mstore-api%2Ftrunk\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/1c7c0c35-5f44-488f-9fe1-269ea4a73854?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7Q8C-77JC-9828
Vulnerability from github – Published: 2025-10-03 09:30 – Updated: 2025-10-03 09:30The Spirit Framework plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 1.2.14. This is due to the custom_actions() function not properly validating a user's identity prior to authenticating them to the site. This makes it possible for unauthenticated attackers to log in as any user, including administrators, granted they have access to the administrator's username.
{
"affected": [],
"aliases": [
"CVE-2025-6388"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-03T09:15:38Z",
"severity": "CRITICAL"
},
"details": "The Spirit Framework plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 1.2.14. This is due to the custom_actions() function not properly validating a user\u0027s identity prior to authenticating them to the site. This makes it possible for unauthenticated attackers to log in as any user, including administrators, granted they have access to the administrator\u0027s username.",
"id": "GHSA-7q8c-77jc-9828",
"modified": "2025-10-03T09:30:19Z",
"published": "2025-10-03T09:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6388"
},
{
"type": "WEB",
"url": "https://themespirit.com/talemy-changelog"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/a4cbc0e7-4328-451f-a595-1ce17e9d0031?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Funnel all access through a single choke point to simplify how users can access a resource. For every access, perform a check to determine if the user has permissions to access the resource.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
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.