#csrf

### Impact The [graphql-upload](https://www.npmjs.com/package/graphql-upload) npm package can execute GraphQL operations contained in `content-type: multipart/form-data` POST requests. Because they are POST requests, they can contain GraphQL mutations. Because they use `content-type: multipart/form-data`, they can be "simple requests" which are not preflighted by browsers. If your GraphQL server uses `graphql-upload` and uses `SameSite=None` cookies for authentication, then JS on any origin can cause browsers to send cookie-authenticated mutations to your GraphQL server, which will be executed without checking your CORS policy first. (The attack won't be able to see the response to the mutation if your CORS policy is set up properly, but the side effects of the mutation will still happen.) Additionally, if your GraphQL server uses `graphql-upload` relies on network properties for security (whether by explicitly looking at the client's IP address or by only being available on a privat...

Dolibarr ERP & CRM <=15.0.3 is vulnerable to Eval injection. By default, any administrator can be added to the installation page of dolibarr, and if successfully added, malicious code can be inserted into the database and then execute it by eval.

Cross-Site Request Forgery (CSRF) vulnerability in Cozmoslabs Profile Builder plugin <= 3.6.0 at WordPress allows uploading the JSON file and updating the options. Requires Import and Export add-on.

In AdGuardHome, versions v0.95 through v0.108.0-b.13 are vulnerable to Cross-Site Request Forgery (CSRF), in the custom filtering rules functionality. An attacker can persuade an authorized user to follow a malicious link, resulting in deleting/modifying the custom filtering rules. The file that contains the vulnerable code is no longer present as of v0.108.0-b.16.

In AdGuardHome, versions v0.95 through v0.108.0-b.13 are vulnerable to Cross-Site Request Forgery (CSRF), in the custom filtering rules functionality. An attacker can persuade an authorized user to follow a malicious link, resulting in deleting/modifying the custom filtering rules.

In Gogs, versions v0.6.5 through v0.12.10 are vulnerable to Stored Cross-Site Scripting (XSS) that leads to an account takeover.

The Disable User Login WordPress plugin through 1.0.1 does not have authorisation and CSRF checks when updating its settings, allowing unauthenticated attackers to block (or unblock) users at will.

The Simple File List WordPress plugin before 4.4.12 does not implement nonce checks, which could allow attackers to make a logged in admin create new page and change it's content via a CSRF attack.

The Woo Billingo Plus WordPress plugin before 4.4.5.4, Integration for Billingo & Gravity Forms WordPress plugin before 1.0.4, Integration for Szamlazz.hu & Gravity Forms WordPress plugin before 1.2.7 are lacking CSRF checks in various AJAX actions, which could allow attackers to make logged in Shop Managers and above perform unwanted actions, such as deactivate the plugin's license

### Impact _What kind of vulnerability is it? Who is impacted?_ The default cookie name (and documentation recommendation) was prefixed with `Host__` instead of `__Host-`. The point of this prefix is for additional security, to ensure that, when no domain option is provided in the cookie options, we can guarantee the cookie came from the correct domain. ### Patches _Has the problem been patched? What versions should users upgrade to?_ Yes, the problem is patched from version 2.2.1, this will not be back ported, but you can use the workaround described below. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ You can work around this by providing a custom `cookieName` as part of the options, which is correctly prefixed with `__Host-`. ### References _Are there any links users can visit to find out more?_ https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#cookie-with-__host-prefix ...