Common Weakness Enumeration

CWE-434

Allowed

Unrestricted 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.

5965 vulnerabilities reference this CWE, most recent first.

GHSA-XPXJ-GV5M-476X

Vulnerability from github – Published: 2026-06-17 18:35 – Updated: 2026-06-17 18:35
VLAI
Details

Subscriber Arbitrary File Upload in Grip <= 1.0.9 versions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-52488"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-17T13:19:12Z",
    "severity": "CRITICAL"
  },
  "details": "Subscriber Arbitrary File Upload in Grip \u003c= 1.0.9 versions.",
  "id": "GHSA-xpxj-gv5m-476x",
  "modified": "2026-06-17T18:35:42Z",
  "published": "2026-06-17T18:35:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52488"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/theme/grip/vulnerability/wordpress-grip-theme-1-0-9-arbitrary-plugin-activation-deactivation-to-rce-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQ2V-8QF4-3RG6

Vulnerability from github – Published: 2026-07-11 06:31 – Updated: 2026-07-11 06:31
VLAI
Details

The Swiss Toolkit For WP plugin for WordPress is vulnerable to arbitrary file upload due to a flawed file type validation bypass in the upload_extension_files() function in all versions up to, and including, 1.4.6. The upload_extension_files() function hooks into WordPress's wp_check_filetype_and_ext filter and uses strpos() to check if a filename contains a configured extension string, rather than verifying the actual file extension. This makes it possible for authenticated attackers, with Author-level access and above, to upload arbitrary files (including PHP) on the affected site's server which may make remote code execution possible, granted the "Enhanced Multi-Format Image Support" feature is enabled with at least one extension (e.g., avif) in the allowed formats.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-2354"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-11T05:16:33Z",
    "severity": "HIGH"
  },
  "details": "The Swiss Toolkit For WP plugin for WordPress is vulnerable to arbitrary file upload due to a flawed file type validation bypass in the `upload_extension_files()` function in all versions up to, and including, 1.4.6. The `upload_extension_files()` function hooks into WordPress\u0027s `wp_check_filetype_and_ext` filter and uses `strpos()` to check if a filename contains a configured extension string, rather than verifying the actual file extension. This makes it possible for authenticated attackers, with Author-level access and above, to upload arbitrary files (including PHP) on the affected site\u0027s server which may make remote code execution possible, granted the \"Enhanced Multi-Format Image Support\" feature is enabled with at least one extension (e.g., avif) in the allowed formats.",
  "id": "GHSA-xq2v-8qf4-3rg6",
  "modified": "2026-07-11T06:31:16Z",
  "published": "2026-07-11T06:31:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2354"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/swiss-toolkit-for-wp/tags/1.4.2/includes/plugins/class-boomdevs-swiss-toolkit-extension-supports.php#L49"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/swiss-toolkit-for-wp/tags/1.4.2/includes/plugins/class-boomdevs-swiss-toolkit-extension-supports.php#L95"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/swiss-toolkit-for-wp/trunk/includes/plugins/class-boomdevs-swiss-toolkit-extension-supports.php#L49"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/swiss-toolkit-for-wp/trunk/includes/plugins/class-boomdevs-swiss-toolkit-extension-supports.php#L95"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/06bccd2e-6891-433a-9f5b-3ec0c30afef4?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-XQ3X-GRRJ-FJ6X

Vulnerability from github – Published: 2023-04-02 12:30 – Updated: 2024-05-20 21:50
VLAI
Summary
sjqzhang go-fastdfs vulnerable to path traversal
Details

sjqzhang go-fastdfs up to 1.4.3 is vulnerable to path traversal in the function upload of the file /group1/upload of the component File Upload Handler. The attack may be launched remotely and the exploit has been disclosed to the public and may be used.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sjqzhang/go-fastdfs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.5-0.20230408141131-61cbff5124c6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-1800"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-24",
      "CWE-434"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-04-07T22:24:59Z",
    "nvd_published_at": "2023-04-02T11:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "sjqzhang go-fastdfs up to 1.4.3 is vulnerable to path traversal in the function upload of the file `/group1/upload` of the component `File Upload Handler`. The attack may be launched remotely and the exploit has been disclosed to the public and may be used.",
  "id": "GHSA-xq3x-grrj-fj6x",
  "modified": "2024-05-20T21:50:28Z",
  "published": "2023-04-02T12:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1800"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sjqzhang/go-fastdfs/commit/61cbff5124c61e292994099372b11c06cdb5b80b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sjqzhang/go-fastdfs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yangyanglo/ForCVE/blob/93a16663cd32a36d37d8a0f0102e1592254d0279/2023-0x05.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yangyanglo/ForCVE/blob/main/2023-0x05.md"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.224768"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.224768"
    }
  ],
  "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": "sjqzhang go-fastdfs vulnerable to path traversal"
}

GHSA-XQ44-VPM8-W66C

Vulnerability from github – Published: 2023-04-26 03:30 – Updated: 2024-04-04 03:41
VLAI
Details

IBM Cloud Pak for Data 4.5 and 4.6 could allow a privileged user to upload malicious files of dangerous types that can be automatically processed within the product's environment. IBM X-Force ID: 232034.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-36769"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434",
      "CWE-77"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-26T03:15:08Z",
    "severity": "HIGH"
  },
  "details": "\nIBM Cloud Pak for Data 4.5 and 4.6 could allow a privileged user to upload malicious files of dangerous types that can be automatically processed within the product\u0027s environment. IBM X-Force ID: 232034.\n\n",
  "id": "GHSA-xq44-vpm8-w66c",
  "modified": "2024-04-04T03:41:29Z",
  "published": "2023-04-26T03:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36769"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/232034"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6980959"
    }
  ],
  "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"
    }
  ]
}

GHSA-XQ4G-5HPC-WFCX

Vulnerability from github – Published: 2024-05-03 15:30 – Updated: 2024-08-01 15:31
VLAI
Details

An arbitrary file upload vulnerability in Zhongcheng Kexin Ticketing Management Platform 20.04 allows attackers to execute arbitrary code via uploading a crafted file.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-33786"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-03T13:15:21Z",
    "severity": "CRITICAL"
  },
  "details": "An arbitrary file upload vulnerability in Zhongcheng Kexin Ticketing Management Platform 20.04 allows attackers to execute arbitrary code via uploading a crafted file.",
  "id": "GHSA-xq4g-5hpc-wfcx",
  "modified": "2024-08-01T15:31:43Z",
  "published": "2024-05-03T15:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33786"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jiankeguyue/VulnerabilityReport/blob/main/zhongcheng_kexin_ticketing_management_platform.md"
    }
  ],
  "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"
    }
  ]
}

GHSA-XQ9M-VV28-7F24

Vulnerability from github – Published: 2024-12-24 12:30 – Updated: 2024-12-24 12:30
VLAI
Details

The DirectoryPress – Business Directory And Classified Ad Listing plugin for WordPress is vulnerable to Stored Cross-Site Scripting via SVG File uploads in all versions up to, and including, 3.6.16 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses the SVG file. When DirectoryPress Frontend is installed, this can be exploited by unauthenticated users.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-10584"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-24T11:15:05Z",
    "severity": "MODERATE"
  },
  "details": "The DirectoryPress \u2013 Business Directory And Classified Ad Listing plugin for WordPress is vulnerable to Stored Cross-Site Scripting via SVG File uploads in all versions up to, and including, 3.6.16 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses the SVG file. When DirectoryPress Frontend is installed, this can be exploited by unauthenticated users.",
  "id": "GHSA-xq9m-vv28-7f24",
  "modified": "2024-12-24T12:30:42Z",
  "published": "2024-12-24T12:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10584"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3205071/directorypress/trunk/includes/directorypress_svg.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/4625072b-815d-41d2-bf8f-ac290efde369?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQCW-GM88-2753

Vulnerability from github – Published: 2022-05-24 16:57 – Updated: 2024-04-04 02:08
VLAI
Details

Unrestricted file upload vulnerability in Micro Focus ArcSight Logger, version 6.7.0 and later. This vulnerability could allow Unrestricted Upload of File with Dangerous type.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-11655"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-04T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Unrestricted file upload vulnerability in Micro Focus ArcSight Logger, version 6.7.0 and later. This vulnerability could allow Unrestricted Upload of File with Dangerous type.",
  "id": "GHSA-xqcw-gm88-2753",
  "modified": "2024-04-04T02:08:34Z",
  "published": "2022-05-24T16:57:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11655"
    },
    {
      "type": "WEB",
      "url": "https://community.microfocus.com/t5/ArcSight-Announcements/ArcSight-Logger-Fix-for-Security-Vulnerability/td-p/2699569"
    }
  ],
  "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-XQHV-CHQM-FHCC

Vulnerability from github – Published: 2026-07-08 20:27 – Updated: 2026-07-08 20:27
VLAI
Summary
Joro: Unauthenticated Cross-Origin Plugin Upload Leads to RCE
Details

Unauthenticated Cross-Origin Plugin Upload Leads to RCE (Joro ≤ v1.1.0)

Severity: Critical CVSS v3.1: 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) Affected versions: Joro ≤ v1.1.0, proxy mode (default), Linux/macOS Reporter: cstover Date: 2026-05-27


Summary

Joro's default proxy mode (in versions <= 1.1.0) exposes a local API on 127.0.0.1:9090 that performs no authentication and applies a wildcard CORS policy. Because plugin uploads use the CORS-safelisted multipart/form-data content type, cross-origin JavaScript on any page the operator visits can reach privileged endpoints - including uploading a native plugin and triggering a restart - directly through the operator's browser, with no preflight or credentials. Since plugins execute on load, this yields unauthenticated remote code execution as the operator's user from a single page visit.


Root Cause

Three weaknesses combined into the exploit chain.

1. No authentication in proxy mode. internal/api/server.go applied AuthMiddleware only when listenerMode was true. In the default proxy mode every API endpoint — including plugin upload and system restart — accepted requests without any token, cookie, or credential.

2. Permissive CORS with an insufficient protection assumption. corsMiddleware set Access-Control-Allow-Origin: * unconditionally on all responses. SECURITY.md documented this as an intentional tradeoff on the basis that proxy mode binds to 127.0.0.1, which the document states "limits exposure to the local machine."

That assumption was incorrect. multipart/form-data is a CORS-safelisted Content-Type, so cross-origin JavaScript can POST files to the Joro API without triggering a preflight request — the browser allows it. Any web page the operator visited reached the localhost API through their browser without restriction. The localhost bind provided no protection against browser-mediated requests.

3. Plugin init() executed on plugin.Open() before symbol lookup. internal/plugins/loader.go called plugin.Open(), which ran the plugin's init() functions before any symbol lookup occurred. A plugin with no exports still executed its payload the moment Joro restarted.


Attack Chain

  1. The operator visits an attacker-controlled page in Firefox on their machine.
  2. JavaScript on the page fetches pwn.so from the attacker's server (same-origin, no CORS issue).
  3. JavaScript POSTs pwn.so to http://127.0.0.1:9090/api/v1/plugins/upload as multipart/form-data. Joro accepts it — no auth, no preflight.
  4. JavaScript POSTs to http://127.0.0.1:9090/api/v1/system/restart. Joro re-executes.
  5. On restart, plugin.Open("pwn.so") calls init(), which opens a goroutine and dials back to the attacker's listener.
  6. An interactive /bin/bash -i shell is obtained as the operator's user.

The plugin ABI matches without any access to the operator's machine. The same public v1.1.0 release tarball is downloaded and Joro's own --build-plugin feature is used, which reads runtime/debug.BuildInfo from the release binary and forwards every ABI-relevant flag. One .so works against every operator running that release.


Impact

Unauthenticated, remote, browser-mediated code execution as the operator's user. Because the exploit pivots through the operator's browser to the loopback-bound API, the network bind offers no protection, and a single ABI-matched plugin works against every operator running the affected release.

Fix

The chain is broken at multiple layers. Cross-origin browser access to the proxy-mode API is eliminated, the API is restricted to same-origin requests targeting a loopback host, and the UI/API is bound to loopback only.

1. Removed the wildcard CORS header and gated the proxy-mode API behind a same-origin guard

corsMiddleware (which set Access-Control-Allow-Origin: * on every response) was deleted, and proxy mode now wraps the API in originGuard instead. (internal/api/server.go, commit 5c0ca35)

 var handler http.Handler = mux
 if s.listenerMode {
+     // Listener/teamserver: bearer-token auth.
      handler = team.AuthMiddleware(s.teamToken, handler)
+} else {
+     // Proxy mode: restrict the API to same-origin browser requests.
+     handler = originGuard(uiBind, handler)
 }
-handler = corsMiddleware(handler)
-// corsMiddleware adds permissive CORS headers for dev usage.
-func corsMiddleware(next http.Handler) http.Handler {
-     return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
-             w.Header().Set("Access-Control-Allow-Origin", "*")
-             w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS")
-             w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization, X-Joro-Nickname")
-             if r.Method == http.MethodOptions {
-                     w.WriteHeader(http.StatusNoContent)
-                     return
-             }
-             next.ServeHTTP(w, r)
-     })
-}

2. Same-origin enforcement via Sec-Fetch-Site + Origin/Host

originGuard rejects state-changing requests (and the /ws upgrade) whose Sec-Fetch-Site indicates a cross-origin initiator or whose Origin host does not match the request Host. Non-browser local tooling (no browser headers) is still allowed. (internal/api/originguard.go, commit 5c0ca35)

func isMutating(method string) bool {
      switch method {
      case http.MethodPost, http.MethodPut, http.MethodDelete, http.MethodPatch:
              return true
      default:
              return false
      }
}

func sameOrigin(r *http.Request) bool {
      switch r.Header.Get("Sec-Fetch-Site") {
      case "", "same-origin", "none":
              // Same-origin, a direct navigation, or a non-browser client.
      default: // "cross-site", "same-site"
              return false
      }
      if origin := r.Header.Get("Origin"); origin != "" {
              if origin == "null" {
                      return false // opaque/sandboxed cross-origin context
              }
              u, err := url.Parse(origin)
              if err != nil || !strings.EqualFold(reqHostname(u.Host), reqHostname(r.Host)) {
                      return false
              }
      }
      return true
}

3. Tightened the WebSocket origin check

The WebSocket upgrader previously accepted every origin (CheckOrigin: return true). It now rejects cross-origin handshakes while still permitting non-browser clients. (internal/api/ws.go, commit 5c0ca35)

var upgrader = websocket.Upgrader{
-     CheckOrigin: func(r *http.Request) bool { return true },
+     CheckOrigin: func(r *http.Request) bool {
+             origin := r.Header.Get("Origin")
+             if origin == "" {
+                     return true
+             }
+             if origin == "null" {
+                     return false
+             }
+             u, err := url.Parse(origin)
+             if err != nil {
+                     return false
+             }
+             return strings.EqualFold(reqHostname(u.Host), reqHostname(r.Host))
+     },
 }

4. Bound the proxy-mode UI/API to loopback and removed the wildcard host exception

The same-origin check alone can be defeated by DNS rebinding under a wildcard bind, because a rebound host (e.g. attacker.com) carries consistent Origin/Host/Sec-Fetch-Site headers. Two coordinated changes close this: the proxy-mode UI/API now binds to 127.0.0.1 regardless of --bind (which governs only the proxy port), and hostAllowed no longer has a wildcard exception, so the host must be loopback or the exact bind address. (internal/api/server.go and internal/api/originguard.go, commit 871936f)

+// In proxy mode the UI/API binds to loopback only: --bind governs the proxy
+// port, and remote collaboration is listener/teamserver mode (bearer-token auth).
+uiBind := s.cfg.BindAddr
+if !s.listenerMode {
+     uiBind = "127.0.0.1"
+}
+
 var handler http.Handler = mux
 ...
 s.srv = &http.Server{
-     Addr:              fmt.Sprintf("%s:%d", s.cfg.BindAddr, s.cfg.UIPort),
+     Addr:              fmt.Sprintf("%s:%d", uiBind, s.cfg.UIPort),
 func hostAllowed(reqHost, bindAddr string) bool {
      h := reqHostname(reqHost)
      if h == "" {
              return false
      }
      switch h {
      case "localhost", "127.0.0.1", "::1":
              return true
      }
-     switch bindAddr {
-     case "", "0.0.0.0", "::":
-             return true
-     }
      return strings.EqualFold(h, reqHostname(bindAddr))
 }
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/BishopFox/joro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260601151442-5c0ca35db828"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53649"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-352",
      "CWE-434",
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-08T20:27:02Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "# Unauthenticated Cross-Origin Plugin Upload Leads to RCE (Joro \u2264 v1.1.0)\n\n**Severity:** Critical\n**CVSS v3.1:** 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H)\n**Affected versions:** Joro \u2264 v1.1.0, proxy mode (default), Linux/macOS\n**Reporter:** cstover\n**Date:** 2026-05-27\n\n---\n\n## Summary\n\nJoro\u0027s default proxy mode (in versions \u003c= 1.1.0) exposes a local API on `127.0.0.1:9090` that performs no authentication and applies a wildcard CORS policy. Because plugin uploads use the CORS-safelisted `multipart/form-data` content type, cross-origin JavaScript on any page the operator visits can reach privileged endpoints - including uploading a native plugin and triggering a restart - directly through the operator\u0027s browser, with no preflight or credentials. Since plugins execute on load, this yields unauthenticated remote code execution as the operator\u0027s user from a single page visit.\n\n---\n\n## Root Cause\n\nThree weaknesses combined into the exploit chain.\n\n**1. No authentication in proxy mode.**\n`internal/api/server.go` applied `AuthMiddleware` only when `listenerMode` was `true`. In the default proxy mode every API endpoint \u2014 including plugin upload and system restart \u2014 accepted requests without any token, cookie, or credential.\n\n**2. Permissive CORS with an insufficient protection assumption.**\n`corsMiddleware` set `Access-Control-Allow-Origin: *` unconditionally on all responses. `SECURITY.md` documented this as an intentional tradeoff on the basis that proxy mode binds to `127.0.0.1`, which the document states \"limits exposure to the local machine.\"\n\nThat assumption was incorrect. `multipart/form-data` is a CORS-safelisted `Content-Type`, so cross-origin JavaScript can POST files to the Joro API without triggering a preflight request \u2014 the browser allows it. Any web page the operator visited reached the localhost API through their browser without restriction. The localhost bind provided no protection against browser-mediated requests.\n\n**3. Plugin `init()` executed on `plugin.Open()` before symbol lookup.**\n`internal/plugins/loader.go` called `plugin.Open()`, which ran the plugin\u0027s `init()` functions before any symbol lookup occurred. A plugin with no exports still executed its payload the moment Joro restarted.\n\n---\n\n## Attack Chain\n\n1. The operator visits an attacker-controlled page in Firefox on their machine.\n2. JavaScript on the page fetches `pwn.so` from the attacker\u0027s server (same-origin, no CORS issue).\n3. JavaScript POSTs `pwn.so` to `http://127.0.0.1:9090/api/v1/plugins/upload` as `multipart/form-data`. Joro accepts it \u2014 no auth, no preflight.\n4. JavaScript POSTs to `http://127.0.0.1:9090/api/v1/system/restart`. Joro re-executes.\n5. On restart, `plugin.Open(\"pwn.so\")` calls `init()`, which opens a goroutine and dials back to the attacker\u0027s listener.\n6. An interactive `/bin/bash -i` shell is obtained as the operator\u0027s user.\n\nThe plugin ABI matches without any access to the operator\u0027s machine. The same public v1.1.0 release tarball is downloaded and Joro\u0027s own `--build-plugin` feature is used, which reads `runtime/debug.BuildInfo` from the release binary and forwards every ABI-relevant flag. One `.so` works against every operator running that release.\n\n---\n\n## Impact\n\nUnauthenticated, remote, browser-mediated code execution as the operator\u0027s user. Because the exploit pivots through the operator\u0027s browser to the loopback-bound API, the network bind offers no protection, and a single ABI-matched plugin works against every operator running the affected release.\n\n## Fix\n\nThe chain is broken at multiple layers. Cross-origin browser access to the proxy-mode API is eliminated, the API is restricted to same-origin requests targeting a loopback host, and the UI/API is bound to loopback only.\n\n### 1. Removed the wildcard CORS header and gated the proxy-mode API behind a same-origin guard\n\n`corsMiddleware` (which set `Access-Control-Allow-Origin: *` on every response) was deleted, and proxy mode now wraps the API in `originGuard` instead. (`internal/api/server.go`, commit `5c0ca35`)\n\n```diff\n var handler http.Handler = mux\n if s.listenerMode {\n+     // Listener/teamserver: bearer-token auth.\n      handler = team.AuthMiddleware(s.teamToken, handler)\n+} else {\n+     // Proxy mode: restrict the API to same-origin browser requests.\n+     handler = originGuard(uiBind, handler)\n }\n-handler = corsMiddleware(handler)\n```\n\n```diff\n-// corsMiddleware adds permissive CORS headers for dev usage.\n-func corsMiddleware(next http.Handler) http.Handler {\n-     return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n-             w.Header().Set(\"Access-Control-Allow-Origin\", \"*\")\n-             w.Header().Set(\"Access-Control-Allow-Methods\", \"GET, POST, PUT, DELETE, OPTIONS\")\n-             w.Header().Set(\"Access-Control-Allow-Headers\", \"Content-Type, Authorization, X-Joro-Nickname\")\n-             if r.Method == http.MethodOptions {\n-                     w.WriteHeader(http.StatusNoContent)\n-                     return\n-             }\n-             next.ServeHTTP(w, r)\n-     })\n-}\n```\n\n### 2. Same-origin enforcement via `Sec-Fetch-Site` + `Origin`/`Host`\n\n`originGuard` rejects state-changing requests (and the `/ws` upgrade) whose `Sec-Fetch-Site` indicates a cross-origin initiator or whose `Origin` host does not match the request `Host`. Non-browser local tooling (no browser headers) is still allowed. (`internal/api/originguard.go`, commit `5c0ca35`)\n\n```go\nfunc isMutating(method string) bool {\n      switch method {\n      case http.MethodPost, http.MethodPut, http.MethodDelete, http.MethodPatch:\n              return true\n      default:\n              return false\n      }\n}\n\nfunc sameOrigin(r *http.Request) bool {\n      switch r.Header.Get(\"Sec-Fetch-Site\") {\n      case \"\", \"same-origin\", \"none\":\n              // Same-origin, a direct navigation, or a non-browser client.\n      default: // \"cross-site\", \"same-site\"\n              return false\n      }\n      if origin := r.Header.Get(\"Origin\"); origin != \"\" {\n              if origin == \"null\" {\n                      return false // opaque/sandboxed cross-origin context\n              }\n              u, err := url.Parse(origin)\n              if err != nil || !strings.EqualFold(reqHostname(u.Host), reqHostname(r.Host)) {\n                      return false\n              }\n      }\n      return true\n}\n```\n\n### 3. Tightened the WebSocket origin check\n\nThe WebSocket upgrader previously accepted every origin (`CheckOrigin: return true`). It now rejects cross-origin handshakes while still permitting non-browser clients. (`internal/api/ws.go`, commit `5c0ca35`)\n\n```diff\nvar upgrader = websocket.Upgrader{\n-     CheckOrigin: func(r *http.Request) bool { return true },\n+     CheckOrigin: func(r *http.Request) bool {\n+             origin := r.Header.Get(\"Origin\")\n+             if origin == \"\" {\n+                     return true\n+             }\n+             if origin == \"null\" {\n+                     return false\n+             }\n+             u, err := url.Parse(origin)\n+             if err != nil {\n+                     return false\n+             }\n+             return strings.EqualFold(reqHostname(u.Host), reqHostname(r.Host))\n+     },\n }\n```\n\n### 4. Bound the proxy-mode UI/API to loopback and removed the wildcard host exception\n\nThe same-origin check alone can be defeated by DNS rebinding under a wildcard bind, because a rebound host (e.g. `attacker.com`) carries consistent `Origin`/`Host`/`Sec-Fetch-Site` headers. Two coordinated changes close this: the proxy-mode UI/API now binds to `127.0.0.1` regardless of `--bind` (which governs only the proxy port), and `hostAllowed` no longer has a wildcard exception, so the host must be loopback or the exact bind address. (`internal/api/server.go` and `internal/api/originguard.go`, commit `871936f`)\n\n```diff\n+// In proxy mode the UI/API binds to loopback only: --bind governs the proxy\n+// port, and remote collaboration is listener/teamserver mode (bearer-token auth).\n+uiBind := s.cfg.BindAddr\n+if !s.listenerMode {\n+     uiBind = \"127.0.0.1\"\n+}\n+\n var handler http.Handler = mux\n ...\n s.srv = \u0026http.Server{\n-     Addr:              fmt.Sprintf(\"%s:%d\", s.cfg.BindAddr, s.cfg.UIPort),\n+     Addr:              fmt.Sprintf(\"%s:%d\", uiBind, s.cfg.UIPort),\n```\n\n```diff\n func hostAllowed(reqHost, bindAddr string) bool {\n      h := reqHostname(reqHost)\n      if h == \"\" {\n              return false\n      }\n      switch h {\n      case \"localhost\", \"127.0.0.1\", \"::1\":\n              return true\n      }\n-     switch bindAddr {\n-     case \"\", \"0.0.0.0\", \"::\":\n-             return true\n-     }\n      return strings.EqualFold(h, reqHostname(bindAddr))\n }\n```",
  "id": "GHSA-xqhv-chqm-fhcc",
  "modified": "2026-07-08T20:27:02Z",
  "published": "2026-07-08T20:27:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/BishopFox/joro/security/advisories/GHSA-xqhv-chqm-fhcc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/BishopFox/joro"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Joro: Unauthenticated Cross-Origin Plugin Upload Leads to RCE"
}

GHSA-XQHW-96QR-HJW7

Vulnerability from github – Published: 2025-09-17 09:30 – Updated: 2025-09-17 09:30
VLAI
Details

The StoreEngine – Powerful WordPress eCommerce Plugin for Payments, Memberships, Affiliates, Sales & More plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the import() function in all versions up to, and including, 1.5.0. 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.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-9216"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-17T07:15:42Z",
    "severity": "HIGH"
  },
  "details": "The StoreEngine \u2013 Powerful WordPress eCommerce Plugin for Payments, Memberships, Affiliates, Sales \u0026 More plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the import() function in all versions up to, and including, 1.5.0. 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-xqhw-96qr-hjw7",
  "modified": "2025-09-17T09:30:44Z",
  "published": "2025-09-17T09:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9216"
    },
    {
      "type": "WEB",
      "url": "https://github.com/d0n601/CVE-2025-9216"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/storeengine/trunk/addons/csv/ajax/import.php#L52"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3360097/storeengine/trunk/addons/csv/ajax/import.php"
    },
    {
      "type": "WEB",
      "url": "https://ryankozak.com/posts/cve-2025-9216"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/7f8cc393-4d6f-4d15-ad95-d4a89dfe433c?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-XQP4-GHH2-WGPJ

Vulnerability from github – Published: 2022-08-13 00:00 – Updated: 2022-08-17 00:00
VLAI
Details

A vulnerability was found in SourceCodester Zoo Management System. It has been classified as critical. Affected is an unknown function of the file /pages/apply_vacancy.php. The manipulation of the argument filename leads to unrestricted upload. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-206250 is the identifier assigned to this vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-2804"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-12T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability was found in SourceCodester Zoo Management System. It has been classified as critical. Affected is an unknown function of the file /pages/apply_vacancy.php. The manipulation of the argument filename leads to unrestricted upload. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-206250 is the identifier assigned to this vulnerability.",
  "id": "GHSA-xqp4-ghh2-wgpj",
  "modified": "2022-08-17T00:00:24Z",
  "published": "2022-08-13T00:00:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2804"
    },
    {
      "type": "WEB",
      "url": "https://s1.ax1x.com/2022/08/12/vJ5pEd.png"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.206250"
    }
  ],
  "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"
    }
  ]
}

Mitigation
Architecture and Design

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
Architecture and Design

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
Architecture and Design

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
Implementation

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
Architecture and Design

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
Implementation

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
Implementation

When running on a web server that supports case-insensitive filenames, perform case-insensitive evaluations of the extensions that are provided.

Mitigation MIT-15
Architecture and Design

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
Implementation

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
Implementation

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
Architecture and Design Operation

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
Architecture and Design Operation

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.