CWE-502
AllowedDeserialization of Untrusted Data
Abstraction: Base · Status: Draft
The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.
4797 vulnerabilities reference this CWE, most recent first.
GHSA-35QX-QJJJ-9PFH
Vulnerability from github – Published: 2025-08-22 18:31 – Updated: 2025-08-22 21:31OperaMasks SDK ELite Script Engine v0.5.0 was discovered to contain a deserialization vulnerability.
{
"affected": [],
"aliases": [
"CVE-2025-52287"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-22T18:15:35Z",
"severity": "HIGH"
},
"details": "OperaMasks SDK ELite Script Engine v0.5.0 was discovered to contain a deserialization vulnerability.",
"id": "GHSA-35qx-qjjj-9pfh",
"modified": "2025-08-22T21:31:15Z",
"published": "2025-08-22T18:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52287"
},
{
"type": "WEB",
"url": "https://gist.github.com/ChangeYourWay/5bf54a234611f14fba1af03ad91e62f8"
},
{
"type": "WEB",
"url": "https://github.com/ChangeYourWay/post/blob/main/ELite"
}
],
"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-3644-Q5CJ-C5C7
Vulnerability from github – Published: 2026-05-13 15:29 – Updated: 2026-06-08 23:54Description
The LangSmith SDK's prompt pull methods (pull_prompt / pull_prompt_commit in Python, pullPrompt / pullPromptCommit in JS/TS) fetch and deserialize prompt manifests from the LangSmith Hub. These manifests may contain serialized LangChain objects and model configuration that affect runtime behavior. When pulling a public prompt by owner/name identifier, the manifest content is controlled by an external party, but prior versions of the SDK did not distinguish this from pulling a prompt within the caller's own organization.
Prompt manifests can intentionally configure a model with a custom base URL, default headers, model name, or other constructor arguments. These are supported features, but they also mean the prompt contents should be treated as executable configuration rather than plain text. A prompt can also include serialized LangChain Runnable or PromptTemplate objects with attacker-controlled constructor kwargs, or secret references that, if secrets_from_env is enabled, read environment variables at deserialization time.
Applications are exposed when all of the following are true:
- The application calls
pull_promptorpull_prompt_commit(Python) orpullPromptorpullPromptCommit(JS/TS) with a publicowner/nameprompt identifier. - The prompt was published or modified by an untrusted or compromised account.
- The application uses the pulled prompt without independently validating its contents.
Applications that only pull prompts from their own organization (referenced by name only, without an owner/ prefix) are not affected by the public prompt trust boundary issue described above. However, same-organization prompts carry their own risk. If an attacker gains write access to the organization (for example, through a leaked LANGSMITH_API_KEY or a compromised team member account), they can push a malicious prompt that is pulled and deserialized without any additional warning.
Impact
An attacker who publishes a malicious prompt to LangSmith Hub may be able to affect applications that pull that prompt by owner/name. If the prompt manifest reaches the SDK's deserialization path, the SDK will instantiate the referenced LangChain objects with the attacker-supplied constructor arguments rather than treating the manifest as inert data.
Realistic impacts include:
- Server-side request forgery (SSRF), outbound request redirection, and interception of LLM traffic if a prompt manifest configures an LLM client with an attacker-controlled
base_url, proxy, or equivalent endpoint-setting parameter. In typical deployments, redirected requests may include prompt contents, system prompts, retrieved context, model parameters, provider credentials, or other secrets and may disclose them to the attacker-controlled endpoint. - Prompt injection or behavior manipulation if a manifest embeds attacker-controlled system messages, prompt templates, or model parameters that alter the application's behavior.
- Additional deserialization risk when
include_model=Trueis passed, because this expands the allowlist to partner integration classes. This is not the default, but it materially increases risk when pulling prompts from outside the caller's organization.
Remediation
The LangSmith SDK now blocks pulling public prompts by owner/name by default. Callers must explicitly opt in by passing dangerously_pull_public_prompt=True (Python) or dangerouslyPullPublicPrompt: true (JS/TS) to acknowledge the trust boundary. This flag should only be set after reviewing and trusting the prompt contents, not merely the publishing account.
Upgrade to LangSmith SDK Python >= 0.8.0 or JS/TS >= 0.6.0.
Guidance for prompt pull methods
The prompt pull methods (pull_prompt / pull_prompt_commit in Python, pullPrompt / pullPromptCommit in JS/TS) should be used only with trusted prompts. Do not pull public prompts by owner/name from untrusted or unreviewed sources without understanding that the manifest contents will be deserialized and may affect runtime behavior.
When pulling prompts that include model configuration (include_model=True in Python, includeModel: true in JS/TS), the deserialization allowlist expands to include partner integration classes. Because this mode is not the default and is often unnecessary for third-party prompts, prefer the default (false) when pulling prompts from sources outside your organization.
Avoid passing secrets_from_env=True (Python) when pulling untrusted prompts. This parameter allows prompt manifests to read environment variables during deserialization. Only use it with trusted prompts from your own organization.
Same-organization prompts
Prompts pulled from the caller's own organization (referenced by name only, without an owner/ prefix) are not gated by the new dangerously_pull_public_prompt flag, but they are not inherently safe. If an attacker gains write access to the organization (for example, through a leaked LANGSMITH_API_KEY or a compromised team member account), they can push a malicious prompt that redirects LLM traffic to attacker-controlled infrastructure and may disclose any credentials attached to those requests.
The security of same-organization prompts follows a shared responsibility model. The LangSmith SDK enforces trust boundaries for public prompts pulled from external accounts, but it cannot protect against compromised credentials or accounts within the caller's own organization. Securing API keys, managing team member access, and reviewing prompt contents before production deployment are the responsibility of the organization. Organizations should treat prompts as executable configuration and apply the same review and audit practices they would apply to application code.
Credits
First reported by @Moaaz-0x.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "langsmith"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "langsmith"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "langchain-classic"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "langchain"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.30"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45134"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-13T15:29:30Z",
"nvd_published_at": "2026-05-27T20:16:38Z",
"severity": "HIGH"
},
"details": "## Description\n\nThe LangSmith SDK\u0027s prompt pull methods (`pull_prompt` / `pull_prompt_commit` in Python, `pullPrompt` / `pullPromptCommit` in JS/TS) fetch and deserialize prompt manifests from the LangSmith Hub. These manifests may contain serialized LangChain objects and model configuration that affect runtime behavior. When pulling a public prompt by `owner/name` identifier, the manifest content is controlled by an external party, but prior versions of the SDK did not distinguish this from pulling a prompt within the caller\u0027s own organization.\n\nPrompt manifests can intentionally configure a model with a custom base URL, default headers, model name, or other constructor arguments. These are supported features, but they also mean the prompt contents should be treated as executable configuration rather than plain text. A prompt can also include serialized LangChain `Runnable` or `PromptTemplate` objects with attacker-controlled constructor kwargs, or secret references that, if `secrets_from_env` is enabled, read environment variables at deserialization time.\nApplications are exposed when all of the following are true:\n\n- The application calls `pull_prompt` or `pull_prompt_commit` (Python) or `pullPrompt` or `pullPromptCommit` (JS/TS) with a public `owner/name` prompt identifier.\n- The prompt was published or modified by an untrusted or compromised account.\n- The application uses the pulled prompt without independently validating its contents.\n\nApplications that only pull prompts from their own organization (referenced by name only, without an `owner/` prefix) are not affected by the public prompt trust boundary issue described above. However, same-organization prompts carry their own risk. If an attacker gains write access to the organization (for example, through a leaked `LANGSMITH_API_KEY` or a compromised team member account), they can push a malicious prompt that is pulled and deserialized without any additional warning.\n\n## Impact\n\nAn attacker who publishes a malicious prompt to LangSmith Hub may be able to affect applications that pull that prompt by `owner/name`. If the prompt manifest reaches the SDK\u0027s deserialization path, the SDK will instantiate the referenced LangChain objects with the attacker-supplied constructor arguments rather than treating the manifest as inert data.\n\nRealistic impacts include:\n\n- Server-side request forgery (SSRF), outbound request redirection, and interception of LLM traffic if a prompt manifest configures an LLM client with an attacker-controlled `base_url`, proxy, or equivalent endpoint-setting parameter. In typical deployments, redirected requests may include prompt contents, system prompts, retrieved context, model parameters, provider credentials, or other secrets and may disclose them to the attacker-controlled endpoint.\n- Prompt injection or behavior manipulation if a manifest embeds attacker-controlled system messages, prompt templates, or model parameters that alter the application\u0027s behavior.\n- Additional deserialization risk when `include_model=True` is passed, because this expands the allowlist to partner integration classes. This is not the default, but it materially increases risk when pulling prompts from outside the caller\u0027s organization.\n\n## Remediation\n\nThe LangSmith SDK now blocks pulling public prompts by `owner/name` by default. Callers must explicitly opt in by passing `dangerously_pull_public_prompt=True` (Python) or `dangerouslyPullPublicPrompt: true` (JS/TS) to acknowledge the trust boundary. This flag should only be set after reviewing and trusting the prompt contents, not merely the publishing account.\n\nUpgrade to LangSmith SDK **Python \u003e= 0.8.0** or **JS/TS \u003e= 0.6.0**.\n\n### Guidance for prompt pull methods\n\nThe prompt pull methods (`pull_prompt` / `pull_prompt_commit` in Python, `pullPrompt` / `pullPromptCommit` in JS/TS) should be used only with trusted prompts. Do not pull public prompts by `owner/name` from untrusted or unreviewed sources without understanding that the manifest contents will be deserialized and may affect runtime behavior.\n\nWhen pulling prompts that include model configuration (`include_model=True` in Python, `includeModel: true` in JS/TS), the deserialization allowlist expands to include partner integration classes. Because this mode is not the default and is often unnecessary for third-party prompts, prefer the default (`false`) when pulling prompts from sources outside your organization.\n\nAvoid passing `secrets_from_env=True` (Python) when pulling untrusted prompts. This parameter allows prompt manifests to read environment variables during deserialization. Only use it with trusted prompts from your own organization.\n\n### Same-organization prompts\n\nPrompts pulled from the caller\u0027s own organization (referenced by name only, without an `owner/` prefix) are not gated by the new `dangerously_pull_public_prompt` flag, but they are not inherently safe. If an attacker gains write access to the organization (for example, through a leaked `LANGSMITH_API_KEY` or a compromised team member account), they can push a malicious prompt that redirects LLM traffic to attacker-controlled infrastructure and may disclose any credentials attached to those requests.\n\nThe security of same-organization prompts follows a shared responsibility model. The LangSmith SDK enforces trust boundaries for public prompts pulled from external accounts, but it cannot protect against compromised credentials or accounts within the caller\u0027s own organization. Securing API keys, managing team member access, and reviewing prompt contents before production deployment are the responsibility of the organization. Organizations should treat prompts as executable configuration and apply the same review and audit practices they would apply to application code.\n\n## Credits\n\nFirst reported by @Moaaz-0x.",
"id": "GHSA-3644-q5cj-c5c7",
"modified": "2026-06-08T23:54:03Z",
"published": "2026-05-13T15:29:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/langchain-ai/langsmith-sdk/security/advisories/GHSA-3644-q5cj-c5c7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45134"
},
{
"type": "PACKAGE",
"url": "https://github.com/langchain-ai/langsmith-sdk"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "LangSmith SDK: Public prompt pull deserializes untrusted manifests without trust boundary warning"
}
GHSA-36FC-7WJG-MFVJ
Vulnerability from github – Published: 2026-05-27 16:57 – Updated: 2026-07-10 19:07GitHub Security Advisory Draft — GM-374
Summary
Multiple locations in Pimcore v11 call PHP's unserialize() on data from database columns and filesystem files without the allowed_classes restriction, enabling object injection if an attacker can control the serialized data source.
Severity
CVSS 3.1: 8.0 (High) — AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
Affected Component
- Package:
pimcore/pimcoreandpimcore/admin-ui-classic-bundle - Files:
lib/Tool/Authentication.php(line 82) — session token deserializationmodels/Site/Dao.php(line 68) — site domains from databasemodels/DataObject/ClassDefinition/CustomLayout/Dao.php(line 69) — layout definitions from databasemodels/Tool/TmpStore/Dao.php(line 64) — temporary store data from databasemodels/Asset/WebDAV/Service.php(line 36) — delete log from filesystemadmin-ui-classic-bundle/src/Helper/Dashboard.php(line 64) — dashboard config from filesystem
Description
Six locations in Pimcore core call unserialize() directly (bypassing Tool\Serialize) on data sourced from database columns or filesystem files without passing the allowed_classes parameter. This means any class available in the autoloader will be instantiated during deserialization.
If an attacker can write to the data source (e.g., via SQL injection targeting the tmp_store, sites, or custom_layouts tables, or via a file write vulnerability targeting the WebDAV delete log), they can inject serialized PHP gadget chains that execute arbitrary code when the data is deserialized.
This is related to but distinct from the Tool\Serialize::unserialize() issue — these calls bypass the wrapper entirely.
Impact
PHP object injection leading to Remote Code Execution when chained with a data source write vulnerability. Pimcore's dependency tree (Guzzle, Symfony, Monolog, Doctrine) provides numerous known gadget chains.
Proof of Concept
- Identify a writable data source (e.g.,
tmp_storetable via SQL injection, orwebdav-delete.datvia file write) - Write a serialized PHP gadget chain (e.g., Monolog
BufferHandlerchain from phpggc) - Trigger the deserialization (e.g., access a page that reads TmpStore, or trigger a WebDAV operation)
- The gadget chain executes with web server privileges
Suggested Fix
Add allowed_classes parameter to all unserialize() calls. Where no objects are needed, use ['allowed_classes' => false]. Consider migrating to JSON serialization for data that doesn't require object preservation.
// Example fix for Site/Dao.php:
$siteDomains = unserialize($site['domains'], ['allowed_classes' => false]);
// Example fix for TmpStore/Dao.php:
$item['data'] = unserialize($item['data'], ['allowed_classes' => false]);
References
- CWE-502: Deserialization of Untrusted Data
- OWASP Deserialization Cheat Sheet
- phpggc: PHP Generic Gadget Chains
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.3.6"
},
"package": {
"ecosystem": "Packagist",
"name": "pimcore/pimcore"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0-RC1"
},
{
"fixed": "12.3.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.5.16"
},
"package": {
"ecosystem": "Packagist",
"name": "pimcore/pimcore"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "11.5.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "pimcore/pimcore"
},
"ranges": [
{
"events": [
{
"introduced": "2026.1.0"
},
{
"fixed": "2026.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45162"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-27T16:57:04Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "# GitHub Security Advisory Draft \u2014 GM-374\n\n## Summary\nMultiple locations in Pimcore v11 call PHP\u0027s `unserialize()` on data from database columns and filesystem files without the `allowed_classes` restriction, enabling object injection if an attacker can control the serialized data source.\n\n## Severity\nCVSS 3.1: 8.0 (High) \u2014 AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H\n\n## Affected Component\n- **Package:** `pimcore/pimcore` and `pimcore/admin-ui-classic-bundle`\n- **Files:**\n - `lib/Tool/Authentication.php` (line 82) \u2014 session token deserialization\n - `models/Site/Dao.php` (line 68) \u2014 site domains from database\n - `models/DataObject/ClassDefinition/CustomLayout/Dao.php` (line 69) \u2014 layout definitions from database\n - `models/Tool/TmpStore/Dao.php` (line 64) \u2014 temporary store data from database\n - `models/Asset/WebDAV/Service.php` (line 36) \u2014 delete log from filesystem\n - `admin-ui-classic-bundle/src/Helper/Dashboard.php` (line 64) \u2014 dashboard config from filesystem\n\n## Description\nSix locations in Pimcore core call `unserialize()` directly (bypassing `Tool\\Serialize`) on data sourced from database columns or filesystem files without passing the `allowed_classes` parameter. This means any class available in the autoloader will be instantiated during deserialization.\n\nIf an attacker can write to the data source (e.g., via SQL injection targeting the `tmp_store`, `sites`, or `custom_layouts` tables, or via a file write vulnerability targeting the WebDAV delete log), they can inject serialized PHP gadget chains that execute arbitrary code when the data is deserialized.\n\nThis is related to but distinct from the `Tool\\Serialize::unserialize()` issue \u2014 these calls bypass the wrapper entirely.\n\n## Impact\nPHP object injection leading to Remote Code Execution when chained with a data source write vulnerability. Pimcore\u0027s dependency tree (Guzzle, Symfony, Monolog, Doctrine) provides numerous known gadget chains.\n\n## Proof of Concept\n1. Identify a writable data source (e.g., `tmp_store` table via SQL injection, or `webdav-delete.dat` via file write)\n2. Write a serialized PHP gadget chain (e.g., Monolog `BufferHandler` chain from phpggc)\n3. Trigger the deserialization (e.g., access a page that reads TmpStore, or trigger a WebDAV operation)\n4. The gadget chain executes with web server privileges\n\n## Suggested Fix\nAdd `allowed_classes` parameter to all `unserialize()` calls. Where no objects are needed, use `[\u0027allowed_classes\u0027 =\u003e false]`. Consider migrating to JSON serialization for data that doesn\u0027t require object preservation.\n\n```php\n// Example fix for Site/Dao.php:\n$siteDomains = unserialize($site[\u0027domains\u0027], [\u0027allowed_classes\u0027 =\u003e false]);\n\n// Example fix for TmpStore/Dao.php:\n$item[\u0027data\u0027] = unserialize($item[\u0027data\u0027], [\u0027allowed_classes\u0027 =\u003e false]);\n```\n\n## References\n- CWE-502: Deserialization of Untrusted Data\n- OWASP Deserialization Cheat Sheet\n- phpggc: PHP Generic Gadget Chains",
"id": "GHSA-36fc-7wjg-mfvj",
"modified": "2026-07-10T19:07:27Z",
"published": "2026-05-27T16:57:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pimcore/pimcore/security/advisories/GHSA-36fc-7wjg-mfvj"
},
{
"type": "WEB",
"url": "https://github.com/pimcore/pimcore/pull/19119"
},
{
"type": "WEB",
"url": "https://github.com/pimcore/pimcore/commit/4788bf3a3a7f2f760a8fe61e522565941e154e1e"
},
{
"type": "PACKAGE",
"url": "https://github.com/pimcore/pimcore"
},
{
"type": "WEB",
"url": "https://github.com/pimcore/pimcore/releases/tag/v12.3.7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Pimcore has Unsafe PHP Deserialization in Multiple Locations Without allowed_classes Restriction"
}
GHSA-36FQ-JGMW-4R9C
Vulnerability from github – Published: 2025-09-19 09:31 – Updated: 2026-05-29 20:50Arbitrary Code Execution in Keras
Keras versions prior to 3.11.0 allow for arbitrary code execution when loading a crafted .keras model archive, even when safe_mode=True.
The issue arises because the archive’s config.json is parsed before layer deserialization. This can invoke keras.config.enable_unsafe_deserialization(), effectively disabling safe mode from within the loading process itself. An attacker can place this call first in the archive and then include a Lambda layer whose function is deserialized from a pickle, leading to the execution of attacker-controlled Python code as soon as a victim loads the model file.
Exploitation requires a user to open an untrusted model; no additional privileges are needed. The fix in version 3.11.0 enforces safe-mode semantics before reading any user-controlled configuration and prevents the toggling of unsafe deserialization via the config file.
Affected versions: < 3.11.0 Patched version: 3.11.0
It is recommended to upgrade to version 3.11.0 or later and to avoid opening untrusted model files.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "keras"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-9906"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-19T17:16:44Z",
"nvd_published_at": "2025-09-19T09:15:36Z",
"severity": "HIGH"
},
"details": "### Arbitrary Code Execution in Keras\n\nKeras versions prior to 3.11.0 allow for arbitrary code execution when loading a crafted `.keras` model archive, even when `safe_mode=True`.\n\nThe issue arises because the archive\u2019s `config.json` is parsed before layer deserialization. This can invoke `keras.config.enable_unsafe_deserialization()`, effectively disabling safe mode from within the loading process itself. An attacker can place this call first in the archive and then include a `Lambda` layer whose function is deserialized from a pickle, leading to the execution of attacker-controlled Python code as soon as a victim loads the model file.\n\nExploitation requires a user to open an untrusted model; no additional privileges are needed. The fix in version 3.11.0 enforces safe-mode semantics *before* reading any user-controlled configuration and prevents the toggling of unsafe deserialization via the config file.\n\n**Affected versions:** \u003c 3.11.0\n**Patched version:** 3.11.0\n\nIt is recommended to upgrade to version 3.11.0 or later and to avoid opening untrusted model files.",
"id": "GHSA-36fq-jgmw-4r9c",
"modified": "2026-05-29T20:50:12Z",
"published": "2025-09-19T09:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9906"
},
{
"type": "WEB",
"url": "https://github.com/keras-team/keras/pull/21429"
},
{
"type": "WEB",
"url": "https://github.com/keras-team/keras/commit/713172ab56b864e59e2aa79b1a51b0e728bba858"
},
{
"type": "PACKAGE",
"url": "https://github.com/keras-team/keras"
},
{
"type": "WEB",
"url": "https://github.com/keras-team/keras/releases/tag/v3.11.0"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/keras/PYSEC-2025-76.yaml"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2025-9906"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Keras is vulnerable to Deserialization of Untrusted Data"
}
GHSA-36JX-769R-M5FX
Vulnerability from github – Published: 2025-10-22 15:31 – Updated: 2026-01-20 15:31Deserialization of Untrusted Data vulnerability in wpeverest Everest Forms - Frontend Listing everest-forms-frontend-listing allows Object Injection.This issue affects Everest Forms - Frontend Listing: from n/a through <= 1.0.5.
{
"affected": [],
"aliases": [
"CVE-2025-60210"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-22T15:15:58Z",
"severity": "MODERATE"
},
"details": "Deserialization of Untrusted Data vulnerability in wpeverest Everest Forms - Frontend Listing everest-forms-frontend-listing allows Object Injection.This issue affects Everest Forms - Frontend Listing: from n/a through \u003c= 1.0.5.",
"id": "GHSA-36jx-769r-m5fx",
"modified": "2026-01-20T15:31:30Z",
"published": "2025-10-22T15:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-60210"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/everest-forms-frontend-listing/vulnerability/wordpress-everest-forms-frontend-listing-plugin-1-0-5-php-object-injection-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/everest-forms-frontend-listing/vulnerability/wordpress-everest-forms-frontend-listing-plugin-1-0-5-php-object-injection-vulnerability"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/everest-forms-frontend-listing/vulnerability/wordpress-everest-forms-frontend-listing-plugin-1-0-5-php-object-injection-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-36M8-M5CM-HFHR
Vulnerability from github – Published: 2024-07-22 12:30 – Updated: 2024-07-22 12:30Deserialization of Untrusted Data vulnerability in WP MEDIA SAS Search & Replace.This issue affects Search & Replace: from n/a through 3.2.2.
{
"affected": [],
"aliases": [
"CVE-2024-38759"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-22T11:15:04Z",
"severity": "MODERATE"
},
"details": "Deserialization of Untrusted Data vulnerability in WP MEDIA SAS Search \u0026 Replace.This issue affects Search \u0026 Replace: from n/a through 3.2.2.",
"id": "GHSA-36m8-m5cm-hfhr",
"modified": "2024-07-22T12:30:38Z",
"published": "2024-07-22T12:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38759"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/search-and-replace/wordpress-search-replace-plugin-3-2-2-deserialization-of-untrusted-data-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-36M8-W8QF-G76P
Vulnerability from github – Published: 2026-05-18 12:31 – Updated: 2026-05-29 17:29SGLang's multimodal generation runtime is vulnerable to unauthenticated remote code execution when the --enable-custom-logit-processor option is enabled, as Python objects loaded via dill.loads() will be deserialized without validation.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "sglang"
},
"ranges": [
{
"events": [
{
"introduced": "0.4.1.post7"
},
{
"last_affected": "0.5.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-7304"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T17:29:23Z",
"nvd_published_at": "2026-05-18T12:16:16Z",
"severity": "CRITICAL"
},
"details": "SGLang\u0027s multimodal generation runtime is vulnerable to unauthenticated remote code execution when the --enable-custom-logit-processor option is enabled, as Python objects loaded via dill.loads() will be deserialized without validation.",
"id": "GHSA-36m8-w8qf-g76p",
"modified": "2026-05-29T17:29:23Z",
"published": "2026-05-18T12:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7304"
},
{
"type": "WEB",
"url": "https://antiproof.ai/blog/three-rces-in-sglang"
},
{
"type": "PACKAGE",
"url": "https://github.com/sgl-project/sglang"
},
{
"type": "WEB",
"url": "https://github.com/sgl-project/sglang/tree/main/python/sglang"
}
],
"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": "SGLang: Unauthenticated RCE via --enable-custom-logit-processor"
}
GHSA-36P2-8879-3C27
Vulnerability from github – Published: 2022-03-24 00:00 – Updated: 2022-03-30 00:01A deserialization vulnerability exists in how the LogService.rem service in Rockwell Automation FactoryTalk AssetCentre v10.00 and earlier verifies serialized data. This vulnerability may allow a remote, unauthenticated attacker to execute arbitrary commands in FactoryTalk AssetCentre.
{
"affected": [],
"aliases": [
"CVE-2021-27470"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-23T20:15:00Z",
"severity": "CRITICAL"
},
"details": "A deserialization vulnerability exists in how the LogService.rem service in Rockwell Automation FactoryTalk AssetCentre v10.00 and earlier verifies serialized data. This vulnerability may allow a remote, unauthenticated attacker to execute arbitrary commands in FactoryTalk AssetCentre.",
"id": "GHSA-36p2-8879-3c27",
"modified": "2022-03-30T00:01:02Z",
"published": "2022-03-24T00:00:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27470"
},
{
"type": "WEB",
"url": "https://idp.rockwellautomation.com/adfs/ls/idpinitiatedsignon.aspx?RelayState=RPID%3Drockwellautomation.custhelp.com%26RelayState%3Danswers%2Fanswer_view%2Fa_id%2F1130831"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/uscert/ics/advisories/icsa-21-091-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-36P7-PVQ8-JJMX
Vulnerability from github – Published: 2025-08-28 15:30 – Updated: 2026-04-01 18:36Deserialization of Untrusted Data vulnerability in emarket-design Employee Spotlight allows Object Injection. This issue affects Employee Spotlight: from n/a through 5.1.1.
{
"affected": [],
"aliases": [
"CVE-2025-53583"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-28T13:16:05Z",
"severity": "HIGH"
},
"details": "Deserialization of Untrusted Data vulnerability in emarket-design Employee Spotlight allows Object Injection. This issue affects Employee Spotlight: from n/a through 5.1.1.",
"id": "GHSA-36p7-pvq8-jjmx",
"modified": "2026-04-01T18:36:01Z",
"published": "2025-08-28T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53583"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/employee-spotlight/vulnerability/wordpress-employee-spotlight-plugin-5-1-1-php-object-injection-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-36VX-8X4W-9H2M
Vulnerability from github – Published: 2021-12-24 00:00 – Updated: 2022-01-08 00:01The HornetQ component of Artemis in EAP 7 was not updated with the fix for CVE-2016-4978. A remote attacker could use this flaw to execute arbitrary code with the permissions of the application using a JMS ObjectMessage.
{
"affected": [],
"aliases": [
"CVE-2021-20318"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-23T20:15:00Z",
"severity": "HIGH"
},
"details": "The HornetQ component of Artemis in EAP 7 was not updated with the fix for CVE-2016-4978. A remote attacker could use this flaw to execute arbitrary code with the permissions of the application using a JMS ObjectMessage.",
"id": "GHSA-36vx-8x4w-9h2m",
"modified": "2022-01-08T00:01:02Z",
"published": "2021-12-24T00:00:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20318"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2010559"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
Mitigation
When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
Mitigation
Explicitly define a final object() to prevent deserialization.
Mitigation
- Make fields transient to protect them from deserialization.
- An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.
Mitigation
Avoid having unnecessary types or gadgets (a sequence of instances and method invocations that can self-execute during the deserialization process, often found in libraries) available that can be leveraged for malicious ends. This limits the potential for unintended or unauthorized types and gadgets to be leveraged by the attacker. Add only acceptable classes to an allowlist. Note: new gadgets are constantly being discovered, so this alone is not a sufficient mitigation.
Mitigation
Employ cryptography of the data or code for protection. However, it's important to note that it would still be client-side security. This is risky because if the client is compromised then the security implemented on the client (the cryptography) can be bypassed.
Mitigation MIT-29
Strategy: Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
CAPEC-586: Object Injection
An adversary attempts to exploit an application by injecting additional, malicious content during its processing of serialized objects. Developers leverage serialization in order to convert data or state into a static, binary format for saving to disk or transferring over a network. These objects are then deserialized when needed to recover the data/state. By injecting a malformed object into a vulnerable application, an adversary can potentially compromise the application by manipulating the deserialization process. This can result in a number of unwanted outcomes, including remote code execution.