#csrf

Fastify is a web framework with minimal overhead and plugin architecture. The attacker can use the incorrect `Content-Type` to bypass the `Pre-Flight` checking of `fetch`. `fetch()` requests with Content-Type’s essence as "application/x-www-form-urlencoded", "multipart/form-data", or "text/plain", could potentially be used to invoke routes that only accepts `application/json` content type, thus bypassing any CORS protection, and therefore they could lead to a Cross-Site Request Forgery attack. This issue has been patched in version 4.10.2 and 3.29.4. As a workaround, implement Cross-Site Request Forgery protection using `@fastify/csrf'.

Multiple Cross-Site Request Forgery vulnerabilities in All-In-One Security (AIOS) – Security and Firewall (WordPress plugin) <= 5.1.0 on WordPress.

An issue was discovered in Appalti & Contratti 9.12.2. It allows Session Fixation. When a user logs in providing a JSESSIONID cookie that is issued by the server at the first visit, the cookie value is not updated after a successful login.

### Impact It's possible with a simple request to perform deletion or renaming of tags without needing any confirmation, by using a CSRF attack. ### Patches The problem has been patched in XWiki 13.10.7, 14.4.1 and 14.5RC1. ### Workarounds It's possible to patch existing instances directly by editing the page Main.Tags and add this kind of check, in the code for renaming and for deleting: ``` #if (!$services.csrf.isTokenValid($request.get('form_token'))) #set ($discard = $response.sendError(401, "Wrong CSRF token")) #end ``` See the commit with the fix for more information about patching the page: https://github.com/xwiki/xwiki-platform/commit/7fd4cda0590180c4d34f557597e9e10e263def9e ### References * https://jira.xwiki.org/browse/XWIKI-19748 * https://github.com/xwiki/xwiki-platform/commit/7fd4cda0590180c4d34f557597e9e10e263def9e ### For more information If you have any questions or comments about this advisory: * Open an issue in [JIRA](https://jira.xwiki.org) * Ema...

A vulnerability identified in the Tailscale client allows a malicious website to access the peer API, which can then be used to access Tailscale environment variables. **Affected platforms:** All **Patched Tailscale client versions:** v1.32.3 or later, v1.33.257 or later (unstable) ### What happened? In the Tailscale client, the peer API was vulnerable to DNS rebinding. This allowed an attacker-controlled website visited by the node to rebind DNS for the peer API to an attacker-controlled DNS server, and then making peer API requests in the client, including accessing the node’s Tailscale environment variables. ### Who is affected? All Tailscale clients prior to version v.1.32.3 are affected. ### What should I do? Upgrade to v1.32.3 or later to remediate the issue. ### What is the impact? An attacker with access to the peer API on a node could use that access to read the node’s environment variables, including any credentials or secrets stored in environment variables. This may in...

A vulnerability identified in the Tailscale Windows client allows a malicious website to reconfigure the Tailscale daemon `tailscaled`, which can then be used to remotely execute code. **Affected platforms:** Windows **Patched Tailscale client versions:** v1.32.3 or later, v1.33.257 or later (unstable) ### What happened? In the Tailscale Windows client, the local API was bound to a local TCP socket, and communicated with the Windows client GUI in cleartext with no Host header verification. This allowed an attacker-controlled website visited by the node to rebind DNS to an attacker-controlled DNS server, and then make local API requests in the client, including changing the coordination server to an attacker-controlled coordination server. ### Who is affected? All Windows clients prior to version v.1.32.3 are affected. ### What should I do? If you are running Tailscale on Windows, upgrade to v1.32.3 or later to remediate the issue. ### What is the impact? An attacker-controlled coo...

### Impact The attacker can use the incorrect `Content-Type` to bypass the `Pre-Flight` checking of `fetch`. `fetch()` requests with Content-Type’s [essence](https://mimesniff.spec.whatwg.org/#mime-type-essence) as "application/x-www-form-urlencoded", "multipart/form-data", or "text/plain", could potentially be used to invoke routes that only accepts `application/json` content type, thus bypassing any [CORS protection](https://fetch.spec.whatwg.org/#simple-header), and therefore they could lead to a Cross-Site Request Forgery attack. ### Patches For `4.x` users, please update to at least `4.10.2`. For `3.x` users, please update to at least `3.29.4`. ### Workarounds Implement Cross-Site Request Forgery protection using [`@fastify/csrf`](https://www.npmjs.com/package/@fastify/csrf). ### References Check out the HackerOne report: https://hackerone.com/reports/1763832. ### For more information [Fastify security policy](https://github.com/fastify/fastify/security/policy)

A vulnerability in the "/admin/wlmultipleap.asp" of optilink OP-XT71000N version: V2.2 could allow an unauthenticated, remote attacker to conduct a cross-site request forgery (CSRF) attack to create Multiple WLAN BSSID.

This Metasploit module exploits a cross-site request forgery (CSRF) vulnerability in F5 Big-IP's iControl interface to write an arbitrary file to the filesystem. While any file can be written to any location as root, the exploitability is limited by SELinux; the vast majority of writable locations are unavailable. By default, we write to a script that executes at reboot, which means the payload will execute the next time the server boots. An alternate target - Login - will add a backdoor that executes next time a user logs in interactively. This overwrites a file, but we restore it when we get a session Note that because this is a CSRF vulnerability, it starts a web server, but an authenticated administrator must visit the site, which redirects them to the target.

The Booster for WooCommerce WordPress plugin before 5.6.7, Booster Plus for WooCommerce WordPress plugin before 5.6.5, Booster Elite for WooCommerce WordPress plugin before 1.1.7 do not have CSRF check in place when deleting files uploaded at the checkout, allowing attackers to make a logged in shop manager or admin delete them via a CSRF attack