Common Weakness Enumeration

CWE-279

Allowed

Incorrect Execution-Assigned Permissions

Abstraction: Variant · Status: Draft

While it is executing, the product sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.

49 vulnerabilities reference this CWE, most recent first.

GHSA-PH6M-XM86-G466

Vulnerability from github – Published: 2025-05-13 21:30 – Updated: 2025-05-13 21:30
VLAI
Details

Incorrect execution-assigned permissions for some Edge Orchestrator software for Intel(R) Tiber™ Edge Platform may allow an authenticated user to potentially enable escalation of privilege via local access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-22843"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-279"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-13T21:16:09Z",
    "severity": "HIGH"
  },
  "details": "Incorrect execution-assigned permissions for some Edge Orchestrator software for Intel(R) Tiber\u2122 Edge Platform may allow an authenticated user to potentially enable escalation of privilege via local access.",
  "id": "GHSA-ph6m-xm86-g466",
  "modified": "2025-05-13T21:30:57Z",
  "published": "2025-05-13T21:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22843"
    },
    {
      "type": "WEB",
      "url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01239.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-PQ7M-3GW7-GQ5X

Vulnerability from github – Published: 2022-01-21 18:55 – Updated: 2024-09-27 17:22
VLAI
Summary
Execution with Unnecessary Privileges in ipython
Details

We’d like to disclose an arbitrary code execution vulnerability in IPython that stems from IPython executing untrusted files in CWD. This vulnerability allows one user to run code as another.

Proof of concept

User1:

mkdir -m 777 /tmp/profile_default
mkdir -m 777 /tmp/profile_default/startup
echo 'print("stealing your private secrets")' > /tmp/profile_default/startup/foo.py

User2:

cd /tmp
ipython

User2 will see:

Python 3.9.7 (default, Oct 25 2021, 01:04:21)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.29.0 -- An enhanced Interactive Python. Type '?' for help.
stealing your private secrets

Patched release and documentation

See https://ipython.readthedocs.io/en/stable/whatsnew/version8.html#ipython-8-0-1-cve-2022-21699,

Version 8.0.1, 7.31.1 for current Python version are recommended. Version 7.16.3 has also been published for Python 3.6 users, Version 5.11 (source only, 5.x branch on github) for older Python versions.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ipython"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ipython"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "7.16.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ipython"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.17.0"
            },
            {
              "fixed": "7.31.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ipython"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-21699"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250",
      "CWE-269",
      "CWE-279"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-01-19T21:26:17Z",
    "nvd_published_at": "2022-01-19T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "We\u2019d like to disclose an arbitrary code execution vulnerability in IPython that stems from IPython executing untrusted files in CWD. This vulnerability allows one user to run code as another.\n \nProof of concept\n\nUser1:\n```\nmkdir -m 777 /tmp/profile_default\nmkdir -m 777 /tmp/profile_default/startup\necho \u0027print(\"stealing your private secrets\")\u0027 \u003e /tmp/profile_default/startup/foo.py\n```\n\nUser2:\n```\ncd /tmp\nipython\n```\n\n \n\nUser2 will see:\n```\nPython 3.9.7 (default, Oct 25 2021, 01:04:21)\nType \u0027copyright\u0027, \u0027credits\u0027 or \u0027license\u0027 for more information\nIPython 7.29.0 -- An enhanced Interactive Python. Type \u0027?\u0027 for help.\nstealing your private secrets\n```\n\n\n## Patched release and documentation\n\nSee https://ipython.readthedocs.io/en/stable/whatsnew/version8.html#ipython-8-0-1-cve-2022-21699, \n\nVersion 8.0.1, 7.31.1 for current Python version are recommended. \nVersion 7.16.3 has also been published for Python 3.6 users, \nVersion 5.11 (source only, 5.x branch on github) for older Python versions.",
  "id": "GHSA-pq7m-3gw7-gq5x",
  "modified": "2024-09-27T17:22:07Z",
  "published": "2022-01-21T18:55:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ipython/ipython/security/advisories/GHSA-pq7m-3gw7-gq5x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21699"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ipython/ipython/commit/46a51ed69cdf41b4333943d9ceeb945c4ede5668"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ipython/ipython/commit/5fa1e409d2dc126c456510c16ece18e08b524e5b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ipython/ipython/commit/67ca2b3aa9039438e6f80e3fccca556f26100b4d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ipython/ipython/commit/a06ca837273271b4acb82c29be97c0b6d12a30ea"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ipython/ipython"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/ipython/PYSEC-2022-12.yaml"
    },
    {
      "type": "WEB",
      "url": "https://ipython.readthedocs.io/en/stable/whatsnew/version8.html#ipython-8-0-1-cve-2022-21699"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/01/msg00021.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/CRQRTWHYXMLDJ572VGVUZMUPEOTPM3KB"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DZ7LVZBB4D7KVSFNEQUBEHFO3JW6D2ZK"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Execution with Unnecessary Privileges in ipython"
}

GHSA-PWHC-RPQ9-4C8W

Vulnerability from github – Published: 2025-11-06 15:12 – Updated: 2025-11-06 23:12
VLAI
Summary
containerd affected by a local privilege escalation via wide permissions on CRI directory
Details

Impact

An overly broad default permission vulnerability was found in containerd.

  • /var/lib/containerd was created with the permission bits 0o711, while it should be created with 0o700
  • Allowed local users on the host to potentially access the metadata store and the content store
  • /run/containerd/io.containerd.grpc.v1.cri was created with 0o755, while it should be created with 0o700
  • Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host.
  • /run/containerd/io.containerd.sandbox.controller.v1.shim was created with 0o711, while it should be created with 0o700

The directory paths may differ depending on the daemon configuration. When the temp directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700.

Patches

This bug has been fixed in the following containerd versions:

  • 2.2.0
  • 2.1.5
  • 2.0.7
  • 1.7.29

Users should update to these versions to resolve the issue. These updates automatically change the permissions of the existing directories.

[!NOTE]

/run/containerd and /run/containerd/io.containerd.runtime.v2.task are still created with 0o711. This is an expected behavior for supporting userns-remapped containers.

Workarounds

The system administrator on the host can manually chmod the directories to not have group or world accessible permisisons:

chmod 700 /var/lib/containerd
chmod 700 /run/containerd/io.containerd.grpc.v1.cri
chmod 700 /run/containerd/io.containerd.sandbox.controller.v1.shim

An alternative mitigation would be to run containerd in rootless mode.

Credits

The containerd project would like to thank David Leadbeater for responsibly disclosing this issue in accordance with the containerd security policy.

For more information

If you have any questions or comments about this advisory:

To report a security issue in containerd:

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containerd/containerd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containerd/containerd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containerd/containerd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0-beta.0"
            },
            {
              "fixed": "2.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containerd/containerd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0-beta.0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-25621"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-279"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-06T15:12:08Z",
    "nvd_published_at": "2025-11-06T19:15:40Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAn overly broad default permission vulnerability was found in containerd.\n\n- `/var/lib/containerd` was created with the permission bits 0o711, while it should be created with 0o700\n  - Allowed local users on the host to potentially access the metadata store and the content store\n- `/run/containerd/io.containerd.grpc.v1.cri` was created with 0o755, while it should be created with 0o700\n  - Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host.\n- `/run/containerd/io.containerd.sandbox.controller.v1.shim` was created with 0o711, while it should be created with 0o700\n\nThe directory paths may differ depending on the daemon configuration.\nWhen the `temp` directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700.\n\n### Patches\n\nThis bug has been fixed in the following containerd versions:\n\n* 2.2.0\n* 2.1.5\n* 2.0.7\n* 1.7.29\n\nUsers should update to these versions to resolve the issue.\nThese updates automatically change the permissions of the existing directories.\n\n\u003e [!NOTE]\n\u003e\n\u003e `/run/containerd` and `/run/containerd/io.containerd.runtime.v2.task` are still created with 0o711.\n\u003e This is an expected behavior for supporting userns-remapped containers.\n\n### Workarounds\n\nThe system administrator on the host can manually chmod the directories to not \nhave group or world accessible permisisons:\n\n```\nchmod 700 /var/lib/containerd\nchmod 700 /run/containerd/io.containerd.grpc.v1.cri\nchmod 700 /run/containerd/io.containerd.sandbox.controller.v1.shim\n```\n\nAn alternative mitigation would be to run containerd in [rootless mode](https://github.com/containerd/containerd/blob/main/docs/rootless.md).\n\n### Credits\n\nThe containerd project would like to thank David Leadbeater for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)\n* Email us at [security@containerd.io](mailto:security@containerd.io)\n\nTo report a security issue in containerd:\n\n* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)",
  "id": "GHSA-pwhc-rpq9-4c8w",
  "modified": "2025-11-06T23:12:26Z",
  "published": "2025-11-06T15:12:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/containerd/containerd/security/advisories/GHSA-pwhc-rpq9-4c8w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25621"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containerd/containerd/commit/7c59e8e9e970d38061a77b586b23655c352bfec5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/containerd/containerd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containerd/containerd/blob/main/docs/rootless.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "containerd affected by a local privilege escalation via wide permissions on CRI directory"
}

GHSA-Q8X7-J9X6-2FPC

Vulnerability from github – Published: 2026-03-04 18:31 – Updated: 2026-04-02 15:31
VLAI
Details

A vulnerability was recently discovered in the rpc.mountd daemon in the nfs-utils package for Linux, that allows a NFSv3 client to escalate the privileges assigned to it in the /etc/exports file at mount time. In particular, it allows the client to access any subdirectory or subtree of an exported directory, regardless of the set file permissions, and regardless of any 'root_squash' or 'all_squash' attributes that would normally be expected to apply to that client.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-12801"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-279",
      "CWE-732"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-04T16:16:23Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was recently discovered in the rpc.mountd daemon in the nfs-utils package for Linux, that allows a NFSv3 client to escalate the\nprivileges assigned to it in the /etc/exports file at mount time. In particular, it allows the client to access any subdirectory or subtree of an exported directory, regardless of the set file permissions, and regardless of any \u0027root_squash\u0027 or \u0027all_squash\u0027 attributes that would normally be expected to apply to that client.",
  "id": "GHSA-q8x7-j9x6-2fpc",
  "modified": "2026-04-02T15:31:35Z",
  "published": "2026-03-04T18:31:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12801"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:3938"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:3939"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:3940"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:3941"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:3942"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:5127"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:5606"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:5867"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:5873"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:5877"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-12801"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2413081"
    }
  ],
  "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-QC59-CXJ2-C2W4

Vulnerability from github – Published: 2025-04-15 14:48 – Updated: 2025-04-15 14:48
VLAI
Summary
aws-cdk-lib's aspect order change causes different Permissions Boundary assigned to Role
Details

Summary

The AWS Cloud Development Kit (AWS CDK) is an open-source software development framework for defining cloud infrastructure in code and provisioning it through AWS CloudFormation. In the CDK, developers organize their applications into reusable components called "constructs," which are organized into a hierarchical tree structure. One of the features of this framework is the ability to call "Aspects," which are mechanisms to set configuration options for all AWS Resources in a particular part of the hierarchy at once. Aspect execution happens in a specific order, and the last Aspect to execute controls the final values in the template.

AWS CDK version 2.172.0 introduced a new priority system for Aspects. Prior to this version, CDK would run Aspects based on hierarchical location. The new priority system takes precedence over hierarchical location, altering the invocation order of Aspects. Different priority classes were introduced: Aspects added by CDK APIs were classified as MUTATING (priority 200), while Aspects added directly by the user were classified as DEFAULT (priority 500) unless the user specified otherwise. As a result of this change, CDK apps that use a custom Aspect to assign a default permissions boundary and then use a built-in CDK method to override it on select resources could have unexpected permissions boundaries assigned.

The following is an affected code sample:

Aspects.of(stack).add(new CustomAspectThatAssignsDefaultPermissionsBoundaries());   // {1}

PermissionsBoundary.of(lambdaFunc).apply(...);  // {2} -- uses Aspects internally

In versions prior to 2.172.0, the Aspect added by {2} would invoke last and assign its permissions boundary to the Lambda function role.

In versions 2.172.0 and after, the Aspect added by {2} would have priority 200 while the Aspect added by {1} would have priority 500 and therefore be invoked last. The Lambda function role would get the permissions boundary of {1} assigned, which may not be what users expect.

Impact

If an unexpected permissions boundary is selected for a role, it could lead to that role having insufficient permissions. Alternatively, this could lead to a role having wider permissions than intended; however, this could happen only in combination with an overly permissive role policy, as permissions boundaries do not grant permissions by themselves.

Impacted versions: versions 2.172.0 up until 2.189.1

Patches

In version 2.189.1, the behavior has been reverted to the behavior of pre-2.172.0. The new behavior is available through a feature flag:

{
  "context": {
    "@aws-cdk/core:aspectPrioritiesMutating": true
  }
}

The patches are included in AWS CDK Library version 2.189.1 and after. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

As a workaround, users can use the location hierarchy to order the invocation of Aspects. To do this, users can assign the custom Aspect a priority of MUTATING to ensure it has the same priority as the Aspect added by the CDK API, and that the location hierarchy is used for the order of invocation Aspects.

The following code is an example:

Aspects.of(stack).add(new CustomAspectThatAssignsDefaultPermissionsBoundaries(), {
  priority: AspectPriority.MUTATING,
});

References

If you have any questions or comments about this advisory, we ask that you contact AWS/Amazon Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Credit

We would like to thank GoDaddy for collaborating on this issue through the coordinated vulnerability disclosure process.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "aws-cdk-lib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.172.0"
            },
            {
              "fixed": "2.189.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-279"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-15T14:48:49Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n\nThe [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/) is an open-source software development framework for defining cloud infrastructure in code and provisioning it through AWS CloudFormation. In the CDK, developers organize their applications into reusable components called \"[constructs](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html),\" which are organized into a hierarchical tree structure. One of the features of this framework is the ability to call \"[Aspects](https://docs.aws.amazon.com/cdk/v2/guide/aspects.html),\" which are mechanisms to set configuration options for all AWS Resources in a particular part of the hierarchy at once. Aspect execution happens in a specific order, and the last Aspect to execute controls the final values in the template.\n\nAWS CDK version [2.172.0](https://github.com/aws/aws-cdk/releases/tag/v2.172.0) introduced a new priority system for Aspects. Prior to this version, CDK would run Aspects based on hierarchical location. The new priority system takes precedence over hierarchical location, altering the invocation order of Aspects. Different priority classes were introduced: Aspects added by CDK APIs were classified as MUTATING (priority 200), while Aspects added directly by the user were classified as DEFAULT (priority 500) unless the user specified otherwise. As a result of this change, CDK apps that use a custom Aspect to assign a default permissions boundary and then use a built-in CDK method to override it on select resources could have unexpected permissions boundaries assigned. \n\nThe following is an affected code sample:\n\n```ts\nAspects.of(stack).add(new CustomAspectThatAssignsDefaultPermissionsBoundaries());   // {1}\n\nPermissionsBoundary.of(lambdaFunc).apply(...);  // {2} -- uses Aspects internally\n```\n\nIn versions prior to 2.172.0, the Aspect added by {2} would invoke last and assign its permissions boundary to the Lambda function role.\n\nIn versions 2.172.0 and after, the Aspect added by {2} would have priority 200 while the Aspect added by {1} would have priority 500 and therefore be invoked last. The Lambda function role would get the permissions boundary of {1} assigned, which may not be what users expect. \n\n### Impact\n\nIf an unexpected permissions boundary is selected for a role, it could lead to that role having insufficient permissions. Alternatively, this could lead to a role having wider permissions than intended; however, this could happen only in combination with an overly permissive role policy, as permissions boundaries do not grant permissions by themselves.\n\nImpacted versions: versions 2.172.0 up until 2.189.1\n\n### Patches\n\nIn version 2.189.1, the behavior has been reverted to the behavior of pre-2.172.0. The new behavior is available through a feature flag:\n\n```json\n{\n  \"context\": {\n    \"@aws-cdk/core:aspectPrioritiesMutating\": true\n  }\n}\n```\n\nThe patches are included in AWS CDK Library version 2.189.1 and after. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. \n\n### Workarounds\n\nAs a workaround, users can use the location hierarchy to order the invocation of Aspects. To do this, users can assign the custom Aspect a priority of MUTATING to ensure it has the same priority as the Aspect added by the CDK API, and that the location hierarchy is used for the order of invocation Aspects.\n\nThe following code is an example:\n\n```ts\nAspects.of(stack).add(new CustomAspectThatAssignsDefaultPermissionsBoundaries(), {\n  priority: AspectPriority.MUTATING,\n});\n```\n\n### References\n\nIf you have any questions or comments about this advisory, we ask that you contact AWS/Amazon Security via our [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.\n\n### Credit\n\nWe would like to thank GoDaddy for collaborating on this issue through the coordinated vulnerability disclosure process.",
  "id": "GHSA-qc59-cxj2-c2w4",
  "modified": "2025-04-15T14:48:49Z",
  "published": "2025-04-15T14:48:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-cdk/security/advisories/GHSA-qc59-cxj2-c2w4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-cdk/commit/b7f4bc7aee1d99b70e4d9d3cedea53e910ee37ef"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aws/aws-cdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-cdk/releases/tag/v2.189.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "aws-cdk-lib\u0027s aspect order change causes different Permissions Boundary assigned to Role"
}

GHSA-QV8F-7M6R-V8HP

Vulnerability from github – Published: 2024-12-06 18:30 – Updated: 2024-12-06 18:30
VLAI
Details

A local low-level user on the server machine with credentials to the running OAS services can create and execute a report with an rdlx file on the server system itself. Any code within the rdlx file of the report executes with SYSTEM privileges, resulting in privilege escalation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-11220"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-279",
      "CWE-732"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-06T18:15:22Z",
    "severity": "HIGH"
  },
  "details": "A local low-level user on the server machine with credentials to the running OAS services can create and execute a report with an rdlx file on the server system itself. Any code within the rdlx file of the report executes with SYSTEM privileges, resulting in privilege escalation.",
  "id": "GHSA-qv8f-7m6r-v8hp",
  "modified": "2024-12-06T18:30:46Z",
  "published": "2024-12-06T18:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11220"
    },
    {
      "type": "WEB",
      "url": "https://openautomationsoftware.com/downloads"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-24-338-03"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-RX8M-JV6M-48MJ

Vulnerability from github – Published: 2025-05-13 21:30 – Updated: 2025-05-13 21:30
VLAI
Details

Incorrect execution-assigned permissions for some Edge Orchestrator software for Intel(R) Tiber™ Edge Platform may allow an authenticated user to potentially enable escalation of privilege via adjacent access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-23233"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-279"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-13T21:16:10Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect execution-assigned permissions for some Edge Orchestrator software for Intel(R) Tiber\u2122 Edge Platform may allow an authenticated user to potentially enable escalation of privilege via adjacent access.",
  "id": "GHSA-rx8m-jv6m-48mj",
  "modified": "2025-05-13T21:30:57Z",
  "published": "2025-05-13T21:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23233"
    },
    {
      "type": "WEB",
      "url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01239.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-VC5P-J8VW-MC6X

Vulnerability from github – Published: 2021-08-25 21:01 – Updated: 2023-04-03 19:40
VLAI
Summary
Permissions bypass in pleaser
Details

Failure to normalize the umask in pleaser before 0.4.0 allows a local attacker to gain full root privileges if they are allowed to execute at least one command.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "pleaser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-31155"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-279"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-06-01T19:29:53Z",
    "nvd_published_at": "2021-05-27T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "Failure to normalize the umask in pleaser before 0.4.0 allows a local attacker to gain full root privileges if they are allowed to execute at least one command.",
  "id": "GHSA-vc5p-j8vw-mc6x",
  "modified": "2023-04-03T19:40:38Z",
  "published": "2021-08-25T21:01:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31155"
    },
    {
      "type": "WEB",
      "url": "https://crates.io/crates/pleaser"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/edneville/please"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/edneville/please/-/tree/master/src/bin"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2021-0101.html"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2021/05/18/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Permissions bypass in pleaser"
}

GHSA-WXJ9-7P6Q-955H

Vulnerability from github – Published: 2024-06-27 00:31 – Updated: 2024-07-03 18:47
VLAI
Details

An issue in OpenEMR 7.0.2 allows a remote attacker to escalate privileges viaa crafted POST request using the noteid parameter.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-37734"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-279"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-26T22:15:10Z",
    "severity": "CRITICAL"
  },
  "details": "An issue in OpenEMR 7.0.2 allows a remote attacker to escalate privileges viaa crafted POST request using the noteid parameter.",
  "id": "GHSA-wxj9-7p6q-955h",
  "modified": "2024-07-03T18:47:04Z",
  "published": "2024-06-27T00:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37734"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openemr/openemr/pull/7435#event-12872646667"
    },
    {
      "type": "WEB",
      "url": "https://github.com/A3h1nt/CVEs/tree/main/OpenEMR"
    }
  ],
  "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"
    }
  ]
}

Mitigation MIT-1
Architecture and Design Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Mitigation MIT-46
Architecture and Design

Strategy: Separation of Privilege

  • Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
  • Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CAPEC-81: Web Server Logs Tampering

Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs typically for the purposes of masking other malicious behavior. Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern. This pattern of attack is similar to "Log Injection-Tampering-Forging" except that in this case, the attack is targeting the logs of the web server and not the application.