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.
4829 vulnerabilities reference this CWE, most recent first.
GHSA-JFH8-C2JP-5V3Q
Vulnerability from github – Published: 2021-12-10 00:40 – Updated: 2025-10-22 19:13Summary
Log4j versions prior to 2.16.0 are subject to a remote code execution vulnerability via the ldap JNDI parser. As per Apache's Log4j security guide: Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.16.0, this behavior has been disabled by default.
Log4j version 2.15.0 contained an earlier fix for the vulnerability, but that patch did not disable attacker-controlled JNDI lookups in all situations. For more information, see the Updated advice for version 2.16.0 section of this advisory.
Impact
Logging untrusted or user controlled data with a vulnerable version of Log4J may result in Remote Code Execution (RCE) against your application. This includes untrusted data included in logged errors such as exception traces, authentication failures, and other unexpected vectors of user controlled input.
Affected versions
Any Log4J version prior to v2.15.0 is affected to this specific issue.
The v1 branch of Log4J which is considered End Of Life (EOL) is vulnerable to other RCE vectors so the recommendation is to still update to 2.16.0 where possible.
Security releases
Additional backports of this fix have been made available in versions 2.3.1, 2.12.2, and 2.12.3
Affected packages
Only the org.apache.logging.log4j:log4j-core package is directly affected by this vulnerability. The org.apache.logging.log4j:log4j-api should be kept at the same version as the org.apache.logging.log4j:log4j-core package to ensure compatability if in use.
Remediation Advice
Updated advice for version 2.16.0
The Apache Logging Services team provided updated mitigation advice upon the release of version 2.16.0, which disables JNDI by default and completely removes support for message lookups. Even in version 2.15.0, lookups used in layouts to provide specific pieces of context information will still recursively resolve, possibly triggering JNDI lookups. This problem is being tracked as CVE-2021-45046. More information is available on the GitHub Security Advisory for CVE-2021-45046.
Users who want to avoid attacker-controlled JNDI lookups but cannot upgrade to 2.16.0 must ensure that no such lookups resolve to attacker-provided data and ensure that the the JndiLookup class is not loaded.
Please note that Log4J v1 is End Of Life (EOL) and will not receive patches for this issue. Log4J v1 is also vulnerable to other RCE vectors and we recommend you migrate to Log4J 2.16.0 where possible.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.logging.log4j:log4j-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.13.0"
},
{
"fixed": "2.15.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.logging.log4j:log4j-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.0-beta9"
},
{
"fixed": "2.3.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.logging.log4j:log4j-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.4"
},
{
"fixed": "2.12.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.guicedee.services:log4j-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.2.1.2-jre17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xbib.elasticsearch:log4j"
},
"versions": [
"6.3.2.1"
]
},
{
"package": {
"ecosystem": "Maven",
"name": "uk.co.nichesolutions.logging.log4j:log4j-core"
},
"versions": [
"2.6.3-CUSTOM"
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.ops4j.pax.logging:pax-logging-log4j2"
},
"ranges": [
{
"events": [
{
"introduced": "1.8.0"
},
{
"fixed": "1.9.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.ops4j.pax.logging:pax-logging-log4j2"
},
"ranges": [
{
"events": [
{
"introduced": "1.10.0"
},
{
"fixed": "1.10.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.ops4j.pax.logging:pax-logging-log4j2"
},
"ranges": [
{
"events": [
{
"introduced": "1.11.0"
},
{
"fixed": "1.11.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.ops4j.pax.logging:pax-logging-log4j2"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-44228"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400",
"CWE-502",
"CWE-917"
],
"github_reviewed": true,
"github_reviewed_at": "2021-12-10T00:40:41Z",
"nvd_published_at": "2021-12-10T10:15:00Z",
"severity": "CRITICAL"
},
"details": "# Summary\n\nLog4j versions prior to 2.16.0 are subject to a remote code execution vulnerability via the ldap JNDI parser.\nAs per [Apache\u0027s Log4j security guide](https://logging.apache.org/log4j/2.x/security.html): Apache Log4j2 \u003c=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.16.0, this behavior has been disabled by default.\n\nLog4j version 2.15.0 contained an earlier fix for the vulnerability, but that patch did not disable attacker-controlled JNDI lookups in all situations. For more information, see the `Updated advice for version 2.16.0` section of this advisory.\n\n# Impact\n\nLogging untrusted or user controlled data with a vulnerable version of Log4J may result in Remote Code Execution (RCE) against your application. This includes untrusted data included in logged errors such as exception traces, authentication failures, and other unexpected vectors of user controlled input. \n\n# Affected versions\n\nAny Log4J version prior to v2.15.0 is affected to this specific issue.\n\nThe v1 branch of Log4J which is considered End Of Life (EOL) is vulnerable to other RCE vectors so the recommendation is to still update to 2.16.0 where possible.\n\n## Security releases\nAdditional backports of this fix have been made available in versions 2.3.1, 2.12.2, and 2.12.3\n\n## Affected packages\nOnly the `org.apache.logging.log4j:log4j-core` package is directly affected by this vulnerability. The `org.apache.logging.log4j:log4j-api` should be kept at the same version as the `org.apache.logging.log4j:log4j-core` package to ensure compatability if in use.\n\n# Remediation Advice\n\n## Updated advice for version 2.16.0\n\nThe Apache Logging Services team provided updated mitigation advice upon the release of version 2.16.0, which [disables JNDI by default and completely removes support for message lookups](https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0).\nEven in version 2.15.0, lookups used in layouts to provide specific pieces of context information will still recursively resolve, possibly triggering JNDI lookups. This problem is being tracked as [CVE-2021-45046](https://nvd.nist.gov/vuln/detail/CVE-2021-45046). More information is available on the [GitHub Security Advisory for CVE-2021-45046](https://github.com/advisories/GHSA-7rjr-3q55-vv33).\n\nUsers who want to avoid attacker-controlled JNDI lookups but cannot upgrade to 2.16.0 must [ensure that no such lookups resolve to attacker-provided data and ensure that the the JndiLookup class is not loaded](https://issues.apache.org/jira/browse/LOG4J2-3221).\n\nPlease note that Log4J v1 is End Of Life (EOL) and will not receive patches for this issue. Log4J v1 is also vulnerable to other RCE vectors and we recommend you migrate to Log4J 2.16.0 where possible.",
"id": "GHSA-jfh8-c2jp-5v3q",
"modified": "2025-10-22T19:13:24Z",
"published": "2021-12-10T00:40:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44228"
},
{
"type": "WEB",
"url": "https://github.com/apache/logging-log4j2/pull/608"
},
{
"type": "WEB",
"url": "https://github.com/github/advisory-database/pull/5501"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-397453.pdf"
},
{
"type": "WEB",
"url": "https://packetstormsecurity.com/files/165673/UniFi-Network-Application-Unauthenticated-Log4Shell-Remote-Code-Execution.html"
},
{
"type": "WEB",
"url": "https://packetstormsecurity.com/files/167794/Open-Xchange-App-Suite-7.10.x-Cross-Site-Scripting-Command-Injection.html"
},
{
"type": "WEB",
"url": "https://packetstormsecurity.com/files/167917/MobileIron-Log4Shell-Remote-Command-Execution.html"
},
{
"type": "WEB",
"url": "https://packetstormsecurity.com/files/171626/AD-Manager-Plus-7122-Remote-Code-Execution.html"
},
{
"type": "WEB",
"url": "https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0032"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd"
},
{
"type": "WEB",
"url": "https://seclists.org/fulldisclosure/2022/Dec/2"
},
{
"type": "WEB",
"url": "https://seclists.org/fulldisclosure/2022/Jul/11"
},
{
"type": "WEB",
"url": "https://seclists.org/fulldisclosure/2022/Mar/23"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20211210-0007"
},
{
"type": "WEB",
"url": "https://support.apple.com/kb/HT213189"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd"
},
{
"type": "WEB",
"url": "https://twitter.com/kurtseifried/status/1469345530182455296"
},
{
"type": "WEB",
"url": "https://www.bentley.com/en/common-vulnerability-exposure/be-2022-0001"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-44228"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-5020"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00646.html"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/930724"
},
{
"type": "WEB",
"url": "https://www.nu11secur1ty.com/2021/12/cve-2021-44228.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/alert-cve-2021-44228.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-479842.pdf"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-661247.pdf"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-714170.pdf"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-7rjr-3q55-vv33"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/logging-log4j2"
},
{
"type": "WEB",
"url": "https://github.com/cisagov/log4j-affected-db"
},
{
"type": "WEB",
"url": "https://github.com/cisagov/log4j-affected-db/blob/develop/SOFTWARE-LIST.md"
},
{
"type": "WEB",
"url": "https://github.com/nu11secur1ty/CVE-mitre/tree/main/CVE-2021-44228"
},
{
"type": "WEB",
"url": "https://github.com/tangxiaofeng7/apache-log4j-poc"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/LOG4J2-3198"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/LOG4J2-3201"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/LOG4J2-3214"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/LOG4J2-3221"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/12/msg00007.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/M5CSVUNV4HWZZXGOKNSK6L7RPM7BOKIB"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VU57UJDCFIASIO35GC55JMKSRXJMCDFM"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/M5CSVUNV4HWZZXGOKNSK6L7RPM7BOKIB"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VU57UJDCFIASIO35GC55JMKSRXJMCDFM"
},
{
"type": "WEB",
"url": "https://logging.apache.org/log4j/2.x/changes-report.html#a2.15.0"
},
{
"type": "WEB",
"url": "https://logging.apache.org/log4j/2.x/manual/lookups.html#JndiLookup"
},
{
"type": "WEB",
"url": "https://logging.apache.org/log4j/2.x/manual/migration.html"
},
{
"type": "WEB",
"url": "https://logging.apache.org/log4j/2.x/security.html"
},
{
"type": "WEB",
"url": "https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/165225/Apache-Log4j2-2.14.1-Remote-Code-Execution.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/165260/VMware-Security-Advisory-2021-0028.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/165261/Apache-Log4j2-2.14.1-Information-Disclosure.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/165270/Apache-Log4j2-2.14.1-Remote-Code-Execution.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/165281/Log4j2-Log4Shell-Regexes.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/165282/Log4j-Payload-Generator.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/165306/L4sh-Log4j-Remote-Code-Execution.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/165307/Log4j-Remote-Code-Execution-Word-Bypassing.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/165311/log4j-scan-Extensive-Scanner.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/165371/VMware-Security-Advisory-2021-0028.4.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/165532/Log4Shell-HTTP-Header-Injection.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/165642/VMware-vCenter-Server-Unauthenticated-Log4Shell-JNDI-Injection-Remote-Code-Execution.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/165673/UniFi-Network-Application-Unauthenticated-Log4Shell-Remote-Code-Execution.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/167794/Open-Xchange-App-Suite-7.10.x-Cross-Site-Scripting-Command-Injection.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/167917/MobileIron-Log4Shell-Remote-Command-Execution.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/171626/AD-Manager-Plus-7122-Remote-Code-Execution.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2022/Dec/2"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2022/Jul/11"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2022/Mar/23"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/12/10/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/12/10/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/12/10/3"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/12/13/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/12/13/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/12/14/4"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/12/15/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:H",
"type": "CVSS_V3"
}
],
"summary": "Remote code injection in Log4j"
}
GHSA-JFH9-JWF2-W35R
Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2022-05-13 01:38The PHP form code generated by PHP FormMail Generator deserializes untrusted input as part of the phpfmg_filman_download() function. A remote unauthenticated attacker may be able to use this vulnerability to inject PHP code, or along with CVE-2016-9484 to perform local file inclusion attacks and obtain files from the server.
{
"affected": [],
"aliases": [
"CVE-2016-9483"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-13T20:29:00Z",
"severity": "CRITICAL"
},
"details": "The PHP form code generated by PHP FormMail Generator deserializes untrusted input as part of the phpfmg_filman_download() function. A remote unauthenticated attacker may be able to use this vulnerability to inject PHP code, or along with CVE-2016-9484 to perform local file inclusion attacks and obtain files from the server.",
"id": "GHSA-jfh9-jwf2-w35r",
"modified": "2022-05-13T01:38:31Z",
"published": "2022-05-13T01:38:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9483"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/494015"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/94778"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JFVP-PW77-78H3
Vulnerability from github – Published: 2026-05-14 06:31 – Updated: 2026-05-14 06:31GitLab has remediated an issue in GitLab EE affecting all versions from 11.9 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an unauthenticated user to cause denial of service by uploading a specially crafted file due to improper validation.
{
"affected": [],
"aliases": [
"CVE-2026-1184"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-14T06:16:21Z",
"severity": "MODERATE"
},
"details": "GitLab has remediated an issue in GitLab EE affecting all versions from 11.9 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an unauthenticated user to cause denial of service by uploading a specially crafted file due to improper validation.",
"id": "GHSA-jfvp-pw77-78h3",
"modified": "2026-05-14T06:31:33Z",
"published": "2026-05-14T06:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1184"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3515842"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/releases/2026/05/13/patch-release-gitlab-18-11-3-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/work_items/586634"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JG22-MG44-37J8
Vulnerability from github – Published: 2026-06-03 20:56 – Updated: 2026-06-03 20:56Summary
Using CookieJar.load() with untrusted input may allow arbitrary code execution.
Impact
Most applications using this function will be doing so with the user's own data, so this is unlikely to affect many applications.
Workaround
If an application does allow attacker controlled files to be loaded, a workaround on older releases would be to sanitise the files before loading.
Patch: https://github.com/aio-libs/aiohttp/commit/dcf40f30637e8752c76781cf6703b5a236749a00
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "aiohttp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.14.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34993"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-03T20:56:54Z",
"nvd_published_at": "2026-06-02T20:16:34Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nUsing ``CookieJar.load()`` with untrusted input may allow arbitrary code execution.\n\n### Impact\n\nMost applications using this function will be doing so with the user\u0027s own data, so this is unlikely to affect many applications.\n\n### Workaround\n\nIf an application does allow attacker controlled files to be loaded, a workaround on older releases would be to sanitise the files before loading.\n\n-----\n\nPatch: https://github.com/aio-libs/aiohttp/commit/dcf40f30637e8752c76781cf6703b5a236749a00",
"id": "GHSA-jg22-mg44-37j8",
"modified": "2026-06-03T20:56:54Z",
"published": "2026-06-03T20:56:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/security/advisories/GHSA-jg22-mg44-37j8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34993"
},
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/commit/dcf40f30637e8752c76781cf6703b5a236749a00"
},
{
"type": "PACKAGE",
"url": "https://github.com/aio-libs/aiohttp"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:C/C:L/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "AIOHTTP is Vulnerable to Deserialization of Untrusted Data"
}
GHSA-JG6F-48FF-5XRW
Vulnerability from github – Published: 2025-02-28 17:46 – Updated: 2025-02-28 17:46Name: ASA-2025-004: Non-deterministic JSON Unmarshalling of IBC Acknowledgement can result in a chain halt Component: IBC-Go Criticality: Critical (Considerable Impact; Almost Certain Likelihood per ACMv1.2) Affected versions: IBC-Go >= v7; Earlier IBC-Go versions may also be affected. Affected users: Validators, Full nodes, IBC Middleware authors
Description
An issue was discovered in IBC-Go's deserialization of acknowledgements that results in non-deterministic behavior which can halt a chain. Any user that can open an IBC channel can introduce this state to the chain
Patches
The new IBC-Go releases below address this issue:
Workarounds
To prevent this state from being introduced to a chain, it is possible to permission Channel Opening as a workaround.
Notes on Re-Release
Is this state breaking? Probably not but it depends on your transfer middlewares
This patch is not state breaking unless you depend on transfer middlewares that deserialize and serialize acknowledgement packets before passing them to the transfer handler. As far as we can tell, these middlewares are rare. For example, packet-forward-middleware and ibc-hooks, do not serialize ack packets in this way and therefore aren't broken by this patch. So if these are the only transfer middlewares you depend on, you can safely apply this patch in a rolling manner (and we've already cut new versions of these for you).
What to do if you do depend on ack-serializing middleware
In the unlikely case that you depend on middlewares that serialize ack packets and you do not update them when you apply this patch, all transfers that are handled by the middleware will fail (or experience other unexpected behavior) if the serialization approach differs from the transfer app's. If you have such dependencies and do not update them, validators who apply the patch in a rolling manner will halt when they upgrade, and transfers processed by the middleware will just fail once everyone has upgraded.
To update these middlewares and avoid failing transfers or a chain halt, you will simply need to change the serialization approach in the middleware to use ibc-go's codec: transfertypes.ModuleCdc.[Must]MarshalJSON, rather than whatever you're doing today. For example:
import transfertypes "github.com/cosmos/ibc-go/v10/modules/apps/transfer/types"
transfertypes.ModuleCdc.[Must]MarshalJSON
func MarshalAsIBCDoes(ack channeltypes.Acknowledgement) ([]byte, error) {
return transfertypes.ModuleCdc.MarshalJSON(&ack)
}
When you do make a change to the serialization approach, this will make the patch state breaking and you will need a coordinated upgrade. So for absolute clarity: chains with these ack-serializing middlewares must do coordinated upgrades
Why we retracted the earlier patch in favor of this approach
We retracted the releases of ibc-go we cut earlier today because these broke all transfer middlewares that deserialized then re-serialized receive packets differently than the transfer app. It turned out that this was a common pattern (unlike serializing/deserializing ack packets), so widely used middlewares, including packet-forward-middleware, broke unexpectedly.
In the new set of patches, we removed this constraint on how middlewares serialize receive packets, preventing this breakage. Only the serialization requirement on acknowledgement packets remains. This is convenient because this is the only constraint we had to add to fix the vulnerability, and middlewares that deserialize and serialize ack packets are much less common than ones that do so for receive packets. The constraint on receive packets was added for defense in depth.
Testing we have done to gain more confidence in this release
- In addition to testing ibc-go, we also did the following:
- Tested pfm v7 and v8 after bumping dependencies
- Tested ibc-hooks v7 and v8 after bumping dependencies
- Ran a patched node on mainnet on the cosmos hub and triggered failing and successful transactions that used PFM
- Ran a patched node on osmosis and triggered failing and successful transactions that used ibc-hooks This is a more thorough process than before, so we have higher confidence.
Timeline
- February 18, 2025, 4:54am PST: Issue reported to the Cosmos Bug Bounty program
- February 18, 2025, 6:56am PST: Issue triaged by Amulet on-call, and distributed to Core team
- February 18, 2025, 8:15am PST: Core team completes validation of issue
- February 25, 2025, 8:00am PST / 17:00 CET: Pre-notification delivered
- February 27, 2025, 8:00am PST / 17:00 CET: Patch made available
- February 27, 2025, 1:00pm PST: Patch re-release made available
This issue was reported to the Cosmos Bug Bounty Program by swelf19 on HackerOne on February 18, 2025. If you believe you have found a bug in the Interchain Stack or would like to contribute to the program by reporting a bug, please see https://hackerone.com/cosmos.
If you have questions about Interchain security efforts, please reach out to our official communication channel at security@interchain.io. For more information about the Interchain Foundation’s engagement with Amulet, and to sign up for security notification emails, please see https://github.com/interchainio/security.
A Github Security Advisory for this issue is available in the IBC-Go repository.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c 7.9.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/cosmos/ibc-go"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 7.9.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/cosmos/ibc-go/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 7.9.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/cosmos/ibc-go/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 7.9.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/cosmos/ibc-go/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 7.9.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/cosmos/ibc-go/v5"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 7.9.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/cosmos/ibc-go/v6"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/cosmos/ibc-go/v7"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.9.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/cosmos/ibc-go/v8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2025-02-28T17:46:04Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "Name: ASA-2025-004: Non-deterministic JSON Unmarshalling of IBC Acknowledgement can result in a chain halt\nComponent: IBC-Go\nCriticality: Critical (Considerable Impact; Almost Certain Likelihood per [ACMv1.2](https://github.com/interchainio/security/blob/main/resources/CLASSIFICATION_MATRIX.md))\nAffected versions: IBC-Go \u003e= v7; Earlier IBC-Go versions may also be affected.\nAffected users: Validators, Full nodes, IBC Middleware authors\n\n### Description\n\nAn issue was discovered in IBC-Go\u0027s deserialization of acknowledgements that results in non-deterministic behavior which can halt a chain. Any user that can open an IBC channel can introduce this state to the chain\n\n### Patches\n\nThe new IBC-Go releases below address this issue:\n\n* [v7.9.2](https://github.com/cosmos/ibc-go/releases/tag/v7.9.2)\n* [v8.6.1](https://github.com/cosmos/ibc-go/releases/tag/v8.6.1)\n\n### Workarounds\n\nTo prevent this state from being introduced to a chain, it is possible to permission Channel Opening as a workaround.\n\n### Notes on Re-Release\n\n#### Is this state breaking? Probably not but it depends on your transfer middlewares\n\nThis patch is not state breaking unless you depend on transfer middlewares that deserialize and serialize acknowledgement packets before passing them to the transfer handler. As far as we can tell, these middlewares are rare. For example, packet-forward-middleware and ibc-hooks, do not serialize ack packets in this way and therefore aren\u0027t broken by this patch. So if these are the only transfer middlewares you depend on, you can safely apply this patch in a rolling manner (and we\u0027ve already cut new versions of these for you).\n\n#### What to do if you do depend on ack-serializing middleware\n\nIn the unlikely case that you depend on middlewares that serialize ack packets and you do not update them when you apply this patch, all transfers that are handled by the middleware will fail (or experience other unexpected behavior) if the serialization approach differs from the transfer app\u0027s. If you have such dependencies and do not update them, validators who apply the patch in a rolling manner will halt when they upgrade, and transfers processed by the middleware will just fail once everyone has upgraded.\n\nTo update these middlewares and avoid failing transfers or a chain halt, you will simply need to change the serialization approach in the middleware to use ibc-go\u0027s codec: `transfertypes.ModuleCdc.[Must]MarshalJSON`, rather than whatever you\u0027re doing today. For example:\n\n```\nimport transfertypes \"github.com/cosmos/ibc-go/v10/modules/apps/transfer/types\"\ntransfertypes.ModuleCdc.[Must]MarshalJSON\nfunc MarshalAsIBCDoes(ack channeltypes.Acknowledgement) ([]byte, error) {\n\treturn transfertypes.ModuleCdc.MarshalJSON(\u0026ack)\n}\n```\nWhen you do make a change to the serialization approach, this will make the patch state breaking and you will need a coordinated upgrade. So for absolute clarity: chains with these ack-serializing middlewares must do coordinated upgrades\n\n#### Why we retracted the earlier patch in favor of this approach\nWe retracted the releases of ibc-go we cut earlier today because these broke all transfer middlewares that deserialized then re-serialized receive packets differently than the transfer app. It turned out that this was a common pattern (unlike serializing/deserializing ack packets), so widely used middlewares, including packet-forward-middleware, broke unexpectedly.\n\nIn the new set of patches, we removed this constraint on how middlewares serialize receive packets, preventing this breakage. Only the serialization requirement on acknowledgement packets remains. This is convenient because this is the only constraint we had to add to fix the vulnerability, and middlewares that deserialize and serialize ack packets are much less common than ones that do so for receive packets. The constraint on receive packets was added for defense in depth.\n\n#### Testing we have done to gain more confidence in this release\n* In addition to testing ibc-go, we also did the following:\n* Tested pfm v7 and v8 after bumping dependencies\n* Tested ibc-hooks v7 and v8 after bumping dependencies\n* Ran a patched node on mainnet on the cosmos hub and triggered failing and successful transactions that used PFM\n* Ran a patched node on osmosis and triggered failing and successful transactions that used ibc-hooks\nThis is a more thorough process than before, so we have higher confidence.\n\n### Timeline\n\n* February 18, 2025, 4:54am PST: Issue reported to the Cosmos Bug Bounty program\n* February 18, 2025, 6:56am PST: Issue triaged by Amulet on-call, and distributed to Core team\n* February 18, 2025, 8:15am PST: Core team completes validation of issue\n* February 25, 2025, 8:00am PST / 17:00 CET: Pre-notification delivered\n* February 27, 2025, 8:00am PST / 17:00 CET: Patch made available\n* February 27, 2025, 1:00pm PST: Patch re-release made available\n\nThis issue was reported to the Cosmos Bug Bounty Program by swelf19 on HackerOne on February 18, 2025. If you believe you have found a bug in the Interchain Stack or would like to contribute to the program by reporting a bug, please see https://hackerone.com/cosmos.\n\nIf you have questions about Interchain security efforts, please reach out to our official communication channel at [security@interchain.io](mailto:security@interchain.io). For more information about the Interchain Foundation\u2019s engagement with Amulet, and to sign up for security notification emails, please see https://github.com/interchainio/security. \n\nA Github Security Advisory for this issue is available in the IBC-Go [repository](https://github.com/cosmos/ibc-go/security/advisories/GHSA-jg6f-48ff-5xrw).",
"id": "GHSA-jg6f-48ff-5xrw",
"modified": "2025-02-28T17:46:04Z",
"published": "2025-02-28T17:46:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cosmos/ibc-go/security/advisories/GHSA-jg6f-48ff-5xrw"
},
{
"type": "WEB",
"url": "https://github.com/cosmos/ibc-go/commit/59987d52d959dc5876ffd4f307c9b33a52a43748"
},
{
"type": "WEB",
"url": "https://github.com/cosmos/ibc-go/commit/9869b3c6f7eb05a935b1eb33611c5406f68438a5"
},
{
"type": "PACKAGE",
"url": "https://github.com/cosmos/ibc-go"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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",
"type": "CVSS_V4"
}
],
"summary": "IBC-Go has Non-deterministic JSON Unmarshalling of IBC Acknowledgement"
}
GHSA-JGCW-5VW9-7W3C
Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-05-24 19:15An issue was discovered in Concrete CMS through 8.5.5. Arbitrary File deletion can occur via PHAR deserialization in is_dir (PHP Object Injection associated with the __wakeup magic method).
{
"affected": [],
"aliases": [
"CVE-2021-40102"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-24T15:15:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in Concrete CMS through 8.5.5. Arbitrary File deletion can occur via PHAR deserialization in is_dir (PHP Object Injection associated with the __wakeup magic method).",
"id": "GHSA-jgcw-5vw9-7w3c",
"modified": "2022-05-24T19:15:42Z",
"published": "2022-05-24T19:15:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40102"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/921288"
},
{
"type": "WEB",
"url": "https://documentation.concretecms.org/developers/introduction/version-history/856-release-notes"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-JGJ7-CGHF-2WQ9
Vulnerability from github – Published: 2022-05-14 01:29 – Updated: 2022-05-14 01:29In WordPress before 4.9.9 and 5.x before 5.0.1, contributors could conduct PHP object injection attacks via crafted metadata in a wp.getMediaItem XMLRPC call. This is caused by mishandling of serialized data at phar:// URLs in the wp_get_attachment_thumb_file function in wp-includes/post.php.
{
"affected": [],
"aliases": [
"CVE-2018-20148"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-12-14T20:29:00Z",
"severity": "CRITICAL"
},
"details": "In WordPress before 4.9.9 and 5.x before 5.0.1, contributors could conduct PHP object injection attacks via crafted metadata in a wp.getMediaItem XMLRPC call. This is caused by mishandling of serialized data at phar:// URLs in the wp_get_attachment_thumb_file function in wp-includes/post.php.",
"id": "GHSA-jgj7-cghf-2wq9",
"modified": "2022-05-14T01:29:39Z",
"published": "2022-05-14T01:29:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-20148"
},
{
"type": "WEB",
"url": "https://blog.secarma.co.uk/labs/near-phar-dangerous-unserialization-wherever-you-are"
},
{
"type": "WEB",
"url": "https://codex.wordpress.org/Version_4.9.9"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/02/msg00019.html"
},
{
"type": "WEB",
"url": "https://wordpress.org/news/2018/12/wordpress-5-0-1-security-release"
},
{
"type": "WEB",
"url": "https://wordpress.org/support/wordpress-version/version-5-0-1"
},
{
"type": "WEB",
"url": "https://wpvulndb.com/vulnerabilities/9171"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2019/dsa-4401"
},
{
"type": "WEB",
"url": "https://www.zdnet.com/article/wordpress-plugs-bug-that-led-to-google-indexing-some-user-passwords"
},
{
"type": "WEB",
"url": "https://www.zdnet.com/article/wordpress-vulnerability-affects-a-third-of-most-popular-websites-online"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106220"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JGWR-3QM3-26F3
Vulnerability from github – Published: 2021-03-19 20:11 – Updated: 2022-08-22 19:40The fix for CVE-2020-9484 was incomplete. When using Apache Tomcat 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41, 8.5.0 to 8.5.61 or 7.0.0. to 7.0.107 with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published mitigations for CVE-2020-9484 also apply to this issue.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0-M1"
},
{
"fixed": "10.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.5.61"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 7.0.107"
},
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.0.108"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-25329"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2021-03-19T20:10:56Z",
"nvd_published_at": "2021-03-01T12:15:00Z",
"severity": "HIGH"
},
"details": "The fix for CVE-2020-9484 was incomplete. When using Apache Tomcat 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41, 8.5.0 to 8.5.61 or 7.0.0. to 7.0.107 with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published mitigations for CVE-2020-9484 also apply to this issue.",
"id": "GHSA-jgwr-3qm3-26f3",
"modified": "2022-08-22T19:40:41Z",
"published": "2021-03-19T20:11:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25329"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/6d66e99ef85da93e4d2c2a536ca51aa3418bfaf4"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com//security-alerts/cpujul2021.html"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4891"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210409-0002"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202208-34"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/03/msg00018.html"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfe62fbf9d4c314f166fe8c668e50e5d9dd882a99447f26f0367474bf@%3Cusers.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfe62fbf9d4c314f166fe8c668e50e5d9dd882a99447f26f0367474bf@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfe62fbf9d4c314f166fe8c668e50e5d9dd882a99447f26f0367474bf@%3Cannounce.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfe62fbf9d4c314f166fe8c668e50e5d9dd882a99447f26f0367474bf@%3Cannounce.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfe62fbf9d4c314f166fe8c668e50e5d9dd882a99447f26f0367474bf%40%3Cannounce.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf6d5d57b114678d8898005faef31e9fd6d7c981fcc4ccfc3bc272fc9@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb51ccd58b2152fc75125b2406fc93e04ca9d34e737263faa6ff0f41f@%3Cusers.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r8a2ac0e476dbfc1e6440b09dcc782d444ad635d6da26f0284725a5dc@%3Cusers.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r732b2ca289dc02df2de820e8775559abd6c207f159e39f559547a085@%3Cusers.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r11ce01e8a4c7269b88f88212f21830edf73558997ac7744f37769b77@%3Cusers.tomcat.apache.org%3E"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/tomcat"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/03/01/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Potential remote code execution in Apache Tomcat"
}
GHSA-JGXC-8MWQ-9XQW
Vulnerability from github – Published: 2024-01-22 06:30 – Updated: 2025-11-04 00:30In Clojure before 1.9.0, classes can be used to construct a serialized object that executes arbitrary code upon deserialization. This is relevant if a server deserializes untrusted objects.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.clojure:clojure"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-20189"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-22T21:25:51Z",
"nvd_published_at": "2024-01-22T06:15:07Z",
"severity": "CRITICAL"
},
"details": "In Clojure before 1.9.0, classes can be used to construct a serialized object that executes arbitrary code upon deserialization. This is relevant if a server deserializes untrusted objects.",
"id": "GHSA-jgxc-8mwq-9xqw",
"modified": "2025-11-04T00:30:44Z",
"published": "2024-01-22T06:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-20189"
},
{
"type": "WEB",
"url": "https://github.com/frohoff/ysoserial/pull/68/files"
},
{
"type": "WEB",
"url": "https://github.com/clojure/clojure/commit/271674c9b484d798484d134a5ac40a6df15d3ac3"
},
{
"type": "WEB",
"url": "https://clojure.atlassian.net/browse/CLJ-2204"
},
{
"type": "PACKAGE",
"url": "https://github.com/clojure/clojure"
},
{
"type": "WEB",
"url": "https://groups.google.com/d/msg/clojure/WaL3hHzsevI/7zHU-L7LBQAJ"
},
{
"type": "WEB",
"url": "https://hackmd.io/%40fe1w0/HyefvRQKp"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20241108-0002"
},
{
"type": "WEB",
"url": "https://security.snyk.io/vuln/SNYK-JAVA-ORGCLOJURE-5740378"
}
],
"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": "Clojure classes can be used to craft a serialized object that runs arbitrary code on deserialization"
}
GHSA-JH46-RMG6-R59W
Vulnerability from github – Published: 2023-10-31 06:30 – Updated: 2023-11-08 18:30Thorn SFTP gateway 3.4.x before 3.4.4 uses Pivotal Spring Framework for Java deserialization of untrusted data, which is not supported by Pivotal, a related issue to CVE-2016-1000027. Also, within the specific context of Thorn SFTP gateway, this leads to remote code execution.
{
"affected": [],
"aliases": [
"CVE-2023-47174"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-31T04:15:11Z",
"severity": "CRITICAL"
},
"details": "Thorn SFTP gateway 3.4.x before 3.4.4 uses Pivotal Spring Framework for Java deserialization of untrusted data, which is not supported by Pivotal, a related issue to CVE-2016-1000027. Also, within the specific context of Thorn SFTP gateway, this leads to remote code execution.",
"id": "GHSA-jh46-rmg6-r59w",
"modified": "2023-11-08T18:30:30Z",
"published": "2023-10-31T06:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47174"
},
{
"type": "WEB",
"url": "https://help.thorntech.com/docs/sftp-gateway-gcp-3.0/gcp-java-deserialization-rce"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
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.