CWE-1259
AllowedImproper Restriction of Security Token Assignment
Abstraction: Base · Status: Incomplete
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.
20 vulnerabilities reference this CWE, most recent first.
GHSA-5HCJ-RWM6-XMW4
Vulnerability from github – Published: 2024-07-31 18:48 – Updated: 2024-11-18 16:26Impact
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?
{
"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:31A 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.
{
"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:31In 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.
{
"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-F2RQ-QHQV-93PG
Vulnerability from github – Published: 2025-06-02 18:30 – Updated: 2025-06-04 18:30Clinical 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.
{
"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-FV25-93G9-XJJV
Vulnerability from github – Published: 2024-09-04 03:30 – Updated: 2024-11-05 12:31Page table protection configuration vulnerability in the trusted firmware module Impact: Successful exploitation of this vulnerability may affect service confidentiality.
{
"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:30A 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.
{
"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"
}
]
}
GHSA-HJRF-2M68-5959
Vulnerability from github – Published: 2022-12-22 03:33 – Updated: 2024-06-24 21:24Overview
Versions <=8.5.1 of jsonwebtoken library can be misconfigured so that passing a poorly implemented key retrieval function (referring to the secretOrPublicKey argument from the readme link) will result in incorrect verification of tokens. There is a possibility of using a different algorithm and key combination in verification than the one that was used to sign the tokens. Specifically, tokens signed with an asymmetric public key could be verified with a symmetric HS256 algorithm. This can lead to successful validation of forged tokens.
Am I affected?
You will be affected if your application is supporting usage of both symmetric key and asymmetric key in jwt.verify() implementation with the same key retrieval function.
How do I fix it?
Update to version 9.0.0.
Will the fix impact my users?
There is no impact for end users
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.5.1"
},
"package": {
"ecosystem": "npm",
"name": "jsonwebtoken"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-23541"
],
"database_specific": {
"cwe_ids": [
"CWE-1259",
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-22T03:33:19Z",
"nvd_published_at": "2022-12-22T18:15:00Z",
"severity": "MODERATE"
},
"details": "# Overview\n\nVersions `\u003c=8.5.1` of `jsonwebtoken` library can be misconfigured so that passing a poorly implemented key retrieval function (referring to the `secretOrPublicKey` argument from the [readme link](https://github.com/auth0/node-jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback)) will result in incorrect verification of tokens. There is a possibility of using a different algorithm and key combination in verification than the one that was used to sign the tokens. Specifically, tokens signed with an asymmetric public key could be verified with a symmetric HS256 algorithm. This can lead to successful validation of forged tokens. \n\n# Am I affected?\n\nYou will be affected if your application is supporting usage of both symmetric key and asymmetric key in jwt.verify() implementation with the same key retrieval function. \n\n# How do I fix it?\n \nUpdate to version 9.0.0.\n\n# Will the fix impact my users?\n\nThere is no impact for end users",
"id": "GHSA-hjrf-2m68-5959",
"modified": "2024-06-24T21:24:06Z",
"published": "2022-12-22T03:33:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/auth0/node-jsonwebtoken/security/advisories/GHSA-hjrf-2m68-5959"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23541"
},
{
"type": "WEB",
"url": "https://github.com/auth0/node-jsonwebtoken/commit/e1fa9dcc12054a8681db4e6373da1b30cf7016e3"
},
{
"type": "PACKAGE",
"url": "https://github.com/auth0/node-jsonwebtoken"
},
{
"type": "WEB",
"url": "https://github.com/auth0/node-jsonwebtoken/releases/tag/v9.0.0"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240621-0007"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "jsonwebtoken\u0027s insecure implementation of key retrieval function could lead to Forgeable Public/Private Tokens from RSA to HMAC"
}
GHSA-P49J-V9WC-WG57
Vulnerability from github – Published: 2026-04-21 18:27 – Updated: 2026-04-21 18:27Impact
OpenBao's namespaces provide multi-tenant separation. A tenant who leaks token accessors can have their token revoked or renewed by a privileged administrator in another tenant.
Patches
This was addressed in v2.5.3.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/openbao/openbao"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260420162526-f58111d2ca54"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40264"
],
"database_specific": {
"cwe_ids": [
"CWE-1259"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-21T18:27:42Z",
"nvd_published_at": "2026-04-21T01:16:06Z",
"severity": "LOW"
},
"details": "### Impact\n\nOpenBao\u0027s namespaces provide multi-tenant separation. A tenant who leaks token accessors can have their token revoked or renewed by a privileged administrator in another tenant.\n\n### Patches\n\nThis was addressed in v2.5.3.",
"id": "GHSA-p49j-v9wc-wg57",
"modified": "2026-04-21T18:27:42Z",
"published": "2026-04-21T18:27:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openbao/openbao/security/advisories/GHSA-p49j-v9wc-wg57"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40264"
},
{
"type": "WEB",
"url": "https://github.com/openbao/openbao/pull/2934"
},
{
"type": "WEB",
"url": "https://github.com/openbao/openbao/commit/059cc5950303688335d5c8ab9af8e453795d693a"
},
{
"type": "PACKAGE",
"url": "https://github.com/openbao/openbao"
},
{
"type": "WEB",
"url": "https://github.com/openbao/openbao/releases/tag/v2.5.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenBao\u0027s Token Store Allows Cross-Namespace Renewal, Revocation"
}
GHSA-R9R6-V98F-CVCC
Vulnerability from github – Published: 2025-09-23 12:31 – Updated: 2025-09-23 12:31An information disclosure vulnerability exists in multiple WSO2 products due to improper implementation of the enrich mediator. Authenticated users may be able to view unintended business data from other mediation contexts because the internal state is not properly isolated or cleared between executions.
This vulnerability does not impact user credentials or access tokens but may lead to leakage of sensitive business information handled during message flows.
{
"affected": [],
"aliases": [
"CVE-2024-4598"
],
"database_specific": {
"cwe_ids": [
"CWE-1259"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-23T11:15:39Z",
"severity": "MODERATE"
},
"details": "An information disclosure vulnerability exists in multiple WSO2 products due to improper implementation of the enrich mediator. Authenticated users may be able to view unintended business data from other mediation contexts because the internal state is not properly isolated or cleared between executions.\n\nThis vulnerability does not impact user credentials or access tokens but may lead to leakage of sensitive business information handled during message flows.",
"id": "GHSA-r9r6-v98f-cvcc",
"modified": "2025-09-23T12:31:11Z",
"published": "2025-09-23T12:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4598"
},
{
"type": "WEB",
"url": "https://security.docs.wso2.com/en/latest/security-announcements/security-advisories/2025/WSO2-2024-3355"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VGH5-4JJP-4PMH
Vulnerability from github – Published: 2025-09-30 18:30 – Updated: 2025-10-01 21:31TitanSystems Zender v3.9.7 contains an account takeover vulnerability in its password reset functionality. A temporary password or reset token issued to one user can be used to log in as another user, due to improper validation of token-user linkage. This allows remote attackers to gain unauthorized access to any user account by exploiting the password reset mechanism. The vulnerability occurs because the reset token is not correctly bound to the requesting account and is accepted for other user emails during login, enabling privilege escalation and information disclosure.
{
"affected": [],
"aliases": [
"CVE-2025-56676"
],
"database_specific": {
"cwe_ids": [
"CWE-1259"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-30T16:15:53Z",
"severity": "MODERATE"
},
"details": "TitanSystems Zender v3.9.7 contains an account takeover vulnerability in its password reset functionality. A temporary password or reset token issued to one user can be used to log in as another user, due to improper validation of token-user linkage. This allows remote attackers to gain unauthorized access to any user account by exploiting the password reset mechanism. The vulnerability occurs because the reset token is not correctly bound to the requesting account and is accepted for other user emails during login, enabling privilege escalation and information disclosure.",
"id": "GHSA-vgh5-4jjp-4pmh",
"modified": "2025-10-01T21:31:20Z",
"published": "2025-09-30T18:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-56676"
},
{
"type": "WEB",
"url": "https://codecanyon.net/item/zender-android-mobile-devices-as-sms-gateway-saas-platform/26594230"
},
{
"type": "WEB",
"url": "https://darklotus.medium.com/cve-2025-56676-critical-vulnerability-in-zender-gateway-allows-account-takeover-2b5bcb50c762"
},
{
"type": "WEB",
"url": "https://previews.titansystems.ph/zender/dashboard/auth"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L",
"type": "CVSS_V3"
}
]
}
Mitigation
- 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.