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.
14994 vulnerabilities reference this CWE, most recent first.
GHSA-4PH2-8337-HM62
Vulnerability from github – Published: 2021-02-08 17:43 – Updated: 2021-02-05 21:22Impact
This advisory concerns users of MostRecentProvider in the DynamoDB Encryption Client with a key provider like AWS Key Management Service that allows for permissions on keys to be modified.
When key usage permissions were changed at the key provider, time-based key reauthorization logic in MostRecentProvider did not reauthorize the use of the key. This created the potential for keys to be used in the DynamoDB Encryption Client after permissions to do so were revoked at the key provider.
Patches
Fixed as of 1.3.0. We recommend users to modify their code and adopt CachingMostRecentProvider.
Workarounds
Users who cannot upgrade to use the CachingMostRecentProvider can call clear() on the cache to manually flush all of its contents. Next use of the key will force a re-validation to occur with the key provider.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "dynamodb-encryption-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2021-02-05T21:22:28Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\nThis advisory concerns users of MostRecentProvider in the DynamoDB Encryption Client with a key provider like AWS Key Management Service that allows for permissions on keys to be modified.\n\nWhen key usage permissions were changed at the key provider, time-based key reauthorization logic in MostRecentProvider did not reauthorize the use of the key. This created the potential for keys to be used in the DynamoDB Encryption Client after permissions to do so were revoked at the key provider.\n\n### Patches\nFixed as of 1.3.0. We recommend users to modify their code and adopt `CachingMostRecentProvider`.\n\n\n### Workarounds\nUsers who cannot upgrade to use the `CachingMostRecentProvider` can call `clear()` on the cache to manually flush all of its contents. Next use of the key will force a re-validation to occur with the key provider.",
"id": "GHSA-4ph2-8337-hm62",
"modified": "2021-02-05T21:22:28Z",
"published": "2021-02-08T17:43:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aws/aws-dynamodb-encryption-python/security/advisories/GHSA-4ph2-8337-hm62"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-dynamodb-encryption-python/commit/90606ec9af7c2b5cb338d64639a62ee867d38d6b"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-dynamodb-encryption-python/blob/master/CHANGELOG.rst#130----2021-02-04"
},
{
"type": "WEB",
"url": "https://pypi.org/project/dynamodb-encryption-sdk"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Key Caching behavior in the DynamoDB Encryption Client."
}
GHSA-4PJ2-VQ9J-XJ3G
Vulnerability from github – Published: 2026-07-31 18:32 – Updated: 2026-07-31 18:32The per-tool permission system (custom roles / role-based tool permissions, introduced in pgAdmin 4 9.3) did not enforce its permission check consistently. In SERVER mode, pgAdmin 4 gates each tool behind a per-tool Flask-Security permission, but the permission decorator (permissions_required) was applied only to a single "front door" route per tool. Every other backend route and Socket.IO handler in that tool's workflow relied solely on pga_login_required/socket_login_required, which check authentication but not the tool permission.
The reporter verified three cases against a test build: (1) a user without tools_query_tool permission received 403 on the protected sqleditor initialization route, but the same session went on to connect the server, initialize the viewdata backend chain, and retrieve real table row content; (2) a user without tools_grant_wizard received 403 on the protected acl route, but the same session still enumerated grantable objects, generated GRANT SQL, and successfully applied it -- confirmed database-side via has_table_privilege(); (3) a user without tools_schema_diff received 403 on the protected panel route, but the same session initialized schema diff, enumerated and connected databases, and obtained real DDL differences via the compare_database Socket.IO handler. The reporter also confirmed a related but distinct issue: a non-owner triggering /misc/workspace/adhoc_connect_server against an administrator-owned shared server caused pgAdmin to persist a new server row still owned by the administrator (user_id/shared unchanged from the source), even though the connection attempt itself reported failure.
During remediation, the same front-door-only permission gap was found to also affect the ERD, PSQL, and Debugger tools, and the Backup, Restore, Maintenance, and Import/Export blueprints, none of which were part of the original report; these were fixed using the same pattern as an extension of the reported defect class.
An authenticated user who had valid pgAdmin login and a stored, working database connection, but had been explicitly denied a specific tool's permission by an administrator, could therefore still drive that tool end-to-end through its other routes and sockets, including obtaining an interactive psql session over the /pty Socket.IO namespace and invoking backup/restore/maintenance/import-export jobs.
Because the bypass only restores access to tools operating over the user's own already-authenticated database connection, it does not grant the user any database privilege they did not already hold; it circumvents pgAdmin's own tool-level access-control policy (an organisational segregation-of-duties control, separate from database-level authorization), letting a user reach a pgAdmin feature an administrator intended to withhold from them, using capabilities their existing database role already permits through other means.
Socket.IO event handlers had no permission-aware equivalent of permissions_required; only socket_login_required existed, checking authentication but not the tool permission.
Fix adds a socket_permissions_required decorator (mirroring permissions_required, honouring the Administrator bypass, reading permissions via has_permission()) and applies it, alongside permissions_required, as the outermost decorator on every backend route and Socket.IO handler for the affected tools. Regression tests assert 403 on every gated route and socket handler for a permission-less user.
This issue affects pgAdmin 4 in SERVER mode: from 9.3 before 9.17.
{
"affected": [],
"aliases": [
"CVE-2026-17350"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-31T16:16:59Z",
"severity": "MODERATE"
},
"details": "The per-tool permission system (custom roles / role-based tool permissions, introduced in pgAdmin 4 9.3) did not enforce its permission check consistently. In SERVER mode, pgAdmin 4 gates each tool behind a per-tool Flask-Security permission, but the permission decorator (permissions_required) was applied only to a single \"front door\" route per tool. Every other backend route and Socket.IO handler in that tool\u0027s workflow relied solely on pga_login_required/socket_login_required, which check authentication but not the tool permission.\n\nThe reporter verified three cases against a test build: (1) a user without tools_query_tool permission received 403 on the protected sqleditor initialization route, but the same session went on to connect the server, initialize the viewdata backend chain, and retrieve real table row content; (2) a user without tools_grant_wizard received 403 on the protected acl route, but the same session still enumerated grantable objects, generated GRANT SQL, and successfully applied it -- confirmed database-side via has_table_privilege(); (3) a user without tools_schema_diff received 403 on the protected panel route, but the same session initialized schema diff, enumerated and connected databases, and obtained real DDL differences via the compare_database Socket.IO handler. The reporter also confirmed a related but distinct issue: a non-owner triggering /misc/workspace/adhoc_connect_server against an administrator-owned shared server caused pgAdmin to persist a new server row still owned by the administrator (user_id/shared unchanged from the source), even though the connection attempt itself reported failure.\n\nDuring remediation, the same front-door-only permission gap was found to also affect the ERD, PSQL, and Debugger tools, and the Backup, Restore, Maintenance, and Import/Export blueprints, none of which were part of the original report; these were fixed using the same pattern as an extension of the reported defect class.\n\nAn authenticated user who had valid pgAdmin login and a stored, working database connection, but had been explicitly denied a specific tool\u0027s permission by an administrator, could therefore still drive that tool end-to-end through its other routes and sockets, including obtaining an interactive psql session over the /pty Socket.IO namespace and invoking backup/restore/maintenance/import-export jobs.\n\nBecause the bypass only restores access to tools operating over the user\u0027s own already-authenticated database connection, it does not grant the user any database privilege they did not already hold; it circumvents pgAdmin\u0027s own tool-level access-control policy (an organisational segregation-of-duties control, separate from database-level authorization), letting a user reach a pgAdmin feature an administrator intended to withhold from them, using capabilities their existing database role already permits through other means.\n\nSocket.IO event handlers had no permission-aware equivalent of permissions_required; only socket_login_required existed, checking authentication but not the tool permission.\n\nFix adds a socket_permissions_required decorator (mirroring permissions_required, honouring the Administrator bypass, reading permissions via has_permission()) and applies it, alongside permissions_required, as the outermost decorator on every backend route and Socket.IO handler for the affected tools. Regression tests assert 403 on every gated route and socket handler for a permission-less user.\n\nThis issue affects pgAdmin 4 in SERVER mode: from 9.3 before 9.17.",
"id": "GHSA-4pj2-vq9j-xj3g",
"modified": "2026-07-31T18:32:17Z",
"published": "2026-07-31T18:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-17350"
},
{
"type": "WEB",
"url": "https://github.com/pgadmin-org/pgadmin4/issues/10190"
},
{
"type": "WEB",
"url": "https://github.com/pgadmin-org/pgadmin4/commit/461c3afba92baad37c70a6fbd52d205d13a9de53"
},
{
"type": "WEB",
"url": "https://github.com/pgadmin-org/pgadmin4/commit/64a9cdbd6a240a962144f84418beaf9e66419779"
},
{
"type": "WEB",
"url": "https://github.com/pgadmin-org/pgadmin4/commit/ba1984718ad703011740ad48cb9b82402b89cc2c"
},
{
"type": "WEB",
"url": "https://github.com/pgadmin-org/pgadmin4/commit/d36bd8dc96812c716664feac533d240544e70adc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/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-4PMJ-QPM8-X7GV
Vulnerability from github – Published: 2025-01-31 00:30 – Updated: 2025-01-31 18:31This vulnerability allows remote attackers to disclose sensitive information on affected installations of Alpine Halo9 devices. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the DLT interface, which listens on TCP port 3490 by default. The issue results from the lack of authentication prior to allowing access to functionality. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the device.
{
"affected": [],
"aliases": [
"CVE-2024-23962"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-31T00:15:09Z",
"severity": "HIGH"
},
"details": "This vulnerability allows remote attackers to disclose sensitive information on affected installations of Alpine Halo9 devices. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the DLT interface, which listens on TCP port 3490 by default. The issue results from the lack of authentication prior to allowing access to functionality. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the device.",
"id": "GHSA-4pmj-qpm8-x7gv",
"modified": "2025-01-31T18:31:05Z",
"published": "2025-01-31T00:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23962"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-24-847"
}
],
"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-4PMR-4Q2R-C836
Vulnerability from github – Published: 2024-12-09 15:31 – Updated: 2026-04-28 21:35Missing Authorization vulnerability in mg12 WP-RecentComments allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP-RecentComments: from n/a through 2.2.7.
{
"affected": [],
"aliases": [
"CVE-2023-23886"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-09T13:15:21Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in mg12 WP-RecentComments allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP-RecentComments: from n/a through 2.2.7.",
"id": "GHSA-4pmr-4q2r-c836",
"modified": "2026-04-28T21:35:16Z",
"published": "2024-12-09T15:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23886"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wp-recentcomments/vulnerability/wordpress-wp-recentcomments-plugin-2-2-7-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:L",
"type": "CVSS_V3"
}
]
}
GHSA-4PP4-WVVQ-CGJ8
Vulnerability from github – Published: 2023-07-12 09:30 – Updated: 2024-04-04 06:03In fastDial service, there is a missing permission check. This could lead to local information disclosure with no additional execution privileges needed.
{
"affected": [],
"aliases": [
"CVE-2023-33894"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-12T09:15:13Z",
"severity": "MODERATE"
},
"details": "In fastDial service, there is a missing permission check. This could lead to local information disclosure with no additional execution privileges needed.",
"id": "GHSA-4pp4-wvvq-cgj8",
"modified": "2024-04-04T06:03:28Z",
"published": "2023-07-12T09:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33894"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1676902764208259073"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4PP6-FG3P-GPGV
Vulnerability from github – Published: 2025-07-04 12:30 – Updated: 2026-04-28 21:35Missing Authorization vulnerability in Paytiko - Payment Orchestration Platform Paytiko for WooCommerce allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Paytiko for WooCommerce: from n/a through 1.3.14.
{
"affected": [],
"aliases": [
"CVE-2025-50032"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-04T12:15:32Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Paytiko - Payment Orchestration Platform Paytiko for WooCommerce allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Paytiko for WooCommerce: from n/a through 1.3.14.",
"id": "GHSA-4pp6-fg3p-gpgv",
"modified": "2026-04-28T21:35:43Z",
"published": "2025-07-04T12:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50032"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/paytiko/vulnerability/wordpress-paytiko-for-woocommerce-1-3-13-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:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4PQH-76JG-2W88
Vulnerability from github – Published: 2022-07-07 00:00 – Updated: 2022-07-14 00:00In Autoboot, there is a possible permission bypass due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS06713894; Issue ID: ALPS06713894.
{
"affected": [],
"aliases": [
"CVE-2022-21777"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-06T14:15:00Z",
"severity": "HIGH"
},
"details": "In Autoboot, there is a possible permission bypass due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS06713894; Issue ID: ALPS06713894.",
"id": "GHSA-4pqh-76jg-2w88",
"modified": "2022-07-14T00:00:19Z",
"published": "2022-07-07T00:00:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21777"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/July-2022"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4PX4-8GJQ-R2Q2
Vulnerability from github – Published: 2024-08-13 12:30 – Updated: 2024-08-13 12:30Missing Authorization vulnerability in anhvnit Woocommerce OpenPos allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Woocommerce OpenPos: from n/a through 6.4.4.
{
"affected": [],
"aliases": [
"CVE-2024-37935"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-13T10:15:04Z",
"severity": "HIGH"
},
"details": "Missing Authorization vulnerability in anhvnit Woocommerce OpenPos allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Woocommerce OpenPos: from n/a through 6.4.4.",
"id": "GHSA-4px4-8gjq-r2q2",
"modified": "2024-08-13T12:30:51Z",
"published": "2024-08-13T12:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37935"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/woocommerce-openpos/wordpress-woocommerce-openpos-plugin-6-4-4-unauthenticated-sensitive-data-exposure-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-4PX8-8H5W-7VJP
Vulnerability from github – Published: 2025-03-27 12:30 – Updated: 2026-04-01 18:34Missing Authorization vulnerability in weDevs WP ERP allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects WP ERP: from n/a through 1.13.4.
{
"affected": [],
"aliases": [
"CVE-2025-30896"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T11:15:50Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in weDevs WP ERP allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects WP ERP: from n/a through 1.13.4.",
"id": "GHSA-4px8-8h5w-7vjp",
"modified": "2026-04-01T18:34:08Z",
"published": "2025-03-27T12:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30896"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/erp/vulnerability/wordpress-wp-erp-plugin-1-13-4-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:L",
"type": "CVSS_V3"
}
]
}
GHSA-4Q36-23HM-63MG
Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-05-26 13:30Missing Authorization vulnerability in Webful Creations RepairBuddy allows Exploiting Incorrectly Configured Access Control Security Levels.
This issue affects RepairBuddy: from n/a through 4.1121.
{
"affected": [],
"aliases": [
"CVE-2026-24638"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-26T09:16:19Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Webful Creations RepairBuddy allows Exploiting Incorrectly Configured Access Control Security Levels.\n\nThis issue affects RepairBuddy: from n/a through 4.1121.",
"id": "GHSA-4q36-23hm-63mg",
"modified": "2026-05-26T13:30:55Z",
"published": "2026-05-26T13:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24638"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/computer-repair-shop/vulnerability/wordpress-repairbuddy-plugin-4-1121-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"
}
]
}
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.