When on a security audit for a client it was discovered that a key component – the open-source private paste service PrivateBin contained a previously undocumented flaw. Cross-site-scripting is nothing new. I actually feel there must be prehistoric cave paintings and markings somewhere in the world containing some variation of <script>alert(1)</script>. Although XSS payloads embedded within images are somewhat less common, this is still a valid method (in certain cases) of delivering a payload to an unsuspecting victim.
As such it was interesting to find that this issue, which had been found in version 1.3.5 had been lurking undiscovered since version 0.21 when the project was sill known as ZeroBin.
Embedding a payload within an SVG image and using this as an attachment to a paste resulted in a preview image being displayed to the end user. Once this was viewed in a new tab, the XSS executed.The following Proof of Concept was provided and has been documented in PrivateBin’s report:

1. Create the following SVG as a file:

       <?xml version="1.0" standalone="no"?>
       <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
   "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
       <svg version="1.1" baseProfile="full"
   xmlns="http://www.w3.org/2000/svg">
       <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900"
   stroke="#004400"/>
       <script type="text/javascript">
       alert(document.domain);
       </script>
       </svg>

2. Upload it as an attachment to a PrivateBin instance that has attachments enabled and hasn’t set the recommended content security policy (in particular, one that has either no content security policy set or that allows * or blob: as a script-src).
3. Open the paste. (In a real attack scenario this would be done by the victim.) – The SVG is rendered safely as a preview, and script isn’t yet executed.
4. Now (depending on your device) right-click or long tap on the image and open it in a new tab.
5. Now a blob: URI opens in a new tab with the image and the modal is shown, therefore the script got executed.So if it was as simple as it seems, why had this not been found before now?

To give credit where credit is due, PrivateBin really know their stuff.
They have (and had) a strict content-security-policy (CSP) in place which would mitigate this kind of attack. We were just (un?)fortunate enough to be using a Linux version of a Chrome-based browser which ignored the CSP entirely. Aside from this, there are instances out in the wild where the default CSP had been edited, lowering the effectiveness.The official report from PrivateBin and the subsequent reporting from Portswigger’s “The Daily Swig” goes into more detail on how to entice a user to view an image in a new tab and covers the mitigations put in place to further patch the vulnerability.

We would like to thank our client (who will remain unnamed due to our strict NDAs), Portswigger for coverage and most of all PrivateBin for their fast and effective communication, patching, and release of a new version.

References:
https://privatebin.info/reports/vulnerability-2022-04-09.html
https://portswigger.net/daily-swig/xss-vulnerability-in-open-source-tool-privatebin-patched
https://nvd.nist.gov/vuln/detail/CVE-2022-24833