CWE-862
Weakness 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.
Dimensions
- Behavior-Property: Missing
- Behavior-Type: Authorization
Mapping guidance
This CWE entry is a Class and might have Base-level children that would be more appropriate
Examine children of this entry to see if there is a better fit
Relationships and members
Modes of introduction
OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Authorization weaknesses may arise when a single-user application is ported to a multi-user environment.
A developer may introduce authorization weaknesses because of a lack of understanding about the underlying technologies. For example, a developer may assume that attackers cannot modify certain inputs such as headers or cookies.
Detection methods
Automated Static Analysis
Automated static analysis is useful for detecting commonly-used idioms for authorization. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authorization libraries.
Generally, automated static analysis tools have difficulty detecting custom authorization schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an authorization check; an automated technique that detects the absence of authorization may report false positives.
Effectiveness: Limited
Automated Dynamic Analysis
Automated dynamic analysis may find many or all possible interfaces that do not require authorization, but manual analysis is required to determine if the lack of authorization violates business logic.
Manual Analysis
This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.
Specifically, manual static analysis is useful for evaluating the correctness of custom authorization mechanisms.
Effectiveness: Moderate
These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. However, manual efforts might not achieve desired code coverage within limited time constraints.
Manual Static Analysis - Binary or Bytecode
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
Effectiveness: SOAR Partial
Dynamic Analysis with Automated Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Web Application Scanner
Web Services Scanner
Database Scanners
Effectiveness: SOAR Partial
Dynamic Analysis with Manual Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Host Application Interface Scanner
Fuzz Tester
Framework-based Fuzzer
Effectiveness: SOAR Partial
Manual Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Focused Manual Spotcheck - Focused manual analysis of source
Manual Source Code Review (not inspections)
Effectiveness: SOAR Partial
Automated Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer
Effectiveness: SOAR Partial
Architecture or Design Review
According to SOAR [REF-1479], the following detection techniques may be useful:
Highly cost effective:
Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Formal Methods / Correct-By-Construction
Effectiveness: High
Notes
Terminology
Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.
Content history
Suggested mappings to ISA/IEC 62443.
Provided diagram to improve CWE usability
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships
updated Potential_Mitigations, References, Relationships
updated Demonstrative_Examples, Observed_Examples, References, Relationships
updated Potential_Mitigations
updated Relationships
updated Detection_Factors
updated Relationships
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
updated References
updated Relationships
updated Relationships
updated Relationships
updated Relationships
updated Alternate_Terms, Observed_Examples
updated Observed_Examples, Related_Attack_Patterns, Relationships
updated Relationships
updated Relationships
updated Observed_Examples
updated Description, Potential_Mitigations
updated References, Relationships, Taxonomy_Mappings
updated Mapping_Notes, Relationships, Taxonomy_Mappings
updated Common_Consequences, Description, Diagram, Relationships, Terminology_Notes
updated Applicable_Platforms, Detection_Factors, Observed_Examples, References
updated Applicable_Platforms, Relationships, Weakness_Ordinalities
updated Applicable_Platforms, Observed_Examples, Relationships
updated Applicable_Platforms, Dimensions, References, Relationships, Taxonomy_Mappings
19823 vulnerabilities reference this CWE, most recent first.
GHSA-69J6-29VR-P3J9
Vulnerability from github – Published: 2021-10-05 20:24 – Updated: 2025-10-22 19:08Today we are releasing Grafana 7.5.11, and 8.1.6. These patch releases include an important security fix for an issue that affects all Grafana versions from 2.0.1.
Grafana Cloud instances have already been patched and an audit did not find any usage of this attack vector. Grafana Enterprise customers were provided with updated binaries under embargo.
8.1.5 contained a single fix for bar chart panels. We believe that users can expedite deployment by moving from 8.1.4 to 8.1.6 directly.
CVE-2021-39226 Snapshot authentication bypass
Summary
CVSS Score: 9.8 Critical CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
We received a security report to security@grafana.com on 2021-09-15 about a vulnerability in Grafana regarding the snapshot feature. It was later identified as affecting Grafana versions from 2.0.1 to 8.1.6. CVE-2021-39226 has been assigned to this vulnerability.
Impact
Unauthenticated and authenticated users are able to view the snapshot with the lowest database key by accessing the literal paths:
/dashboard/snapshot/:key, or/api/snapshots/:key
If the snapshot "public_mode" configuration setting is set to true (vs default of false), unauthenticated users are able to delete the snapshot with the lowest database key by accessing the literal path:
/api/snapshots-delete/:deleteKey
Regardless of the snapshot "public_mode" setting, authenticated users are able to delete the snapshot with the lowest database key by accessing the literal paths:
/api/snapshots/:key, or/api/snapshots-delete/:deleteKey
The combination of deletion and viewing enables a complete walk through all snapshot data while resulting in complete snapshot data loss.
Attack audit
While we can not guarantee that the below will identify all attacks, if you do find something with the below, you should consider doing a full assessment.
Through reverse proxy/load balancer logs
To determine if your Grafana installation has been exploited for this vulnerability, search through your reverse proxy/load balancer access logs for instances where the path is /dashboard/snapshot/:key, /api/snapshots/:key or /api/snapshots-delete/:deleteKey, and the response status code was 200 (OK).
For example, if you’re using the Kubernetes ingress-nginx controller and sending logs to Loki, use a LogQL query like {job="nginx-ingress-controller"} |= "\"status\": 200" |= "\"uri\": \"/api/snapshots/:key\"".
Through the Grafana Enterprise audit feature
If you enabled “Log web requests” in your configuration with router_logging = true, look for
"requestUri":"/api/snapshots-delete/”,“requestUri":"/api/snapshots/:key", or "type":"snapshot" in combination with "action":"delete".
Patched versions
Release 8.1.6:
Release 7.5.11:
Solutions and mitigations
Download and install the appropriate patch for your version of Grafana.
Grafana Cloud instances have already been patched, and Grafana Enterprise customers were provided with updated binaries under embargo.
Workaround
If for some reason you cannot upgrade:
You can use a reverse proxy or similar to block access to the literal paths
* /api/snapshots/:key
* /api/snapshots-delete/:deleteKey
* /dashboard/snapshot/:key
* /api/snapshots/:key
They have no normal function and can be disabled without side effects.
Timeline and postmortem
Here is a detailed timeline starting from when we originally learned of the issue. All times in UTC.
- 2021-09-15 14:49: Tuan Tran theblackturtle0901@gmail.com sends initial report about viewing snapshots without authentication
- 2021-09-15 15:56: Initial reproduction
- 2021-09-15 17:10: MEDIUM severity declared
- 2021-09-15 18:58: Workaround deployed on Grafana Cloud
- 2021-09-15 19:15:
/api/snapshots/:keyfound to be vulnerable as well - 2021-09-15 19:30:
/api/snapshots/:keyblocked on Grafana Cloud - 2021-09-16 09:31:
/api/snapshots-delete/:deleteKeyfound to be vulnerable as well, blocked on Grafana Cloud. From this point forward, Cloud is not affected any more. - 2021-09-16 09:35: HIGH severity declared
- 2021-09-16 11:19: Realization that combination of deletion and viewing allows enumeration and permanent DoS
- 2021-09-16 11:19: CRITICAL declared
- 2021-09-17 10:53: Determination that no weekend work is needed. While issue is CRITICAL, scope is very limited
- 2021-09-17 14:26: Audit of Grafana Cloud concluded, no evidence of exploitation
- 2021-09-23: Grafana Cloud instances updated
- 2021-09-28 12:00: Grafana Enterprise images released to customers under embargo
- 2021-10-05 17:00: Public release
Reporting security issues
If you think you have found a security vulnerability, please send a report to security@grafana.com. This address can be used for all of Grafana Labs's open source and commercial products (including but not limited to Grafana, Tempo, Loki, Amixr, k6, Tanka, and Grafana Cloud, Grafana Enterprise, and grafana.com). We only accept vulnerability reports at this address. We would prefer that you encrypt your message to us using our PGP key. The key fingerprint is:
F988 7BEA 027A 049F AE8E 5CAA D125 8932 BE24 C5CA
The key is available from keys.gnupg.net by searching for [security@grafana](http://keys.gnupg.net/pks/lookup?search=security@grafana&fingerprint=on&op=index.
Security announcements
We maintain a category on the community site named Security Announcements, where we will post a summary, remediation, and mitigation details for any patch containing security fixes. You can also subscribe to email updates to this category if you have a grafana.com account and sign in to the community site, or via updates from our Security Announcements RSS feed.
Acknowledgement
We would like to thank Tran Viet Tuan for responsibly disclosing the initially discovered vulnerability to us.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/grafana/grafana"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.5.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/grafana/grafana"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.1.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-39226"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2021-10-05T18:49:35Z",
"nvd_published_at": "2021-10-05T18:15:00Z",
"severity": "HIGH"
},
"details": "Today we are releasing Grafana 7.5.11, and 8.1.6. These patch releases include an important security fix for an issue that affects all Grafana versions from 2.0.1.\n\n[Grafana Cloud](https://grafana.com/cloud) instances have already been patched and an audit did not find any usage of this attack vector. [Grafana Enterprise](https://grafana.com/products/enterprise) customers were provided with updated binaries under embargo.\n\n8.1.5 contained a single fix for bar chart panels. We believe that users can expedite deployment by moving from 8.1.4 to 8.1.6 directly.\n\n## CVE-2021-39226 Snapshot authentication bypass\n\n### Summary\n\nCVSS Score: 9.8 Critical\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\n\nWe received a security report to [security@grafana.com](mailto:security@grafana.com) on 2021-09-15 about a vulnerability in Grafana regarding the snapshot feature. It was later identified as affecting Grafana versions from 2.0.1 to 8.1.6. [CVE-2021-39226](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39226) has been assigned to this vulnerability.\n\n### Impact\nUnauthenticated and authenticated users are able to view the snapshot with the lowest database key by accessing the literal paths:\n\n* `/dashboard/snapshot/:key`, or\n* `/api/snapshots/:key`\n\nIf the snapshot \"public_mode\" configuration setting is set to true (vs default of false), unauthenticated users are able to delete the snapshot with the lowest database key by accessing the literal path:\n\n* `/api/snapshots-delete/:deleteKey`\n\nRegardless of the snapshot \"public_mode\" setting, authenticated users are able to delete the snapshot with the lowest database key by accessing the literal paths:\n\n* `/api/snapshots/:key`, or\n* `/api/snapshots-delete/:deleteKey`\n\nThe combination of deletion and viewing enables a complete walk through all snapshot data while resulting in complete snapshot data loss.\n\n### Attack audit\n\nWhile we can not guarantee that the below will identify all attacks, if you do find something with the below, you should consider doing a full assessment.\n\n#### Through reverse proxy/load balancer logs\n\nTo determine if your Grafana installation has been exploited for this vulnerability, search through your reverse proxy/load balancer access logs for instances where the path is `/dashboard/snapshot/:key`, `/api/snapshots/:key` or `/api/snapshots-delete/:deleteKey`, and the response status code was 200 (OK).\nFor example, if you\u2019re using the Kubernetes ingress-nginx controller and sending logs to Loki, use a LogQL query like `{job=\"nginx-ingress-controller\"} |= \"\\\"status\\\": 200\" |= \"\\\"uri\\\": \\\"/api/snapshots/:key\\\"\"`.\n\n#### Through the Grafana Enterprise audit feature\n\nIf you enabled \u201cLog web requests\u201d in your configuration with `router_logging = true`, look for\n`\"requestUri\":\"/api/snapshots-delete/\u201d`,`\u201crequestUri\":\"/api/snapshots/:key\"`, or `\"type\":\"snapshot\"` in combination with `\"action\":\"delete\"`.\n\n### Patched versions\n\nRelease 8.1.6: \n\n- [Download Grafana 8.1.6](https://grafana.com/grafana/download/8.1.6)\n- [Release notes](https://grafana.com/docs/grafana/latest/release-notes/release-notes-8-1-6/)\n\nRelease 7.5.11: \n\n- [Download Grafana 7.5.11](https://grafana.com/grafana/download/7.5.11)\n- [Release notes](https://grafana.com/docs/grafana/latest/release-notes/release-notes-7-5-11/)\n\n### Solutions and mitigations\n\nDownload and install the appropriate patch for your version of Grafana.\n\n[Grafana Cloud](https://grafana.com/cloud) instances have already been patched, and [Grafana Enterprise](https://grafana.com/products/enterprise) customers were provided with updated binaries under embargo.\n\n### Workaround\n\nIf for some reason you cannot upgrade:\n\nYou can use a reverse proxy or similar to block access to the literal paths\n* `/api/snapshots/:key`\n* `/api/snapshots-delete/:deleteKey`\n* `/dashboard/snapshot/:key`\n* `/api/snapshots/:key`\n\nThey have no normal function and can be disabled without side effects.\n\n### Timeline and postmortem\n\nHere is a detailed timeline starting from when we originally learned of the issue. All times in UTC.\n\n* 2021-09-15 14:49: Tuan Tran theblackturtle0901@gmail.com sends initial report about viewing snapshots without authentication\n* 2021-09-15 15:56: Initial reproduction\n* 2021-09-15 17:10: MEDIUM severity declared\n* 2021-09-15 18:58: Workaround deployed on Grafana Cloud\n* 2021-09-15 19:15: `/api/snapshots/:key` found to be vulnerable as well\n* 2021-09-15 19:30: `/api/snapshots/:key` blocked on Grafana Cloud\n* 2021-09-16 09:31: `/api/snapshots-delete/:deleteKey` found to be vulnerable as well, blocked on Grafana Cloud. From this point forward, Cloud is not affected any more.\n* 2021-09-16 09:35: HIGH severity declared\n* 2021-09-16 11:19: Realization that combination of deletion and viewing allows enumeration and permanent DoS\n* 2021-09-16 11:19: CRITICAL declared\n* 2021-09-17 10:53: Determination that no weekend work is needed. While issue is CRITICAL, scope is very limited\n* 2021-09-17 14:26: Audit of Grafana Cloud concluded, no evidence of exploitation\n* 2021-09-23: Grafana Cloud instances updated\n* 2021-09-28 12:00: Grafana Enterprise images released to customers under embargo\n* 2021-10-05 17:00: Public release\n\n## Reporting security issues\n\nIf you think you have found a security vulnerability, please send a report to [security@grafana.com](mailto:security@grafana.com). This address can be used for all of\nGrafana Labs\u0027s open source and commercial products (including but not limited to Grafana, Tempo, Loki, Amixr, k6, Tanka, and Grafana Cloud, Grafana Enterprise, and grafana.com). We only accept vulnerability reports at this address. We would prefer that you encrypt your message to us using our PGP key. The key fingerprint is:\n\nF988 7BEA 027A 049F AE8E 5CAA D125 8932 BE24 C5CA\n\nThe key is available from [keys.gnupg.net](http://keys.gnupg.net/pks/lookup?op=get\u0026fingerprint=on\u0026search=0xD1258932BE24C5CA) by searching for [security@grafana](http://keys.gnupg.net/pks/lookup?search=security@grafana\u0026fingerprint=on\u0026op=index.\n\n## Security announcements\n\nWe maintain a category on the community site named [Security Announcements](https://community.grafana.com/c/security-announcements),\nwhere we will post a summary, remediation, and mitigation details for any patch containing security fixes. You can also subscribe to email updates to this category if you have a grafana.com account and sign in to the community site, or via updates from our [Security Announcements RSS feed](https://community.grafana.com/c/security-announcements.rss).\n\n## Acknowledgement\n\nWe would like to thank [Tran Viet Tuan](https://github.com/theblackturtle) for responsibly disclosing the initially discovered vulnerability to us.",
"id": "GHSA-69j6-29vr-p3j9",
"modified": "2025-10-22T19:08:03Z",
"published": "2021-10-05T20:24:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/grafana/grafana/security/advisories/GHSA-69j6-29vr-p3j9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39226"
},
{
"type": "WEB",
"url": "https://github.com/grafana/grafana/commit/2d456a6375855364d098ede379438bf7f0667269"
},
{
"type": "PACKAGE",
"url": "https://github.com/grafana/grafana"
},
{
"type": "WEB",
"url": "https://grafana.com/docs/grafana/latest/release-notes/release-notes-7-5-11"
},
{
"type": "WEB",
"url": "https://grafana.com/docs/grafana/latest/release-notes/release-notes-8-1-6"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DCKBFUSY6V4VU5AQUYWKISREZX5NLQJT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/E6ANHRDBXQT6TURLP2THM26ZPDINFBEG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DCKBFUSY6V4VU5AQUYWKISREZX5NLQJT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/E6ANHRDBXQT6TURLP2THM26ZPDINFBEG"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20211029-0008"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-39226"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/10/05/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L/E:H",
"type": "CVSS_V3"
}
],
"summary": "Authentication bypass for viewing and deletions of snapshots"
}
GHSA-69J6-4W2P-2887
Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 12:32lunary-ai/lunary is vulnerable to broken access control in the latest version. An attacker can view the content of any dataset without any kind of authorization by sending a GET request to the /v1/datasets endpoint without a valid authorization token.
{
"affected": [],
"aliases": [
"CVE-2024-10272"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-20T10:15:15Z",
"severity": "HIGH"
},
"details": "lunary-ai/lunary is vulnerable to broken access control in the latest version. An attacker can view the content of any dataset without any kind of authorization by sending a GET request to the /v1/datasets endpoint without a valid authorization token.",
"id": "GHSA-69j6-4w2p-2887",
"modified": "2025-03-20T12:32:39Z",
"published": "2025-03-20T12:32:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10272"
},
{
"type": "WEB",
"url": "https://github.com/lunary-ai/lunary/commit/35dd4af0001a54ccb14276a1546eb977f82c0c5e"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/3de48a54-b5c9-40a1-b794-d59c36d58fb6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-69JP-F2P8-9VRG
Vulnerability from github – Published: 2026-08-18 12:31 – Updated: 2026-10-02 22:56Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-4vpg-gwqq-w44c. This link is maintained to preserve external references.
Original Description
SiYuan before v3.7.4 is missing authorization checks in 17 block metadata/content endpoints in kernel/api/block.go (including getRefText, checkBlockExist, and getBlockBreadcrumb). These handlers are gated only by basic authentication (model.CheckAuth) and lack publish-access filtering, allowing anonymous publish-mode readers to disclose private block content-derived text, structural metadata, and existence information for arbitrary block IDs across the workspace.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c 3.7.4"
},
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-02T22:56:13Z",
"nvd_published_at": "2026-08-18T12:19:30Z",
"severity": "HIGH"
},
"details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-4vpg-gwqq-w44c. This link is maintained to preserve external references.\n\n## Original Description\nSiYuan before v3.7.4 is missing authorization checks in 17 block metadata/content endpoints in kernel/api/block.go (including getRefText, checkBlockExist, and getBlockBreadcrumb). These handlers are gated only by basic authentication (model.CheckAuth) and lack publish-access filtering, allowing anonymous publish-mode readers to disclose private block content-derived text, structural metadata, and existence information for arbitrary block IDs across the workspace.",
"id": "GHSA-69jp-f2p8-9vrg",
"modified": "2026-10-02T22:56:13Z",
"published": "2026-08-18T12:31:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-4vpg-gwqq-w44c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74904"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/siyuan-before-missing-authorization-via-block-api"
}
],
"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"
},
{
"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"
}
],
"summary": "Duplicate Advisory: 17 block metadata/content endpoints in kernel/api/block.go have zero publish-access filtering, reachable by anonymous publish-mode readers",
"withdrawn": "2026-10-02T22:56:13Z"
}
GHSA-69M7-6XQG-M79V
Vulnerability from github – Published: 2026-01-06 09:30 – Updated: 2026-04-08 18:34The Tag, Category, and Taxonomy Manager – AI Autotagger with OpenAI plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the taxopress_ai_add_post_term function in all versions up to, and including, 3.41.0. This makes it possible for authenticated attackers, with Contributor-level access and above, to add or remove taxonomy terms (tags, categories) on any post, including ones they do not own.
{
"affected": [],
"aliases": [
"CVE-2025-14371"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-06T08:15:51Z",
"severity": "MODERATE"
},
"details": "The Tag, Category, and Taxonomy Manager \u2013 AI Autotagger with OpenAI plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the taxopress_ai_add_post_term function in all versions up to, and including, 3.41.0. This makes it possible for authenticated attackers, with Contributor-level access and above, to add or remove taxonomy terms (tags, categories) on any post, including ones they do not own.",
"id": "GHSA-69m7-6xqg-m79v",
"modified": "2026-04-08T18:34:01Z",
"published": "2026-01-06T09:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14371"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/simple-tags/tags/3.40.1/modules/taxopress-ai/classes/TaxoPressAiAjax.php#L681"
},
{
"type": "WEB",
"url": "https://research.cleantalk.org/cve-2025-14371"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/1ef51ffb-df1e-442d-abc8-3a0308099a0b?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-69MH-GVH4-8GP7
Vulnerability from github – Published: 2026-09-03 21:19 – Updated: 2026-09-03 21:19CVE: This vulnerability corresponds to CVE-2026-68587.
Summary
Three "heading transaction" endpoints /api/block/getHeadingDeleteTransaction, /api/block/getHeadingLevelTransaction, and /api/block/getHeadingInsertTransaction return the rendered block DOM of a heading and its subtree in the computed transaction payload, with no publish-access check. They are gated by CheckAuth only, so they are reachable by the publish RoleReader token, and by the anonymous account when Publish.Auth.Enable is false.
Despite their write-implying names, these endpoints perform no mutation on this path, they compute a transaction object and return it, and that object contains RenderNodeBlockDOM output. As a result, an anonymous reader who supplies a heading block ID can read the full rendered content of a document that has been explicitly marked publish-disabled by an administrator, content that the reader-facing /api/filetree/getDoc path correctly refuses to return.
Details
Route / auth tier. All three routes are registered CheckAuth-only (no CheckAdminRole). CheckAuth admits RoleReader, and the publish proxy forwards port-6808 traffic with a Reader JWT (anonymous account when publish auth is disabled). Anonymous/reader reachable.
No publish-access filter. GetHeadingDeleteTransaction / GetHeadingLevelTransaction / GetHeadingInsertTransaction load the heading's block tree and render its DOM into the returned transaction's operation data. None of the three invokes IsReadOnlyRoleContext / the publish-access filter that the reader-safe content path (getDoc) applies. The reader-facing content endpoints (getDoc, and the CheckAdminRole-gated getBlockDOM/getBlockKramdown) treat rendered block DOM as gated content; these three transaction endpoints return the same rendered DOM without that gate.
Write-implying name, read behavior. On this code path the endpoints only compute the transaction (e.g. the undoOperations a delete would produce) and return it; nothing is deleted or modified. The returned operation data includes the rendered HTML of the heading subtree. This mismatch, mutation-shaped name, content-returning behavior is why the gap is easy to miss.
Proof of Concept
Reproduced on a local instance (SiYuan running locally, publish mode enabled on port 6808, publish Basic Auth disabled). DOC is a document containing a heading HEADING whose body contains the unique marker UNIQUE_MARKER_99, and DOC is marked publish-disabled by the administrator.
1. Confirm the document is publish-disabled (admin action, the boundary that should block reads):
POST http://127.0.0.1:6806/api/filetree/setPublishAccess
Authorization: Token <admin-token>
{"id":"DOC","visible":false,"password":"","disable":true}
2. Baseline: the reader-safe content path correctly blocks it (anonymous, port 6808):
POST http://127.0.0.1:6808/api/filetree/getDoc
{"id":"DOC"}
Returns the blocked/placeholder response, the publish filter is applied, no content.
3. Disclosure: the transaction endpoint returns the content (anonymous, port 6808):
POST http://127.0.0.1:6808/api/block/getHeadingDeleteTransaction
{"id":"HEADING"}
Returns HTTP 200; data.undoOperations[].data contains the rendered HTML of the heading subtree, including the hidden body text UNIQUE_MARKER_99. Nothing is deleted — the endpoint only computes the transaction. This is the full content of a publish-disabled document returned to an anonymous reader.
4. Sibling endpoints: same disclosure, same input:
POST http://127.0.0.1:6808/api/block/getHeadingLevelTransaction
{"id":"HEADING","level":2}
POST http://127.0.0.1:6808/api/block/getHeadingInsertTransaction
{"id":"HEADING"}
Both return the rendered DOM of the heading subtree in their operation data.
Impact
An anonymous reader (publish mode with auth disabled) or any publish RoleReader who supplies a heading block ID can read the full rendered content of a publish-disabled document, defeating a boundary the administrator explicitly configured.
Precondition: the request requires the target heading's block ID. Block IDs are high-entropy and are not returned by this endpoint, so this endpoint alone does not permit untargeted enumeration of arbitrary documents. However, block/heading IDs for publish-disabled documents are obtainable from other CheckAuth-only endpoints that lack the publish-access filter (the publish-boundary handler set reported separately, e.g. getHeadingChildrenIDs). Chained with such an ID source, this yields end-to-end unauthenticated full-content disclosure of publish-disabled documents. Presented standalone, the attacker must already possess the heading ID.
Impact is confidentiality-only: these endpoints return content but do not (on this path) modify data. No admin role, CSRF token, or write permission is required. Encrypted notebooks are out of scope.
Suggested fix
Apply the same publish-access check the content path uses IsReadOnlyRoleContext / the publish-access filter used by getDoc to all three getHeading*Transaction handlers, or gate them behind CheckAdminRole consistent with getBlockDOM/getBlockKramdown. Any endpoint that returns rendered block DOM should enforce the same publish boundary as the primary content path.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260721013353-69db783b782a"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-68587"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-03T21:19:41Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "**CVE:** This vulnerability corresponds to [CVE-2026-68587](https://nvd.nist.gov/vuln/detail/CVE-2026-68587).\n\n### Summary\n\nThree \"heading transaction\" endpoints `/api/block/getHeadingDeleteTransaction`, `/api/block/getHeadingLevelTransaction`, and `/api/block/getHeadingInsertTransaction` return the rendered block DOM of a heading and its subtree in the computed transaction payload, with no publish-access check. They are gated by `CheckAuth` only, so they are reachable by the publish `RoleReader` token, and by the anonymous account when `Publish.Auth.Enable` is `false`.\n\nDespite their write-implying names, these endpoints perform no mutation on this path, they compute a transaction object and return it, and that object contains `RenderNodeBlockDOM` output. As a result, an anonymous reader who supplies a heading block ID can read the full rendered content of a document that has been explicitly marked publish-disabled by an administrator, content that the reader-facing `/api/filetree/getDoc` path correctly refuses to return.\n\n### Details\n\n**Route / auth tier.** All three routes are registered `CheckAuth`-only (no `CheckAdminRole`). `CheckAuth` admits `RoleReader`, and the publish proxy forwards port-6808 traffic with a Reader JWT (anonymous account when publish auth is disabled). Anonymous/reader reachable.\n\n**No publish-access filter.** `GetHeadingDeleteTransaction` / `GetHeadingLevelTransaction` / `GetHeadingInsertTransaction` load the heading\u0027s block tree and render its DOM into the returned transaction\u0027s operation data. None of the three invokes `IsReadOnlyRoleContext` / the publish-access filter that the reader-safe content path (`getDoc`) applies. The reader-facing content endpoints (`getDoc`, and the `CheckAdminRole`-gated `getBlockDOM`/`getBlockKramdown`) treat rendered block DOM as gated content; these three transaction endpoints return the same rendered DOM without that gate.\n\n**Write-implying name, read behavior.** On this code path the endpoints only *compute* the transaction (e.g. the `undoOperations` a delete would produce) and return it; nothing is deleted or modified. The returned operation data includes the rendered HTML of the heading subtree. This mismatch, mutation-shaped name, content-returning behavior is why the gap is easy to miss.\n\n### Proof of Concept\n\nReproduced on a local instance (SiYuan running locally, publish mode enabled on port 6808, publish Basic Auth disabled). `DOC` is a document containing a heading `HEADING` whose body contains the unique marker `UNIQUE_MARKER_99`, and `DOC` is marked publish-disabled by the administrator.\n\n**1. Confirm the document is publish-disabled (admin action, the boundary that should block reads):**\n```\nPOST http://127.0.0.1:6806/api/filetree/setPublishAccess\nAuthorization: Token \u003cadmin-token\u003e\n{\"id\":\"DOC\",\"visible\":false,\"password\":\"\",\"disable\":true}\n```\n\n**2. Baseline: the reader-safe content path correctly blocks it (anonymous, port 6808):**\n```\nPOST http://127.0.0.1:6808/api/filetree/getDoc\n{\"id\":\"DOC\"}\n```\nReturns the blocked/placeholder response, the publish filter is applied, no content.\n\n**3. Disclosure: the transaction endpoint returns the content (anonymous, port 6808):**\n```\nPOST http://127.0.0.1:6808/api/block/getHeadingDeleteTransaction\n{\"id\":\"HEADING\"}\n```\nReturns HTTP 200; `data.undoOperations[].data` contains the rendered HTML of the heading subtree, including the hidden body text `UNIQUE_MARKER_99`. Nothing is deleted \u2014 the endpoint only computes the transaction. This is the full content of a publish-disabled document returned to an anonymous reader.\n\n**4. Sibling endpoints: same disclosure, same input:**\n```\nPOST http://127.0.0.1:6808/api/block/getHeadingLevelTransaction\n{\"id\":\"HEADING\",\"level\":2}\n\nPOST http://127.0.0.1:6808/api/block/getHeadingInsertTransaction\n{\"id\":\"HEADING\"}\n```\nBoth return the rendered DOM of the heading subtree in their operation data.\n\n### Impact\n\nAn anonymous reader (publish mode with auth disabled) or any publish `RoleReader` who supplies a heading block ID can read the full rendered content of a publish-disabled document, defeating a boundary the administrator explicitly configured.\n\n**Precondition:** the request requires the target heading\u0027s block ID. Block IDs are high-entropy and are not returned by this endpoint, so this endpoint alone does not permit untargeted enumeration of arbitrary documents. However, block/heading IDs for publish-disabled documents are obtainable from other `CheckAuth`-only endpoints that lack the publish-access filter (the publish-boundary handler set reported separately, e.g. `getHeadingChildrenIDs`). Chained with such an ID source, this yields end-to-end unauthenticated full-content disclosure of publish-disabled documents. Presented standalone, the attacker must already possess the heading ID.\n\nImpact is confidentiality-only: these endpoints return content but do not (on this path) modify data. No admin role, CSRF token, or write permission is required. Encrypted notebooks are out of scope.\n\n### Suggested fix\n\nApply the same publish-access check the content path uses `IsReadOnlyRoleContext` / the publish-access filter used by `getDoc` to all three `getHeading*Transaction` handlers, or gate them behind `CheckAdminRole` consistent with `getBlockDOM`/`getBlockKramdown`. Any endpoint that returns rendered block DOM should enforce the same publish boundary as the primary content path.",
"id": "GHSA-69mh-gvh4-8gp7",
"modified": "2026-09-03T21:19:42Z",
"published": "2026-09-03T21:19:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-69mh-gvh4-8gp7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68587"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/commit/69db783b782aea865ea70a1c5ab656e5c0f3dadb"
},
{
"type": "PACKAGE",
"url": "https://github.com/siyuan-note/siyuan"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/siyuan-before-information-disclosure-via-getheading-transaction"
}
],
"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: Full-content disclosure of publish-disabled documents via getHeading*Transaction endpoints (publish mode): reader-reachable rendered DOM with no publish-access check"
}
GHSA-69MJ-PC6R-5CGV
Vulnerability from github – Published: 2026-01-07 12:31 – Updated: 2026-01-07 12:31The User Activity Log plugin is vulnerable to a limited options update in versions up to, and including, 2.2. The failed-login handler 'ual_shook_wp_login_failed' lacks a capability check and writes failed usernames directly into update_option() calls. This makes it possible for unauthenticated attackers to push select site options from 0 to a non-zero value, allowing them to reopen registration or corrupt options like 'wp_user_roles', breaking wp-admin access.
{
"affected": [],
"aliases": [
"CVE-2025-11877"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-07T12:16:46Z",
"severity": "HIGH"
},
"details": "The User Activity Log plugin is vulnerable to a limited options update in versions up to, and including, 2.2. The failed-login handler \u0027ual_shook_wp_login_failed\u0027 lacks a capability check and writes failed usernames directly into update_option() calls. This makes it possible for unauthenticated attackers to push select site options from 0 to a non-zero value, allowing them to reopen registration or corrupt options like \u0027wp_user_roles\u0027, breaking wp-admin access.",
"id": "GHSA-69mj-pc6r-5cgv",
"modified": "2026-01-07T12:31:19Z",
"published": "2026-01-07T12:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11877"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/user-activity-log/trunk/user-functions.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/24225f47-cec2-4270-88f0-8696ebfb7168?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:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-69P7-3985-WF2C
Vulnerability from github – Published: 2024-11-01 15:31 – Updated: 2024-11-01 15:31Missing Authorization vulnerability in Envira Gallery Team Envira Photo Gallery allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Envira Photo Gallery: from n/a through 1.8.7.3.
{
"affected": [],
"aliases": [
"CVE-2024-37095"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-01T15:15:18Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Envira Gallery Team Envira Photo Gallery allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Envira Photo Gallery: from n/a through 1.8.7.3.",
"id": "GHSA-69p7-3985-wf2c",
"modified": "2024-11-01T15:31:56Z",
"published": "2024-11-01T15:31:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37095"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/envira-gallery-lite/wordpress-envira-photo-gallery-plugin-1-8-7-3-csrf-leading-to-notice-dismissal-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-69Q5-H2W4-49J7
Vulnerability from github – Published: 2026-07-02 12:31 – Updated: 2026-07-02 12:31Subscriber Broken Access Control in Werkstatt <= 4.7.2 versions.
{
"affected": [],
"aliases": [
"CVE-2026-57689"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-02T12:17:39Z",
"severity": "MODERATE"
},
"details": "Subscriber Broken Access Control in Werkstatt \u003c= 4.7.2 versions.",
"id": "GHSA-69q5-h2w4-49j7",
"modified": "2026-07-02T12:31:02Z",
"published": "2026-07-02T12:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57689"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/theme/werkstatt/vulnerability/wordpress-werkstatt-theme-4-7-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-69Q5-RX53-RW8H
Vulnerability from github – Published: 2022-05-10 00:00 – Updated: 2022-05-18 00:00IBM Navigator for i 7.2, 7.3, and 7.4 (heritage version) could allow a remote attacker to obtain access to the web interface without valid credentials. By modifying the sign on request, an attacker can gain visibility to the fully qualified domain name of the target system and the navigator tasks page, however they do not gain the ability to perform those tasks on the system or see any specific system data. IBM X-Force ID: 225899.
{
"affected": [],
"aliases": [
"CVE-2022-22481"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-09T17:15:00Z",
"severity": "MODERATE"
},
"details": "IBM Navigator for i 7.2, 7.3, and 7.4 (heritage version) could allow a remote attacker to obtain access to the web interface without valid credentials. By modifying the sign on request, an attacker can gain visibility to the fully qualified domain name of the target system and the navigator tasks page, however they do not gain the ability to perform those tasks on the system or see any specific system data. IBM X-Force ID: 225899.",
"id": "GHSA-69q5-rx53-rw8h",
"modified": "2022-05-18T00:00:37Z",
"published": "2022-05-10T00:00:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22481"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/225899"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/6583553"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-69Q6-GH68-57P3
Vulnerability from github – Published: 2022-05-24 17:21 – Updated: 2022-05-24 17:21Global RADAR BSA Radar 1.6.7234.24750 and earlier lacks valid authorization controls in multiple functions. This can allow for manipulation and takeover of user accounts if successfully exploited. The following vulnerable functions are exposed: ChangePassword, SaveUserProfile, and GetUser.
{
"affected": [],
"aliases": [
"CVE-2020-14944"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-06-22T22:15:00Z",
"severity": "HIGH"
},
"details": "Global RADAR BSA Radar 1.6.7234.24750 and earlier lacks valid authorization controls in multiple functions. This can allow for manipulation and takeover of user accounts if successfully exploited. The following vulnerable functions are exposed: ChangePassword, SaveUserProfile, and GetUser.",
"id": "GHSA-69q6-gh68-57p3",
"modified": "2022-05-24T17:21:29Z",
"published": "2022-05-24T17:21:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14944"
},
{
"type": "WEB",
"url": "https://github.com/wsummerhill/BSA-Radar_CVE-Vulnerabilities"
},
{
"type": "WEB",
"url": "https://github.com/wsummerhill/BSA-Radar_CVE-Vulnerabilities/blob/master/CVE-2020-14944%20-%20Access%20Control%20Vulnerabilities.md"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/158372/BSA-Radar-1.6.7234.24750-Cross-Site-Request-Forgery.html"
}
],
"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
- 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.