The Popup Builder WordPress plugin through 4.1.15 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 even when the unfiltered_html capability is disallowed (for example in multisite setup).

CVE-2023-3226

Cross Site Scripting vulnerability in Service Provider Management System v.1.0 allows a remote attacker to execute arbitrary code and obtain sensitive information via the firstname, middlename and lastname parameters in the /php-spms/admin/?page=user endpoint.

**About the Application**

This Service Provider Management System v.1.0 is a sort of Content Management System (CMS) that is built specifically for companies that provide different services. The project is a company website that allows the management to dynamically manage the site information and other data on the front end. This project has 2 modules which are the Public and Management site.

The Management Site is the side of the system where accessible to the company staff or system-registered users only. On this site, users are required to log in with their valid system credentials to gain access to the features and functionalities. Users have 2 different roles which are the Administrator and the Staff. The Administrator users have the privilege to manage and access all the features and functionalities of the said site while the Staff users only have limited permissions. Here, system users can manage the list of services that their company provided. They can also update the dynamic page content of the public website on this side.

**Vulnerability Description**

Cross Site Scripting vulnerability in Service Provider Management System v.1.0 allows a remote attacker to execute arbitrary code and obtain sensitive information via the firstname, middlename and lastname parameters in the /php-spms/admin/?page=user endpoint.

**Vulnerable Code**

**Filename:** /php-spms/admin/user/index.php

**Vulnerable Endpoint:** /php-spms/admin/?page=user

**Vulnerable Parameter:** firstname, middlename, lastname

**Code:**

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<form action="" id="manage-user">	
	<input type="hidden" name="id" value="<?php echo $_settings->userdata('id') ?>">
		<div class="form-group">
			<label for="name">First Name</label>
			<input type="text" name="firstname" id="firstname" class="form-control" value="<?php echo isset($meta['firstname']) ? $meta['firstname']: '' ?>" required>
		</div>
		<div class="form-group">
			<label for="name">Middle Name</label>
			<input type="text" name="middlename" id="middlename" class="form-control" value="<?php echo isset($meta['middlename']) ? $meta['middlename']: '' ?>">
		</div>
		<div class="form-group">
			<label for="name">Last Name</label>
			<input type="text" name="lastname" id="lastname" class="form-control" value="<?php echo isset($meta['lastname']) ? $meta['lastname']: '' ?>" required>
		</div>
		<div class="form-group">
			<label for="username">Username</label>
			<input type="text" name="username" id="username" class="form-control" value="<?php echo isset($meta['username']) ? $meta['username']: '' ?>" required  autocomplete="off">
		</div>
		<div class="form-group">
			<label for="password">Password</label>
			<input type="password" name="password" id="password" class="form-control" value="" autocomplete="off"><small><i>Leave this blank if you dont want to change the password.</i></small>
		</div>
		<div class="form-group">
			<label for="" class="control-label">Avatar</label>
			<div class="custom-file">
				<input type="file" class="form-control" id="customFile" name="img" onchange="displayImg(this,$(this))" accept="image/png, image/jpeg">
			</div>
		</div>
		<div class="form-group d-flex justify-content-center">
			<img src="<?php echo validate_image(isset($meta['avatar']) ? $meta['avatar'] :'') ?>" alt="" id="cimg" class="img-fluid img-thumbnail">
		</div>
</form>

When users input their names, such as their firstname, middlename, and lastname, the website neglects the critical step of sanitizing this information to ensure it’s free from potentially harmful characters before storing it in the backend. This oversight creates a security vulnerability known as ‘Stored Cross-Site Scripting’ (Stored XSS), especially concerning these name parameters.

Stored Cross-Site Scripting (XSS) is a type of security vulnerability that occurs in web applications when user input, often in the form of text or other content, is not properly sanitized or validated before being stored on the server and then later displayed to other users. This vulnerability allows attackers to inject malicious scripts, typically in the form of JavaScript code, into the application’s data storage. When other users retrieve and view this data, the injected script code is executed within their browsers, potentially leading to a range of malicious actions.

**Impact of Stored Cross-Site Scripting**

The impacts of Stored Cross-Site Scripting (Stored XSS) are mentioned below:

**Session Hijacking**: Attackers can hijack user sessions, gaining unauthorized access to accounts and allowing them to perform actions on behalf of users or access confidential data.

**Manipulation of Web Pages**: Stored XSS can alter the appearance and functionality of web pages, potentially tricking users into executing unintended actions, clicking on malicious links, or downloading malware.

**Attack Scenario**

*   Go to http://application ip/php-spms/admin/?page=user.

*   Provide payload as "><script>alert("XSS on Firstname"), "><script>alert("XSS on Middlename"), "><script>alert("XSS on Lastname") on parameter such as firstname, middlename and lastname respectively.

_User Details_

*   Click on Update.
    
*   You will observe the popup of each payload we provided.
    

_XSS on Firstname_

_XSS on Middlename_

_XSS on Lastname_

Mitigating stored cross-site scripting (XSS) vulnerabilities is crucial for securing web applications. To prevent stored XSS, follow these best practices:

*   **Whitelist Input**: Only allow specific, safe characters and patterns in user input. Reject any input that doesn’t conform to this whitelist.
    
*   **Data Sanitization**: Filter and clean user input to remove or encode any potentially malicious characters. Use libraries like OWASP’s Java Encoder, PHP’s htmlspecialchars, or equivalent functions in other languages.
    
*   **Sanitization Libraries**: Use security libraries and frameworks that provide built-in XSS prevention mechanisms, such as Ruby on Rails, Django, or AngularJS.
    
*   **Use HTTP-Only Cookies**: Mark cookies as HTTP-only to prevent JavaScript from accessing them, reducing the impact of XSS attacks.
    
*   **Session Management**: Implement secure session management to ensure that session cookies and tokens are properly protected and rotated.
    
*   **Security Headers**: Use security headers like X-XSS-Protection and X-Content-Type-Options to instruct browsers to mitigate certain types of attacks.
    

That’s all in this writeup.

Thanks for reading this far. If you enjoyed the writeup, do support me **here**.

CVE-2023-43456: CVE-2023-43456 - Stored Cross-Site Scripting (XSS)

OPNsense versions 23.1.11_1, 23.7.3, and 23.7.4 suffer from cross site scripting vulnerabilities that can allow for privilege escalation.

Advisory X41-2023-001: Two Vulnerabilities in OPNsense  
===========================================================  
Highest Severity Rating: High  
Confirmed Affected Versions: 23.1.11_1, 23.7.3, 23.7.4  
Confirmed Patched Versions: Commit 484753b2abe3fd0fcdb73d8bf00c3fc3709eb8b7  
Vendor: Deciso B.V. / OPNsense  
Vendor URL: https://opnsense.org  
Credit: X41 D-Sec GmbH, Yasar Klawohn and JM  
Status: Public   
Advisory-URL: https://www.x41-dsec.de/lab/advisories/x41-2023-001-opnsense

Summary and Impact  
------------------  
The OPNsense dashboard displays widgets with information about the system,  
running services, gateways and more. These widgets can be arranged in  
different orders and columns. The values for the number of columns and the  
order of widgets are stored server-side and are the same for all users of an  
OPNsense instance. They are reflected unmodified on every visit. This can be  
abused by a low-privileged attacker to inject their own content into the  
page, enabling a cross-site scripting (XSS) attack that can result in  
privilege escalation.

Product Description  
-------------------  
OPNsense is an open source, FreeBSD-based firewall and routing operating  
system. It includes many features of commercial firewalls and can be managed  
entirely via its web GUI.

Stored XSS in the OPNsense Dashboard via the column_count Parameter  
===================================================================  
Severity Rating: High  
Vector: Network  
CWE: 79  
CVSS Score: 8.0  
CVSS Vector: 3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H  
Credit: X41 D-Sec GmbH, Yasar Klawohn

Analysis  
--------  
The number of columns displayed in the dashboard is set via an HTTP POST  
request to /index.php, using the column_count request parameter. This  
parameter is not properly escaped when returned to the client. To exploit  
this issue, the payload "><script>alert(1)</script> is submitted as part of  
the column_count parameter. This input is reflected unmodified in the  
response and on any subsequent visit to the dashboard by any user. Only the  
"Lobby: Login / Logout / Dashboard" permission is required to abuse this  
issue.

Once the server receives the POST request, the column_count parameter is  
written unmodified into the configuration:

} elseif ($_SERVER['REQUEST_METHOD'] === 'POST' && !empty($_POST['origin'])  
            && $_POST['origin'] == 'dashboard') {  
    // ...  
    if (!empty($_POST['column_count'])) {  
        $config['widgets']['column_count'] = $_POST['column_count'];  
    } elseif(isset($config['widgets']['column_count'])) {  
        unset($config['widgets']['column_count']);  
    }  
    write_config('Widget configuration has been changed');  
    header(url_safe('Location: /index.php'));  
    exit;  
}  
// from:  
// https://github.com/opnsense/core/blob/2306449329e462364c07317b23a1f257779a4fc8/src/www/index.php#L66-L79

If the column_count parameter is not empty, it is used unmodified: 

// ...  
if ($_SERVER['REQUEST_METHOD'] === 'GET') {  
    $pconfig = $config['widgets'];  
    // ...  
    $pconfig['column_count'] =  
       !empty($pconfig['column_count']) ? $pconfig['column_count'] : 2;  
    // ...  
// from:  
// https://github.com/opnsense/core/blob/306449329e462364c07317b23a1f257779a4fc8/src/www/index.php#L42

Below, the unmodified value is written:

  
<section class="page-content-main">  
  <form method="post" id="iform">  
    <input type="hidden" value="dashboard" name="origin" id="origin" />  
    <input type="hidden" value="" name="sequence" id="sequence" />  
    <input type="hidden" value="<?= $pconfig['column_count'];?>"  
        name="column_count" id="column_count_input" />  
  </form>  
  


Proof of Concept  
----------------  
Log in as root. On the left side, go to System -> Access -> Users, and add a  
new user. For "Effective Privileges", only select "Lobby: Login / Logout /  
Dashboard". The user is now only able to view the dashboard and the help  
pages.

Log in as that newly created user and open your browser's network monitor.  
In the OPNsense dashboard, select "1 column" from the top right and then  
press "save settings". Repeat the POST request and replace the column_count  
variable with

column_count=1"><script>alert(1)</script>

Now, log in as admin again, you should see an alert box resulting from the  
following HTML response:

<form method="post" id="iform">  
      
    <input type="hidden" value="1">  
        <script>alert(1)</script>"  
        name="column_count" id="column_count_input" />  
</form>

This is the stored XSS and can result in privilege escalation. The OPNsense  
developers did apply a Content-Security-Policy, but unfortunately allow  
unsafe-inline and unsafe-eval for scripts, which does not prevent the  
exploitation of this vulnerability.

Stored XSS in the OPNsense Dashboard via the sequence Parameter  
===============================================================  
Severity Rating: High   
Vector: Network  
CWE: 79  
CVSS Score: 8.0  
CVSS Vector: 3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H  
Credit: X41 D-Sec GmbH, JM and Yasar Klawohn

Analysis  
--------  
The order in which the widgets are displayed in the Dashboard is set via an  
HTTP POST request to /index.php, using the sequence request parameter. This  
parameter is not properly escaped when returned to the client. To exploit  
this issue, the payload "><script>alert(1)</script> is submitted as part of  
the sequence parameter. This input is reflected unmodified in the response  
and on any subsequent visit to the dashboard by any user. Only the "Lobby:  
Login / Logout / Dashboard" permission is required to abuse this issue.

The order in which widgets are displayed on the dashboard can be set in the  
same POST request, via the sequence parameter. The sequence parameter has the  
following format:

sequence=services_status-container:00000000-col3:show,  
    interface_list-container:00000001-col4:show,  
    gateways-container:00000002-col4:show

Once the server receives the POST request, the sequence parameter is written  
unmodified into the configuration:

} elseif ($_SERVER['REQUEST_METHOD'] === 'POST' && !empty($_POST['origin'])  
            && $_POST['origin'] == 'dashboard') {  
    if (!empty($_POST['sequence'])) {  
        $config['widgets']['sequence'] = $_POST['sequence'];  
    } elseif (isset($config['widgets']['sequence'])) {  
        unset($config['widgets']['sequence']);  
    }  
    // ...  
    write_config('Widget configuration has been changed');  
    header(url_safe('Location: /index.php'));  
    exit;  
}  
// from:  
// https://github.com/opnsense/core/blob/cbaf7cee1f0a6fabd1ec4c752a5d169c402976dc/src/www/index.php#L66-L80

When serving a GET request, the sequence parameter is returned unmodified,  
starting with a read of its value from the configuration:

// ...  
$pconfig = $config['widgets'];  
// set default dashboard view  
$pconfig['sequence'] = !empty($pconfig['sequence']) ?  
    $pconfig['sequence'] : '';  
// ...  
// from:  
// https://github.com/opnsense/core/blob/2306449329e462364c07317b23a1f257779a4fc8/src/www/index.php#L39-L41

sequence is then split by comma and further split by colon into name,  
sortKey, and state. The list of widgets is sorted on the server side using  
the sortKey.

$widgetSeqParts = explode(",", $pconfig['sequence']);  
foreach (glob('/usr/local/www/widgets/widgets/*.widget.php') as $php_file) {  
    $widgetItem = array();  
    // [...]  
    foreach ($widgetSeqParts as $seqPart) {  
        $tmp = explode(':', $seqPart);  
        if (count($tmp) == 3 &&  
            explode('-', $tmp[0])[0] == $widgetItem['name']  
        ) {  
            $widgetItem['state'] = $tmp[2];  
            $widgetItem['sortKey'] = $tmp[1];  
        }  
    }  
    $widgetCollection[] = $widgetItem;  
}  
// sort widgets  
usort($widgetCollection, function ($item1, $item2) {  
    return strcmp(strtolower($item1['sortKey']),  
        strtolower($item2['sortKey']));  
});  
// from:  
// https://github.com/opnsense/core/blob/2306449329e462364c07317b23a1f257779a4fc8/src/www/index.php#L44-L65

Finally, the sortKey is written unescaped into an HTML attribute:

<section  
    class="widgetdiv"  
    data-sortkey="<?=$widgetItem['sortKey'] ?>"  
    id="<?=$widgetItem['name'];?>"  
    style="display:<?=$divdisplay;?>;"  


Proof of Concept  
----------------  
Log in as root. On the left side, go to System -> Access -> Users, and add a  
new user. For "Effective Privileges", only select "Lobby: Login / Logout /  
Dashboard". The user is now only able to view the dashboard and the help  
pages.

Log in as that newly created user and open your browser's network monitor. In  
the OPNsense dashboard, reorder the widgets via drag-and-drop, then press  
"save settings".

Repeat the POST request and replace the sequence variable with

sequence=gateways-container:1"><script>alert(1)</script>-col4:show

Now, log in as admin again, you should see an alert box resulting from the  
following HTML response:

<div class="container-fluid">  
      
        <section class="widgetdiv" data-sortkey="1">  
            <script>alert(2)</script>  
            -col4" id="gateways"  style="display:block;">

This is the stored XSS and can result in privilege escalation.

The OPNsense developers did apply a Content-Security-Policy, but  
unfortunately allow unsafe-inline and unsafe-eval for scripts, which does not  
prevent the exploitation of this vulnerability.

Workarounds  
===========

Remove all effective privileges for /index.php* of low-privilege users.

Timeline  
========  
2023-09-13: Problem discovered

2023-09-14: Write-up and discovery of second finding

2023-09-19: Disclosure to Deciso B.V. / OPNsense

2023-09-19: Issue fixed upstream by Deciso B.V. / OPNsense

2023-09-20: CVE requested

2023-09-20: Informed Deciso B.V. / OPNsense that we will make the issues  
public the following day, since the patch is public

2023-09-21: Release of advisory

About X41 D-Sec GmbH  
====================  
X41 is an expert provider for application security services.  
Having extensive industry experience and expertise in the area of information  
security, a strong core security team of world class security experts enables  
X41 to perform premium security services.

Fields of expertise in the area of application security are security centered  
code reviews, binary reverse engineering and vulnerability discovery.  
Custom research and IT security consulting and support services are core  
competencies of X41.

OPNsense 23.1.11_1 / 23.7.3 / 23.7.4 Cross Site Scripting / Privilege Escalation

LogoBee CMS version 0.2 suffers from a cross site scripting vulnerability.

    ====================================================================================================================================| # Title     : LogoBee CMS v0.2 XSS Vulnerability                                                                                 || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 63.0.3 (32-bit)                                            || # Vendor    : https://logobee.com                                                                                                |  | # Dork      : intext:''Logo & Web Design by LogoBee''                                                                            |====================================================================================================================================poc :[+]  Dorking İn Google Or Other Search Enggine .[+]  use payload : /updates.php?id=<marquee><font color=lime size=32>Hacked by indoushka</font></marquee>[+]  http://vaxform127.0.0.1/updates.php?id=%3Cmarquee%3E%3Cfont%20color=lime%20size=32%3EHacked%20by%20indoushka%3C/font%3E%3C/marquee%3EGreetings to :=========================================================================================================================jericho * Larry W. Cashdollar * brutelogic* shadow_00715 *9aylas*djroot.dz*LiquidWorm*Hussin-X*D4NB4R *ViRuS_Ra3cH *yasMouh* CraCkEr  |=======================================================================================================================================

LogoBee CMS 0.2 Cross Site Scripting

Unauth. Reflected Cross-Site Scripting (XSS) vulnerability in Xtemos WoodMart plugin <= 7.2.4 versions.

**Solution**

 Fixed

Update the WordPress WoodMart theme to the latest available version (at least 7.2.5).

Found this useful? Thank Rafie Muhammad (Patchstack) for reporting this vulnerability. Buy a coffee ☕

Rafie Muhammad (Patchstack) discovered and reported this Cross Site Scripting (XSS) vulnerability in WordPress WoodMart Theme. This could allow a malicious actor to inject malicious scripts, such as redirects, advertisements, and other HTML payloads into your website which will be executed when guests visit your site. This vulnerability has been fixed in version 7.2.5.

**Other vulnerabilities in this theme**

 0 present

 5 patched

View all

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-41872: WordPress Woodmart theme <= 7.2.4 - Reflected Cross Site Scripting (XSS) vulnerability - Patchstack

Unauth. Reflected Cross-Site Scripting (XSS) vulnerability in Tyche Softwares Order Delivery Date for WooCommerce plugin <= 3.20.0 versions.

**Solution**

 Fixed

Update the WordPress Order Delivery Date for WooCommerce plugin to the latest available version (at least 3.20.1).

Phd discovered and reported this Cross Site Scripting (XSS) vulnerability in WordPress Order Delivery Date for WooCommerce Plugin. This could allow a malicious actor to inject malicious scripts, such as redirects, advertisements, and other HTML payloads into your website which will be executed when guests visit your site. This vulnerability has been fixed in version 3.20.1.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-41874: WordPress Order Delivery Date for WooCommerce plugin <= 3.20.0 - Reflected Cross Site Scripting (XSS) vulnerability - Patchstack

Auth. (admin+) Stored Cross-Site Scripting (XSS) vulnerability in Christoph Rado Cookie Notice & Consent plugin <= 1.6.0 versions.

**Solution**

 Fixed

Update the WordPress Cookie Notice & Consent plugin to the latest available version (at least 1.6.1).

DoYeon Park (p6rkdoye0n) discovered and reported this Cross Site Scripting (XSS) vulnerability in WordPress Cookie Notice & Consent Plugin. This could allow a malicious actor to inject malicious scripts, such as redirects, advertisements, and other HTML payloads into your website which will be executed when guests visit your site. This vulnerability has been fixed in version 1.6.1.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-41948: WordPress Cookie Notice & Consent plugin <= 1.6.0 - Cross Site Scripting (XSS) vulnerability - Patchstack

Auth. (admin+) Cross-Site Scripting (XSS) vulnerability in Avirtum iFolders plugin <= 1.5.0 versions.

**Solution**

 Fixed

Update the WordPress iFolders plugin to the latest available version (at least 1.5.1).

emad discovered and reported this Cross Site Scripting (XSS) vulnerability in WordPress iFolders Plugin. This could allow a malicious actor to inject malicious scripts, such as redirects, advertisements, and other HTML payloads into your website which will be executed when guests visit your site. This vulnerability has been fixed in version 1.5.1.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-41949: WordPress iFolders plugin <= 1.5.0 - Cross Site Scripting (XSS) vulnerability - Patchstack

The Contact Form by FormGet plugin for WordPress is vulnerable to Stored Cross-Site Scripting via 'formget' shortcode in versions up to, and including, 5.5.5 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers with contributor-level and above permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

CVE-2023-5125: index.php in formget-contact-form/trunk – WordPress Plugin Repository

Taskhub version 2.8.8 suffers from a cross site scripting vulnerability.

    ## Title: TASKHUB-2.8.8-XSS-Reflected## Author: nu11secur1ty## Date: 09/22/2023## Vendor: https://codecanyon.net/user/infinitietech## Software: https://codecanyon.net/item/taskhub-project-management-finance-crm-tool/25685874## Reference: https://portswigger.net/web-security/cross-site-scripting## Description:The value of the JSON parameter within the project parameter is copiedinto the HTML document as plain text between tags. The payloadvn5mr<img src=a onerror=alert(1)>i62kl was submitted in the JSONparameter within the project parameter. This input was echoedunmodified in the application's response. The already authenticated(by using a USER ACCOUNT)attacker can get a CSRF token and cookiesession it depends on the scenarios.STATUS: HIGH Vulnerability[+]Test exploit:```surw7%3Cscript%3Ealert(1)%3C%2fscript%3E```## Reproduce:[href](https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/infinitietech/TASKHUB-2.8.8)## Proof and Exploit:[href](https://www.nu11secur1ty.com/2023/09/taskhub-288-xss-reflected.html)## Time spent:01:10:00

Tag

#xss