CWE-351
AllowedInsufficient Type Distinction
Abstraction: Base · Status: Draft
The product does not properly distinguish between different types of elements in a way that leads to insecure behavior.
27 vulnerabilities reference this CWE, most recent first.
CVE-2023-2866 (GCVE-0-2023-2866)
Vulnerability from cvelistv5 – Published: 2023-06-07 20:12 – Updated: 2025-01-16 21:32- CWE-351 - Insufficient Type Distinction
| Vendor | Product | Version | |
|---|---|---|---|
| Advantech | WebAccess/SCADA |
Affected:
8.4.5
|
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-02T06:33:06.094Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-150-01"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2023-2866",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-01-16T21:20:42.928189Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-01-16T21:32:10.686Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "WebAccess/SCADA",
"vendor": "Advantech",
"versions": [
{
"status": "affected",
"version": "8.4.5"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"user": "00000000-0000-4000-9000-000000000000",
"value": "Marlon Luis Petry reported this vulnerability to CISA."
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\n\n\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eIf an attacker can trick an authenticated user into loading a maliciously crafted .zip file onto Advantech WebAccess version 8.4.5, a web shell could be used to give the attacker full control of the SCADA server. \u003c/span\u003e\n\n"
}
],
"value": "\nIf an attacker can trick an authenticated user into loading a maliciously crafted .zip file onto Advantech WebAccess version 8.4.5, a web shell could be used to give the attacker full control of the SCADA server. \n\n"
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.3,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-351",
"description": "CWE-351 Insufficient Type Distinction",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2023-06-07T20:12:46.824Z",
"orgId": "7d14cffa-0d7d-4270-9dc0-52cabd5a23a6",
"shortName": "icscert"
},
"references": [
{
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-150-01"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\n\n\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eAdvantech released a new \u003c/span\u003e\u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://www.advantech.com/en/support/details/installation?id=1-MS9MJV\"\u003eversion V9.1.4\u003c/a\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;to address the problem by not including these files.\u003c/span\u003e\n\n\u003cbr\u003e"
}
],
"value": "\nAdvantech released a new version V9.1.4 https://www.advantech.com/en/support/details/installation \u00a0to address the problem by not including these files.\n\n\n"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Advantech WebAccess Insufficient Type Distinction",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\n\u003cp\u003eAdvantech recommends users locate and delete the \u201cWADashboardSetup.msi\u201d file to avoid this issue.\u003c/p\u003e\u003cp\u003eIf\n users wish to remedy this problem in version 8.4.5, they can uninstall \n\"WebAccess Dashboard\" from the control panel. Delete all the files:\u003c/p\u003e\u003cp\u003e\\Inetpub\\wwwroot\\broadweb\\WADashboard\u003c/p\u003e\u003cp\u003e\\WebAccess\\Node\\WADashboardSetup.msi\u003c/p\u003e\n\n\u003cbr\u003e"
}
],
"value": "Advantech recommends users locate and delete the \u201cWADashboardSetup.msi\u201d file to avoid this issue.\n\nIf\n users wish to remedy this problem in version 8.4.5, they can uninstall \n\"WebAccess Dashboard\" from the control panel. Delete all the files:\n\n\\Inetpub\\wwwroot\\broadweb\\WADashboard\n\n\\WebAccess\\Node\\WADashboardSetup.msi\n\n\n\n\n"
}
],
"x_generator": {
"engine": "Vulnogram 0.1.0-dev"
}
}
},
"cveMetadata": {
"assignerOrgId": "7d14cffa-0d7d-4270-9dc0-52cabd5a23a6",
"assignerShortName": "icscert",
"cveId": "CVE-2023-2866",
"datePublished": "2023-06-07T20:12:46.824Z",
"dateReserved": "2023-05-24T14:09:39.667Z",
"dateUpdated": "2025-01-16T21:32:10.686Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2022-1642 (GCVE-0-2022-1642)
Vulnerability from cvelistv5 – Published: 2022-06-16 16:39 – Updated: 2024-08-03 00:10| URL | Tags |
|---|---|
| https://github.com/apple/swift-corelibs-foundatio… | x_refsource_MISC |
| Vendor | Product | Version | |
|---|---|---|---|
| Swift Project | Swift Corelib-Foundation |
Affected:
5.5.0 , < unspecified
(custom)
Affected: unspecified , ≤ 5.6.1 (custom) |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-03T00:10:03.820Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://github.com/apple/swift-corelibs-foundation/security/advisories/GHSA-239c-6cv2-wwx8"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "Swift Corelib-Foundation",
"vendor": "Swift Project",
"versions": [
{
"lessThan": "unspecified",
"status": "affected",
"version": "5.5.0",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.6.1",
"status": "affected",
"version": "unspecified",
"versionType": "custom"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "A program using swift-corelibs-foundation is vulnerable to a denial of service attack caused by a potentially malicious source producing a JSON document containing a type mismatch. This vulnerability is caused by the interaction between a deserialization mechanism offered by the Swift standard library, the Codable protocol; and the JSONDecoder class offered by swift-corelibs-foundation, which can deserialize types that adopt the Codable protocol based on the content of a provided JSON document. When a type that adopts Codable requests the initialization of a field with an integer value, the JSONDecoder class uses a type-erased container with different accessor methods to attempt and coerce a corresponding JSON value and produce an integer. In the case the JSON value was a numeric literal with a floating-point portion, JSONDecoder used different type-eraser methods during validation than it did during the final casting of the value. The checked casting produces a deterministic crash due to this mismatch. The JSONDecoder class is often wrapped by popular Swift-based web frameworks to parse the body of HTTP requests and perform basic type validation. This makes the attack low-effort: sending a specifically crafted JSON document during a request to these endpoints will cause them to crash. The attack does not have any confidentiality or integrity risks in and of itself; the crash is produced deterministically by an abort function that ensures that execution does not continue in the face of this violation of assumptions. However, unexpected crashes can lead to violations of invariants in services, so it\u0027s possible that this attack can be used to trigger error conditions that escalate the risk. Producing a denial of service may also be the goal of an attacker in itself. This issue is solved in Swift 5.6.2 for Linux and Windows. This issue was solved by ensuring that the same methods are invoked both when validating and during casting, so that no type mismatch occurs. Swift for Linux and Windows versions are not ABI-interchangeable. To upgrade a service, its owner must update to this version of the Swift toolchain, then recompile and redeploy their software. The new version of Swift includes an updated swift-corelibs-foundation package. Versions of Swift running on Darwin-based operating systems are not affected."
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-241",
"description": "CWE-241: Improper Handling of Unexpected Data Type",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-351",
"description": "CWE-351: Insufficient Type Distinction",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-704",
"description": "CWE-704: Incorrect Type Conversion or Cast",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2022-06-16T16:39:46.000Z",
"orgId": "e4a1ddda-f4f5-496e-96c8-82c37d06abd0",
"shortName": "Swift"
},
"references": [
{
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/apple/swift-corelibs-foundation/security/advisories/GHSA-239c-6cv2-wwx8"
}
],
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "cve@forums.swift.org",
"ID": "CVE-2022-1642",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Swift Corelib-Foundation",
"version": {
"version_data": [
{
"version_affected": "\u003e=",
"version_value": "5.5.0"
},
{
"version_affected": "\u003c=",
"version_value": "5.6.1"
}
]
}
}
]
},
"vendor_name": "Swift Project"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "A program using swift-corelibs-foundation is vulnerable to a denial of service attack caused by a potentially malicious source producing a JSON document containing a type mismatch. This vulnerability is caused by the interaction between a deserialization mechanism offered by the Swift standard library, the Codable protocol; and the JSONDecoder class offered by swift-corelibs-foundation, which can deserialize types that adopt the Codable protocol based on the content of a provided JSON document. When a type that adopts Codable requests the initialization of a field with an integer value, the JSONDecoder class uses a type-erased container with different accessor methods to attempt and coerce a corresponding JSON value and produce an integer. In the case the JSON value was a numeric literal with a floating-point portion, JSONDecoder used different type-eraser methods during validation than it did during the final casting of the value. The checked casting produces a deterministic crash due to this mismatch. The JSONDecoder class is often wrapped by popular Swift-based web frameworks to parse the body of HTTP requests and perform basic type validation. This makes the attack low-effort: sending a specifically crafted JSON document during a request to these endpoints will cause them to crash. The attack does not have any confidentiality or integrity risks in and of itself; the crash is produced deterministically by an abort function that ensures that execution does not continue in the face of this violation of assumptions. However, unexpected crashes can lead to violations of invariants in services, so it\u0027s possible that this attack can be used to trigger error conditions that escalate the risk. Producing a denial of service may also be the goal of an attacker in itself. This issue is solved in Swift 5.6.2 for Linux and Windows. This issue was solved by ensuring that the same methods are invoked both when validating and during casting, so that no type mismatch occurs. Swift for Linux and Windows versions are not ABI-interchangeable. To upgrade a service, its owner must update to this version of the Swift toolchain, then recompile and redeploy their software. The new version of Swift includes an updated swift-corelibs-foundation package. Versions of Swift running on Darwin-based operating systems are not affected."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-241: Improper Handling of Unexpected Data Type"
}
]
},
{
"description": [
{
"lang": "eng",
"value": "CWE-351: Insufficient Type Distinction"
}
]
},
{
"description": [
{
"lang": "eng",
"value": "CWE-704: Incorrect Type Conversion or Cast"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://github.com/apple/swift-corelibs-foundation/security/advisories/GHSA-239c-6cv2-wwx8",
"refsource": "MISC",
"url": "https://github.com/apple/swift-corelibs-foundation/security/advisories/GHSA-239c-6cv2-wwx8"
}
]
}
}
}
},
"cveMetadata": {
"assignerOrgId": "e4a1ddda-f4f5-496e-96c8-82c37d06abd0",
"assignerShortName": "Swift",
"cveId": "CVE-2022-1642",
"datePublished": "2022-06-16T16:39:46.000Z",
"dateReserved": "2022-05-09T00:00:00.000Z",
"dateUpdated": "2024-08-03T00:10:03.820Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2020-10134 (GCVE-0-2020-10134)
Vulnerability from cvelistv5 – Published: 2020-05-19 15:50 – Updated: 2024-09-16 20:01| URL | Tags |
|---|---|
| https://kb.cert.org/vuls/id/534195/ | third-party-advisoryx_refsource_CERT-VN |
| https://www.bluetooth.com/learn-about-bluetooth/b… | x_refsource_CONFIRM |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-04T10:50:57.888Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"name": "VU#534195",
"tags": [
"third-party-advisory",
"x_refsource_CERT-VN",
"x_transferred"
],
"url": "https://kb.cert.org/vuls/id/534195/"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/method-vulnerability/"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "LE",
"vendor": "Bluetooth",
"versions": [
{
"lessThanOrEqual": "5.2",
"status": "affected",
"version": "5.2",
"versionType": "custom"
}
]
}
],
"credits": [
{
"lang": "en",
"value": "Thanks to Ludwig Peuckert and Maximilian von Tschirschnitz for reporting this vulnerability."
}
],
"datePublic": "2020-05-18T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "Pairing in Bluetooth\u00ae Core v5.2 and earlier may permit an unauthenticated attacker to acquire credentials with two pairing devices via adjacent access when the unauthenticated user initiates different pairing methods in each peer device and an end-user erroneously completes both pairing procedures with the MITM using the confirmation number of one peer as the passkey of the other. An adjacent, unauthenticated attacker could be able to initiate any Bluetooth operation on either attacked device exposed by the enabled Bluetooth profiles. This exposure may be limited when the user must authorize certain access explicitly, but so long as a user assumes that it is the intended remote device requesting permissions, device-local protections may be weakened."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "ADJACENT_NETWORK",
"availabilityImpact": "NONE",
"baseScore": 6.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-351",
"description": "CWE-351",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2020-05-19T15:50:14.000Z",
"orgId": "37e5125f-f79b-445b-8fad-9564f167944b",
"shortName": "certcc"
},
"references": [
{
"name": "VU#534195",
"tags": [
"third-party-advisory",
"x_refsource_CERT-VN"
],
"url": "https://kb.cert.org/vuls/id/534195/"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/method-vulnerability/"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Bluetooth devices supporting LE and specific BR/EDR implementations are vulnerable to method confusion attacks",
"x_generator": {
"engine": "Vulnogram 0.0.9"
},
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "cert@cert.org",
"DATE_PUBLIC": "2020-05-18T00:00:00.000Z",
"ID": "CVE-2020-10134",
"STATE": "PUBLIC",
"TITLE": "Bluetooth devices supporting LE and specific BR/EDR implementations are vulnerable to method confusion attacks"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "LE",
"version": {
"version_data": [
{
"version_affected": "\u003c=",
"version_name": "5.2",
"version_value": "5.2"
}
]
}
}
]
},
"vendor_name": "Bluetooth"
}
]
}
},
"credit": [
{
"lang": "eng",
"value": "Thanks to Ludwig Peuckert and Maximilian von Tschirschnitz for reporting this vulnerability."
}
],
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "Pairing in Bluetooth\u00ae Core v5.2 and earlier may permit an unauthenticated attacker to acquire credentials with two pairing devices via adjacent access when the unauthenticated user initiates different pairing methods in each peer device and an end-user erroneously completes both pairing procedures with the MITM using the confirmation number of one peer as the passkey of the other. An adjacent, unauthenticated attacker could be able to initiate any Bluetooth operation on either attacked device exposed by the enabled Bluetooth profiles. This exposure may be limited when the user must authorize certain access explicitly, but so long as a user assumes that it is the intended remote device requesting permissions, device-local protections may be weakened."
}
]
},
"generator": {
"engine": "Vulnogram 0.0.9"
},
"impact": {
"cvss": {
"attackComplexity": "LOW",
"attackVector": "ADJACENT_NETWORK",
"availabilityImpact": "NONE",
"baseScore": 6.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N",
"version": "3.1"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-351"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "VU#534195",
"refsource": "CERT-VN",
"url": "https://kb.cert.org/vuls/id/534195/"
},
{
"name": "https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/method-vulnerability/",
"refsource": "CONFIRM",
"url": "https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/method-vulnerability/"
}
]
},
"source": {
"discovery": "UNKNOWN"
}
}
}
},
"cveMetadata": {
"assignerOrgId": "37e5125f-f79b-445b-8fad-9564f167944b",
"assignerShortName": "certcc",
"cveId": "CVE-2020-10134",
"datePublished": "2020-05-19T15:50:14.117Z",
"dateReserved": "2020-03-05T00:00:00.000Z",
"dateUpdated": "2024-09-16T20:01:34.146Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
GHSA-4V6W-XPMH-GFGP
Vulnerability from github – Published: 2025-07-25 19:21 – Updated: 2025-09-05 16:08Summary
An inconsistency in MethodNode can be exploited to access unexpected object fields through dot notation. This can be used to achieve arbitrary code execution at load time.
While this issue may seem similar to https://github.com/skops-dev/skops/security/advisories/GHSA-m7f4-hrc6-fwg3, it is actually more severe, as it relies on fewer assumptions about trusted types.
Details
The MethodNode allows access to attributes of existing objects via dot notation. However, there are several critical shortcomings:
-
Although the
__class__and__module__fields are checked viaget_untrusted_typesand during theloadphase (as a concatenated string), they are not actually used byMethodNode. Instead, thefuncandobjentries in theschema.jsonare used to determine behavior. This means that even an apparently harmless__module__.__class__pair can lead to access of arbitrary attributes or methods of loaded objects, without any additional checks. -
Nothing prevents an attacker from chaining multiple
MethodNodeinstances to traverse the object hierarchy and access harmful attributes.
An object can be loaded using the ObjectNode, which normally enforces strict checks and allows only trusted or explicitly permitted objects. However, once the object is loaded, dot notation can be used to access any of its attributes or methods. Furthermore, by chaining multiple MethodNodes, one can traverse the Python object hierarchy and reach dangerous components such as the builtins dictionary—which contains functions like exec and eval.
This vulnerability allows the attacker to bypass both get_untrusted_types and load checks, enabling access to dangerous attributes and methods without triggering any alerts. As demonstrated in the PoC, arbitrary code execution is possible using just an anonymous object returned by get_untrusted_types (in the example, builtins.int, though any type would suffice since it doesn't influence the exploit).
For example, consider a malicious schema.json snippet like:
...
"__class__": "int",
"__module__": "builtins",
"__loader__": "MethodNode",
"content": {
"obj": {
"__class__": "int",
"__module__": "builtins",
"__loader__": "MethodNode",
"content": {
"obj": {
"__class__": "QuadraticDiscriminantAnalysis",
"__module__": "sklearn.discriminant_analysis",
"__loader__": "ObjectNode",
"__id__": 1
},
"func": "decision_function"
}
},
"func": "__builtins__"
}
...
Here, the attacker loads a trusted QuadraticDiscriminantAnalysis object using ObjectNode, accesses its decision_function method via MethodNode, and then uses another MethodNode to access the __builtins__ dictionary—all without triggering the untrusted type detection mechanisms.
Proof of Concept (PoC)
The provided PoC demonstrates arbitrary code execution using only builtins.int as the type returned by get_untrusted_types and verified by load. Note that the actual type is fully controlled by the attacker and can be anything (e.g., provola.whatever), as it's not used by skops or the exploit.
Components Used in the Exploit
To craft the exploit, the following skops nodes are used:
MethodNode– to silently access arbitrary Python attributes via dot notation. This is the vulnerable core.ObjectNode– to load a trusted object and use it as a base to access its attributes and methods. Also used to set object state via__setstate__.PartialNode– to easily control arguments passed to functions accessed.DefaultDictNode– to store a crafted call toexecusing thedefault_factoryattribute.DictNode– to trigger the call at load time.JsonNode,TypeNode,ListNode, etc. – for basic types, structures, and constants.
Additionally, the interesting implementation of GridSearchCV.score was leveraged, specifically:
def score(self, X, y=None, **params):
...
scorer = self.scorer_[self.refit]
return scorer(self.best_estimator_, X, y, **score_params)
Exploit Logic (Python Equivalent)
The schema.json used in this exploit is quite complex and carefully constructed. For this reason, the exploit logic is illustrated using the following Python code, which presents the core idea in a simplified and readable format. It simulates how the malicious schema.json is interpreted and executed by skops during model loading. The complete malicious skops model is attached for reference. This code demonstrates how an attacker can manipulate trusted objects and attributes using MethodNode, ultimately gaining access to the __builtins__ dictionary and invoking exec with a controlled payload. By chaining multiple nodes and leveraging Python's object model, arbitrary code execution is achieved—without triggering any type validation mechanisms.
from sklearn.discriminant_analysis import QuadraticDiscriminantAnalysis
from sklearn.model_selection._search import GridSearchCV
from functools import partial
from collections import defaultdict
# Step 1: Access builtins via dot traversal
a = QuadraticDiscriminantAnalysis().decision_function.__builtins__
# Step 2: Prepare GridSearchCV with overridden attributes
b = GridSearchCV()
b._sklearn_version = "1.7.0"
... # Less interesting attributes
b.scorer_ = a # builtins dict
b.refit = "exec"
b.best_estimator_ = "import os; os.system('/bin/sh')"
# Step 3: Create callable chain
c = b.score
d = partial(c, {}, {}) # empty dicts as globals/locals
e = defaultdict(**{})
e.default_factory = d
f = e.__getitem__ # dot traversal again :)
# Step 4: Force __getitem__ with a missing key to trigger default_factory
What we can see here is that, when f is called, it invokes the __getitem__ method of a defaultdict. Since the requested key doesn’t exist (the dict is empty), default_factory is triggered — which is the partial function d, wrapping the score method of the loaded GridSearchCV object.
Critically, the attributes of the GridSearchCV object (scorer_, refit, and best_estimator_) have been overwritten so that:
scorer_is the__builtins__dictionary,refitis set to"exec"— selecting theexecfunction from__builtins__,best_estimator_contains the malicious payload:"import os; os.system('/bin/sh')".
When score() is eventually called via the partial function, it resolves self.scorer_[self.refit] to exec, and then calls it as:
exec(self.best_estimator_, {}, {})
In other words:
exec("import os; os.system('/bin/sh')", {}, {})
This leads to arbitrary command execution.
Finally, to trigger this chain, it's sufficient to force a call to f (i.e., __getitem__) with a key that doesn’t exist. This can be done automatically at model load time using DictNode. We use the implementation of DictNode._construct():
def _construct(self):
content = gettype(self.module_name, self.class_name)()
key_types = self.children["key_types"].construct()
for k_type, (key, val) in zip(key_types, self.children["content"].items()):
content[k_type(key)] = val.construct()
return content
By setting key_types = [f] and using a missing key, the exploit executes automatically during model loading.
What is shown when loading the model
Suppose a user loads the model with the following code:
from skops.io import load, get_untrusted_types
unknown_types = get_untrusted_types(file="model.skops")
print("Unknown types", unknown_types)
input("Press enter to load the model...")
loaded = load("model.skops", trusted=unknown_types)
The output will be:
Unkonown types ['builtins.int']
Press enter to load the model...
However, the model loading will trigger the execution of the payload, which in this case is a shell command. The same can be modified to execute any arbitrary code.
Attachments
Tthe complete exploit is uploaded in the following drive location: https://drive.google.com/drive/folders/1bmVV18mnPbWy21hVYgf51yVJpf78vtB_?usp=sharing
Impact
An attacker can craft a malicious model file that, when loaded, executes arbitrary code on the victim’s machine. This occurs at load time, requiring no user interaction beyond loading the model. Given that skops is often used in collaborative environments and is designed with security in mind, this vulnerability poses a significant threat.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "skops"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.12.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-54413"
],
"database_specific": {
"cwe_ids": [
"CWE-351"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-25T19:21:31Z",
"nvd_published_at": "2025-07-26T04:16:06Z",
"severity": "HIGH"
},
"details": "## Summary\n\nAn inconsistency in `MethodNode` can be exploited to access unexpected object fields through dot notation. This can be used to achieve **arbitrary code execution at load time**.\n\nWhile this issue may seem similar to https://github.com/skops-dev/skops/security/advisories/GHSA-m7f4-hrc6-fwg3, it is actually more severe, as it relies on fewer assumptions about trusted types.\n\n\n## Details\n\nThe `MethodNode` allows access to attributes of existing objects via dot notation. However, there are several critical shortcomings:\n\n* Although the `__class__` and `__module__` fields are checked via `get_untrusted_types` and during the `load` phase (as a concatenated string), **they are not actually used by `MethodNode`**. Instead, the `func` and `obj` entries in the `schema.json` are used to determine behavior. This means that even an apparently harmless `__module__.__class__` pair can lead to access of arbitrary attributes or methods of loaded objects, without any additional checks.\n\n* **Nothing prevents an attacker from chaining multiple `MethodNode` instances** to traverse the object hierarchy and access harmful attributes.\n\nAn object can be loaded using the `ObjectNode`, which normally enforces strict checks and allows only trusted or explicitly permitted objects. However, once the object is loaded, dot notation can be used to access any of its attributes or methods. Furthermore, by chaining multiple `MethodNode`s, one can traverse the Python object hierarchy and reach dangerous components such as the `builtins` dictionary\u2014which contains functions like `exec` and `eval`.\n\nThis vulnerability allows the attacker to **bypass both `get_untrusted_types` and `load` checks**, enabling access to dangerous attributes and methods without triggering any alerts. As demonstrated in the PoC, arbitrary code execution is possible using just an anonymous object returned by `get_untrusted_types` (in the example, `builtins.int`, though any type would suffice since it doesn\u0027t influence the exploit).\n\n\nFor example, consider a malicious `schema.json` snippet like:\n\n```json\n...\n\"__class__\": \"int\",\n\"__module__\": \"builtins\",\n\"__loader__\": \"MethodNode\",\n\"content\": {\n \"obj\": {\n \"__class__\": \"int\",\n \"__module__\": \"builtins\",\n \"__loader__\": \"MethodNode\",\n \"content\": {\n \"obj\": {\n \"__class__\": \"QuadraticDiscriminantAnalysis\",\n \"__module__\": \"sklearn.discriminant_analysis\",\n \"__loader__\": \"ObjectNode\",\n \"__id__\": 1\n },\n \"func\": \"decision_function\"\n }\n },\n \"func\": \"__builtins__\"\n}\n...\n```\n\nHere, the attacker loads a trusted `QuadraticDiscriminantAnalysis` object using `ObjectNode`, accesses its `decision_function` method via `MethodNode`, and then uses another `MethodNode` to access the `__builtins__` dictionary\u2014**all without triggering the untrusted type detection mechanisms**.\n\n\n## Proof of Concept (PoC)\n\nThe provided PoC demonstrates arbitrary code execution using only `builtins.int` as the type returned by `get_untrusted_types` and verified by `load`. Note that the actual type is fully controlled by the attacker and can be anything (e.g., `provola.whatever`), as it\u0027s not used by `skops` or the exploit.\n\n### Components Used in the Exploit\n\nTo craft the exploit, the following `skops` nodes are used:\n\n* **`MethodNode`** \u2013 to silently access arbitrary Python attributes via dot notation. This is the vulnerable core.\n* **`ObjectNode`** \u2013 to load a trusted object and use it as a base to access its attributes and methods. Also used to set object state via `__setstate__`.\n* **`PartialNode`** \u2013 to easily control arguments passed to functions accessed.\n* **`DefaultDictNode`** \u2013 to store a crafted call to `exec` using the `default_factory` attribute.\n* **`DictNode`** \u2013 to trigger the call at load time.\n* **`JsonNode`, `TypeNode`, `ListNode`**, etc. \u2013 for basic types, structures, and constants.\n\nAdditionally, the interesting implementation of `GridSearchCV.score` was leveraged, specifically:\n\n```python\ndef score(self, X, y=None, **params):\n ...\n scorer = self.scorer_[self.refit]\n return scorer(self.best_estimator_, X, y, **score_params)\n```\n\n\n### Exploit Logic (Python Equivalent)\nThe `schema.json` used in this exploit is quite complex and carefully constructed. For this reason, the exploit logic is illustrated using the following Python code, which presents the core idea in a simplified and readable format. It simulates how the malicious `schema.json` is interpreted and executed by `skops` during model loading. The complete malicious `skops` model is attached for reference. This code demonstrates how an attacker can manipulate trusted objects and attributes using `MethodNode`, ultimately gaining access to the `__builtins__` dictionary and invoking `exec` with a controlled payload. By chaining multiple nodes and leveraging Python\u0027s object model, arbitrary code execution is achieved\u2014without triggering any type validation mechanisms.\n\n\n```python\nfrom sklearn.discriminant_analysis import QuadraticDiscriminantAnalysis\nfrom sklearn.model_selection._search import GridSearchCV\nfrom functools import partial\nfrom collections import defaultdict\n\n# Step 1: Access builtins via dot traversal\na = QuadraticDiscriminantAnalysis().decision_function.__builtins__\n\n# Step 2: Prepare GridSearchCV with overridden attributes\nb = GridSearchCV()\nb._sklearn_version = \"1.7.0\"\n... # Less interesting attributes\nb.scorer_ = a # builtins dict\nb.refit = \"exec\"\nb.best_estimator_ = \"import os; os.system(\u0027/bin/sh\u0027)\"\n\n# Step 3: Create callable chain\nc = b.score\nd = partial(c, {}, {}) # empty dicts as globals/locals\ne = defaultdict(**{})\ne.default_factory = d\nf = e.__getitem__ # dot traversal again :)\n\n# Step 4: Force __getitem__ with a missing key to trigger default_factory\n```\n\nWhat we can see here is that, when `f` is called, it invokes the `__getitem__` method of a `defaultdict`. Since the requested key doesn\u2019t exist (the dict is empty), `default_factory` is triggered \u2014 which is the partial function `d`, wrapping the `score` method of the loaded `GridSearchCV` object.\n\nCritically, the attributes of the `GridSearchCV` object (`scorer_`, `refit`, and `best_estimator_`) have been overwritten so that:\n\n* `scorer_` is the `__builtins__` dictionary,\n* `refit` is set to `\"exec\"` \u2014 selecting the `exec` function from `__builtins__`,\n* `best_estimator_` contains the malicious payload: `\"import os; os.system(\u0027/bin/sh\u0027)\"`.\n\nWhen `score()` is eventually called via the partial function, it resolves `self.scorer_[self.refit]` to `exec`, and then calls it as:\n\n```python\nexec(self.best_estimator_, {}, {})\n```\n\nIn other words:\n\n```python\nexec(\"import os; os.system(\u0027/bin/sh\u0027)\", {}, {})\n```\n\nThis leads to **arbitrary command execution**.\n\nFinally, to trigger this chain, it\u0027s sufficient to force a call to `f` (i.e., `__getitem__`) with a key that doesn\u2019t exist. This can be done automatically at model load time using `DictNode`. We use the implementation of `DictNode._construct()`:\n\n```python\ndef _construct(self):\n content = gettype(self.module_name, self.class_name)()\n key_types = self.children[\"key_types\"].construct()\n for k_type, (key, val) in zip(key_types, self.children[\"content\"].items()):\n content[k_type(key)] = val.construct()\n return content\n```\n\nBy setting `key_types = [f]` and using a missing key, the exploit executes automatically during model loading.\n\n### What is shown when loading the model\n\nSuppose a user loads the model with the following code:\n\n```python\nfrom skops.io import load, get_untrusted_types\n\nunknown_types = get_untrusted_types(file=\"model.skops\")\nprint(\"Unknown types\", unknown_types)\ninput(\"Press enter to load the model...\")\nloaded = load(\"model.skops\", trusted=unknown_types)\n```\n\nThe output will be:\n\n```\nUnkonown types [\u0027builtins.int\u0027]\nPress enter to load the model...\n```\n\nHowever, the model loading will trigger the execution of the payload, which in this case is a shell command. The same can be modified to execute any arbitrary code.\n\n\n### Attachments\nTthe complete exploit is uploaded in the following drive location: https://drive.google.com/drive/folders/1bmVV18mnPbWy21hVYgf51yVJpf78vtB_?usp=sharing\n\n\n## Impact\n\nAn attacker can craft a malicious model file that, when loaded, executes **arbitrary code** on the victim\u2019s machine. This occurs **at load time**, requiring no user interaction beyond loading the model. Given that `skops` is often used in collaborative environments and is designed with security in mind, this vulnerability poses a significant threat.",
"id": "GHSA-4v6w-xpmh-gfgp",
"modified": "2025-09-05T16:08:49Z",
"published": "2025-07-25T19:21:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/skops-dev/skops/security/advisories/GHSA-4v6w-xpmh-gfgp"
},
{
"type": "WEB",
"url": "https://github.com/skops-dev/skops/security/advisories/GHSA-m7f4-hrc6-fwg3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54413"
},
{
"type": "WEB",
"url": "https://github.com/skops-dev/skops/commit/0aeca055509dfb48c1506870aabdd9e247adf603"
},
{
"type": "WEB",
"url": "https://drive.google.com/drive/folders/1bmVV18mnPbWy21hVYgf51yVJpf78vtB_?usp=sharing"
},
{
"type": "WEB",
"url": "https://github.com/io-no/CVE-Reports/tree/main/CVE-2025-54413"
},
{
"type": "PACKAGE",
"url": "https://github.com/skops-dev/skops"
},
{
"type": "WEB",
"url": "https://github.com/skops-dev/skops/releases/tag/v0.12.0"
}
],
"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": "Skops may allow MethodNode to access unexpected object fields through dot notation, leading to arbitrary code execution at load time"
}
GHSA-5XH2-23CC-5JC6
Vulnerability from github – Published: 2025-01-09 18:51 – Updated: 2025-01-09 22:04Vulnerability Summary
A type confusion vulnerability exists in Strawberry GraphQL's relay integration that affects multiple ORM integrations (Django, SQLAlchemy, Pydantic). The vulnerability occurs when multiple GraphQL types are mapped to the same underlying model while using the relay node interface.
Affected Components - Strawberry GraphQL relay integration - Specifically impacts implementations using: - Django integration - SQLAlchemy integration - Pydantic integration
Technical Details
The vulnerability manifests when:
1. Multiple GraphQL types inherit from relay.Node
2. These types are mapped to the same database model
3. The global node field is used for type resolution
Example of vulnerable code:
from fruits.models import Fruit
import strawberry_django
import strawberry
@strawberry_django.type(Fruit)
class FruitType(relay.Node):
name: strawberry.auto
@strawberry_django.type(Fruit)
class SpecialFruitType(relay.Node):
secret_name: strawberry.auto
@strawberry.type
class Query:
node: relay.Node = strawberry_django.node()
Security Impact
When querying for a specific type using the global node field (e.g., FruitType:some-id), the resolver may incorrectly return an instance of a different type mapped to the same model (e.g., SpecialFruitType). This can lead to:
- Information disclosure if the alternate type exposes sensitive fields
- Potential privilege escalation if the alternate type contains data intended for restricted access
Note
Even with knowledge of the correct type name (e.g., SpecialFruitType), attackers may still be able to access unauthorized data through direct type queries.
We recommend to use permission on fields instead of creating a dedicate type.
Recommendations
1. Avoid mapping multiple relay Node types to the same model
2. Implement strict access controls at the field resolution level (using permissions)
3. Consider using separate models for different access levels of the same data
4. Update to strawberry-graphql>=0.257.0
5. If using strawberry-graphql-django, update to strawberry-graphql-django>=0.54.0
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "strawberry-graphql"
},
"ranges": [
{
"events": [
{
"introduced": "0.182.0"
},
{
"fixed": "0.257.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-22151"
],
"database_specific": {
"cwe_ids": [
"CWE-351",
"CWE-843"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-09T18:51:51Z",
"nvd_published_at": "2025-01-09T19:15:20Z",
"severity": "LOW"
},
"details": "**Vulnerability Summary**\nA type confusion vulnerability exists in Strawberry GraphQL\u0027s relay integration that affects multiple ORM integrations (Django, SQLAlchemy, Pydantic). The vulnerability occurs when multiple GraphQL types are mapped to the same underlying model while using the relay `node` interface.\n\n**Affected Components**\n- Strawberry GraphQL relay integration\n- Specifically impacts implementations using:\n - Django integration\n - SQLAlchemy integration\n - Pydantic integration\n\n**Technical Details**\n\nThe vulnerability manifests when:\n1. Multiple GraphQL types inherit from `relay.Node`\n2. These types are mapped to the same database model\n3. The global `node` field is used for type resolution\n\nExample of vulnerable code:\n\n```python\nfrom fruits.models import Fruit\nimport strawberry_django\nimport strawberry\n\n@strawberry_django.type(Fruit)\nclass FruitType(relay.Node):\n name: strawberry.auto\n\n@strawberry_django.type(Fruit)\nclass SpecialFruitType(relay.Node):\n secret_name: strawberry.auto\n\n@strawberry.type\nclass Query:\n node: relay.Node = strawberry_django.node()\n```\n\n**Security Impact**\n\nWhen querying for a specific type using the global `node` field (e.g., `FruitType:some-id`), the resolver may incorrectly return an instance of a different type mapped to the same model (e.g., `SpecialFruitType`). This can lead to:\n\n1. Information disclosure if the alternate type exposes sensitive fields\n2. Potential privilege escalation if the alternate type contains data intended for restricted access\n\n**Note**\nEven with knowledge of the correct type name (e.g., `SpecialFruitType`), attackers may still be able to access unauthorized data through direct type queries.\n\nWe recommend to use permission on fields instead of creating a dedicate type.\n\n**Recommendations**\n1. Avoid mapping multiple relay Node types to the same model\n2. Implement strict access controls at the field resolution level (using permissions)\n3. Consider using separate models for different access levels of the same data\n4. Update to `strawberry-graphql\u003e=0.257.0`\n5. If using `strawberry-graphql-django`, update to `strawberry-graphql-django\u003e=0.54.0`",
"id": "GHSA-5xh2-23cc-5jc6",
"modified": "2025-01-09T22:04:49Z",
"published": "2025-01-09T18:51:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/strawberry-graphql/strawberry/security/advisories/GHSA-5xh2-23cc-5jc6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22151"
},
{
"type": "WEB",
"url": "https://github.com/strawberry-graphql/strawberry/commit/526eb82b70451c0e59d5a71ae9b7396f59974bd8"
},
{
"type": "PACKAGE",
"url": "https://github.com/strawberry-graphql/strawberry"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Strawberry GraphQL has type resolution vulnerability in node interface that allows potential data leakage through incorrect type resolution"
}
GHSA-6336-QQW9-V6X6
Vulnerability from github – Published: 2026-04-03 03:26 – Updated: 2026-05-06 23:24Summary
Discord Component Interaction Misclassifies Group DM as Direct Message
Current Maintainer Triage
- Status: narrow
- Normalized severity: low
- Assessment: Real on shipped v2026.3.24 component-interaction routing/auth in extensions/discord/src/monitor/agent-components-helpers.ts, but impact is limited to Group DM policy or session misclassification.
Affected Packages / Versions
- Package:
openclaw(npm) - Latest published npm version:
2026.3.31 - Vulnerable version range:
<=2026.3.28 - Patched versions:
>= 2026.3.31 - First stable tag containing the fix:
v2026.3.31
Fix Commit(s)
8c83128fc38d5a3642b8ccbea58550755fdbbbaf— 2026-03-30T11:17:53-06:00
Release Process Note
- The fix is already present in released version
2026.3.31. - This draft looks ready for final maintainer disposition or publication, not additional code-fix work.
Thanks @nexrin for reporting.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.3.28"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.31"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41341"
],
"database_specific": {
"cwe_ids": [
"CWE-351",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-03T03:26:51Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "## Summary\nDiscord Component Interaction Misclassifies Group DM as Direct Message\n\n## Current Maintainer Triage\n- Status: narrow\n- Normalized severity: low\n- Assessment: Real on shipped v2026.3.24 component-interaction routing/auth in extensions/discord/src/monitor/agent-components-helpers.ts, but impact is limited to Group DM policy or session misclassification.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version: `2026.3.31`\n- Vulnerable version range: `\u003c=2026.3.28`\n- Patched versions: `\u003e= 2026.3.31`\n- First stable tag containing the fix: `v2026.3.31`\n\n## Fix Commit(s)\n- `8c83128fc38d5a3642b8ccbea58550755fdbbbaf` \u2014 2026-03-30T11:17:53-06:00\n\n## Release Process Note\n- The fix is already present in released version `2026.3.31`.\n- This draft looks ready for final maintainer disposition or publication, not additional code-fix work.\n\nThanks @nexrin for reporting.",
"id": "GHSA-6336-qqw9-v6x6",
"modified": "2026-05-06T23:24:54Z",
"published": "2026-04-03T03:26:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-6336-qqw9-v6x6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41341"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/8c83128fc38d5a3642b8ccbea58550755fdbbbaf"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.31"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-component-interaction-misclassification-in-discord-extension"
}
],
"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:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: Discord Component Interaction Misclassifies Group DM as Direct Message"
}
GHSA-98VJ-MM79-V77R
Vulnerability from github – Published: 2025-11-25 20:43 – Updated: 2025-11-27 08:59Impact
Backend users with precise control over the contents of template closures can execute arbitrary PHP functions that do not have required parameters.
Patches
Update to Contao 4.13.57, 5.3.42 or 5.6.5
Workarounds
Manually patch the Contao\Template::once() method.
Resources
https://contao.org/en/security-advisories/remote-code-execution-in-template-closures
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "contao/core-bundle"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.13.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "contao/core-bundle"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-RC1"
},
{
"fixed": "5.3.42"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "contao/core-bundle"
},
"ranges": [
{
"events": [
{
"introduced": "5.4.0-RC1"
},
{
"fixed": "5.6.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-65960"
],
"database_specific": {
"cwe_ids": [
"CWE-351"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-25T20:43:13Z",
"nvd_published_at": "2025-11-25T19:15:51Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nBackend users with precise control over the contents of template closures can execute arbitrary PHP functions that do not have required parameters.\n\n### Patches\n\nUpdate to Contao 4.13.57, 5.3.42 or 5.6.5\n\n### Workarounds\n\nManually patch the `Contao\\Template::once()` method.\n\n### Resources\n\nhttps://contao.org/en/security-advisories/remote-code-execution-in-template-closures",
"id": "GHSA-98vj-mm79-v77r",
"modified": "2025-11-27T08:59:22Z",
"published": "2025-11-25T20:43:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/contao/contao/security/advisories/GHSA-98vj-mm79-v77r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65960"
},
{
"type": "WEB",
"url": "https://github.com/contao/contao/commit/577d7fdd5b1ca84f65f034ff556865422f0a3bd1"
},
{
"type": "WEB",
"url": "https://github.com/contao/contao/commit/676f0855d39007ac9a0dbe7ae6a7414cba2312a5"
},
{
"type": "WEB",
"url": "https://github.com/contao/contao/commit/ebf84c90e5679a67060f396b924ce4a3c3f206b3"
},
{
"type": "WEB",
"url": "https://contao.org/en/security-advisories/remote-code-execution-in-template-closures"
},
{
"type": "PACKAGE",
"url": "https://github.com/contao/contao"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Contao is vulnerable to remote code execution in template closures"
}
GHSA-9HQ9-CR36-4WPJ
Vulnerability from github – Published: 2025-05-20 19:35 – Updated: 2025-05-20 19:35Problem
By design, the file management module in TYPO3’s backend user interface has historically allowed the upload of any file type, with the exception of those that are directly executable in a web server context. This lack of restriction means it is possible to upload files that may be considered potentially harmful, such as executable binaries (e.g., .exe files), or files with inconsistent file extensions and MIME types (for example, a file incorrectly named with a .png extension but actually carrying the MIME type application/zip).
Although such files are not directly executable through the web server, their presence can introduce indirect risks. For example, third-party services such as antivirus scanners or malware detection systems might flag or block access to the website for end users if suspicious files are found. This could negatively affect the availability or reputation of the site.
Solution
Update to TYPO3 versions 9.5.51 ELTS, 10.4.50 ELTS, 11.5.44 ELTS, 12.4.31 LTS, 13.4.12 LTS that fix the problem described.
[!NOTE] The mitigation strategies outlined below apply broadly to all file uploads handled through TYPO3's File Abstraction Layer (FAL), not just those performed via the backend interface. This means that any extension or custom integration leveraging FAL will also be subject to the new validation rules and configuration options. Developers are advised to review the implications for their code and refer to the documentation of that change for guidance.
[!IMPORTANT]
Strong security defaults - Manual actions required
These versions introduce new configuration options to better control which files are permitted for upload and to improve consistency checks.
A new configuration option,
$GLOBALS['TYPO3_CONF_VARS']['SYS']['miscfile_ext'], has been added. This option allows administrators to explicitly define which file extensions should be permitted that are not already part of the built-in text or media file groups - examples include archive formats such asziporxz.In addition, two new feature flags have been introduced to enhance security: *
security.system.enforceAllowedFileExtensions, enforces the defined list of allowed file extensions. This flag is enabled by default in new TYPO3 installations, but remains disabled in existing installations to prevent breaking changes. *security.system.enforceFileExtensionMimeTypeConsistency, ensures that the uploaded file’s extension matches its actual MIME type, providing further validation of file integrity. This flag is active by default.It is recommended to configure the allowed file extensions via
$GLOBALS['TYPO3_CONF_VARS']['SYS']['miscfile_ext']and to enable the feature flagsecurity.system.enforceAllowedFileExtensionsto enforce the restriction.
Credits
Thanks to Hamed Kohi for reporting this issue, and to TYPO3 core & security team member Oliver Hader for fixing it.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.5.50"
},
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.5.51"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.4.49"
},
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.4.50"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.5.43"
},
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.5.44"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.4.30"
},
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.4.31"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 13.4.11"
},
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "13.0.0"
},
{
"fixed": "13.4.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-47939"
],
"database_specific": {
"cwe_ids": [
"CWE-351",
"CWE-434"
],
"github_reviewed": true,
"github_reviewed_at": "2025-05-20T19:35:21Z",
"nvd_published_at": "2025-05-20T14:15:50Z",
"severity": "MODERATE"
},
"details": "### Problem\nBy design, the file management module in TYPO3\u2019s backend user interface has historically allowed the upload of any file type, with the exception of those that are directly executable in a web server context. This lack of restriction means it is possible to upload files that may be considered potentially harmful, such as executable binaries (e.g., `.exe` files), or files with inconsistent file extensions and MIME types (for example, a file incorrectly named with a `.png` extension but actually carrying the MIME type `application/zip`).\n\nAlthough such files are not directly executable through the web server, their presence can introduce indirect risks. For example, third-party services such as antivirus scanners or malware detection systems might flag or block access to the website for end users if suspicious files are found. This could negatively affect the availability or reputation of the site.\n\n### Solution\nUpdate to TYPO3 versions 9.5.51 ELTS, 10.4.50 ELTS, 11.5.44 ELTS, 12.4.31 LTS, 13.4.12 LTS that fix the problem described.\n\n\u003e [!NOTE]\n\u003e The mitigation strategies outlined below apply broadly to all file uploads handled through TYPO3\u0027s File Abstraction Layer (FAL), not just those performed via the backend interface. This means that any extension or custom integration leveraging FAL will also be subject to the new validation rules and configuration options. Developers are advised to review the implications for their code and refer to the [documentation of that change](https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.4.x/Important-106240-EnforceFile-extensionsAndMime-typeConsistencyInFileAbstractionLayer.html) for guidance.\n\n\u003e [!IMPORTANT]\n\u003e\n\u003e **Strong security defaults - Manual actions required**\n\u003e \n\u003e These versions introduce new configuration options to better control which files are permitted for upload and to improve consistency checks.\n\u003e \n\u003e A new configuration option, `$GLOBALS[\u0027TYPO3_CONF_VARS\u0027][\u0027SYS\u0027][\u0027miscfile_ext\u0027]`, has been added. This option allows administrators to explicitly define which file extensions should be permitted that are not already part of the built-in text or media file groups - examples include archive formats such as `zip` or `xz`.\n\u003e \n\u003e In addition, two new feature flags have been introduced to enhance security:\n\u003e * `security.system.enforceAllowedFileExtensions`, enforces the defined list of allowed file extensions. This flag is enabled by default in new TYPO3 installations, but remains disabled in existing installations to prevent breaking changes.\n\u003e * `security.system.enforceFileExtensionMimeTypeConsistency`, ensures that the uploaded file\u2019s extension matches its actual MIME type, providing further validation of file integrity. This flag is active by default.\n\u003e \n\u003e It is recommended to configure the allowed file extensions via `$GLOBALS[\u0027TYPO3_CONF_VARS\u0027][\u0027SYS\u0027][\u0027miscfile_ext\u0027]` and to enable the feature flag `security.system.enforceAllowedFileExtensions` to enforce the restriction.\n\n### Credits\nThanks to Hamed Kohi for reporting this issue, and to TYPO3 core \u0026 security team member Oliver Hader for fixing it.",
"id": "GHSA-9hq9-cr36-4wpj",
"modified": "2025-05-20T19:35:21Z",
"published": "2025-05-20T19:35:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/TYPO3/typo3/security/advisories/GHSA-9hq9-cr36-4wpj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47939"
},
{
"type": "WEB",
"url": "https://github.com/TYPO3-CMS/core/commit/c265beed6e2c01817c534a226e80e593400f8255"
},
{
"type": "PACKAGE",
"url": "https://github.com/TYPO3-CMS/core"
},
{
"type": "WEB",
"url": "https://typo3.org/security/advisory/typo3-core-sa-2025-014"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "TYPO3 Allows Unrestricted File Upload in File Abstraction Layer"
}
GHSA-G4W7-3QR8-5623
Vulnerability from github – Published: 2021-08-25 20:47 – Updated: 2021-08-19 21:18An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via the repr(Rust) type.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "rusqlite"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-35872"
],
"database_specific": {
"cwe_ids": [
"CWE-351"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-19T21:18:44Z",
"nvd_published_at": "2020-12-31T10:15:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via the repr(Rust) type.",
"id": "GHSA-g4w7-3qr8-5623",
"modified": "2021-08-19T21:18:44Z",
"published": "2021-08-25T20:47:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35872"
},
{
"type": "WEB",
"url": "https://github.com/rusqlite/rusqlite/commit/71b2f5187b0cbace3f8b6ff53432ff2ca0defcf0"
},
{
"type": "PACKAGE",
"url": "https://github.com/rusqlite/rusqlite"
},
{
"type": "WEB",
"url": "https://github.com/rusqlite/rusqlite/releases/tag/0.23.0"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2020-0014.html"
}
],
"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": "Improper type usage in rusqlite"
}
GHSA-HWHH-RXM7-PXHQ
Vulnerability from github – Published: 2024-12-03 18:31 – Updated: 2024-12-03 18:31IBM Cognos Controller 11.0.0 and 11.0.1
could allow an authenticated user to upload insecure files, due to insufficient file type distinction.
{
"affected": [],
"aliases": [
"CVE-2024-45676"
],
"database_specific": {
"cwe_ids": [
"CWE-351"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-03T18:15:14Z",
"severity": "MODERATE"
},
"details": "IBM Cognos Controller 11.0.0 and 11.0.1 \n\n\n\n\n\n\n\ncould allow an authenticated user to upload insecure files, due to insufficient file type distinction.",
"id": "GHSA-hwhh-rxm7-pxhq",
"modified": "2024-12-03T18:31:04Z",
"published": "2024-12-03T18:31:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45676"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7177220"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.