CWE-732
Allowed-with-ReviewIncorrect Permission Assignment for Critical Resource
Abstraction: Class · Status: Draft
The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
2075 vulnerabilities reference this CWE, most recent first.
GHSA-2574-CW53-M29G
Vulnerability from github – Published: 2023-06-15 21:30 – Updated: 2024-04-04 04:53PublicCMS <=V4.0.202302 is vulnerable to Insecure Permissions.
{
"affected": [],
"aliases": [
"CVE-2023-34852"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-15T20:15:09Z",
"severity": "CRITICAL"
},
"details": "PublicCMS \u003c=V4.0.202302 is vulnerable to Insecure Permissions.",
"id": "GHSA-2574-cw53-m29g",
"modified": "2024-04-04T04:53:12Z",
"published": "2023-06-15T21:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34852"
},
{
"type": "WEB",
"url": "https://github.com/funny-kill/CVE-2023-34852/blob/main/CVE-2023-34852.md"
},
{
"type": "WEB",
"url": "https://github.com/sanluan/PublicCMS"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2575-PGHM-6QQX
Vulnerability from github – Published: 2022-02-15 01:57 – Updated: 2023-09-18 20:18In Kubernetes v1.8.x-v1.14.x, schema info is cached by kubectl in the location specified by --cache-dir (defaulting to $HOME/.kube/http-cache), written with world-writeable permissions (rw-rw-rw-). If --cache-dir is specified and pointed at a different location accessible to other users/groups, the written files may be modified by other users/groups and disrupt the kubectl invocation.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/client-go"
},
"ranges": [
{
"events": [
{
"introduced": "1.8.0"
},
{
"fixed": "1.12.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-11244"
],
"database_specific": {
"cwe_ids": [
"CWE-524",
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-07T17:22:21Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "In Kubernetes v1.8.x-v1.14.x, schema info is cached by kubectl in the location specified by `--cache-dir` (defaulting to `$HOME/.kube/http-cache`), written with world-writeable permissions (`rw-rw-rw-`). If `--cache-dir` is specified and pointed at a different location accessible to other users/groups, the written files may be modified by other users/groups and disrupt the kubectl invocation. ",
"id": "GHSA-2575-pghm-6qqx",
"modified": "2023-09-18T20:18:54Z",
"published": "2022-02-15T01:57:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11244"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/issues/76676"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/pull/77874"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/pull/77874/commits/f228ae3364729caed59087e23c42868454bc3ff4"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/client-go/commit/790a4f63632139cf6731014d00a9a8338f1fbd7d"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3942"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0020"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0074"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190509-0002"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/108064"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Kubernetes Unsafe Cacheing "
}
GHSA-25Q7-6X5V-RX9H
Vulnerability from github – Published: 2022-04-21 01:57 – Updated: 2024-02-28 01:09A missing permission check was found in The CLI in JBoss Operations Network before 2.3.1 does not properly check permissions, which allows JBoss ON users to perform management tasks and configuration changes with the privileges of the administrator user.
{
"affected": [],
"aliases": [
"CVE-2010-0737"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-30T23:15:00Z",
"severity": "HIGH"
},
"details": "A missing permission check was found in The CLI in JBoss Operations Network before 2.3.1 does not properly check permissions, which allows JBoss ON users to perform management tasks and configuration changes with the privileges of the administrator user.",
"id": "GHSA-25q7-6x5v-rx9h",
"modified": "2024-02-28T01:09:58Z",
"published": "2022-04-21T01:57:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-0737"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0737"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-269G-PWP5-87PP
Vulnerability from github – Published: 2020-10-12 17:33 – Updated: 2021-10-05 16:04Vulnerability
The JUnit4 test rule TemporaryFolder contains a local information disclosure vulnerability.
Example of vulnerable code:
public static class HasTempFolder {
@Rule
public TemporaryFolder folder = new TemporaryFolder();
@Test
public void testUsingTempFolder() throws IOException {
folder.getRoot(); // Previous file permissions: `drwxr-xr-x`; After fix:`drwx------`
File createdFile= folder.newFile("myfile.txt"); // unchanged/irrelevant file permissions
File createdFolder= folder.newFolder("subfolder"); // unchanged/irrelevant file permissions
// ...
}
}
Impact
On Unix like systems, the system's temporary directory is shared between all users on that system. Because of this, when files and directories are written into this directory they are, by default, readable by other users on that same system.
This vulnerability does not allow other users to overwrite the contents of these directories or files. This is purely an information disclosure vulnerability.
When analyzing the impact of this vulnerability, here are the important questions to ask:
- Do the JUnit tests write sensitive information, like API keys or passwords, into the temporary folder?
- If yes, this vulnerability impacts you, but only if you also answer 'yes' to question 2.
- If no, this vulnerability does not impact you.
- Do the JUnit tests ever execute in an environment where the OS has other untrusted users.
This may apply in CI/CD environments but normally won't be 'yes' for personal developer machines.
- If yes, and you answered 'yes' to question 1, this vulnerability impacts you.
- If no, this vulnerability does not impact you.
Patches
Because certain JDK file system APIs were only added in JDK 1.7, this this fix is dependent upon the version of the JDK you are using. - Java 1.7 and higher users: this vulnerability is fixed in 4.13.1. - Java 1.6 and lower users: no patch is available, you must use the workaround below.
Workarounds
If you are unable to patch, or are stuck running on Java 1.6, specifying the java.io.tmpdir system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability.
References
- CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
- Fix commit https://github.com/junit-team/junit4/commit/610155b8c22138329f0723eec22521627dbc52ae
Similar Vulnerabilities
- Google Guava - https://github.com/google/guava/issues/4011
- Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945
- JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
For more information
If you have any questions or comments about this advisory, please pen an issue in junit-team/junit4.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "junit:junit"
},
"ranges": [
{
"events": [
{
"introduced": "4.7"
},
{
"fixed": "4.13.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-15250"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2020-10-12T17:32:34Z",
"nvd_published_at": "2020-10-12T18:15:00Z",
"severity": "MODERATE"
},
"details": "### Vulnerability\n\nThe JUnit4 test rule [TemporaryFolder](https://junit.org/junit4/javadoc/4.13/org/junit/rules/TemporaryFolder.html) contains a local information disclosure vulnerability.\n\nExample of vulnerable code:\n```java\npublic static class HasTempFolder {\n @Rule\n public TemporaryFolder folder = new TemporaryFolder();\n\n @Test\n public void testUsingTempFolder() throws IOException {\n folder.getRoot(); // Previous file permissions: `drwxr-xr-x`; After fix:`drwx------`\n File createdFile= folder.newFile(\"myfile.txt\"); // unchanged/irrelevant file permissions\n File createdFolder= folder.newFolder(\"subfolder\"); // unchanged/irrelevant file permissions\n // ...\n }\n}\n```\n\n### Impact\n\nOn Unix like systems, the system\u0027s temporary directory is shared between all users on that system. Because of this, when files and directories are written into this directory they are, by default, readable by other users on that same system.\n\nThis vulnerability **does not** allow other users to overwrite the contents of these directories or files. This is purely an information disclosure vulnerability.\n\nWhen analyzing the impact of this vulnerability, here are the important questions to ask:\n\n1. Do the JUnit tests write sensitive information, like API keys or passwords, into the temporary folder?\n - If yes, this vulnerability impacts you, but only if you also answer \u0027yes\u0027 to question 2.\n - If no, this vulnerability does not impact you.\n2. Do the JUnit tests ever execute in an environment where the OS has other untrusted users. \n _This may apply in CI/CD environments but normally won\u0027t be \u0027yes\u0027 for personal developer machines._\n - If yes, and you answered \u0027yes\u0027 to question 1, this vulnerability impacts you.\n - If no, this vulnerability does not impact you.\n\n### Patches\n\nBecause certain JDK file system APIs were only added in JDK 1.7, this this fix is dependent upon the version of the JDK you are using.\n - Java 1.7 and higher users: this vulnerability is fixed in 4.13.1.\n - Java 1.6 and lower users: **no patch is available, you must use the workaround below.**\n\n### Workarounds\n\nIf you are unable to patch, or are stuck running on Java 1.6, specifying the `java.io.tmpdir` system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability.\n\n### References\n- [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/200.html)\n- Fix commit https://github.com/junit-team/junit4/commit/610155b8c22138329f0723eec22521627dbc52ae\n\n#### Similar Vulnerabilities\n - Google Guava - https://github.com/google/guava/issues/4011\n - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945\n - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824\n\n### For more information\nIf you have any questions or comments about this advisory, please pen an issue in [junit-team/junit4](https://github.com/junit-team/junit4/issues).",
"id": "GHSA-269g-pwp5-87pp",
"modified": "2021-10-05T16:04:16Z",
"published": "2020-10-12T17:33:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15250"
},
{
"type": "WEB",
"url": "https://github.com/junit-team/junit4/issues/1676"
},
{
"type": "WEB",
"url": "https://github.com/junit-team/junit4/commit/610155b8c22138329f0723eec22521627dbc52ae"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ra1bdb9efae84794e8ffa2f8474be8290ba57830eefe9714b95da714b@%3Cdev.pdfbox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/raebf13f53cd5d23d990712e3d11c80da9a7bae94a6284050f148ed99@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb2771949c676ca984e58a5cd5ca79c2634dee1945e0406e48e0f8457@%3Cdev.creadur.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb2ffe2993f4dccc48d832e1a0f1c419477781b6ea16e725ca2276dbb@%3Cdev.knox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb33212dab7beccaf1ffef9b88610047c644f644c7a0ebdc44d77e381@%3Ccommits.turbine.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rbaec90e699bc7c7bd9a053f76707a36fda48b6d558f31dc79147dbf9@%3Cdev.creadur.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc49cf1547ef6cac1be4b3c92339b2cae0acacf5acaba13cfa429a872@%3Cdev.creadur.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rdbdd30510a7c4d0908fd22075c02b75bbc2e0d977ec22249ef3133cb@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rde385b8b53ed046600ef68dd6b4528dea7566aaddb02c3e702cc28bc@%3Ccommits.creadur.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rde8e70b95c992378e8570e4df400c6008a9839eabdfb8f800a3e5af6@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rdef7d1380c86e7c0edf8a0f89a2a8db86fce5e363457d56b722691b4@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rea812d8612fdc46842a2a57248cad4b01ddfdb1e9b037c49e68fdbfb@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/reb700e60b9642eafa4b7922bfee80796394135aa09c7a239ef9f7486@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf2ec93f4ca9a97d1958eb4a31b1830f723419ce9bf2018a6e5741d5b@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf6e5d894d4b03bef537c9d6641272e0197c047c0d1982b4e176d0353@%3Cdev.knox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf797d119cc3f51a8d7c3c5cbe50cb4524c8487282b986edde83a9467@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/11/msg00003.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/junit-team/junit4"
},
{
"type": "WEB",
"url": "https://github.com/junit-team/junit4/blob/7852b90cfe1cea1e0cdaa19d490c83f0d8684b50/doc/ReleaseNotes4.13.1.md"
},
{
"type": "WEB",
"url": "https://junit.org/junit4/javadoc/4.13/org/junit/rules/TemporaryFolder.html"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r01110833b63616ddbef59ae4e10c0fbd0060f0a51206defd4cb4d917@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r09cfbb5aedd76023691bbce9ca4ce2e16bb07dd37554a17efc19935d@%3Cpluto-dev.portals.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r1209986f79359b518d09513ff05a88e5b3c398540e775edea76a4774@%3Cdev.knox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r29d703d1986d9b871466ff24082a1828ac8ad27bb0965a93a383872e@%3Cpluto-scm.portals.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2b78f23bc2711a76a7fc73ad67b7fcd6817c5cfccefd6f30a4f54943@%3Cdev.knox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r30f502d2f79e8d635361adb8108dcbb73095163fcbd776ee7984a094@%3Ccommits.creadur.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r500517c23200fb2fdb0b82770a62dd6c88b3521cfb01cfd0c76e3f8b@%3Cdev.creadur.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5f8841507576f595bb783ccec6a7cb285ea90d4e6f5043eae0e61a41@%3Cdev.creadur.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r687f489b10b0d14e46f626aa88476545e1a2600b24c4ebd3c0d2a10b@%3Cdev.knox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r717877028482c55acf604d7a0106af4ca05da4208c708fb157b53672@%3Ccommits.creadur.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r742b44fd75215fc75963b8ecc22b2e4372e68d67d3d859d2b5e8743f@%3Cdev.knox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r8b02dc6f18df11ff39eedb3038f1e31e6f90a779b1959bae65107279@%3Cdev.knox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r925eaae7dd8f77dd61eefc49c1fcf54bd9ecfe605486870d7b1e9390@%3Cpluto-dev.portals.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r934208a520b38f5cf0cae199b6b076bfe7d081809528b0eff2459e40@%3Cdev.knox.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r95f8ef60c4b3a5284b647bb3132cda08e6fadad888a66b84f49da0b0@%3Ccommits.creadur.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9710067c7096b83cb6ae8f53a2f6f94e9c042d1bf1d6929f8f2a2b7a@%3Ccommits.knox.apache.org%3E"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "TemporaryFolder on unix-like systems does not limit access to created files"
}
GHSA-26GW-4GMP-QGF3
Vulnerability from github – Published: 2022-05-13 01:47 – Updated: 2022-05-13 01:47In ARM Trusted Firmware 1.3, RO memory is always executable at AArch64 Secure EL1, allowing attackers to bypass the MT_EXECUTE_NEVER protection mechanism. This issue occurs because of inconsistency in the number of execute-never bits (one bit versus two bits).
{
"affected": [],
"aliases": [
"CVE-2017-7563"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-06-07T15:29:00Z",
"severity": "HIGH"
},
"details": "In ARM Trusted Firmware 1.3, RO memory is always executable at AArch64 Secure EL1, allowing attackers to bypass the MT_EXECUTE_NEVER protection mechanism. This issue occurs because of inconsistency in the number of execute-never bits (one bit versus two bits).",
"id": "GHSA-26gw-4gmp-qgf3",
"modified": "2022-05-13T01:47:01Z",
"published": "2022-05-13T01:47:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7563"
},
{
"type": "WEB",
"url": "https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-26RP-5GJF-GW47
Vulnerability from github – Published: 2025-01-14 03:31 – Updated: 2025-01-14 03:31Under certain conditions SAP NetWeaver AS for ABAP and ABAP Platform (Internet Communication Framework) allows an attacker to access restricted information due to weak access controls. This can have a significant impact on the confidentiality, integrity, and availability of an application
{
"affected": [],
"aliases": [
"CVE-2025-0066"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-14T01:15:16Z",
"severity": "CRITICAL"
},
"details": "Under certain conditions SAP NetWeaver AS for ABAP and ABAP Platform (Internet Communication Framework) allows an attacker to access restricted information due to weak access controls. This can have a significant impact on the confidentiality, integrity, and availability of an application",
"id": "GHSA-26rp-5gjf-gw47",
"modified": "2025-01-14T03:31:42Z",
"published": "2025-01-14T03:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0066"
},
{
"type": "WEB",
"url": "https://me.sap.com/notes/3550708"
},
{
"type": "WEB",
"url": "https://url.sap/sapsecuritypatchday"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-26RX-WM6Q-F3G4
Vulnerability from github – Published: 2023-10-19 00:30 – Updated: 2024-11-13 18:31Baker Hughes – Bently Nevada 3500 System TDI Firmware version 5.05
contains a vulnerability in their password retrieval functionality which could allow an attacker to access passwords stored on the device.
{
"affected": [],
"aliases": [
"CVE-2023-34437"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-19T00:15:16Z",
"severity": "HIGH"
},
"details": "\n\n\nBaker Hughes \u2013 Bently Nevada 3500 System TDI Firmware version 5.05\n\n contains\u00a0a vulnerability in their password retrieval functionality which could allow an attacker to access passwords stored on the device.",
"id": "GHSA-26rx-wm6q-f3g4",
"modified": "2024-11-13T18:31:51Z",
"published": "2023-10-19T00:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34437"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-269-05"
}
],
"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-2754-9C8F-G836
Vulnerability from github – Published: 2022-05-13 01:43 – Updated: 2022-05-13 01:43Huawei OceanStor 2800 V3, V300R003C00, V300R003C20, OceanStor 5300 V3, V300R003C00, V300R003C10, V300R003C20, OceanStor 5500 V3, V300R003C00, V300R003C10, V300R003C20, OceanStor 5600 V3, V300R003C00, V300R003C10, V300R003C20, OceanStor 5800 V3, V300R003C00, V300R003C10, V300R003C20 have an improper access control vulnerability. Due to incorrectly restrict access to a resource, an attacker with high privilege may exploit the vulnerability to query some information or send specific message to cause some service abnormal.
{
"affected": [],
"aliases": [
"CVE-2017-15352"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-02-15T16:29:00Z",
"severity": "LOW"
},
"details": "Huawei OceanStor 2800 V3, V300R003C00, V300R003C20, OceanStor 5300 V3, V300R003C00, V300R003C10, V300R003C20, OceanStor 5500 V3, V300R003C00, V300R003C10, V300R003C20, OceanStor 5600 V3, V300R003C00, V300R003C10, V300R003C20, OceanStor 5800 V3, V300R003C00, V300R003C10, V300R003C20 have an improper access control vulnerability. Due to incorrectly restrict access to a resource, an attacker with high privilege may exploit the vulnerability to query some information or send specific message to cause some service abnormal.",
"id": "GHSA-2754-9c8f-g836",
"modified": "2022-05-13T01:43:45Z",
"published": "2022-05-13T01:43:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15352"
},
{
"type": "WEB",
"url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20171122-01-oceanstor-en"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-27MF-H76R-WRJ9
Vulnerability from github – Published: 2025-05-19 18:30 – Updated: 2025-05-19 18:30A permissions issue was addressed with additional restrictions. This issue is fixed in visionOS 2.3, iOS 18.3 and iPadOS 18.3, macOS Sequoia 15.3, watchOS 11.3, tvOS 18.3. An app may be able to modify protected parts of the file system.
{
"affected": [],
"aliases": [
"CVE-2025-31262"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-19T16:15:29Z",
"severity": "MODERATE"
},
"details": "A permissions issue was addressed with additional restrictions. This issue is fixed in visionOS 2.3, iOS 18.3 and iPadOS 18.3, macOS Sequoia 15.3, watchOS 11.3, tvOS 18.3. An app may be able to modify protected parts of the file system.",
"id": "GHSA-27mf-h76r-wrj9",
"modified": "2025-05-19T18:30:46Z",
"published": "2025-05-19T18:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31262"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122066"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122068"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122071"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122072"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122073"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-27VQ-HV74-7CQP
Vulnerability from github – Published: 2024-12-16 17:38 – Updated: 2024-12-18 17:18The OVERWRITE clause of the DEFINE TABLE statement would fail to overwrite data for tables that were defined with TYPE RELATION. Since table definitions include the PERMISSIONS clause, this failure would result in permissions not being overwritten as a result, which may potentially lead users to believe they have changed the table permissions when they have not.
Impact
If a user attempted to update table permissions of a table defined with TYPE RELATION using DEFINE TABLE ... OVERWRITE, permissions for the table would not be changed. This may allow a client that is authorized to run queries in a SurrealDB server to access certain data in that specific table that they were not intended to be able to access after the specified change in permissions.
Patches
The DEFINE TABLE statement has been updated to appropriately overwrite data for tables defined with TYPE RELATION.
- Version 2.1.4 and later are not affected by this issue.
Workarounds
Users of tables with TYPE RELATION that may have been modified using the OVERWRITE clause in order to update permissions are advised to verify that the intended permissions are in place using the INFO FOR DB statement. Affected users who are unable to update and require updating permissions in a table with TYPE RELATION will be required to remove the table and define it from scratch with the intended permissions. Data can be preserved by backing it up to a temporary table.
References
-
5260
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "surrealdb"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "surrealdb-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2024-12-16T17:38:53Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "The `OVERWRITE` clause of the `DEFINE TABLE` statement would fail to overwrite data for tables that were defined with `TYPE RELATION`. Since table definitions include the `PERMISSIONS` clause, this failure would result in permissions not being overwritten as a result, which may potentially lead users to believe they have changed the table permissions when they have not.\n\n### Impact\n\nIf a user attempted to update table permissions of a table defined with `TYPE RELATION` using `DEFINE TABLE ... OVERWRITE`, permissions for the table would not be changed. This may allow a client that is authorized to run queries in a SurrealDB server to access certain data in that specific table that they were not intended to be able to access after the specified change in permissions.\n\n### Patches\n\nThe `DEFINE TABLE` statement has been updated to appropriately overwrite data for tables defined with `TYPE RELATION`.\n\n- Version 2.1.4 and later are not affected by this issue.\n\n### Workarounds\n\nUsers of tables with `TYPE RELATION` that may have been modified using the `OVERWRITE` clause in order to update permissions are advised to verify that the intended permissions are in place using the `INFO FOR DB` statement. Affected users who are unable to update and require updating permissions in a table with `TYPE RELATION` will be required to remove the table and define it from scratch with the intended permissions. Data can be preserved by backing it up to a temporary table.\n\n### References\n\n- #5260",
"id": "GHSA-27vq-hv74-7cqp",
"modified": "2024-12-18T17:18:19Z",
"published": "2024-12-16T17:38:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-27vq-hv74-7cqp"
},
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/pull/5260"
},
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/commit/2f9a58f830c24f107b4783da1f0704a502bc7734"
},
{
"type": "PACKAGE",
"url": "https://github.com/surrealdb/surrealdb"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "SurrealDB has Silent Failure to Overwrite Table Definition of Relation Type"
}
Mitigation
When using a critical resource such as a configuration file, check to see if the resource has insecure permissions (such as being modifiable by any regular user) [REF-62], and generate an error or even exit the software if there is a possibility that the resource could have been modified by an unauthorized party.
Mitigation
Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully defining distinct user groups, privileges, and/or roles. Map these against data, functionality, and the related resources. Then set the permissions accordingly. This will allow you to maintain more fine-grained control over your resources. [REF-207]
Mitigation MIT-22
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation
During program startup, explicitly set the default permissions or umask to the most restrictive setting possible. Also set the appropriate permissions during program installation. This will prevent you from inheriting insecure permissions from any user who installs or runs the program.
Mitigation
For all configuration files, executables, and libraries, make sure that they are only readable and writable by the software's administrator.
Mitigation
Do not suggest insecure configuration changes in documentation, especially if those configurations can extend to resources and other programs that are outside the scope of the application.
Mitigation
Do not assume that a system administrator will manually change the configuration to the settings that are recommended in the software's manual.
Mitigation MIT-37
Strategy: Environment Hardening
Ensure that the software runs properly under the United States Government Configuration Baseline (USGCB) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.
Mitigation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to disable public access.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-122: Privilege Abuse
An adversary is able to exploit features of the target that should be reserved for privileged users or administrators but are exposed to use by lower or non-privileged accounts. Access to sensitive information and functionality must be controlled to ensure that only authorized users are able to access these resources.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
CAPEC-17: Using Malicious Files
An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
CAPEC-180: Exploiting Incorrectly Configured Access Control Security Levels
An attacker exploits a weakness in the configuration of access controls and is able to bypass the intended protection that these measures guard against and thereby obtain unauthorized access to the system or network. Sensitive functionality should always be protected with access controls. However configuring all but the most trivial access control systems can be very complicated and there are many opportunities for mistakes. If an attacker can learn of incorrectly configured access security settings, they may be able to exploit this in an attack.
CAPEC-206: Signing Malicious Code
The adversary extracts credentials used for code signing from a production environment and then uses these credentials to sign malicious content with the developer's key. Many developers use signing keys to sign code or hashes of code. When users or applications verify the signatures are accurate they are led to believe that the code came from the owner of the signing key and that the code has not been modified since the signature was applied. If the adversary has extracted the signing credentials then they can use those credentials to sign their own code bundles. Users or tools that verify the signatures attached to the code will likely assume the code came from the legitimate developer and install or run the code, effectively allowing the adversary to execute arbitrary code on the victim's computer. This differs from CAPEC-673, because the adversary is performing the code signing.
CAPEC-234: Hijacking a privileged process
An adversary gains control of a process that is assigned elevated privileges in order to execute arbitrary code with those privileges. Some processes are assigned elevated privileges on an operating system, usually through association with a particular user, group, or role. If an attacker can hijack this process, they will be able to assume its level of privilege in order to execute their own code.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-61: Session Fixation
The attacker induces a client to establish a session with the target software using a session identifier provided by the attacker. Once the user successfully authenticates to the target software, the attacker uses the (now privileged) session identifier in their own transactions. This attack leverages the fact that the target software either relies on client-generated session identifiers or maintains the same session identifiers after privilege elevation.
CAPEC-62: Cross Site Request Forgery
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.
CAPEC-642: Replace Binaries
Adversaries know that certain binaries will be regularly executed as part of normal processing. If these binaries are not protected with the appropriate file system permissions, it could be possible to replace them with malware. This malware might be executed at higher system permission levels. A variation of this pattern is to discover self-extracting installation packages that unpack binaries to directories with weak file permissions which it does not clean up appropriately. These binaries can be replaced by malware, which can then be executed.