CWE-436
Allowed-with-ReviewInterpretation Conflict
Abstraction: Class · Status: Incomplete
Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state.
289 vulnerabilities reference this CWE, most recent first.
CVE-2021-21366 (GCVE-0-2021-21366)
Vulnerability from cvelistv5 – Published: 2021-03-12 00:00 – Updated: 2024-08-03 18:09{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-03T18:09:16.000Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://github.com/xmldom/xmldom/security/advisories/GHSA-h6q6-9hqw-rwfv"
},
{
"tags": [
"x_transferred"
],
"url": "https://www.npmjs.com/package/xmldom"
},
{
"tags": [
"x_transferred"
],
"url": "https://github.com/xmldom/xmldom/releases/tag/0.5.0"
},
{
"tags": [
"x_transferred"
],
"url": "https://github.com/xmldom/xmldom/commit/d4201b9dfbf760049f457f9f08a3888d48835135"
},
{
"name": "[debian-lts-announce] 20230101 [SECURITY] [DLA 3260-1] node-xmldom security update",
"tags": [
"mailing-list",
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2023/01/msg00000.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "xmldom",
"vendor": "xmldom",
"versions": [
{
"status": "affected",
"version": "\u003c 0.5.0"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module. xmldom versions 0.4.0 and older do not correctly preserve system identifiers, FPIs or namespaces when repeatedly parsing and serializing maliciously crafted documents. This may lead to unexpected syntactic changes during XML processing in some downstream applications. This is fixed in version 0.5.0. As a workaround downstream applications can validate the input and reject the maliciously crafted documents."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 4.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-436",
"description": "CWE-436 Interpretation Conflict",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-115",
"description": "CWE-115: Misinterpretation of Input",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2023-01-01T00:00:00.000Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"url": "https://github.com/xmldom/xmldom/security/advisories/GHSA-h6q6-9hqw-rwfv"
},
{
"url": "https://www.npmjs.com/package/xmldom"
},
{
"url": "https://github.com/xmldom/xmldom/releases/tag/0.5.0"
},
{
"url": "https://github.com/xmldom/xmldom/commit/d4201b9dfbf760049f457f9f08a3888d48835135"
},
{
"name": "[debian-lts-announce] 20230101 [SECURITY] [DLA 3260-1] node-xmldom security update",
"tags": [
"mailing-list"
],
"url": "https://lists.debian.org/debian-lts-announce/2023/01/msg00000.html"
}
],
"source": {
"advisory": "GHSA-h6q6-9hqw-rwfv",
"discovery": "UNKNOWN"
},
"title": "Misinterpretation of malicious XML input"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2021-21366",
"datePublished": "2021-03-12T00:00:00.000Z",
"dateReserved": "2020-12-22T00:00:00.000Z",
"dateUpdated": "2024-08-03T18:09:16.000Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2021-0207 (GCVE-0-2021-0207)
Vulnerability from cvelistv5 – Published: 2021-01-15 17:35 – Updated: 2024-09-17 02:21| URL | Tags |
|---|---|
| https://kb.juniper.net/JSA11097 | x_refsource_CONFIRM |
| Vendor | Product | Version | |
|---|---|---|---|
| Juniper Networks | Junos OS |
Affected:
17.3 , < 17.3R3-S7
(custom)
Affected: 17.4 , < 17.4R2-S11, 17.4R3-S3 (custom) |
|
| Juniper Networks | Junos OS |
Affected:
18.1 , < 18.1R3-S9
(custom)
|
|
| Juniper Networks | Junos OS |
Affected:
18.2 , < 18.2R3-S3
(custom)
|
|
| Juniper Networks | Junos OS |
Affected:
18.3 , < 18.3R3-S1
(custom)
Affected: 18.4 , < 18.4R1-S5, 18.4R2-S3, 18.4R3 (custom) Affected: 19.1 , < 19.1R1-S5, 19.1R2-S1, 19.1R3 (custom) Affected: 19.2 , < 19.2R1-S5, 19.2R2 (custom) Affected: 19.3 , < 19.3R2-S3, 19.3R3 (custom) |
|
| Juniper Networks | Junos OS |
Affected:
19.4 , < 19.4R1-S2, 19.4R2
(custom)
|
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-03T15:32:10.091Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://kb.juniper.net/JSA11097"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"platforms": [
"NFX250, QFX5K Series, EX4600"
],
"product": "Junos OS",
"vendor": "Juniper Networks",
"versions": [
{
"lessThan": "17.3R3-S7",
"status": "affected",
"version": "17.3",
"versionType": "custom"
},
{
"lessThan": "17.4R2-S11, 17.4R3-S3",
"status": "affected",
"version": "17.4",
"versionType": "custom"
}
]
},
{
"platforms": [
"NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4600"
],
"product": "Junos OS",
"vendor": "Juniper Networks",
"versions": [
{
"lessThan": "18.1R3-S9",
"status": "affected",
"version": "18.1",
"versionType": "custom"
}
]
},
{
"platforms": [
"NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600"
],
"product": "Junos OS",
"vendor": "Juniper Networks",
"versions": [
{
"lessThan": "18.2R3-S3",
"status": "affected",
"version": "18.2",
"versionType": "custom"
}
]
},
{
"platforms": [
"NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series"
],
"product": "Junos OS",
"vendor": "Juniper Networks",
"versions": [
{
"lessThan": "18.3R3-S1",
"status": "affected",
"version": "18.3",
"versionType": "custom"
},
{
"lessThan": "18.4R1-S5, 18.4R2-S3, 18.4R3",
"status": "affected",
"version": "18.4",
"versionType": "custom"
},
{
"lessThan": "19.1R1-S5, 19.1R2-S1, 19.1R3",
"status": "affected",
"version": "19.1",
"versionType": "custom"
},
{
"lessThan": "19.2R1-S5, 19.2R2",
"status": "affected",
"version": "19.2",
"versionType": "custom"
},
{
"lessThan": "19.3R2-S3, 19.3R3",
"status": "affected",
"version": "19.3",
"versionType": "custom"
}
]
},
{
"platforms": [
"NFX250, NFX350, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series"
],
"product": "Junos OS",
"vendor": "Juniper Networks",
"versions": [
{
"lessThan": "19.4R1-S2, 19.4R2",
"status": "affected",
"version": "19.4",
"versionType": "custom"
}
]
}
],
"configurations": [
{
"lang": "en",
"value": "The following minimal configuration is required on two interfaces passing traffic on different vlans between each other:\n set interfaces [interface] unit [unit] family ethernet-switching vlan members [name]\n set vlans [name] vlan-id [unit]"
}
],
"datePublic": "2021-01-13T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "An improper interpretation conflict of certain data between certain software components within the Juniper Networks Junos OS devices does not allow certain traffic to pass through the device upon receipt from an ingress interface filtering certain specific types of traffic which is then being redirected to an egress interface on a different VLAN. This causes a Denial of Service (DoS) to those clients sending these particular types of traffic. Such traffic being sent by a client may appear genuine, but is non-standard in nature and should be considered as potentially malicious, and can be targeted to the device, or destined through it for the issue to occur. This issues affects IPv4 and IPv6 traffic. An indicator of compromise may be found by checking log files. You may find that traffic on the input interface has 100% of traffic flowing into the device, yet the egress interface shows 0 pps leaving the device. For example: [show interfaces \"interface\" statistics detail] Output between two interfaces would reveal something similar to: Ingress, first interface: -------------------- Interface Link Input packets (pps) Output packets (pps) et-0/0/0 Up 9999999999 (9999) 1 (0) -------------------- Egress, second interface: -------------------- Interface Link Input packets (pps) Output packets (pps) et-0/0/1 Up 0 (0) 9999999999 (0) -------------------- Dropped packets will not show up in DDoS monitoring/protection counters as issue is not caused by anti-DDoS protection mechanisms. This issue affects: Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S7 on NFX250, QFX5K Series, EX4600; 17.4 versions prior to 17.4R2-S11, 17.4R3-S3 on NFX250, QFX5K Series, EX4600; 18.1 versions prior to 18.1R3-S9 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4600; 18.2 versions prior to 18.2R3-S3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600; 18.3 versions prior to 18.3R3-S1 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 18.4 versions prior to 18.4R1-S5, 18.4R2-S3, 18.4R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.1 versions prior to 19.1R1-S5, 19.1R2-S1, 19.1R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.2 versions prior to 19.2R1-S5, 19.2R2 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.3 versions prior to 19.3R2-S3, 19.3R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.4 versions prior to 19.4R1-S2, 19.4R2 on NFX250, NFX350, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series. This issue does not affect Junos OS releases prior to 17.2R2."
}
],
"exploits": [
{
"lang": "en",
"value": "Juniper SIRT is not aware of any malicious exploitation of this vulnerability."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-436",
"description": "CWE-436 Interpretation Conflict",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-115",
"description": "CWE-115 Misinterpretation of Input",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"description": "Denial of Service (DoS)",
"lang": "en",
"type": "text"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2021-01-15T17:35:54.000Z",
"orgId": "8cbe9d5a-a066-4c94-8978-4b15efeae968",
"shortName": "juniper"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://kb.juniper.net/JSA11097"
}
],
"solutions": [
{
"lang": "en",
"value": "The following software releases have been updated to resolve this specific issue: 17.3R3-S7, 17.4R2-S11, 17.4R3-S3, 18.1R3-S9, 18.2R3-S3, 18.3R3-S1, 18.4R1-S5, 18.4R2-S3, 18.4R3, 19.1R1-S5, 19.1R2-S1, 19.1R3, 19.2R1-S5, 19.2R2, 19.3R2-S3, 19.3R3, 19.4R1-S2, 19.4R2, 20.1R1 and all subsequent releases."
}
],
"source": {
"advisory": "JSA11097",
"defect": [
"1429543"
],
"discovery": "USER"
},
"title": "NFX250, NFX350, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series: Certain genuine traffic received by the Junos OS device will be discarded instead of forwarded.",
"workarounds": [
{
"lang": "en",
"value": "There are no available workarounds for this issue."
}
],
"x_generator": {
"engine": "Vulnogram 0.0.9"
},
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "sirt@juniper.net",
"DATE_PUBLIC": "2021-01-13T17:00:00.000Z",
"ID": "CVE-2021-0207",
"STATE": "PUBLIC",
"TITLE": "NFX250, NFX350, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series: Certain genuine traffic received by the Junos OS device will be discarded instead of forwarded."
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Junos OS",
"version": {
"version_data": [
{
"platform": "NFX250, QFX5K Series, EX4600",
"version_affected": "\u003c",
"version_name": "17.3",
"version_value": "17.3R3-S7"
},
{
"platform": "NFX250, QFX5K Series, EX4600",
"version_affected": "\u003c",
"version_name": "17.4",
"version_value": "17.4R2-S11, 17.4R3-S3"
},
{
"platform": "NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4600",
"version_affected": "\u003c",
"version_name": "18.1",
"version_value": "18.1R3-S9"
},
{
"platform": "NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600",
"version_affected": "\u003c",
"version_name": "18.2",
"version_value": "18.2R3-S3"
},
{
"platform": "NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series",
"version_affected": "\u003c",
"version_name": "18.3",
"version_value": "18.3R3-S1"
},
{
"platform": "NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series",
"version_affected": "\u003c",
"version_name": "18.4",
"version_value": "18.4R1-S5, 18.4R2-S3, 18.4R3"
},
{
"platform": "NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series",
"version_affected": "\u003c",
"version_name": "19.1",
"version_value": "19.1R1-S5, 19.1R2-S1, 19.1R3"
},
{
"platform": "NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series",
"version_affected": "\u003c",
"version_name": "19.2",
"version_value": "19.2R1-S5, 19.2R2"
},
{
"platform": "NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series",
"version_affected": "\u003c",
"version_name": "19.3",
"version_value": "19.3R2-S3, 19.3R3"
},
{
"platform": "NFX250, NFX350, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series",
"version_affected": "\u003c",
"version_name": "19.4",
"version_value": "19.4R1-S2, 19.4R2"
}
]
}
}
]
},
"vendor_name": "Juniper Networks"
}
]
}
},
"configuration": [
{
"lang": "en",
"value": "The following minimal configuration is required on two interfaces passing traffic on different vlans between each other:\n set interfaces [interface] unit [unit] family ethernet-switching vlan members [name]\n set vlans [name] vlan-id [unit]"
}
],
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "An improper interpretation conflict of certain data between certain software components within the Juniper Networks Junos OS devices does not allow certain traffic to pass through the device upon receipt from an ingress interface filtering certain specific types of traffic which is then being redirected to an egress interface on a different VLAN. This causes a Denial of Service (DoS) to those clients sending these particular types of traffic. Such traffic being sent by a client may appear genuine, but is non-standard in nature and should be considered as potentially malicious, and can be targeted to the device, or destined through it for the issue to occur. This issues affects IPv4 and IPv6 traffic. An indicator of compromise may be found by checking log files. You may find that traffic on the input interface has 100% of traffic flowing into the device, yet the egress interface shows 0 pps leaving the device. For example: [show interfaces \"interface\" statistics detail] Output between two interfaces would reveal something similar to: Ingress, first interface: -------------------- Interface Link Input packets (pps) Output packets (pps) et-0/0/0 Up 9999999999 (9999) 1 (0) -------------------- Egress, second interface: -------------------- Interface Link Input packets (pps) Output packets (pps) et-0/0/1 Up 0 (0) 9999999999 (0) -------------------- Dropped packets will not show up in DDoS monitoring/protection counters as issue is not caused by anti-DDoS protection mechanisms. This issue affects: Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S7 on NFX250, QFX5K Series, EX4600; 17.4 versions prior to 17.4R2-S11, 17.4R3-S3 on NFX250, QFX5K Series, EX4600; 18.1 versions prior to 18.1R3-S9 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4600; 18.2 versions prior to 18.2R3-S3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600; 18.3 versions prior to 18.3R3-S1 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 18.4 versions prior to 18.4R1-S5, 18.4R2-S3, 18.4R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.1 versions prior to 19.1R1-S5, 19.1R2-S1, 19.1R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.2 versions prior to 19.2R1-S5, 19.2R2 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.3 versions prior to 19.3R2-S3, 19.3R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.4 versions prior to 19.4R1-S2, 19.4R2 on NFX250, NFX350, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series. This issue does not affect Junos OS releases prior to 17.2R2."
}
]
},
"exploit": [
{
"lang": "en",
"value": "Juniper SIRT is not aware of any malicious exploitation of this vulnerability."
}
],
"generator": {
"engine": "Vulnogram 0.0.9"
},
"impact": {
"cvss": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-436 Interpretation Conflict"
}
]
},
{
"description": [
{
"lang": "eng",
"value": "CWE-115 Misinterpretation of Input"
}
]
},
{
"description": [
{
"lang": "eng",
"value": "Denial of Service (DoS)"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://kb.juniper.net/JSA11097",
"refsource": "CONFIRM",
"url": "https://kb.juniper.net/JSA11097"
}
]
},
"solution": [
{
"lang": "en",
"value": "The following software releases have been updated to resolve this specific issue: 17.3R3-S7, 17.4R2-S11, 17.4R3-S3, 18.1R3-S9, 18.2R3-S3, 18.3R3-S1, 18.4R1-S5, 18.4R2-S3, 18.4R3, 19.1R1-S5, 19.1R2-S1, 19.1R3, 19.2R1-S5, 19.2R2, 19.3R2-S3, 19.3R3, 19.4R1-S2, 19.4R2, 20.1R1 and all subsequent releases."
}
],
"source": {
"advisory": "JSA11097",
"defect": [
"1429543"
],
"discovery": "USER"
},
"work_around": [
{
"lang": "en",
"value": "There are no available workarounds for this issue."
}
]
}
}
},
"cveMetadata": {
"assignerOrgId": "8cbe9d5a-a066-4c94-8978-4b15efeae968",
"assignerShortName": "juniper",
"cveId": "CVE-2021-0207",
"datePublished": "2021-01-15T17:35:54.872Z",
"dateReserved": "2020-10-27T00:00:00.000Z",
"dateUpdated": "2024-09-17T02:21:57.975Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
GHSA-23VG-4CJM-66Q5
Vulnerability from github – Published: 2026-10-15 20:19 – Updated: 2026-10-15 20:19Summary
openapi3filter.ValidationHandler.Middleware validates requests with kin-openapi's
legacy router, which selects an OpenAPI operation from the decoded URL.Path. The
method is documented as implementing gorilla/mux.MiddlewareFunc, but a downstream
gorilla/mux router configured with UseEncodedPath() selects its handler from the
encoded representation (URL.RawPath).
An unauthenticated request such as /public%2Fstatus can therefore be validated as an
intentionally public operation (/public/status) and then dispatched to a protected
operation (/{id}). The configured, rejecting AuthenticationFunc is never invoked,
and the protected downstream handler runs.
This is distinct from GHSA-r277-6w6q-xmqw. The behavior below uses an explicit authentication callback that rejects missing credentials and remains reproducible after the v0.144.0 fix for the unsafe default callback.
Affected products
- Product:
github.com/getkin/kin-openapi - Component:
openapi3filter.ValidationHandler.Middleware - Confirmed post-GHSA affected releases: v0.144.0, v0.145.0, and v0.146.0
- Reporter attestation: each listed release was checked out separately, the attached
single-file test was copied into
openapi3filter/, and that test passed; maintainers should independently confirm the version range - Confirmed affected development revision:
d33e44e67734dcde81b576582185e1343fb3985d - v0.143.0 also reproduces this mechanism, but GHSA-r277-6w6q-xmqw already provides a simpler bypass on that release; the distinct post-fix claim starts at v0.144.0
- Earlier releases: not tested; please treat the introduction boundary as unknown
Security impact
An unauthenticated remote requester can reach a handler whose OpenAPI operation requires authentication when all of the following are true:
- the application uses
ValidationHandler.Middlewareas the security gate; - the downstream router preserves and interprets an encoded path, such as
gorilla/mux with
UseEncodedPath(); - a public exact route and a protected parameterized route overlap after decoding;
- the public and protected operations expose the same HTTP method;
- the protected handler relies on the validation layer's security decision.
The protected operation's path-parameter value is constrained: it is an encoded
representation that decodes to a public literal path (public%2Fstatus in this PoC),
not an arbitrary attacker-selected identifier. A protected operation without a
compatible parameterized path is not reachable through this specific mechanism.
- Primitive: the security decision is made for a different OpenAPI operation than the operation dispatched by the application router.
- Demonstrated impact: a protected handler executes while the explicitly rejecting
AuthenticationFuncis never invoked. - Impact ceiling: confidentiality or integrity loss when the reachable protected handler has that authority; the PoC does not demonstrate data disclosure or state modification.
- Availability impact: not demonstrated.
Root cause
At the confirmed development revision:
openapi3filter/validation_handler.go:ValidationHandler.Loadconstructsrouters/legacy.NewRouterunconditionally.routers/legacy/router.go: route selection uses the decoded request path.routers/gorillamux/router.go: the kin-openapi gorilla router constructs a gorilla/mux router withUseEncodedPath().ValidationHandler.Middlewareforwards the unchanged request after validation.
The component making the authentication decision and the component dispatching the handler can therefore disagree about the selected operation.
Reproduction
The attached PoC uses a real net/http server, an explicit API-key callback that
rejects missing credentials, and a downstream gorilla/mux router with
UseEncodedPath().
From a kin-openapi checkout, copy the self-contained attachment
encoded_path_route_confusion_test.go.txt into openapi3filter/ as
encoded_path_route_confusion_test.go, then run:
go test -v ./openapi3filter -run '^TestEncodedPathAuthorizationBypass$' -count=1
Expected attack observation:
status=202 downstream_route=/{id} protected_id=public%2Fstatus authentication_calls=0
wiring=Router.Use status=202 downstream_route=/{id} protected_id=public%2Fstatus authentication_calls=0
Controls included in the test show that:
/ordinaryselects the protected operation, invokes authentication once, and is rejected with HTTP 401;/public/statusreaches only the intentionally public handler;- the encoded request reaches the protected
/{id}handler with HTTP 202 while the authentication callback remains uncalled; - both external wrapping and the documented
router.Use(validationHandler.Middleware)wiring reproduce the same result.
Reverse-proxy reachability
The same request was reproduced through Nginx 1.31.3 using the official
nginx:alpine image digest
sha256:4a73073bd557c65b759505da037898b61f1be6cbcc3c2c3aeac22d2a470c1752.
The exact container invocation was:
docker run --rm --name kin-openapi-nginx \
--add-host=host.docker.internal:host-gateway \
-p 18081:8080 -p 18082:8081 \
-v "$PWD/poc/nginx.conf:/etc/nginx/nginx.conf:ro" \
nginx:alpine
Container port 8080 uses proxy_pass http://host.docker.internal:18080; without a
replacement URI. Host port 18081 therefore preserved /public%2Fstatus; the protected
handler returned HTTP 202 and the
authentication callback remained at zero calls. With
proxy_pass http://host.docker.internal:18080/; on container port 8081 / host port
18082, Nginx canonicalized the upstream URI; both layers selected /public/status and
the bypass did not occur.
Nginx access-log observations:
server_port=8080 "GET /public%2Fstatus HTTP/1.1" 202 0 "curl/8.7.1"
server_port=8081 "GET /public%2Fstatus HTTP/1.1" 204 0 "curl/8.7.1"
server_port=8080 "GET /ordinary HTTP/1.1" 401 0 "curl/8.7.1"
The response route headers were X-Poc-Route: /{id} on the preserving listener and
X-Poc-Route: /public/status on the canonicalizing listener. Backend observations for
the two requests were:
request_uri="/public%2Fstatus" path="/public/status" raw_path="/public%2Fstatus" auth_before=0
completed request_uri="/public%2Fstatus" auth_after=0
request_uri="/public/status" path="/public/status" raw_path="" auth_before=0
completed request_uri="/public/status" auth_after=0
This control shows that upstream path handling is a deployment precondition rather than claiming that every proxy configuration is affected.
The canonical protected control produced:
request_uri="/ordinary" path="/ordinary" raw_path="" auth_before=0
completed request_uri="/ordinary" auth_after=1
Suggested remediation
The authentication layer and downstream dispatcher must select the same OpenAPI operation from the same request representation.
Potential approaches:
- make
ValidationHandleraccept a caller-suppliedrouters.Routerand require it to match downstream routing semantics; - document that
NewValidatoralready accepts a router but is safe only when the supplied router selects operations using the same semantics as the dispatcher; callers must also supply anAuthenticationFuncthroughValidationOptions, or protected requests fail with the existing missing-authentication-service error; - as an interim hardening option, make
ValidationHandlerfail closed on an encoded path separator whenURL.PathandURL.RawPathcan select different operations, and verify this behavior against the full suite; - document the route-identity requirement and add encoded-separator regression tests.
Replacing the legacy router with the kin-openapi gorilla router closes this PoC, but a local compatibility check changed two existing missing-path-parameter tests from HTTP 400 semantics to route-not-found HTTP 404 semantics. A direct router swap is therefore not a fully validated drop-in fix.
Public-reference triage
The public advisory list and related path-encoding reports reviewed on 2026-08-18 did not describe this authentication-boundary crossing. Relevant nearby reports include issues #397, #1089, and #1105 and PR #400. This search is not proof of novelty; please deduplicate against private reports.
Credit
Preferred credit: Satoru Kanno (GMO CONNECT Inc., GMO Internet Group, Inc.)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/getkin/kin-openapi"
},
"ranges": [
{
"events": [
{
"introduced": "0.144.0"
},
{
"fixed": "0.147.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-100351"
],
"database_specific": {
"cwe_ids": [
"CWE-289",
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-15T20:19:20Z",
"nvd_published_at": "2026-10-15T16:17:31Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`openapi3filter.ValidationHandler.Middleware` validates requests with kin-openapi\u0027s\nlegacy router, which selects an OpenAPI operation from the decoded `URL.Path`. The\nmethod is documented as implementing `gorilla/mux.MiddlewareFunc`, but a downstream\ngorilla/mux router configured with `UseEncodedPath()` selects its handler from the\nencoded representation (`URL.RawPath`).\n\nAn unauthenticated request such as `/public%2Fstatus` can therefore be validated as an\nintentionally public operation (`/public/status`) and then dispatched to a protected\noperation (`/{id}`). The configured, rejecting `AuthenticationFunc` is never invoked,\nand the protected downstream handler runs.\n\nThis is distinct from GHSA-r277-6w6q-xmqw. The behavior below uses an explicit\nauthentication callback that rejects missing credentials and remains reproducible\nafter the v0.144.0 fix for the unsafe default callback.\n\n## Affected products\n\n- Product: `github.com/getkin/kin-openapi`\n- Component: `openapi3filter.ValidationHandler.Middleware`\n- Confirmed post-GHSA affected releases: v0.144.0, v0.145.0, and v0.146.0\n- Reporter attestation: each listed release was checked out separately, the attached\n single-file test was copied into `openapi3filter/`, and that test passed; maintainers\n should independently confirm the version range\n- Confirmed affected development revision: `d33e44e67734dcde81b576582185e1343fb3985d`\n- v0.143.0 also reproduces this mechanism, but GHSA-r277-6w6q-xmqw already provides a\n simpler bypass on that release; the distinct post-fix claim starts at v0.144.0\n- Earlier releases: not tested; please treat the introduction boundary as unknown\n\n## Security impact\n\nAn unauthenticated remote requester can reach a handler whose OpenAPI operation\nrequires authentication when all of the following are true:\n\n1. the application uses `ValidationHandler.Middleware` as the security gate;\n2. the downstream router preserves and interprets an encoded path, such as\n gorilla/mux with `UseEncodedPath()`;\n3. a public exact route and a protected parameterized route overlap after decoding;\n4. the public and protected operations expose the same HTTP method;\n5. the protected handler relies on the validation layer\u0027s security decision.\n\nThe protected operation\u0027s path-parameter value is constrained: it is an encoded\nrepresentation that decodes to a public literal path (`public%2Fstatus` in this PoC),\nnot an arbitrary attacker-selected identifier. A protected operation without a\ncompatible parameterized path is not reachable through this specific mechanism.\n\n- Primitive: the security decision is made for a different OpenAPI operation than the\n operation dispatched by the application router.\n- Demonstrated impact: a protected handler executes while the explicitly rejecting\n `AuthenticationFunc` is never invoked.\n- Impact ceiling: confidentiality or integrity loss when the reachable protected\n handler has that authority; the PoC does not demonstrate data disclosure or state\n modification.\n- Availability impact: not demonstrated.\n\n## Root cause\n\nAt the confirmed development revision:\n\n- `openapi3filter/validation_handler.go`: `ValidationHandler.Load` constructs\n `routers/legacy.NewRouter` unconditionally.\n- `routers/legacy/router.go`: route selection uses the decoded request path.\n- `routers/gorillamux/router.go`: the kin-openapi gorilla router constructs a\n gorilla/mux router with `UseEncodedPath()`.\n- `ValidationHandler.Middleware` forwards the unchanged request after validation.\n\nThe component making the authentication decision and the component dispatching the\nhandler can therefore disagree about the selected operation.\n\n## Reproduction\n\nThe attached PoC uses a real `net/http` server, an explicit API-key callback that\nrejects missing credentials, and a downstream gorilla/mux router with\n`UseEncodedPath()`.\n\nFrom a kin-openapi checkout, copy the self-contained attachment\n`encoded_path_route_confusion_test.go.txt` into `openapi3filter/` as\n`encoded_path_route_confusion_test.go`, then run:\n\n```sh\ngo test -v ./openapi3filter -run \u0027^TestEncodedPathAuthorizationBypass$\u0027 -count=1\n```\n\nExpected attack observation:\n\n```text\nstatus=202 downstream_route=/{id} protected_id=public%2Fstatus authentication_calls=0\nwiring=Router.Use status=202 downstream_route=/{id} protected_id=public%2Fstatus authentication_calls=0\n```\n\nControls included in the test show that:\n\n- `/ordinary` selects the protected operation, invokes authentication once, and is\n rejected with HTTP 401;\n- `/public/status` reaches only the intentionally public handler;\n- the encoded request reaches the protected `/{id}` handler with HTTP 202 while the\n authentication callback remains uncalled;\n- both external wrapping and the documented\n `router.Use(validationHandler.Middleware)` wiring reproduce the same result.\n\n## Reverse-proxy reachability\n\nThe same request was reproduced through Nginx 1.31.3 using the official\n`nginx:alpine` image digest\n`sha256:4a73073bd557c65b759505da037898b61f1be6cbcc3c2c3aeac22d2a470c1752`.\n\nThe exact container invocation was:\n\n```sh\ndocker run --rm --name kin-openapi-nginx \\\n --add-host=host.docker.internal:host-gateway \\\n -p 18081:8080 -p 18082:8081 \\\n -v \"$PWD/poc/nginx.conf:/etc/nginx/nginx.conf:ro\" \\\n nginx:alpine\n```\n\nContainer port 8080 uses `proxy_pass http://host.docker.internal:18080;` without a\nreplacement URI. Host port 18081 therefore preserved `/public%2Fstatus`; the protected\nhandler returned HTTP 202 and the\nauthentication callback remained at zero calls. With\n`proxy_pass http://host.docker.internal:18080/;` on container port 8081 / host port\n18082, Nginx canonicalized the upstream URI; both layers selected `/public/status` and\nthe bypass did not occur.\n\nNginx access-log observations:\n\n```text\nserver_port=8080 \"GET /public%2Fstatus HTTP/1.1\" 202 0 \"curl/8.7.1\"\nserver_port=8081 \"GET /public%2Fstatus HTTP/1.1\" 204 0 \"curl/8.7.1\"\nserver_port=8080 \"GET /ordinary HTTP/1.1\" 401 0 \"curl/8.7.1\"\n```\n\nThe response route headers were `X-Poc-Route: /{id}` on the preserving listener and\n`X-Poc-Route: /public/status` on the canonicalizing listener. Backend observations for\nthe two requests were:\n\n```text\nrequest_uri=\"/public%2Fstatus\" path=\"/public/status\" raw_path=\"/public%2Fstatus\" auth_before=0\ncompleted request_uri=\"/public%2Fstatus\" auth_after=0\nrequest_uri=\"/public/status\" path=\"/public/status\" raw_path=\"\" auth_before=0\ncompleted request_uri=\"/public/status\" auth_after=0\n```\n\nThis control shows that upstream path handling is a deployment precondition rather\nthan claiming that every proxy configuration is affected.\n\nThe canonical protected control produced:\n\n```text\nrequest_uri=\"/ordinary\" path=\"/ordinary\" raw_path=\"\" auth_before=0\ncompleted request_uri=\"/ordinary\" auth_after=1\n```\n\n## Suggested remediation\n\nThe authentication layer and downstream dispatcher must select the same OpenAPI\noperation from the same request representation.\n\nPotential approaches:\n\n1. make `ValidationHandler` accept a caller-supplied `routers.Router` and require it to\n match downstream routing semantics;\n2. document that `NewValidator` already accepts a router but is safe only when the\n supplied router selects operations using the same semantics as the dispatcher;\n callers must also supply an `AuthenticationFunc` through `ValidationOptions`, or\n protected requests fail with the existing missing-authentication-service error;\n3. as an interim hardening option, make `ValidationHandler` fail closed on an encoded\n path separator when `URL.Path` and `URL.RawPath` can select different operations,\n and verify this behavior against the full suite;\n4. document the route-identity requirement and add encoded-separator regression tests.\n\nReplacing the legacy router with the kin-openapi gorilla router closes this PoC, but a\nlocal compatibility check changed two existing missing-path-parameter tests from HTTP\n400 semantics to route-not-found HTTP 404 semantics. A direct router swap is therefore\nnot a fully validated drop-in fix.\n\n## Public-reference triage\n\nThe public advisory list and related path-encoding reports reviewed on 2026-08-18 did\nnot describe this authentication-boundary crossing. Relevant nearby reports include\nissues #397, #1089, and #1105 and PR #400. This search is not proof of novelty; please\ndeduplicate against private reports.\n\n## Credit\n\nPreferred credit: Satoru Kanno (GMO CONNECT Inc., GMO Internet Group, Inc.)",
"id": "GHSA-23vg-4cjm-66q5",
"modified": "2026-10-15T20:19:20Z",
"published": "2026-10-15T20:19:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getkin/kin-openapi/security/advisories/GHSA-23vg-4cjm-66q5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100351"
},
{
"type": "WEB",
"url": "https://github.com/getkin/kin-openapi/commit/eda80e2676e9f577ceed2dd80e64f16083edb041"
},
{
"type": "PACKAGE",
"url": "https://github.com/getkin/kin-openapi"
},
{
"type": "WEB",
"url": "https://github.com/getkin/kin-openapi/releases/tag/v0.147.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "kin-openapi: ValidationHandler security-requirement bypass via encoded-path operation confusion"
}
GHSA-2C29-H3HM-8953
Vulnerability from github – Published: 2023-02-16 21:30 – Updated: 2023-02-27 18:32A improper neutralization of crlf sequences in http headers ('http response splitting') in Fortinet FortiOS versions 7.2.0 through 7.2.2, 7.0.0 through 7.0.8, 6.4.0 through 6.4.11, 6.2.0 through 6.2.12, 6.0.0 through 6.0.16, FortiProxy 7.2.0 through 7.2.1, 7.0.0 through 7.0.7, 2.0.0 through 2.0.10, 1.2.0 through 1.2.13, 1.1.0 through 1.1.6 may allow an authenticated and remote attacker to perform an HTTP request splitting attack which gives attackers control of the remaining headers and body of the response.
{
"affected": [],
"aliases": [
"CVE-2022-42472"
],
"database_specific": {
"cwe_ids": [
"CWE-436"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-16T19:15:00Z",
"severity": "MODERATE"
},
"details": "A improper neutralization of crlf sequences in http headers (\u0027http response splitting\u0027) in Fortinet FortiOS versions 7.2.0 through 7.2.2, 7.0.0 through 7.0.8, 6.4.0 through 6.4.11, 6.2.0 through 6.2.12, 6.0.0 through 6.0.16, FortiProxy 7.2.0 through 7.2.1, 7.0.0 through 7.0.7, 2.0.0 through 2.0.10, 1.2.0 through 1.2.13, 1.1.0 through 1.1.6 may allow an authenticated and remote attacker to perform an HTTP request splitting attack which gives attackers control of the remaining headers and body of the response.",
"id": "GHSA-2c29-h3hm-8953",
"modified": "2023-02-27T18:32:01Z",
"published": "2023-02-16T21:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42472"
},
{
"type": "WEB",
"url": "https://fortiguard.com/psirt/FG-IR-22-362"
}
],
"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"
}
]
}
GHSA-2C2Q-V642-37W6
Vulnerability from github – Published: 2022-05-24 17:09 – Updated: 2022-05-24 17:09The Sophos AV parsing engine before 2020-01-14 allows virus-detection bypass via a crafted ZIP archive. This affects Endpoint Protection, Cloud Optix, Mobile, Intercept X Endpoint, Intercept X for Server, and Secure Web Gateway.
{
"affected": [],
"aliases": [
"CVE-2020-9363"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-436"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-02-24T16:15:00Z",
"severity": "MODERATE"
},
"details": "The Sophos AV parsing engine before 2020-01-14 allows virus-detection bypass via a crafted ZIP archive. This affects Endpoint Protection, Cloud Optix, Mobile, Intercept X Endpoint, Intercept X for Server, and Secure Web Gateway.",
"id": "GHSA-2c2q-v642-37w6",
"modified": "2022-05-24T17:09:34Z",
"published": "2022-05-24T17:09:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9363"
},
{
"type": "WEB",
"url": "https://blog.zoller.lu/p/release-mode-coordinated-disclosure-ref.html"
},
{
"type": "WEB",
"url": "https://community.sophos.com/b/security-blog/posts/sophos-comments-to-cve-2020-9363"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2J66-VP53-PHJJ
Vulnerability from github – Published: 2024-06-16 03:30 – Updated: 2025-04-21 12:30url.c in GNU Wget through 1.24.5 mishandles semicolons in the userinfo subcomponent of a URI, and thus there may be insecure behavior in which data that was supposed to be in the userinfo subcomponent is misinterpreted to be part of the host subcomponent.
{
"affected": [],
"aliases": [
"CVE-2024-38428"
],
"database_specific": {
"cwe_ids": [
"CWE-436"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-16T03:15:08Z",
"severity": "CRITICAL"
},
"details": "url.c in GNU Wget through 1.24.5 mishandles semicolons in the userinfo subcomponent of a URI, and thus there may be insecure behavior in which data that was supposed to be in the userinfo subcomponent is misinterpreted to be part of the host subcomponent.",
"id": "GHSA-2j66-vp53-phjj",
"modified": "2025-04-21T12:30:23Z",
"published": "2024-06-16T03:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38428"
},
{
"type": "WEB",
"url": "https://git.savannah.gnu.org/cgit/wget.git/commit/?id=ed0c7c7e0e8f7298352646b2fd6e06a11e242ace"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/04/msg00029.html"
},
{
"type": "WEB",
"url": "https://lists.gnu.org/archive/html/bug-wget/2024-06/msg00005.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20241115-0005"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-33R2-8G93-5HM2
Vulnerability from github – Published: 2024-03-28 15:30 – Updated: 2024-03-28 15:30The console may experience a service interruption when processing file names with invalid characters.
{
"affected": [],
"aliases": [
"CVE-2023-45715"
],
"database_specific": {
"cwe_ids": [
"CWE-436"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-28T15:15:45Z",
"severity": "LOW"
},
"details": "The console may experience a service interruption when processing file names with invalid characters.\n",
"id": "GHSA-33r2-8g93-5hm2",
"modified": "2024-03-28T15:30:33Z",
"published": "2024-03-28T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45715"
},
{
"type": "WEB",
"url": "https://support.hcltechsw.com/csm?id=kb_article\u0026sysparm_article=KB0111972"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-35HP-HQMV-8QG8
Vulnerability from github – Published: 2026-04-28 22:28 – Updated: 2026-05-08 13:42Summary
Fiber cache middleware's default key generator uses only c.Path() and does not include the query string.
As a result, requests like /?id=1 and /?id=2 can map to the same cache key and share the same cached response.
This can cause response mix-up (cache poisoning-like behavior) for endpoints where response content depends on query parameters.
Details
Default configuration in cache middleware:
KeyGenerator: func(c fiber.Ctx) string { return utils.CopyString(c.Path()) }
References: - https://github.com/gofiber/fiber/blob/main/middleware/cache/config.go#L90-L92 - https://github.com/gofiber/fiber/blob/main/middleware/cache/cache_test.go#L599-L621
The existing test demonstrates that when handler output depends on query parameter id, a second request with a different query still returns the first cached response (cache hit), confirming query is not part of the default cache key.
PoC
Minimal PoC:
package main
import (
"log"
"github.com/gofiber/fiber/v3"
"github.com/gofiber/fiber/v3/middleware/cache"
)
func main() {
app := fiber.New()
app.Use(cache.New()) // default config
app.Get("/", func(c fiber.Ctx) error {
return c.SendString(c.Query("id", "1"))
})
log.Fatal(app.Listen(":3000"))
}
Reproduction:
GET /?id=1- Cache miss
- Response body:
1 GET /?id=2- Cache hit
- Response body:
1(expected2)
Local verification command used:
go test ./middleware/cache -run Test_Cache_WithNoCacheRequestDirective -count=1
Observed result: test passes, confirming this is current behavior.
Impact
- Responses that should vary by query parameters can be mixed between requests.
- In real deployments, this may leak or corrupt user/tenant-specific content if query parameters influence context or data selection.
- This is deployment-dependent but security-relevant, and not safe-by-default for query-variant responses.
Suggested remediation
- Change default cache key generation to include path + normalized query string (or canonicalized original URL).
- Keep ability for custom key generators.
- Add explicit documentation warning that path-only keying is unsafe for query-dependent responses.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/gofiber/fiber/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30246"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-436",
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-28T22:28:14Z",
"nvd_published_at": "2026-05-05T13:16:28Z",
"severity": "MODERATE"
},
"details": "### Summary\nFiber cache middleware\u0027s default key generator uses only `c.Path()` and does not include the query string.\nAs a result, requests like `/?id=1` and `/?id=2` can map to the same cache key and share the same cached response.\n\nThis can cause response mix-up (cache poisoning-like behavior) for endpoints where response content depends on query parameters.\n\n### Details\nDefault configuration in cache middleware:\n\n- `KeyGenerator: func(c fiber.Ctx) string { return utils.CopyString(c.Path()) }`\n\nReferences:\n- https://github.com/gofiber/fiber/blob/main/middleware/cache/config.go#L90-L92\n- https://github.com/gofiber/fiber/blob/main/middleware/cache/cache_test.go#L599-L621\n\nThe existing test demonstrates that when handler output depends on query parameter `id`, a second request with a different query still returns the first cached response (cache hit), confirming query is not part of the default cache key.\n\n### PoC\nMinimal PoC:\n\n```go\npackage main\n\nimport (\n \"log\"\n\n \"github.com/gofiber/fiber/v3\"\n \"github.com/gofiber/fiber/v3/middleware/cache\"\n)\n\nfunc main() {\n app := fiber.New()\n app.Use(cache.New()) // default config\n\n app.Get(\"/\", func(c fiber.Ctx) error {\n return c.SendString(c.Query(\"id\", \"1\"))\n })\n\n log.Fatal(app.Listen(\":3000\"))\n}\n```\n\nReproduction:\n\n1. `GET /?id=1`\n - Cache miss\n - Response body: `1`\n2. `GET /?id=2`\n - Cache hit\n - Response body: `1` (expected `2`)\n\nLocal verification command used:\n\n```bash\ngo test ./middleware/cache -run Test_Cache_WithNoCacheRequestDirective -count=1\n```\n\nObserved result: test passes, confirming this is current behavior.\n\n### Impact\n- Responses that should vary by query parameters can be mixed between requests.\n- In real deployments, this may leak or corrupt user/tenant-specific content if query parameters influence context or data selection.\n- This is deployment-dependent but security-relevant, and not safe-by-default for query-variant responses.\n\n### Suggested remediation\n- Change default cache key generation to include path + normalized query string (or canonicalized original URL).\n- Keep ability for custom key generators.\n- Add explicit documentation warning that path-only keying is unsafe for query-dependent responses.",
"id": "GHSA-35hp-hqmv-8qg8",
"modified": "2026-05-08T13:42:45Z",
"published": "2026-04-28T22:28:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gofiber/fiber/security/advisories/GHSA-35hp-hqmv-8qg8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30246"
},
{
"type": "WEB",
"url": "https://github.com/gofiber/fiber/commit/050ff1ff18511c1475b8ec627460216aaecddd4e"
},
{
"type": "WEB",
"url": "https://github.com/gofiber/fiber/commit/9a0d12c07ed895b84c72987f9288b04137afe5de"
},
{
"type": "PACKAGE",
"url": "https://github.com/gofiber/fiber"
},
{
"type": "WEB",
"url": "https://github.com/gofiber/fiber/blob/main/middleware/cache/cache_test.go#L599-L621"
},
{
"type": "WEB",
"url": "https://github.com/gofiber/fiber/blob/main/middleware/cache/config.go#L90-L92"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Fiber\u0027s cache middleware default key generator ignores query string, causing response mix-up across distinct query parameters"
}
GHSA-3632-GRRP-F8WR
Vulnerability from github – Published: 2022-07-29 00:00 – Updated: 2022-08-04 00:00Fossil 2.18 on Windows allows attackers to cause a denial of service (daemon crash) via an XSS payload in a ticket. This occurs because the ticket data is stored in a temporary file, and the product does not properly handle the absence of this file after Windows Defender has flagged it as malware.
{
"affected": [],
"aliases": [
"CVE-2022-34009"
],
"database_specific": {
"cwe_ids": [
"CWE-436"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-28T00:15:00Z",
"severity": "MODERATE"
},
"details": "Fossil 2.18 on Windows allows attackers to cause a denial of service (daemon crash) via an XSS payload in a ticket. This occurs because the ticket data is stored in a temporary file, and the product does not properly handle the absence of this file after Windows Defender has flagged it as malware.",
"id": "GHSA-3632-grrp-f8wr",
"modified": "2022-08-04T00:00:23Z",
"published": "2022-07-29T00:00:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34009"
},
{
"type": "WEB",
"url": "https://fossil-scm.org/home/doc/trunk/www/changes.wiki"
},
{
"type": "WEB",
"url": "https://gainsec.com/2022/07/27/cve-2022-34009"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3635-87F7-GFGJ
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service (host OS crash) or possibly gain host OS privileges because of an interpretation conflict for a union data structure associated with shadow paging. NOTE: this issue exists because of an incorrect fix for CVE-2017-15595.
{
"affected": [],
"aliases": [
"CVE-2018-19966"
],
"database_specific": {
"cwe_ids": [
"CWE-436"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-12-08T04:29:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service (host OS crash) or possibly gain host OS privileges because of an interpretation conflict for a union data structure associated with shadow paging. NOTE: this issue exists because of an incorrect fix for CVE-2017-15595.",
"id": "GHSA-3635-87f7-gfgj",
"modified": "2022-05-13T01:50:55Z",
"published": "2022-05-13T01:50:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19966"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/10/msg00008.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UXC6BME7SXJI2ZIATNXCAH7RGPI4UKTT"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2019/dsa-4369"
},
{
"type": "WEB",
"url": "https://xenbits.xen.org/xsa/advisory-280.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00072.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106182"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-105: HTTP Request Splitting
An adversary abuses the flexibility and discrepancies in the parsing and interpretation of HTTP Request messages by different intermediary HTTP agents (e.g., load balancer, reverse proxy, web caching proxies, application firewalls, etc.) to split a single HTTP request into multiple unauthorized and malicious HTTP requests to a back-end HTTP agent (e.g., web server).
See CanPrecede relationships for possible consequences.
CAPEC-273: HTTP Response Smuggling
An adversary manipulates and injects malicious content in the form of secret unauthorized HTTP responses, into a single HTTP response from a vulnerable or compromised back-end HTTP agent (e.g., server).
See CanPrecede relationships for possible consequences.
CAPEC-34: HTTP Response Splitting
An adversary manipulates and injects malicious content, in the form of secret unauthorized HTTP responses, into a single HTTP response from a vulnerable or compromised back-end HTTP agent (e.g., web server) or into an already spoofed HTTP response from an adversary controlled domain/site.
See CanPrecede relationships for possible consequences.