Trustwave report also finds 2022 is set to surpass 2021 for volume of critical CVEs

Trustwave report also finds 2022 is set to surpass 2021 for volume of critical CVEs

The rush to patch systems affected by the landmark Log4Shell vulnerability has coincided with a wider improvement in patching rates for the most critical flaws, a report has found.

The remote code execution (RCE) flaw in Apache Log4j (CVE-2021-44228), the near-ubiquitous open source Java logging utility, sent organizations across the ecosystem scrambling to fix applications or patch systems after it emerged in December 2021.

Eight months on, the 2022 Trustwave SpiderLabs Telemetry Report has concluded that organizations “finally understand the necessity of having a solid security posture”.

RECOMMENDED Graph-based JavaScript bug scanner discovers more than 100 zero-days in Node.js libraries

Shodan searches performed by Trustwave SpiderLabs researchers revealed a sharp fall in the proportion of affected instances vulnerable to 2022’s highest profile vulnerabilities versus 2021’s equivalent flaws.

“Vulnerability disclosure-to-patch times have decreased,” Alex Rothacker, director of research and security scanning at Trustwave, told The Daily Swig.

**Celebrity factor**

He also noticed that security flaws’ “level of celebrity” was tied to both patching rates and patching speeds, with Log4j and Spring Framework instances outscoring what Rothacker said are lower profile issues in F5’s BIG-IP and Atlassian’s Confluence on these fronts.

For instance, only 0.36% of 405,993 instances of the most popular products running Log4j were vulnerable to the first Log4Shell patch (as opposed to the subsequent bypass) six months after exploits surfaced.

Equivalent numbers were 0.075% of 452,520 instances running unpatched versions of Spring Framework, another popular open source Java component, in regard to ‘Spring4Shell’ (CVE-2022-22965) three months after its disclosure.

Instances vulnerable to RCEs in F5’s BIG-IP (CVE-2022-1388) and Atlassian Confluence Server and Data Center (CVE-2022-26134) were 2.73% of 1,719 after disclosure and 4.44% of 7,074 hosts respectively – although disclosure was much more recent in these cases.

Catch up on the latest Log4j vulnerability news

By contrast, Trustwave’s 2021 report found that more than 50% of instances were vulnerable in relation to each of three similarly impactful vulnerabilities, weeks or months after patch release.

“Log4Shell seems to have been a call to action for many organizations,” said Rothacker. “The volume of questions and requests for remediation help that we received from customers for Log4Shell was unprecedented.”

**Critical mass**

This year is on course to comfortable eclipse 2021 in terms of both number of CVEs published and the proportion of which that are critical, the report found.

For instance, Rothacker said that August has already surpassed all previous months in 2022 and 2021, with 3,779 CVEs published as of August 26, while July and June also saw high numbers of 2,226 and 2,377 respectively.

Critical vulnerabilities account for 18% of 2022 CVEs, up from 13% of CVEs in 2021.

The report also discovered that some affected instances were still vulnerable to CVEs dating back as far as 2016, with the most widespread bug being CVE-2017-15906, an issue in encrypted remote login tool OpenSSH.

Despite being distributed in most Linux distributions by default, the bug’s medium severity means “it is most likely that many organizations do not see it as a significant issue and are de-prioritizing fixing it” said Rothacker.

“Other listed vulnerabilities either are for less commonly deployed software e.g CVE-2018-15199, or do have other mitigations, or constraints e.g CVE-2018-1312, that make it less likely that they will be exploited,” he added.

The top three CWE classifications for 2022 are cross-site scripting (XSS), SQL injection, and out-of-bounds write bugs.

RELATED CWE Top 25: These are the most dangerous software weaknesses of 2022

Log4Shell legacy? Patching times plummet for most critical vulnerabilities – report

ODGen tool was presented at this year’s Usenix Security Symposium

ODGen tool was presented at this year’s Usenix Security Symposium

Researchers at Johns Hopkins University have developed a graph-based code analysis tool that can detect a wide range of vulnerabilities in JavaScript programs.

Called ODGen, the tool was presented at this year’s Usenix Security Symposium and addresses some of the challenges that limited the use of graph-based security tools in analyzing JavaScript programs.

The researchers proved the effectiveness of ODGen by applying it to thousands of Node.js libraries, where it discovered 180 zero-day vulnerabilities and received 70 CVEs.

**Graph-based methods**

Graph-based scanners parse source code files to build a graph structure that represents the different properties and execution branches of an application. This graph can then be used to model and find vulnerabilities in the source code.

Graph query-based approaches have proven to be very effective in detecting vulnerabilities in some programming languages. One technique in particular, Code Property Graph (CPG), has proven to be successful in securing C/C++ and PHP code.

**RECOMMENDED** Critical command injection vulnerability discovered in Bitbucket Server and Data Center

Inspired by the success of graph methods – particularly CPG – the researchers at Johns Hopkins University tried to apply them to JavaScript. While there are different tools for finding specific vulnerabilities in JavaScript code, graph-based tools promise to provide a general framework for detecting all kinds of vulnerabilities.

“JavaScript, particularly Node.js, is becoming a vital community with millions of packages these days,” Yinzhi Cao, co-author of the paper and assistant professor of computer science at Johns Hopkins University, told _The Daily Swig_.

“At the same time, many of these NPM packages are less maintained and vulnerabilities are prevalent in the NPM ecosystem. That is why we decided to perform the study to make the ecosystem a safer environment.”

However, their initial findings showed that CPG is not very effective in JavaScript due to the language’s dynamic structure, which makes it much more difficult to parse and analyze object relations and program branches prior to execution.

“CPG does not model detailed object relations including (i) prototype chains and (ii) object-level data flows. Therefore, it is hard to apply CPG to detect JavaScript-specific vulnerabilities, such as Prototype Pollution and Internal Property Tampering. And it is hard to model fine-grained object-level data flows in CPG,” Cao said.

**Object Dependence Graph**

In their paper, the researchers propose Object Dependence Graph (ODG) as a novel method to build graphs from JavaScript code. ODG uses some of the components of CPG, such as Abstract Syntax Trees (AST), and adds features that are specific to JavaScript, including fine-grained data dependency between objects. Accordingly, the researchers created ODGen, a tool for creating and querying ODGs.

“Our proposed ODGen abstractly interprets JavaScript code and generates a so-called Object Dependence Graph to capture such dynamic features including object relations so that a graph query-based approach can easily obtain such information and detect vulnerabilities,” Cao said.

Read more of the latest infosec research news

The researchers designed ODGen to detect vulnerabilities at application and package levels. They tested the tool on 330 documented vulnerabilities that spanned across 16 categories, including cross-site scripting (XSS), server- and client-side request forgery (SSRF/CSRF), SQL injection, prototype pollution, and command injection.

The tool was able to detect 13 types of vulnerabilities with very high accuracy, discovering 302 of the 330 bugs.

They expanded their test by crawling 300,000 NPM packages and applying ODGen with graph queries to detect queries. ODGen reported nearly 3,000 security bugs, of which the researchers verified 264 that belonged to libraries with more than 1,000 weekly downloads. They were able to confirm and report 180 security bugs, many of which were in libraries that are used widely in web applications. Of the discovered vulnerabilities, 70 were assigned CVEs.

ODGen shows how much more needs to be done to secure the open source JavaScript ecosystem and how the adaptation of existing tools can help in developing holistic approaches to securing Node.js libraries.

In the future, Cao said, the team might extend ODGen to other programming languages used in web applications, including PHP and Java.

**YOU MIGHT LIKE** Ethereum Foundation offers $1m bug bounty payouts with proof-of-stake migration multiplier

Graph-based JavaScript bug scanner discovers more than 100 zero-day vulnerabilities in Node.js libraries

Cross-site Scripting (XSS) - Generic in GitHub repository nuxt/framework prior to -.

CVE-2022-3063

All versions of package x-data-spreadsheet are vulnerable to Cross-site Scripting (XSS) due to missing sanitization of values inserted into the cells.



A cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to accept a request as originating from a trusted source.

This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.

Injecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.

Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as &lt; and > can be coded as &gt; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.

The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.

**Types of attacks**

There are a few methods by which XSS can be manipulated:

Type

Origin

Description

**Stored**

Server

The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.

**Reflected**

Server

The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.

**DOM-based**

Client

The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.

**Mutated**

The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.

**Affected environments**

The following environments are susceptible to an XSS attack:

*   Web servers
*   Application servers
*   Web application environments

**How to prevent**

This section describes the top best practices designed to specifically protect your code:

*   Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
*   Convert special characters such as ?, &, /, <, > and spaces to their respective HTML or URL encoded equivalents.
*   Give users the option to disable client-side scripts.
*   Redirect invalid requests.
*   Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
*   Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
*   Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.

CVE-2022-25646: Snyk Vulnerability Database | Snyk

IBM Engineering Test Management 7.0, 7.0.1, and 7.0.2 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.  IBM X-Force ID:  210671.

**Security Bulletin**

  

**Summary**

ETM allows customization of "Execution States" names, allowing the injection of XSS payloads and making them vulnerable to XSS. Custom values into the names of "Execution States" are not encoded while displaying them on the "Test Cases Execution Records" (TCER) pages, allowing the execution of Javascript code. This is classified as "CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')".

**Vulnerability Details**

**CVEID:**   CVE-2021-38934  
**DESCRIPTION:**   IBM Engineering Test Management is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.  
CVSS Base score: 5.4  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/210671 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N)

**Affected Products and Versions**

Affected Product(s)

Version(s)

Rational Quality Manager (RQM) 

6.0.6.1

Engineering Test Management (ETM) 

7.0.1

ETM

7.0.2

RQM

6.0.6

ETM

7.0.0

  

**Workarounds and Mitigations**

None

**References**

Off

**Change History**

26 Aug 2022: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY. In addition to other efforts to address potential vulnerabilities, IBM periodically updates the record of components contained in our product offerings. As part of that effort, if IBM identifies previously unidentified packages in a product/service inventory, we address relevant vulnerabilities regardless of CVE date. Inclusion of an older CVEID does not demonstrate that the referenced product has been used by IBM since that date, nor that IBM was aware of a vulnerability as of that date. We are making clients aware of relevant vulnerabilities as we become aware of them. "Affected Products and Versions" referenced in IBM Security Bulletins are intended to be only products and versions that are supported by IBM and have not passed their end-of-support or warranty date. Thus, failure to reference unsupported or extended-support products and versions in this Security Bulletin does not constitute a determination by IBM that they are unaffected by the vulnerability. Reference to one or more unsupported versions in this Security Bulletin shall not create an obligation for IBM to provide fixes for any unsupported or extended-support products or versions.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU059","label":"IBM Software w\\/o TPS"},"Product":{"code":"SSUVV6","label":"IBM Engineering Test Management"},"Component":"","Platform":\[{"code":"PF025","label":"Platform Independent"}\],"Version":"7.0, 7.0.1, 7.0.2","Edition":"","Line of Business":{"code":"LOB59","label":"Sustainability Software"}},{"Business Unit":{"code":"BU059","label":"IBM Software w\\/o TPS"},"Product":{"code":"SSR27Q","label":"Rational Quality Manager"},"Component":"","Platform":\[{"code":"PF025","label":"Platform Independent"}\],"Version":"6.0.6, 6.0.6.1","Edition":"","Line of Business":{"code":"LOB59","label":"Sustainability Software"}}\]

CVE-2021-38934: Custom "Execution States" names on IBM Engineering Test Management TCER pages are vulnerable to XSS ( CVE-2021-38934 )

In oauth2-server (aka node-oauth2-server) through 3.1.1, the value of the redirect_uri parameter received during the authorization and token request is checked against an incorrect URI pattern ("[a-zA-Z][a-zA-Z0-9+.-]+:") before making a redirection. This allows a malicious client to pass an XSS payload through the redirect_uri parameter while making an authorization request. NOTE: this vulnerability is similar to CVE-2020-7741.

I would like to report several security vulnerabilities that I found while using this OAuth server library.

The vulnerabilities and their consequences are listed as following:

**Vulnerability 1:** Missing PKCE support for public clients.

**_Consequences:_** As specified in RFC-7636 (https://tools.ietf.org/html/rfc7636), public clients (e.g., mobile/desktop apps) using Authorization Code Flow are susceptible to authorization code interception attack and PKCE is recommended to mitigate this attack. Since public clients cannot maintain client-side confidentiality regarding client secrets, such attacks have been noticed in the wild extensively.

**Vulnerability 2:** Does not revoke previously issued token if authorization\_code is used more than once.

**_Consequences:_** As specified in RFC-6749 (https://tools.ietf.org/html/rfc6749#section-4.1.2), If an authorization code is used more than once, the authorization server must deny the request and should revoke all tokens previously issued based on that authorization code. Though OAuth2-server currently denies the request in such cases, it doesn't revoke the tokens issued previously to the client, which leaves the user's resources vulnerable as attackers might exploit the previous tokens to get them.

**Vulnerability 3:** Allows fragment in the redirect URI.

**_Consequences:_** Many OAuth attacks regarding misuse of redirect uris have been observed in the wild. As specified in the RFC-6749 (https://tools.ietf.org/html/rfc6749#section-3.1.2), authorization server should not allow fragments in the redirect uri as it allows the attackers to exploit the redirect uri and hence intercept the auth\_code/token.

Any comments or fixes regarding these vulnerabilities?

Thank you.

CVE-2020-26938: Multiple Security Vulnerabilities in Auth and Token Endpoint · Issue #637 · oauthjs/node-oauth2-server

Cross-site Scripting (XSS) - Stored in GitHub repository snipe/snipe-it prior to v6.0.11.

@@ -22,12 +22,13 @@ class Helper

\* @since \[v2.0\]

\* @return string

\*/

public static function parseEscapedMarkedown($str)

public static function parseEscapedMarkedown($str = null)

{

$Parsedown = new \\Parsedown();

$Parsedown\->setSafeMode(true);

  

if ($str) {

return $Parsedown\->text(e($str));

return $Parsedown\->text($str);

}

}

  

@@ -2,6 +2,7 @@

  

namespace App\\Models;

  

use App\\Helpers\\Helper;

use App\\Models\\Traits\\Acceptable;

use App\\Models\\Traits\\Searchable;

use App\\Presenters\\Presentable;

@@ -299,15 +300,14 @@ public function requireAcceptance()

\*/

public function getEula()

{

$Parsedown = new \\Parsedown();

  

if ($this\->category\->eula\_text) {

return $Parsedown\->text(e($this\->category\->eula\_text));

return Helper::parseEscapedMarkedown($this\->category\->eula\_text);

} elseif ((Setting::getSettings()->default\_eula\_text) && ($this\->category\->use\_default\_eula == '1')) {

return $Parsedown\->text(e(Setting::getSettings()->default\_eula\_text));

return Helper::parseEscapedMarkedown(Setting::getSettings()->default\_eula\_text);

}

  

return null;

return null;

}

  

/\*\*

@@ -5,6 +5,7 @@

use App\\Events\\AssetCheckedOut;

use App\\Events\\CheckoutableCheckedOut;

use App\\Exceptions\\CheckoutNotAllowed;

use App\\Helpers\\Helper;

use App\\Http\\Traits\\UniqueSerialTrait;

use App\\Http\\Traits\\UniqueUndeletedTrait;

use App\\Models\\Traits\\Acceptable;

@@ -875,13 +876,12 @@ public function requireAcceptance()

\*/

public function getEula()

{

$Parsedown = new \\Parsedown();

  

  

if (($this\->model) && ($this\->model\->category)) {

if ($this\->model\->category\->eula\_text) {

return $Parsedown\->text(e($this\->model\->category\->eula\_text));

return Helper::parseEscapedMarkedown($this\->model\->category\->eula\_text);

} elseif ($this\->model\->category\->use\_default\_eula == '1') {

return $Parsedown\->text(e(Setting::getSettings()->default\_eula\_text));

return Helper::parseEscapedMarkedown(Setting::getSettings()->default\_eula\_text);

} else {

return false;

}

@@ -9,6 +9,7 @@

use Illuminate\\Database\\Eloquent\\SoftDeletes;

use Illuminate\\Support\\Facades\\Gate;

use Watson\\Validating\\ValidatingTrait;

use App\\Helpers\\Helper;

  

/\*\*

\* Model for Categories. Categories are a higher-level group

@@ -207,12 +208,11 @@ public function models()

\*/

public function getEula()

{

$Parsedown = new \\Parsedown();

  

if ($this\->eula\_text) {

return $Parsedown\->text(e($this\->eula\_text));

return Helper::parseEscapedMarkedown($this\->eula\_text);

} elseif ((Setting::getSettings()->default\_eula\_text) && ($this\->use\_default\_eula == '1')) {

return $Parsedown\->text(e(Setting::getSettings()->default\_eula\_text));

return Helper::parseEscapedMarkedown(Setting::getSettings()->default\_eula\_text);

} else {

return null;

}

@@ -2,6 +2,7 @@

  

namespace App\\Models;

  

use App\\Helpers\\Helper;

use App\\Models\\Traits\\Acceptable;

use App\\Models\\Traits\\Searchable;

use App\\Presenters\\Presentable;

@@ -265,12 +266,10 @@ public function requireAcceptance()

\*/

public function getEula()

{

$Parsedown = new \\Parsedown();

  

if ($this\->category\->eula\_text) {

return $Parsedown\->text(e($this\->category\->eula\_text));

return Helper::parseEscapedMarkedown($this\->category\->eula\_text);

} elseif ((Setting::getSettings()->default\_eula\_text) && ($this\->category\->use\_default\_eula == '1')) {

return $Parsedown\->text(e(Setting::getSettings()->default\_eula\_text));

return Helper::parseEscapedMarkedown(Setting::getSettings()->default\_eula\_text);

} else {

return null;

}

@@ -2,6 +2,7 @@

  

namespace App\\Models;

  

use App\\Helpers\\Helper;

use App\\Models\\Traits\\Searchable;

use App\\Presenters\\Presentable;

use Carbon\\Carbon;

@@ -337,12 +338,11 @@ public function requireAcceptance()

\*/

public function getEula()

{

$Parsedown = new \\Parsedown();

  

if ($this\->category\->eula\_text) {

return $Parsedown\->text(e($this\->category\->eula\_text));

return Helper::parseEscapedMarkedown($this\->category\->eula\_text);

} elseif ($this\->category\->use\_default\_eula == '1') {

return $Parsedown\->text(e(Setting::getSettings()->default\_eula\_text));

return Helper::parseEscapedMarkedown(Setting::getSettings()->default\_eula\_text);

} else {

return false;

}

@@ -8,9 +8,10 @@

use Illuminate\\Support\\Collection;

use Illuminate\\Support\\Facades\\App;

use Illuminate\\Support\\Facades\\Cache;

use Parsedown;

use App\\Helpers\\Helper;

use Watson\\Validating\\ValidatingTrait;

  

  

/\*\*

\* Settings model.

\*/

@@ -135,7 +136,6 @@ public static function setupCompleted(): bool

public function lar\_ver(): string

{

$app = App::getFacadeApplication();

  

return $app::VERSION;

}

  

@@ -147,9 +147,7 @@ public function lar\_ver(): string

public static function getDefaultEula(): ?string

{

if (self::getSettings()->default\_eula\_text) {

$parsedown = new Parsedown();

  

return $parsedown\->text(e(self::getSettings()->default\_eula\_text));

return Helper::parseEscapedMarkedown(self::getSettings()->default\_eula\_text);

}

  

return null;

@@ -2,6 +2,8 @@

  

namespace App\\Presenters;

  

use App\\Helpers\\Helper;

  

/\*\*

\* Class AssetModelPresenter

\*/

@@ -159,10 +161,8 @@ public static function dataTableLayout()

\*/

public function note()

{

$Parsedown = new \\Parsedown();

  

if ($this\->model\->note) {

return $Parsedown\->text($this\->model\->note);

return Helper::parseEscapedMarkedown($this\->model\->note);

}

}

  

@@ -28,7 +28,7 @@

@if ($snipeSettings\->login\_note)

<div class\="col-md-12"\>

<div class\="alert alert-info"\>

{!! Parsedown::instance()\->text(e($snipeSettings\->login\_note)) !!}

{!! Helper::parseEscapedMarkedown($snipeSettings\->login\_note) !!}

</div\>

</div\>

@endif

@@ -17,7 +17,7 @@

<div class\="box-body"\>

<div class\="row"\>

<div class\="col-md-12"\>

{!! Parsedown::instance()\->text(e($snipeSettings\->dashboard\_message)) !!}

{!! Helper::parseEscapedMarkedown($snipeSettings\->dashboard\_message) !!}

</div\>

</div\>

</div\>

@@ -827,7 +827,7 @@

</div\>

@if ($snipeSettings\->footer\_text!='')

<div class\="pull-right"\>

{!! Parsedown::instance()\->text(e($snipeSettings\->footer\_text)) !!}

{!! Helper::parseEscapedMarkedown($snipeSettings\->footer\_text) !!}

</div\>

@endif

  

**0 comments on commit 9cf5f30**

Please sign in to comment.

CVE-2022-3035: Set safeMode to true and use helper for all parsedown · snipe/snipe-it@9cf5f30

The Simply Schedule Appointments WordPress plugin before 1.5.7.7 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-2022-2374

The WooCommerce PDF Invoices & Packing Slips WordPress plugin before 3.0.1 does not sanitise and escape some parameters before outputting them back in an attributes of an admin page, leading to Reflected Cross-Site Scripting.

CVE-2022-2537

The WP Hide & Security Enhancer WordPress plugin before 1.8 does not escape a parameter before outputting it back in an attribute of a backend page, leading to a Reflected Cross-Site Scripting

Tag

#xss