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

The Simple Banner WordPress plugin before 2.12.0 does not properly sanitize its "Simple Banner Text" Settings allowing high privilege users to perform Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed.

CVE-2022-0446

The WP phpMyAdmin WordPress plugin before 5.2.0.4 does not escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks when the unfiltered_html capability is disallowed (for example in multisite setup)

CVE-2022-2407

The Feed Them Social WordPress plugin before 3.0.1 does not sanitise and escape a parameter before outputting it back in the page, leading to a Reflected Cross-Site Scripting

CVE-2022-2383

The WP Sticky Button WordPress plugin before 1.4.1 does not have authorisation and CSRF checks when saving its settings, allowing unauthenticated users to update them. Furthermore, due to the lack of escaping in some of them, it could lead to Stored Cross-Site Scripting issues

CVE-2022-2375

The WP Social Chat WordPress plugin before 6.0.5 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks.

CVE-2022-2361

The Student Result or Employee Database WordPress plugin before 1.7.5 does not have CSRF in its AJAX actions, allowing attackers to make logged in user with a role as low as contributor to add/edit and delete students via CSRF attacks. Furthermore, due to the lack of sanitisation and escaping, it could also lead to Stored Cross-Site scripting

CVE-2022-2312

CVE-2022-2532

The Coming Soon - Under Construction WordPress plugin through 1.1.9 does not sanitize and escape some of its settings, which could allow high-privileged users to perform Cross-Site Scripting attacks even when unfiltered_html is disallowed

CVE-2022-1322

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.

Tag

#xss