CWE-352
AllowedCross-Site Request Forgery (CSRF)
Abstraction: Compound · Status: Stable
The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor.
14161 vulnerabilities reference this CWE, most recent first.
GHSA-XQG5-R78Q-7WRX
Vulnerability from github – Published: 2025-09-05 15:31 – Updated: 2026-04-01 18:36Cross-Site Request Forgery (CSRF) vulnerability in michalzagdan TrustMate.io – WooCommerce integration allows Cross Site Request Forgery. This issue affects TrustMate.io – WooCommerce integration: from n/a through 1.14.0.
{
"affected": [],
"aliases": [
"CVE-2025-58802"
],
"database_specific": {
"cwe_ids": [
"CWE-352"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-05T14:15:50Z",
"severity": "MODERATE"
},
"details": "Cross-Site Request Forgery (CSRF) vulnerability in michalzagdan TrustMate.io \u2013 WooCommerce integration allows Cross Site Request Forgery. This issue affects TrustMate.io \u2013 WooCommerce integration: from n/a through 1.14.0.",
"id": "GHSA-xqg5-r78q-7wrx",
"modified": "2026-04-01T18:36:04Z",
"published": "2025-09-05T15:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58802"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/trustmate-io-integration-for-woocommerce/vulnerability/wordpress-trustmate-io-woocommerce-integration-plugin-1-14-0-cross-site-request-forgery-csrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQGM-MM4X-RX9J
Vulnerability from github – Published: 2023-07-12 06:30 – Updated: 2024-04-04 06:00The Custom Banners plugin for WordPress is vulnerable to Cross-Site Request Forgery in versions up to, and including, 3.2.2 This is due to missing or incorrect nonce validation on the saveCustomFields() function. This makes it possible for unauthenticated attackers to save custom fields via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.
{
"affected": [],
"aliases": [
"CVE-2021-4407"
],
"database_specific": {
"cwe_ids": [
"CWE-352"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-12T04:15:10Z",
"severity": "MODERATE"
},
"details": "The Custom Banners plugin for WordPress is vulnerable to Cross-Site Request Forgery in versions up to, and including, 3.2.2 This is due to missing or incorrect nonce validation on the saveCustomFields() function. This makes it possible for unauthenticated attackers to save custom fields via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.",
"id": "GHSA-xqgm-mm4x-rx9j",
"modified": "2024-04-04T06:00:58Z",
"published": "2023-07-12T06:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4407"
},
{
"type": "WEB",
"url": "https://blog.nintechnet.com/25-wordpress-plugins-vulnerable-to-csrf-attacks"
},
{
"type": "WEB",
"url": "https://blog.nintechnet.com/more-wordpress-plugins-and-themes-vulnerable-to-csrf-attacks"
},
{
"type": "WEB",
"url": "https://blog.nintechnet.com/multiple-wordpress-plugins-fixed-csrf-vulnerabilities-part-1"
},
{
"type": "WEB",
"url": "https://blog.nintechnet.com/multiple-wordpress-plugins-fixed-csrf-vulnerabilities-part-2"
},
{
"type": "WEB",
"url": "https://blog.nintechnet.com/multiple-wordpress-plugins-fixed-csrf-vulnerabilities-part-3"
},
{
"type": "WEB",
"url": "https://blog.nintechnet.com/multiple-wordpress-plugins-fixed-csrf-vulnerabilities-part-4"
},
{
"type": "WEB",
"url": "https://blog.nintechnet.com/multiple-wordpress-plugins-fixed-csrf-vulnerabilities-part-5"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=2473385%40custom-banners\u0026new=2473385%40custom-banners\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/8f4c086d-8209-4212-9d91-67238c1a9143?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQH2-P25V-RV7V
Vulnerability from github – Published: 2023-11-06 12:30 – Updated: 2026-04-28 21:33Cross-Site Request Forgery (CSRF) vulnerability in Alter plugin <= 1.0 versions.
{
"affected": [],
"aliases": [
"CVE-2023-46780"
],
"database_specific": {
"cwe_ids": [
"CWE-352"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-06T12:15:08Z",
"severity": "HIGH"
},
"details": "Cross-Site Request Forgery (CSRF) vulnerability in Alter plugin \u003c=\u00a01.0 versions.",
"id": "GHSA-xqh2-p25v-rv7v",
"modified": "2026-04-28T21:33:00Z",
"published": "2023-11-06T12:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46780"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/alter/vulnerability/wordpress-alter-plugin-1-0-cross-site-request-forgery-csrf-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/alter/wordpress-alter-plugin-1-0-cross-site-request-forgery-csrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/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:27Unauthenticated 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
- The operator visits an attacker-controlled page in Firefox on their machine.
- JavaScript on the page fetches
pwn.sofrom the attacker's server (same-origin, no CORS issue). - JavaScript POSTs
pwn.sotohttp://127.0.0.1:9090/api/v1/plugins/uploadasmultipart/form-data. Joro accepts it — no auth, no preflight. - JavaScript POSTs to
http://127.0.0.1:9090/api/v1/system/restart. Joro re-executes. - On restart,
plugin.Open("pwn.so")callsinit(), which opens a goroutine and dials back to the attacker's listener. - An interactive
/bin/bash -ishell 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))
}
{
"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-XQMW-24V9-R296
Vulnerability from github – Published: 2023-02-13 15:30 – Updated: 2023-02-23 06:30The WP Customer Area WordPress plugin before 8.1.4 does not have CSRF checks when performing some actions such as chmod, mkdir and copy, which could allow attackers to make a logged-in admin perform them and create arbitrary folders, copy file for example.
{
"affected": [],
"aliases": [
"CVE-2022-4745"
],
"database_specific": {
"cwe_ids": [
"CWE-352"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-13T15:15:00Z",
"severity": "HIGH"
},
"details": "The WP Customer Area WordPress plugin before 8.1.4 does not have CSRF checks when performing some actions such as chmod, mkdir and copy, which could allow attackers to make a logged-in admin perform them and create arbitrary folders, copy file for example.",
"id": "GHSA-xqmw-24v9-r296",
"modified": "2023-02-23T06:30:19Z",
"published": "2023-02-13T15:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4745"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/9703f42e-bdfe-4787-92c9-47963d9af425"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQP4-G3QH-3X89
Vulnerability from github – Published: 2022-05-24 19:20 – Updated: 2022-05-24 19:20iCMS v7.0.15 was discovered to contain a Cross-Site Request Forgery (CSRF) via /admincp.php?app=members&do=add.
{
"affected": [],
"aliases": [
"CVE-2020-21141"
],
"database_specific": {
"cwe_ids": [
"CWE-352"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-12T22:15:00Z",
"severity": "HIGH"
},
"details": "iCMS v7.0.15 was discovered to contain a Cross-Site Request Forgery (CSRF) via /admincp.php?app=members\u0026do=add.",
"id": "GHSA-xqp4-g3qh-3x89",
"modified": "2022-05-24T19:20:30Z",
"published": "2022-05-24T19:20:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-21141"
},
{
"type": "WEB",
"url": "https://github.com/hxcc/just_for_fun/blob/master/ICMS%20CSRF"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XQQF-J87H-83GQ
Vulnerability from github – Published: 2022-10-13 12:00 – Updated: 2022-10-15 12:01Cross Site Request Forgery (CSRF) vulnerability in ResIOT ResIOT IOT Platform + LoRaWAN Network Server through 4.1.1000114 allows attackers to add new admin users to the platform or other unspecified impacts.
{
"affected": [],
"aliases": [
"CVE-2022-34020"
],
"database_specific": {
"cwe_ids": [
"CWE-352"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-13T01:15:00Z",
"severity": "HIGH"
},
"details": "Cross Site Request Forgery (CSRF) vulnerability in ResIOT ResIOT IOT Platform + LoRaWAN Network Server through 4.1.1000114 allows attackers to add new admin users to the platform or other unspecified impacts.",
"id": "GHSA-xqqf-j87h-83gq",
"modified": "2022-10-15T12:01:07Z",
"published": "2022-10-13T12:00:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34020"
},
{
"type": "WEB",
"url": "https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html"
},
{
"type": "WEB",
"url": "https://securityblog101.blogspot.com/2022/09/cve-2022-34020.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XQQW-C6R3-8GJC
Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2022-07-29 00:00The Leaflet Map WordPress plugin before 3.0.0 does not verify the CSRF nonce when saving its settings, which allows attackers to make a logged in admin update the settings via a Cross-Site Request Forgery attack. This could lead to Cross-Site Scripting issues by either changing the URL of the JavaScript library being used, or using malicious attributions which will be executed in all page with an embed map from the plugin
{
"affected": [],
"aliases": [
"CVE-2021-24467"
],
"database_specific": {
"cwe_ids": [
"CWE-352"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-09T10:15:00Z",
"severity": "MODERATE"
},
"details": "The Leaflet Map WordPress plugin before 3.0.0 does not verify the CSRF nonce when saving its settings, which allows attackers to make a logged in admin update the settings via a Cross-Site Request Forgery attack. This could lead to Cross-Site Scripting issues by either changing the URL of the JavaScript library being used, or using malicious attributions which will be executed in all page with an embed map from the plugin",
"id": "GHSA-xqqw-c6r3-8gjc",
"modified": "2022-07-29T00:00:48Z",
"published": "2022-05-24T19:10:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-24467"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/ac32d265-066e-49ec-9042-3145cd99e2e8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQR3-6F53-5V7G
Vulnerability from github – Published: 2022-05-17 04:21 – Updated: 2022-05-17 04:21Cross-site request forgery (CSRF) vulnerability in the WhyDoWork AdSense plugin 1.2 for WordPress allows remote attackers to hijack the authentication of administrators for requests that have unspecified impact via a request to the whydowork_adsense page in wp-admin/options-general.php.
{
"affected": [],
"aliases": [
"CVE-2014-9099"
],
"database_specific": {
"cwe_ids": [
"CWE-352"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-11-26T15:59:00Z",
"severity": "MODERATE"
},
"details": "Cross-site request forgery (CSRF) vulnerability in the WhyDoWork AdSense plugin 1.2 for WordPress allows remote attackers to hijack the authentication of administrators for requests that have unspecified impact via a request to the whydowork_adsense page in wp-admin/options-general.php.",
"id": "GHSA-xqr3-6f53-5v7g",
"modified": "2022-05-17T04:21:05Z",
"published": "2022-05-17T04:21:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-9099"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/127658/WordPress-WhyDoWork-AdSense-1.2-XSS-CSRF.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/68954"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XQXC-686P-M2M3
Vulnerability from github – Published: 2023-10-20 09:30 – Updated: 2024-04-04 08:49The BEAR for WordPress is vulnerable to Cross-Site Request Forgery in versions up to, and including, 1.1.3.3. This is due to missing or incorrect nonce validation on the woobe_bulkoperations_apply_default_combination function. This makes it possible for unauthenticated attackers to manipulate products via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.
{
"affected": [],
"aliases": [
"CVE-2023-4937"
],
"database_specific": {
"cwe_ids": [
"CWE-352"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-20T07:15:16Z",
"severity": "MODERATE"
},
"details": "The BEAR for WordPress is vulnerable to Cross-Site Request Forgery in versions up to, and including, 1.1.3.3. This is due to missing or incorrect nonce validation on the woobe_bulkoperations_apply_default_combination function. This makes it possible for unauthenticated attackers to manipulate products via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.",
"id": "GHSA-xqxc-686p-m2m3",
"modified": "2024-04-04T08:49:55Z",
"published": "2023-10-20T09:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4937"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/woo-bulk-editor/trunk/ext/bulkoperations/bulkoperations.php#L286"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/2970262/woo-bulk-editor/trunk/ext/bulkoperations/bulkoperations.php?contextall=1\u0026old=2844667\u0026old_path=%2Fwoo-bulk-editor%2Ftrunk%2Fext%2Fbulkoperations%2Fbulkoperations.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/40bf51bf-efb2-4504-815b-4681d1078f77?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
- For example, use anti-CSRF packages such as the OWASP CSRFGuard. [REF-330]
- Another example is the ESAPI Session Management control, which includes a component for CSRF. [REF-45]
Mitigation
Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.
Mitigation
Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable (CWE-330). [REF-332]
Mitigation
Identify especially dangerous operations. When the user performs a dangerous operation, send a separate confirmation request to ensure that the user intended to perform that operation.
Mitigation
- Use the "double-submitted cookie" method as described by Felten and Zeller:
- When a user visits a site, the site should generate a pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same.
- Because of the same-origin policy, an attacker cannot read or modify the value stored in the cookie. To successfully submit a form on behalf of the user, the attacker would have to correctly guess the pseudorandom value. If the pseudorandom value is cryptographically strong, this will be prohibitively difficult.
- This technique requires Javascript, so it may not work for browsers that have Javascript disabled. [REF-331]
Mitigation
Do not use the GET method for any request that triggers a state change.
Mitigation
Check the HTTP Referer header to see if the request originated from an expected page. This could break legitimate functionality, because users or proxies may have disabled sending the Referer for privacy reasons.
CAPEC-111: JSON Hijacking (aka JavaScript Hijacking)
An attacker targets a system that uses JavaScript Object Notation (JSON) as a transport mechanism between the client and the server (common in Web 2.0 systems using AJAX) to steal possibly confidential information transmitted from the server back to the client inside the JSON object by taking advantage of the loophole in the browser's Same Origin Policy that does not prohibit JavaScript from one website to be included and executed in the context of another website.
CAPEC-462: Cross-Domain Search Timing
An attacker initiates cross domain HTTP / GET requests and times the server responses. The timing of these responses may leak important information on what is happening on the server. Browser's same origin policy prevents the attacker from directly reading the server responses (in the absence of any other weaknesses), but does not prevent the attacker from timing the responses to requests that the attacker issued cross domain.
CAPEC-467: Cross Site Identification
An attacker harvests identifying information about a victim via an active session that the victim's browser has with a social networking site. A victim may have the social networking site open in one tab or perhaps is simply using the "remember me" feature to keep their session with the social networking site active. An attacker induces a payload to execute in the victim's browser that transparently to the victim initiates a request to the social networking site (e.g., via available social network site APIs) to retrieve identifying information about a victim. While some of this information may be public, the attacker is able to harvest this information in context and may use it for further attacks on the user (e.g., spear phishing).
CAPEC-62: Cross Site Request Forgery
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.