CWE-863
Allowed-with-ReviewIncorrect Authorization
Abstraction: Class · Status: Incomplete
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
6552 vulnerabilities reference this CWE, most recent first.
GHSA-V776-QXHX-4CRM
Vulnerability from github – Published: 2025-07-28 18:31 – Updated: 2025-07-28 18:31In JetBrains TeamCity before 2025.07 improper access control allowed disclosure of build settings via VCS configuration
{
"affected": [],
"aliases": [
"CVE-2025-54533"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-28T17:15:33Z",
"severity": "MODERATE"
},
"details": "In JetBrains TeamCity before 2025.07 improper access control allowed disclosure of build settings via VCS configuration",
"id": "GHSA-v776-qxhx-4crm",
"modified": "2025-07-28T18:31:28Z",
"published": "2025-07-28T18:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54533"
},
{
"type": "WEB",
"url": "https://www.jetbrains.com/privacy-security/issues-fixed"
}
],
"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-V7FF-8WCX-GMC5
Vulnerability from github – Published: 2021-04-06 17:31 – Updated: 2022-04-17 16:45Release 9.4.37 introduced a more precise implementation of RFC3986 with regards to URI decoding, together with some new compliance modes to optionally allow support of some URI that may have ambiguous interpretation within the Servlet specified API methods behaviours. The default mode allowed % encoded . characters to be excluded for URI normalisation, which is correct by the RFC, but is not assumed by common Servlet implementations. The default compliance mode allows requests with URIs that contain %2e or %2e%2e segments to access protected resources within the WEB-INF directory. For example a request to /context/%2e/WEB-INF/web.xml can retrieve the web.xml file. This can reveal sensitive information regarding the implementation of a web application. Workarounds found by HttpCompliance mode RFC7230_NO_AMBIGUOUS_URIS can be enabled by updating start.d/http.ini to include: jetty.http.compliance=RFC7230_NO_AMBIGUOUS_URIS.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-webapp"
},
"ranges": [
{
"events": [
{
"introduced": "9.4.37"
},
{
"fixed": "9.4.39"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-28164"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-551",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-02T20:28:10Z",
"nvd_published_at": "2021-04-01T15:15:00Z",
"severity": "MODERATE"
},
"details": "Release 9.4.37 introduced a more precise implementation of [RFC3986](https://tools.ietf.org/html/rfc3986#section-3.3) with regards to URI decoding, together with some new compliance modes to optionally allow support of some URI that may have ambiguous interpretation within the Servlet specified API methods behaviours. The default mode allowed % encoded . characters to be excluded for URI normalisation, which is correct by the RFC, but is not assumed by common Servlet implementations. The default compliance mode allows requests with URIs that contain `%2e` or `%2e%2e` segments to access protected resources within the `WEB-INF` directory. For example a request to `/context/%2e/WEB-INF/web.xml` can retrieve the `web.xml` file. This can reveal sensitive information regarding the implementation of a web application. Workarounds found by HttpCompliance mode RFC7230_NO_AMBIGUOUS_URIS can be enabled by updating `start.d/http.ini` to include: jetty.http.compliance=RFC7230_NO_AMBIGUOUS_URIS.",
"id": "GHSA-v7ff-8wcx-gmc5",
"modified": "2022-04-17T16:45:25Z",
"published": "2021-04-06T17:31:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/eclipse/jetty.project/security/advisories/GHSA-v7ff-8wcx-gmc5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28164"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210611-0006"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd7c8fb305a8637480dc943ba08424c8992dccad018cd1405eb2afe0e@%3Cdev.ignite.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd0471252aeb3384c3cfa6d131374646d4641b80dd313e7b476c47a9c@%3Cissues.solr.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rcea249eb7a0d243f21696e4985de33f3780399bf7b31ea1f6d489b8b@%3Cissues.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rbc075a4ac85e7a8e47420b7383f16ffa0af3b792b8423584735f369f@%3Cissues.solr.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9974f64723875052e02787b2a5eda689ac5247c71b827d455e5dc9a6@%3Cissues.solr.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r90e7b4c42a96d74c219e448bee6a329ab0cd3205c44b63471d96c3ab@%3Cissues.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r8e6c116628c1277c3cf132012a66c46a0863fa2a3037c0707d4640d4@%3Cissues.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r7dd079fa0ac6f47ba1ad0af98d7d0276547b8a4e005f034fb1016951@%3Cissues.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r780c3c210a05c5bf7b4671303f46afc3fe56758e92864e1a5f0590d0@%3Cjira.kafka.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r763840320a80e515331cbc1e613fa93f25faf62e991974171a325c82@%3Cdev.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6ac9e263129328c0db9940d72b4a6062e703c58918dd34bd22cdf8dd@%3Cissues.ignite.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5b3693da7ecb8a75c0e930b4ca26a5f97aa0207d9dae4aa8cc65fe6b@%3Cissues.ignite.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4b1fef117bccc7f5fd4c45fd2cabc26838df823fe5ca94bc42a4fd46@%3Cissues.ignite.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4a66bfbf62281e31bc1345ebecbfd96f35199eecd77bfe4e903e906f@%3Cissues.ignite.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3c55b0baa4dc38958ae147b2f216e212605f1071297f845e14477d36@%3Cissues.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2ea2f0541121f17e470a0184843720046c59d4bde6d42bf5ca6fad81@%3Cissues.solr.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2a3ea27cca2ac7352d392b023b72e824387bc9ff16ba245ec663bdc6@%3Cissues.zookeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r111f1ce28b133a8090ca4f809a1bdf18a777426fc058dc3a16c39c66@%3Cissues.solr.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r0841b06b48324cfc81325de3c05a92e53f997185f9d71ff47734d961@%3Cissues.solr.apache.org%3E"
},
{
"type": "PACKAGE",
"url": "https://github.com/eclipse/jetty.project"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/164590/Jetty-9.4.37.v20210219-Information-Disclosure.html"
}
],
"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"
}
],
"summary": "Authorization Before Parsing and Canonicalization in jetty"
}
GHSA-V7FH-395C-948J
Vulnerability from github – Published: 2026-08-16 06:30 – Updated: 2026-08-17 21:31The Visualizer WordPress plugin before 4.0.7 does not properly authorise access to the configuration of its charts, allowing users with the Contributor role and above to read the full configuration of any chart on the site, including charts the Visualizer WordPress plugin before 4.0.7's own interface denies them, and to retrieve every chart's configuration in a single request. The disclosed configuration can include the credentials of a remote data source a chart reads from.
{
"affected": [],
"aliases": [
"CVE-2026-19726"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-16T06:16:52Z",
"severity": "MODERATE"
},
"details": "The Visualizer WordPress plugin before 4.0.7 does not properly authorise access to the configuration of its charts, allowing users with the Contributor role and above to read the full configuration of any chart on the site, including charts the Visualizer WordPress plugin before 4.0.7\u0027s own interface denies them, and to retrieve every chart\u0027s configuration in a single request. The disclosed configuration can include the credentials of a remote data source a chart reads from.",
"id": "GHSA-v7fh-395c-948j",
"modified": "2026-08-17T21:31:19Z",
"published": "2026-08-16T06:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-19726"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/61a1577e-077f-4a00-96b4-860eda48e03b"
}
],
"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-V7J4-XWPV-VF3Q
Vulnerability from github – Published: 2022-05-24 17:17 – Updated: 2022-05-24 17:17An improper authorization in the receiver component of the Android Suite Daemon.Product: AndroidVersions: Android SoCAndroid ID: A-149813448
{
"affected": [],
"aliases": [
"CVE-2020-0065"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-05-14T21:15:00Z",
"severity": "LOW"
},
"details": "An improper authorization in the receiver component of the Android Suite Daemon.Product: AndroidVersions: Android SoCAndroid ID: A-149813448",
"id": "GHSA-v7j4-xwpv-vf3q",
"modified": "2022-05-24T17:17:51Z",
"published": "2022-05-24T17:17:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0065"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2020-05-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V7M3-MXH9-FX63
Vulnerability from github – Published: 2026-08-12 15:30 – Updated: 2026-08-12 15:30A bundle writer may create misleading release promotion information under specific conditions.
{
"affected": [],
"aliases": [
"CVE-2026-68755"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-12T15:18:22Z",
"severity": "MODERATE"
},
"details": "A bundle writer may create misleading release promotion information under specific conditions.",
"id": "GHSA-v7m3-mxh9-fx63",
"modified": "2026-08-12T15:30:49Z",
"published": "2026-08-12T15:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68755"
},
{
"type": "WEB",
"url": "https://docs.jfrog.com/releases/docs/artifactory-self-managed-releases"
},
{
"type": "WEB",
"url": "https://docs.jfrog.com/releases/docs/jfrog-security-advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V7M9-9497-P9GR
Vulnerability from github – Published: 2020-07-22 23:07 – Updated: 2024-09-24 20:43Impact
What kind of vulnerability is it? Who is impacted?
JupyterHub deployments using:
- KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and
- enabled named_servers (not default), and
- an Authenticator that allows:
- usernames with hyphens or other characters that require escape (e.g.
user-hyphenoruser@email), and - usernames which may match other usernames up to but not including the escaped character (e.g.
userin the above cases)
In this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.
Patches
Has the problem been patched? What versions should users upgrade to?
Patch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
KubeSpawner
Specify configuration:
for KubeSpawner
from traitlets import default
from kubespawner import KubeSpawner
class PatchedKubeSpawner(KubeSpawner):
@default("pod_name_template")
def _default_pod_name_template(self):
if self.name:
return "jupyter-{username}-{servername}"
else:
return "jupyter-{username}"
@default("pvc_name_template")
def _default_pvc_name_template(self):
if self.name:
return "claim-{username}-{servername}"
else:
return "claim-{username}"
c.JupyterHub.spawner_class = PatchedKubeSpawner
Note for KubeSpawner: this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.
Changing the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.
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:
- Open an issue in kubespawner
- Email us at security@ipython.org
Credit: Jining Huang
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.11.1"
},
"package": {
"ecosystem": "PyPI",
"name": "jupyterhub-kubespawner"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.12.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-15110"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2020-07-17T20:49:37Z",
"nvd_published_at": "2020-07-17T21:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nJupyterHub deployments using:\n\n- KubeSpawner \u003c= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and\n- enabled named_servers (not default), and\n- an Authenticator that allows:\n - usernames with hyphens or other characters that require escape (e.g. `user-hyphen` or `user@email`), and\n - usernames which may match other usernames up to but not including the escaped character (e.g. `user` in the above cases)\n\nIn this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nPatch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\n#### KubeSpawner\n\nSpecify configuration:\n\nfor KubeSpawner\n```python\nfrom traitlets import default\nfrom kubespawner import KubeSpawner\n\nclass PatchedKubeSpawner(KubeSpawner):\n @default(\"pod_name_template\")\n def _default_pod_name_template(self):\n if self.name:\n return \"jupyter-{username}-{servername}\"\n else:\n return \"jupyter-{username}\"\n\n @default(\"pvc_name_template\")\n def _default_pvc_name_template(self):\n if self.name:\n return \"claim-{username}-{servername}\"\n else:\n return \"claim-{username}\"\n\nc.JupyterHub.spawner_class = PatchedKubeSpawner\n```\n\n**Note for KubeSpawner:** this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner \u2264 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.\n\nChanging the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.\n\n### References\n_Are there any links users can visit to find out more?_\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [kubespawner](https://github.com/jupyterhub/kubespawner)\n* Email us at [security@ipython.org](mailto:security@ipython.org)\n\nCredit: Jining Huang",
"id": "GHSA-v7m9-9497-p9gr",
"modified": "2024-09-24T20:43:31Z",
"published": "2020-07-22T23:07:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jupyterhub/kubespawner/security/advisories/GHSA-v7m9-9497-p9gr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15110"
},
{
"type": "WEB",
"url": "https://github.com/jupyterhub/kubespawner/commit/3dfe870a7f5e98e2e398b01996ca6b8eff4bb1d0"
},
{
"type": "PACKAGE",
"url": "https://github.com/jupyterhub/kubespawner"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/jupyterhub-kubespawner/PYSEC-2020-51.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Possible pod name collisions in jupyterhub-kubespawner"
}
GHSA-V7PW-9CMM-88M6
Vulnerability from github – Published: 2023-09-06 18:30 – Updated: 2025-10-22 00:32A vulnerability in the remote access VPN feature of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to conduct a brute force attack in an attempt to identify valid username and password combinations or an authenticated, remote attacker to establish a clientless SSL VPN session with an unauthorized user.
This vulnerability is due to improper separation of authentication, authorization, and accounting (AAA) between the remote access VPN feature and the HTTPS management and site-to-site VPN features. An attacker could exploit this vulnerability by specifying a default connection profile/tunnel group while conducting a brute force attack or while establishing a clientless SSL VPN session using valid credentials. A successful exploit could allow the attacker to achieve one or both of the following:
Identify valid credentials that could then be used to establish an unauthorized remote access VPN session. Establish a clientless SSL VPN session (only when running Cisco ASA Software Release 9.16 or earlier).
Notes:
Establishing a client-based remote access VPN tunnel is not possible as these default connection profiles/tunnel groups do not and cannot have an IP address pool configured. This vulnerability does not allow an attacker to bypass authentication. To successfully establish a remote access VPN session, valid credentials are required, including a valid second factor if multi-factor authentication (MFA) is configured.
Cisco will release software updates that address this vulnerability. There are workarounds that address this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2023-20269"
],
"database_specific": {
"cwe_ids": [
"CWE-288",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-06T18:15:08Z",
"severity": "CRITICAL"
},
"details": "A vulnerability in the remote access VPN feature of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to conduct a brute force attack in an attempt to identify valid username and password combinations or an authenticated, remote attacker to establish a clientless SSL VPN session with an unauthorized user.\n\n This vulnerability is due to improper separation of authentication, authorization, and accounting (AAA) between the remote access VPN feature and the HTTPS management and site-to-site VPN features. An attacker could exploit this vulnerability by specifying a default connection profile/tunnel group while conducting a brute force attack or while establishing a clientless SSL VPN session using valid credentials. A successful exploit could allow the attacker to achieve one or both of the following:\n\n \n Identify valid credentials that could then be used to establish an unauthorized remote access VPN session.\n Establish a clientless SSL VPN session (only when running Cisco ASA Software Release 9.16 or earlier).\n \n Notes:\n\n \n Establishing a client-based remote access VPN tunnel is not possible as these default connection profiles/tunnel groups do not and cannot have an IP address pool configured.\n This vulnerability does not allow an attacker to bypass authentication. To successfully establish a remote access VPN session, valid credentials are required, including a valid second factor if multi-factor authentication (MFA) is configured.\n \n Cisco will release software updates that address this vulnerability. There are workarounds that address this vulnerability.",
"id": "GHSA-v7pw-9cmm-88m6",
"modified": "2025-10-22T00:32:51Z",
"published": "2023-09-06T18:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20269"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-ravpn-auth-8LyfCkeC"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-20269"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V7Q8-5286-XFVF
Vulnerability from github – Published: 2025-12-19 00:31 – Updated: 2025-12-19 00:31Improper Authorization (CWE-285) in Kibana can lead to privilege escalation (CAPEC-233) by allowing an authenticated user to bypass intended permission restrictions via a crafted HTTP request. This allows an attacker who lacks the live queries - read permission to successfully retrieve the list of live queries.
{
"affected": [],
"aliases": [
"CVE-2025-68422"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-18T23:15:49Z",
"severity": "MODERATE"
},
"details": "Improper Authorization (CWE-285) in Kibana can lead to privilege escalation (CAPEC-233) by allowing an authenticated user to bypass intended permission restrictions via a crafted HTTP request. This allows an attacker who lacks the live queries - read permission to successfully retrieve the list of live queries.",
"id": "GHSA-v7q8-5286-xfvf",
"modified": "2025-12-19T00:31:42Z",
"published": "2025-12-19T00:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68422"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/kibana-8-19-7-9-1-7-and-9-2-1-security-update-esa-2025-39/384187"
}
],
"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-V7XW-HR75-RM43
Vulnerability from github – Published: 2023-03-08 21:30 – Updated: 2025-03-05 21:31There exists a privilege escalation vulnerability in SmartBear Zephyr Enterprise through 7.15.0 that could be exploited by authorized users to reset passwords for other accounts.
{
"affected": [],
"aliases": [
"CVE-2023-22891"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-08T21:15:00Z",
"severity": "HIGH"
},
"details": "There exists a privilege escalation vulnerability in SmartBear Zephyr Enterprise through 7.15.0 that could be exploited by authorized users to reset passwords for other accounts.",
"id": "GHSA-v7xw-hr75-rm43",
"modified": "2025-03-05T21:31:59Z",
"published": "2023-03-08T21:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22891"
},
{
"type": "WEB",
"url": "https://smartbear.com/security/cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V833-3823-CMHP
Vulnerability from github – Published: 2026-07-31 16:27 – Updated: 2026-07-31 16:27Summary
OnionShare CLI/Desktop 2.6.3 does not enforce the Receive mode disable_files setting at the file upload sink. When a Receive service is configured as a text-message-only endpoint (--disable-files / "Disable uploading files"), a remote sender who can reach the OnionShare service can still send a crafted multipart request containing file[]; OnionShare writes the uploaded bytes to disk before the route handler skips file accounting.
This affects the shipped onionshare-cli Python package and the desktop application because both use the same onionshare_cli.web.receive_mode request-streaming implementation.
Details
Tested repository: https://github.com/onionshare/onionshare at commit 8cc75e1d7e88bd31f7276733449d412bf71c8999.
Affected product evidence:
- cli/pyproject.toml declares onionshare_cli version 2.6.3.
- desktop/pyproject.toml declares onionshare version 2.6.3 and depends on onionshare_cli from ../cli.
- cli/setup.py publishes onionshare-cli and includes onionshare_cli.web plus templates/static resources.
- desktop/setup.py publishes onionshare and exposes both onionshare and onionshare-cli console scripts.
Reachable default/common paths:
- CLI Receive mode is exposed through --receive (cli/onionshare_cli/__init__.py:55-57).
- The --disable-files option is documented and stored in mode settings (cli/onionshare_cli/__init__.py:156-160, cli/onionshare_cli/__init__.py:254-261).
- Desktop Receive mode exposes the same setting via the "Disable uploading files" checkbox and stores it as receive.disable_files (desktop/onionshare/tab/mode/receive_mode/__init__.py:89-99, desktop/onionshare/tab/mode/receive_mode/__init__.py:246-254).
- User documentation says "Disable uploading files" should "only allow submitting text messages, like for an anonymous contact form" (docs/source/features.rst:64).
- Advanced documentation lists --disable-files and disable_files as the option to disable receiving files (docs/source/advanced.rst:162-163, docs/source/advanced.rst:455).
Root cause:
- The Receive template hides the file input when disable_files is set (cli/onionshare_cli/resources/templates/receive.html:51-56), but this is only UI-side.
- The /upload route skips request.files.getlist("file[]") and file accounting when disable_files is enabled (cli/onionshare_cli/web/receive_mode.py:96-135). However, by this point Werkzeug has already parsed the multipart body and invoked the custom stream factory.
- ReceiveModeRequest.__init__() treats every POST /upload or POST /upload-ajax as an upload request and creates a receive directory regardless of disable_files (cli/onionshare_cli/web/receive_mode.py:369-391).
- ReceiveModeRequest._get_file_stream() creates a writable ReceiveModeFile for each uploaded part without checking self.web.settings.get("receive", "disable_files") (cli/onionshare_cli/web/receive_mode.py:517-540).
- ReceiveModeFile opens <receive_mode_dir>/<secure_filename>.part, writes attacker-controlled bytes, then renames the .part file to the final filename (cli/onionshare_cli/web/receive_mode.py:272-285, cli/onionshare_cli/web/receive_mode.py:320-346).
False-positive screening performed:
- secure_filename() is used at cli/onionshare_cli/web/receive_mode.py:111-113 and cli/onionshare_cli/web/receive_mode.py:527-528, so the confirmed issue is not path traversal; the file is written under the configured receive data directory.
- The UI hiding the file input is bypassable by direct multipart POST.
- Route-level if not disable_files only affects later accounting/status/webhook behavior; it does not prevent the stream sink from creating and writing the file.
- Default non-public onion services require the sender to know the onion address and private key unless the user opts into public mode. This limits exposure but does not enforce the user-selected "text only" security policy for authorized senders or public contact-form deployments.
- A control case with disable_text=True showed submitted text was not written as a message file, demonstrating the harness was exercising the settings boundary.
Affected versions / patched versions:
- Affected versions: unknown; confirmed in version 2.6.3 at commit 8cc75e1d7e88bd31f7276733449d412bf71c8999. Earlier versions were not tested during this audit.
- Patched versions: 2.6.4
Severity:
Rationale: AV:N because the Receive endpoint is reached over the OnionShare HTTP service; AC:L because a crafted multipart POST is straightforward once the service is reachable; PR:L because the sender generally needs the OnionShare URL/private key unless the receiver intentionally runs public mode; UI:N because no further receiver interaction is required after service startup; S:U because the same local application writes the file; C:N because this PoC does not read data; I:L because the attacker writes unwanted files in a mode configured to reject files; A:L because the bypass can consume disk/storage despite the files-disabled policy, bounded by available disk and operator controls.
PoC
The following safe local proof uses only temporary directories and Flask's local test client. In this audit environment, several runtime dependencies were absent (waitress, flask_compress, flask_socketio, unidecode, stem, qrcode), so the harness stubbed those imports while executing the real receive_mode request parsing and file writing code. No external network traffic was sent and no real files outside temporary directories were modified.
Maintainer reproduction from a clean checkout with normal dependencies can omit the import stubs and run the same test-client setup, or can start a local Receive service with --disable-files and submit a multipart request to /upload-ajax.
Positive setup and trigger:
import os, tempfile, shutil
from io import BytesIO
from onionshare_cli.common import Common
from onionshare_cli.settings import Settings
from onionshare_cli.mode_settings import ModeSettings
from onionshare_cli.web import Web
base = tempfile.mkdtemp(prefix='os-disable-files-poc-')
data_dir = os.path.join(base, 'receive-data')
os.mkdir(data_dir)
common = Common()
common.settings = Settings(common)
mode_settings = ModeSettings(common)
web = Web(common, False, mode_settings, 'receive')
web.app.testing = True
web.proxies = None
web.settings.set('receive', 'data_dir', data_dir)
web.settings.set('receive', 'disable_files', True)
with web.app.test_client() as c:
res = c.post(
'/upload-ajax',
buffered=True,
content_type='multipart/form-data',
data={'file[]': (BytesIO(b'DISABLE_FILES_BYPASS_MARKER'), 'audit.txt')},
)
print(res.status_code)
print(res.get_data(as_text=True))
for root, dirs, files in os.walk(data_dir):
for name in files:
path = os.path.join(root, name)
print(os.path.relpath(path, data_dir), open(path, 'rb').read().decode())
shutil.rmtree(base)
Observed output from this environment after re-running the proof after drafting:
May 29, 06:13PM: Upload of total size 274.0 B is starting
=> 27.0 B audit.txt positive_status: 200
positive_response: {"info_flashes": ["Nothing submitted or message was too long (> 524288 characters)"]}
positive_written: [('2026-05-29/181347904165/audit.txt', 'DISABLE_FILES_BYPASS_MARKER')]
The response says nothing/fileless was submitted, but the audit.txt file was created under the Receive data directory.
Negative/control case:
web2.settings.set('receive', 'disable_text', True)
# POST only a text field to /upload-ajax
Observed control output:
control_status: 200
control_response: {"info_flashes": ["Nothing submitted"]}
control_written_files: []
cleanup_done: true
Cleanup:
- The PoC deletes all temporary directories with shutil.rmtree(...); the audit run printed cleanup_done: true.
Impact
A Receive service operator can configure OnionShare as a text-only submission endpoint (for example, an anonymous contact form) and still receive attacker-controlled files on disk. This bypasses the explicit user-selected restriction and can lead to unwanted file placement and disk consumption in a deployment where file uploads were intentionally disabled.
The response and GUI/history accounting can be misleading because the route skips file processing while the lower-level request stream has already written the file. This may delay detection by the operator.
The confirmed issue does not provide arbitrary path traversal because filenames are sanitized and writes occur under the configured Receive data directory.
Suggested remediation
Enforce disable_files before any multipart file stream is written, not only in the route handler or template:
- In
ReceiveModeRequest._get_file_stream(), ifself.web.settings.get("receive", "disable_files")is true, reject the file part before creatingReceiveModeFile, or route it to a discard stream and mark the request as rejected. - Ensure
/uploadand/upload-ajaxreturn an explicit error when files are submitted while files are disabled. - Avoid creating a receive subdirectory for a file-only request that is rejected by policy.
- Add regression tests for both
/uploadand/upload-ajaxproving no file appears underreceive.data_dirwhenreceive.disable_filesis true. - Add a control regression test proving
disable_textstill prevents message-file creation.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "onionshare-cli"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54707"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-31T16:27:59Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nOnionShare CLI/Desktop 2.6.3 does not enforce the Receive mode `disable_files` setting at the file upload sink. When a Receive service is configured as a text-message-only endpoint (`--disable-files` / \"Disable uploading files\"), a remote sender who can reach the OnionShare service can still send a crafted multipart request containing `file[]`; OnionShare writes the uploaded bytes to disk before the route handler skips file accounting.\n\nThis affects the shipped `onionshare-cli` Python package and the desktop application because both use the same `onionshare_cli.web.receive_mode` request-streaming implementation.\n\n### Details\nTested repository: `https://github.com/onionshare/onionshare` at commit `8cc75e1d7e88bd31f7276733449d412bf71c8999`.\n\nAffected product evidence:\n- `cli/pyproject.toml` declares `onionshare_cli` version `2.6.3`.\n- `desktop/pyproject.toml` declares `onionshare` version `2.6.3` and depends on `onionshare_cli` from `../cli`.\n- `cli/setup.py` publishes `onionshare-cli` and includes `onionshare_cli.web` plus templates/static resources.\n- `desktop/setup.py` publishes `onionshare` and exposes both `onionshare` and `onionshare-cli` console scripts.\n\nReachable default/common paths:\n- CLI Receive mode is exposed through `--receive` (`cli/onionshare_cli/__init__.py:55-57`).\n- The `--disable-files` option is documented and stored in mode settings (`cli/onionshare_cli/__init__.py:156-160`, `cli/onionshare_cli/__init__.py:254-261`).\n- Desktop Receive mode exposes the same setting via the \"Disable uploading files\" checkbox and stores it as `receive.disable_files` (`desktop/onionshare/tab/mode/receive_mode/__init__.py:89-99`, `desktop/onionshare/tab/mode/receive_mode/__init__.py:246-254`).\n- User documentation says \"Disable uploading files\" should \"only allow submitting text messages, like for an anonymous contact form\" (`docs/source/features.rst:64`).\n- Advanced documentation lists `--disable-files` and `disable_files` as the option to disable receiving files (`docs/source/advanced.rst:162-163`, `docs/source/advanced.rst:455`).\n\nRoot cause:\n- The Receive template hides the file input when `disable_files` is set (`cli/onionshare_cli/resources/templates/receive.html:51-56`), but this is only UI-side.\n- The `/upload` route skips `request.files.getlist(\"file[]\")` and file accounting when `disable_files` is enabled (`cli/onionshare_cli/web/receive_mode.py:96-135`). However, by this point Werkzeug has already parsed the multipart body and invoked the custom stream factory.\n- `ReceiveModeRequest.__init__()` treats every `POST /upload` or `POST /upload-ajax` as an upload request and creates a receive directory regardless of `disable_files` (`cli/onionshare_cli/web/receive_mode.py:369-391`).\n- `ReceiveModeRequest._get_file_stream()` creates a writable `ReceiveModeFile` for each uploaded part without checking `self.web.settings.get(\"receive\", \"disable_files\")` (`cli/onionshare_cli/web/receive_mode.py:517-540`).\n- `ReceiveModeFile` opens `\u003creceive_mode_dir\u003e/\u003csecure_filename\u003e.part`, writes attacker-controlled bytes, then renames the `.part` file to the final filename (`cli/onionshare_cli/web/receive_mode.py:272-285`, `cli/onionshare_cli/web/receive_mode.py:320-346`).\n\nFalse-positive screening performed:\n- `secure_filename()` is used at `cli/onionshare_cli/web/receive_mode.py:111-113` and `cli/onionshare_cli/web/receive_mode.py:527-528`, so the confirmed issue is not path traversal; the file is written under the configured receive data directory.\n- The UI hiding the file input is bypassable by direct multipart POST.\n- Route-level `if not disable_files` only affects later accounting/status/webhook behavior; it does not prevent the stream sink from creating and writing the file.\n- Default non-public onion services require the sender to know the onion address and private key unless the user opts into public mode. This limits exposure but does not enforce the user-selected \"text only\" security policy for authorized senders or public contact-form deployments.\n- A control case with `disable_text=True` showed submitted text was not written as a message file, demonstrating the harness was exercising the settings boundary.\n\nAffected versions / patched versions:\n- Affected versions: unknown; confirmed in version `2.6.3` at commit `8cc75e1d7e88bd31f7276733449d412bf71c8999`. Earlier versions were not tested during this audit.\n- Patched versions: 2.6.4\n\nSeverity:\n\n Rationale: `AV:N` because the Receive endpoint is reached over the OnionShare HTTP service; `AC:L` because a crafted multipart POST is straightforward once the service is reachable; `PR:L` because the sender generally needs the OnionShare URL/private key unless the receiver intentionally runs public mode; `UI:N` because no further receiver interaction is required after service startup; `S:U` because the same local application writes the file; `C:N` because this PoC does not read data; `I:L` because the attacker writes unwanted files in a mode configured to reject files; `A:L` because the bypass can consume disk/storage despite the files-disabled policy, bounded by available disk and operator controls.\n\n### PoC\nThe following safe local proof uses only temporary directories and Flask\u0027s local test client. In this audit environment, several runtime dependencies were absent (`waitress`, `flask_compress`, `flask_socketio`, `unidecode`, `stem`, `qrcode`), so the harness stubbed those imports while executing the real `receive_mode` request parsing and file writing code. No external network traffic was sent and no real files outside temporary directories were modified.\n\nMaintainer reproduction from a clean checkout with normal dependencies can omit the import stubs and run the same test-client setup, or can start a local Receive service with `--disable-files` and submit a multipart request to `/upload-ajax`.\n\nPositive setup and trigger:\n```python\nimport os, tempfile, shutil\nfrom io import BytesIO\nfrom onionshare_cli.common import Common\nfrom onionshare_cli.settings import Settings\nfrom onionshare_cli.mode_settings import ModeSettings\nfrom onionshare_cli.web import Web\n\nbase = tempfile.mkdtemp(prefix=\u0027os-disable-files-poc-\u0027)\ndata_dir = os.path.join(base, \u0027receive-data\u0027)\nos.mkdir(data_dir)\n\ncommon = Common()\ncommon.settings = Settings(common)\nmode_settings = ModeSettings(common)\nweb = Web(common, False, mode_settings, \u0027receive\u0027)\nweb.app.testing = True\nweb.proxies = None\nweb.settings.set(\u0027receive\u0027, \u0027data_dir\u0027, data_dir)\nweb.settings.set(\u0027receive\u0027, \u0027disable_files\u0027, True)\n\nwith web.app.test_client() as c:\n res = c.post(\n \u0027/upload-ajax\u0027,\n buffered=True,\n content_type=\u0027multipart/form-data\u0027,\n data={\u0027file[]\u0027: (BytesIO(b\u0027DISABLE_FILES_BYPASS_MARKER\u0027), \u0027audit.txt\u0027)},\n )\n print(res.status_code)\n print(res.get_data(as_text=True))\n for root, dirs, files in os.walk(data_dir):\n for name in files:\n path = os.path.join(root, name)\n print(os.path.relpath(path, data_dir), open(path, \u0027rb\u0027).read().decode())\n\nshutil.rmtree(base)\n```\n\nObserved output from this environment after re-running the proof after drafting:\n```text\nMay 29, 06:13PM: Upload of total size 274.0 B is starting\n=\u003e 27.0 B audit.txt positive_status: 200\npositive_response: {\"info_flashes\": [\"Nothing submitted or message was too long (\u003e 524288 characters)\"]}\npositive_written: [(\u00272026-05-29/181347904165/audit.txt\u0027, \u0027DISABLE_FILES_BYPASS_MARKER\u0027)]\n```\n\nThe response says nothing/fileless was submitted, but the `audit.txt` file was created under the Receive data directory.\n\nNegative/control case:\n```python\nweb2.settings.set(\u0027receive\u0027, \u0027disable_text\u0027, True)\n# POST only a text field to /upload-ajax\n```\n\nObserved control output:\n```text\ncontrol_status: 200\ncontrol_response: {\"info_flashes\": [\"Nothing submitted\"]}\ncontrol_written_files: []\ncleanup_done: true\n```\n\nCleanup:\n- The PoC deletes all temporary directories with `shutil.rmtree(...)`; the audit run printed `cleanup_done: true`.\n\n### Impact\nA Receive service operator can configure OnionShare as a text-only submission endpoint (for example, an anonymous contact form) and still receive attacker-controlled files on disk. This bypasses the explicit user-selected restriction and can lead to unwanted file placement and disk consumption in a deployment where file uploads were intentionally disabled.\n\nThe response and GUI/history accounting can be misleading because the route skips file processing while the lower-level request stream has already written the file. This may delay detection by the operator.\n\nThe confirmed issue does not provide arbitrary path traversal because filenames are sanitized and writes occur under the configured Receive data directory.\n\n### Suggested remediation\nEnforce `disable_files` before any multipart file stream is written, not only in the route handler or template:\n\n- In `ReceiveModeRequest._get_file_stream()`, if `self.web.settings.get(\"receive\", \"disable_files\")` is true, reject the file part before creating `ReceiveModeFile`, or route it to a discard stream and mark the request as rejected.\n- Ensure `/upload` and `/upload-ajax` return an explicit error when files are submitted while files are disabled.\n- Avoid creating a receive subdirectory for a file-only request that is rejected by policy.\n- Add regression tests for both `/upload` and `/upload-ajax` proving no file appears under `receive.data_dir` when `receive.disable_files` is true.\n- Add a control regression test proving `disable_text` still prevents message-file creation.",
"id": "GHSA-v833-3823-cmhp",
"modified": "2026-07-31T16:27:59Z",
"published": "2026-07-31T16:27:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/onionshare/onionshare/security/advisories/GHSA-v833-3823-cmhp"
},
{
"type": "WEB",
"url": "https://github.com/onionshare/onionshare/commit/a090e97193efc91fbeac9dace7793ea568b83cf5"
},
{
"type": "PACKAGE",
"url": "https://github.com/onionshare/onionshare"
},
{
"type": "WEB",
"url": "https://github.com/onionshare/onionshare/releases/tag/v2.6.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "OnionShare Receive mode writes uploaded files even when file uploads are disabled"
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
No CAPEC attack patterns related to this CWE.