CWE-668
DiscouragedExposure of Resource to Wrong Sphere
Abstraction: Class · Status: Draft
The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.
1251 vulnerabilities reference this CWE, most recent first.
GHSA-F7M8-MJCP-G22J
Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-07-13 00:01Viewing restrictions bypass vulnerability in Address of Cybozu Garoon 4.0.0 to 5.0.2 allows a remote authenticated attacker to obtain the data of Address without the viewing privilege.
{
"affected": [],
"aliases": [
"CVE-2021-20756"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-18T06:15:00Z",
"severity": "MODERATE"
},
"details": "Viewing restrictions bypass vulnerability in Address of Cybozu Garoon 4.0.0 to 5.0.2 allows a remote authenticated attacker to obtain the data of Address without the viewing privilege.",
"id": "GHSA-f7m8-mjcp-g22j",
"modified": "2022-07-13T00:01:06Z",
"published": "2022-05-24T19:11:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20756"
},
{
"type": "WEB",
"url": "https://cs.cybozu.co.jp/2021/007206.html"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN54794245/index.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F7RC-58QH-7PQ6
Vulnerability from github – Published: 2022-07-27 00:00 – Updated: 2022-07-29 00:00Inappropriate implementation in Web Contents in Google Chrome prior to 101.0.4951.64 allowed a remote attacker to leak cross-origin data via a crafted HTML page.
{
"affected": [],
"aliases": [
"CVE-2022-1637"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-26T22:15:00Z",
"severity": "MODERATE"
},
"details": "Inappropriate implementation in Web Contents in Google Chrome prior to 101.0.4951.64 allowed a remote attacker to leak cross-origin data via a crafted HTML page.",
"id": "GHSA-f7rc-58qh-7pq6",
"modified": "2022-07-29T00:00:31Z",
"published": "2022-07-27T00:00:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1637"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2022/05/stable-channel-update-for-desktop_10.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1311820"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202208-25"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-F7XM-4PW3-GMVW
Vulnerability from github – Published: 2022-04-21 01:46 – Updated: 2024-02-28 00:52Mutt before 1.5.20 patch 7 allows an attacker to cause a denial of service via a series of requests to mutt temporary files.
{
"affected": [],
"aliases": [
"CVE-2005-2351"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-01T19:15:00Z",
"severity": "MODERATE"
},
"details": "Mutt before 1.5.20 patch 7 allows an attacker to cause a denial of service via a series of requests to mutt temporary files.",
"id": "GHSA-f7xm-4pw3-gmvw",
"modified": "2024-02-28T00:52:08Z",
"published": "2022-04-21T01:46:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2005-2351"
},
{
"type": "WEB",
"url": "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311296"
},
{
"type": "WEB",
"url": "https://security-tracker.debian.org/tracker/CVE-2005-2351"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F848-R5G6-6GPF
Vulnerability from github – Published: 2022-05-24 17:18 – Updated: 2024-04-24 20:35The DMS/ECM module in Dolibarr 11.0.4 allows users with the 'Setup documents directories' permission to rename uploaded files to have insecure file extensions. This bypasses the .noexe protection mechanism against XSS.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "dolibarr/dolibarr"
},
"versions": [
"11.0.4"
]
}
],
"aliases": [
"CVE-2020-13240"
],
"database_specific": {
"cwe_ids": [
"CWE-276",
"CWE-668",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-24T20:35:34Z",
"nvd_published_at": "2020-05-20T15:15:00Z",
"severity": "MODERATE"
},
"details": "The DMS/ECM module in Dolibarr 11.0.4 allows users with the \u0027Setup documents directories\u0027 permission to rename uploaded files to have insecure file extensions. This bypasses the .noexe protection mechanism against XSS.",
"id": "GHSA-f848-r5g6-6gpf",
"modified": "2024-04-24T20:35:34Z",
"published": "2022-05-24T17:18:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13240"
},
{
"type": "PACKAGE",
"url": "https://github.com/Dolibarr/dolibarr"
},
{
"type": "WEB",
"url": "https://www.dubget.com/stored-xss-via-file-upload.html"
}
],
"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"
}
],
"summary": "Dolibarr Stored Cross-site Scripting"
}
GHSA-F92V-GRC2-W2FG
Vulnerability from github – Published: 2022-08-18 19:04 – Updated: 2022-08-18 19:04Vulnerability Report
Impact
Smart contract applications that make use of the selfdestruct functionality and their end-users.
Classification
The vulnerability has been classified as high with a CVSS score of 8.2. It has the potential to create a denial-of-service to all contracts that can invoke the selfdestruct function to destroy a smart contract.
Users Impacted
Due to the successfully coordinated security vulnerability disclosure, no smart contracts were impacted through the use of this vulnerability. Smart contract states and storage values are not affected by this vulnerability. User funds and balances are safe.
Disclosure
In Ethermint running versions before v0.17.2, the contract selfdestruct invocation permanently removes the corresponding bytecode from the internal database storage. However, due to a bug in the DeleteAccount function, all contracts that used the identical bytecode (i.e shared the same CodeHash) will also stop working once one contract invokes selfdestruct, even though the other contracts did not invoke the selfdestruct OPCODE.
Additional Details
The same contract bytecode can be deployed multiple times to create multiple contract instances. In the internal database, the bytecode is stored as a key-value entry bytecode hash --> bytecode which is shared by those contracts. Unfortunately, when one of the contracts invokes selfdestruct, it will remove the corresponding bytecode hash -> bytecode entry, and thus it disables all the contracts that share the same bytecode.
The attack scenario is as follows:
- The malicious attacker identifies a vulnerable contract that can invoke
selfdestruct - The attacker deploys a copy of the contract with identical bytecode
- Finally, the attacker triggers the
selfdestructoperation on their redeployed contract, actively causing a DoS on the original and vulnerable contract. All transactions will fail until a workaround is used (see below).
Patches
Has the problem been patched? What versions should users upgrade to?
This vulnerability has been patched in Ethermint versions ≥v0.18.0. The patch has state machine-breaking changes for applications using Ethermint so a coordinated upgrade procedure is required.
Details
The patch removes the bytecode deletion logic, i.e. contract bytecodes are never deleted from the internal database after the patch.
At the moment, Ethermint does not track how many times each bytecode is used, and thus it cannot determine if it is safe to delete a particular bytecode on selfdestruct invocations. This behavior is the same with go-ethereum.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
If a contract is subject to DoS due to this issue, the user can redeploy the same contract, i.e with identical bytecode, so that the original contract's code is recovered.
The new contract deployment restores the bytecode hash -> bytecode entry in the internal state.
References
Are there any links users can visit to find out more?
For more information
If you have any questions or comments about this advisory:
- Reach out to the Core Team in Discord
- Open a discussion in evmos/ethermint
- Email us at security@evmos.org for security questions
- For Press, email us at evmos@west-comms.com.
Credits
Thanks to the
- Cronos Team: @yihuang and @tomtau for discovering the issue, @gakuzen-crypto, @polycryptics, @FinnZhangCrypto, @wilson-ang, @brianatcrypto for the impact analysis.
- Evmos Team: @facs95 for patching the issue and @fedekunze for managing the release and coordinating between teams.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.17.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/ethermint"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.18.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.0.3"
},
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/evmos"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.0.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.7.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/crypto-org-chain/cronos"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.7.1-rc2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.17.5"
},
"package": {
"ecosystem": "Go",
"name": "github.com/Kava-Labs/kava"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.18.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-35936"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": true,
"github_reviewed_at": "2022-08-18T19:04:47Z",
"nvd_published_at": "2022-08-05T13:15:00Z",
"severity": "HIGH"
},
"details": "# Vulnerability Report\n\n## Impact\n\nSmart contract applications that make use of the `selfdestruct` functionality and their end-users.\n\n## Classification\n\nThe vulnerability has been classified as `high` with a CVSS score of `8.2`. It has the potential to create a denial-of-service to all contracts that can invoke the [`selfdestruct`](https://ethereum.stackexchange.com/questions/315/why-are-selfdestructs-used-in-contract-programming#347) function to destroy a smart contract. \n\n## Users Impacted\n\nDue to the successfully coordinated security vulnerability disclosure, no smart contracts were impacted through the use of this vulnerability. Smart contract states and storage values are not affected by this vulnerability. User funds and balances are safe.\n\n## Disclosure\n\nIn Ethermint running versions before `v0.17.2`, the contract `selfdestruct` invocation permanently removes the corresponding bytecode from the internal database storage. However, due to a bug in the [`DeleteAccount`](https://github.com/evmos/ethermint/blob/c9d42d667b753147977a725e98ed116c933c76cb/x/evm/keeper/statedb.go#L199-L203) function, all contracts that used the identical bytecode (i.e shared the same `CodeHash`) will also stop working once one contract invokes `selfdestruct`, even though the other contracts did not invoke the `selfdestruct` OPCODE.\n\n### Additional Details\n\nThe same contract bytecode can be deployed multiple times to create multiple contract instances. In the internal database, the bytecode is stored as a key-value entry `bytecode hash --\u003e bytecode` which is shared by those contracts. Unfortunately, when one of the contracts invokes `selfdestruct`, it will remove the corresponding `bytecode hash -\u003e bytecode` entry, and thus it disables all the contracts that share the same bytecode.\n\nThe attack scenario is as follows:\n\n1. The malicious attacker identifies a vulnerable contract that can invoke `selfdestruct`\n2. The attacker deploys a copy of the contract with identical bytecode\n3. Finally, the attacker triggers the `selfdestruct` operation on their redeployed contract, actively causing a DoS on the original and vulnerable contract. All transactions will fail until a workaround is used (see below).\n\n## Patches\n\n*Has the problem been patched? What versions should users upgrade to?*\n\nThis vulnerability has been patched in Ethermint versions \u2265[v0.18.0](https://github.com/evmos/ethermint/releases/tag/v0.18.0). The patch has state machine-breaking changes for applications using Ethermint so a coordinated upgrade procedure is required.\n\n#### Details\n\nThe patch removes the bytecode deletion logic, i.e. contract bytecodes are never deleted from the internal database after the patch.\nAt the moment, Ethermint does not track how many times each bytecode is used, and thus it cannot determine if it is safe to delete a particular bytecode on `selfdestruct` invocations. This behavior is the same with go-ethereum.\n\n## Workarounds\n\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nIf a contract is subject to DoS due to this issue, the user can redeploy the same contract, _i.e_ with identical bytecode, so that the original contract\u0027s code is recovered.\n\nThe new contract deployment restores the `bytecode hash -\u003e bytecode` entry in the internal state.\n\n## References\n\n*Are there any links users can visit to find out more?*\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n- Reach out to the Core Team in [Discord](https://discord.gg/evmos)\n* Open a discussion in [evmos/ethermint](https://github.com/evmos/ethermint/discussions)\n* Email us at [security@evmos.org](mailto:security@evmos.org) for security questions\n* For Press, email us at [evmos@west-comms.com](mailto:evmos@west-comms.com).\n\n### Credits\n\nThanks to the \n\n- Cronos Team: @yihuang and @tomtau for discovering the issue, @gakuzen-crypto, @polycryptics, @FinnZhangCrypto, @wilson-ang, @brianatcrypto for the impact analysis.\n- Evmos Team: @facs95 for patching the issue and @fedekunze for managing the release and coordinating between teams.\n",
"id": "GHSA-f92v-grc2-w2fg",
"modified": "2022-08-18T19:04:47Z",
"published": "2022-08-18T19:04:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/evmos/ethermint/security/advisories/GHSA-f92v-grc2-w2fg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35936"
},
{
"type": "WEB",
"url": "https://github.com/evmos/ethermint/commit/144741832007a26dbe950512acbda4ed95b2a451"
},
{
"type": "PACKAGE",
"url": "https://github.com/evmos/ethermint"
},
{
"type": "WEB",
"url": "https://github.com/evmos/ethermint/blob/c9d42d667b753147977a725e98ed116c933c76cb/x/evm/keeper/statedb.go#L199-L203"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "Ethermint vulnerable to DoS through unintended Contract Selfdestruct"
}
GHSA-F93F-4Q67-PCMR
Vulnerability from github – Published: 2024-02-27 12:31 – Updated: 2024-04-10 15:30In the Linux kernel, the following vulnerability has been resolved:
fs/mount_setattr: always cleanup mount_kattr
Make sure that finish_mount_kattr() is called after mount_kattr was succesfully built in both the success and failure case to prevent leaking any references we took when we built it. We returned early if path lookup failed thereby risking to leak an additional reference we took when building mount_kattr when an idmapped mount was requested.
{
"affected": [],
"aliases": [
"CVE-2021-46923"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-27T10:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/mount_setattr: always cleanup mount_kattr\n\nMake sure that finish_mount_kattr() is called after mount_kattr was\nsuccesfully built in both the success and failure case to prevent\nleaking any references we took when we built it. We returned early if\npath lookup failed thereby risking to leak an additional reference we\ntook when building mount_kattr when an idmapped mount was requested.",
"id": "GHSA-f93f-4q67-pcmr",
"modified": "2024-04-10T15:30:32Z",
"published": "2024-02-27T12:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46923"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/012e332286e2bb9f6ac77d195f17e74b2963d663"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/47b5d0a7532d39e42a938f81e3904268145c341d"
}
],
"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-F94J-9C53-2WH5
Vulnerability from github – Published: 2024-05-03 03:30 – Updated: 2024-05-03 03:30Softing Secure Integration Server Exposure of Resource to Wrong Sphere Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Softing Secure Integration Server. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed.
The specific flaw exists within the handling of OPC FileDirectory namespaces. The issue results from the lack of proper validation of user-supplied data before using it to create a server object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root. Was ZDI-CAN-20547.
{
"affected": [],
"aliases": [
"CVE-2023-39478"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-03T03:15:14Z",
"severity": "MODERATE"
},
"details": "Softing Secure Integration Server Exposure of Resource to Wrong Sphere Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Softing Secure Integration Server. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed.\n\nThe specific flaw exists within the handling of OPC FileDirectory namespaces. The issue results from the lack of proper validation of user-supplied data before using it to create a server object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root. Was ZDI-CAN-20547.",
"id": "GHSA-f94j-9c53-2wh5",
"modified": "2024-05-03T03:30:56Z",
"published": "2024-05-03T03:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39478"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-23-1060"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FC93-89FQ-8669
Vulnerability from github – Published: 2022-01-15 00:01 – Updated: 2023-08-08 15:31The broadcast that DevicePickerFragment sends when a new device is paired doesn't have any permission checks, so any app can register to listen for it. This lets apps keep track of what devices are paired without requesting BLUETOOTH permissions.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-9Android ID: A-162951906
{
"affected": [],
"aliases": [
"CVE-2021-1037"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-14T20:15:00Z",
"severity": "MODERATE"
},
"details": "The broadcast that DevicePickerFragment sends when a new device is paired doesn\u0027t have any permission checks, so any app can register to listen for it. This lets apps keep track of what devices are paired without requesting BLUETOOTH permissions.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-9Android ID: A-162951906",
"id": "GHSA-fc93-89fq-8669",
"modified": "2023-08-08T15:31:36Z",
"published": "2022-01-15T00:01:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1037"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/aaos/2022-01-01"
}
],
"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-FCJ5-HC2W-P9G4
Vulnerability from github – Published: 2022-10-07 18:15 – Updated: 2022-10-12 12:00Improper access control vulnerability in cloudNotificationManager.java SmartThings prior to version 1.7.89.0 allows attackers to access sensitive information via REMOVE_PERSISTENT_BANNER broadcast.
{
"affected": [],
"aliases": [
"CVE-2022-39869"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-07T15:15:00Z",
"severity": "HIGH"
},
"details": "Improper access control vulnerability in cloudNotificationManager.java SmartThings prior to version 1.7.89.0 allows attackers to access sensitive information via REMOVE_PERSISTENT_BANNER broadcast.",
"id": "GHSA-fcj5-hc2w-p9g4",
"modified": "2022-10-12T12:00:27Z",
"published": "2022-10-07T18:15:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39869"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2022\u0026month=10"
}
],
"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-FCR8-4R9F-R66M
Vulnerability from github – Published: 2025-01-17 16:29 – Updated: 2025-01-17 21:56Impact
Enabling frame-ancestors: 'self' grants any JupyterHub user the ability to extract formgrader content by sending malicious links to users with access to formgrader, at least when using the default JupyterHub configuration of enable_subdomains = False.
1915 disables a protection which would allow user Alice to craft a page embedding formgrader in an IFrame. If Bob visits that page, his credentials will be sent and the formgrader page loaded. Because Alice's page is on the same Origin as the formgrader iframe, Javasript on Alice's page has full access to the contents of the page served by formgrader using Bob's credentials.
Workarounds
- Disable
frame-ancestors: self, or - enable per-user and per-service subdomains with
JupyterHub.enable_subdomains = True(then even if embedding in an IFrame is allowed, the host page does not have access to the contents of the frame).
References
JupyterHub documentation on why and when frame-ancestors: self is insecure, and why it was disabled by default: https://jupyterhub.readthedocs.io/en/stable/explanation/websecurity.html#:~:text=frame-ancestors
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "nbgrader"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.4"
},
{
"fixed": "0.9.5"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.9.4"
]
}
],
"aliases": [
"CVE-2025-23205"
],
"database_specific": {
"cwe_ids": [
"CWE-1021",
"CWE-668"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-17T16:29:16Z",
"nvd_published_at": "2025-01-17T21:15:11Z",
"severity": "HIGH"
},
"details": "### Impact\n\nEnabling frame-ancestors: \u0027self\u0027 grants any JupyterHub user the ability to extract formgrader content by sending malicious links to users with access to formgrader, at least when using the default JupyterHub configuration of `enable_subdomains = False`.\n\n#1915 disables a protection which would allow user Alice to craft a page embedding formgrader in an IFrame. If Bob visits that page, his credentials will be sent and the formgrader page loaded. Because Alice\u0027s page is on the same Origin as the formgrader iframe, Javasript on Alice\u0027s page has _full access_ to the contents of the page served by formgrader using Bob\u0027s credentials.\n\n### Workarounds\n\n- Disable `frame-ancestors: self`, or\n- enable per-user and per-service subdomains with `JupyterHub.enable_subdomains = True` (then even if embedding in an IFrame is allowed, the host page does not have access to the contents of the frame).\n\n### References\n\nJupyterHub documentation on why and when `frame-ancestors: self` is insecure, and why it was disabled by default: https://jupyterhub.readthedocs.io/en/stable/explanation/websecurity.html#:~:text=frame-ancestors",
"id": "GHSA-fcr8-4r9f-r66m",
"modified": "2025-01-17T21:56:51Z",
"published": "2025-01-17T16:29:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jupyter/nbgrader/security/advisories/GHSA-fcr8-4r9f-r66m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23205"
},
{
"type": "WEB",
"url": "https://github.com/jupyter/nbgrader/pull/1915"
},
{
"type": "WEB",
"url": "https://github.com/jupyter/nbgrader/commit/73e137511ac1dc02e95790d4fd6d4d88dab42325"
},
{
"type": "PACKAGE",
"url": "https://github.com/jupyter/nbgrader"
},
{
"type": "WEB",
"url": "https://jupyterhub.readthedocs.io/en/stable/explanation/websecurity.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "nbgrader\u0027s `frame-ancestors: self` grants all users access to formgrader"
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.