Spark's Apache Maven-based build includes a convenience script, 'build/mvn', that downloads and runs a zinc server to speed up compilation. It has been included in release branches since 1.3.x, up to and including master. This server will accept connections from external hosts by default. A specially-crafted request to the zinc server could cause it to reveal information in files readable to the developer account running the build. Note that this issue does not affect end users of Spark, only developers building Spark from source code.

**Reporting security issues**

Apache Spark uses the standard process outlined by the Apache Security Team for reporting vulnerabilities. Note that vulnerabilities should not be publicly disclosed until the project has responded.

To report a possible security vulnerability, please email security@spark.apache.org. This is a non-public list that will reach the Apache Security team, as well as the Spark PMC.

**Known security issues****CVE-2022-31777: Apache Spark XSS vulnerability in log viewer UI Javascript**

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:

*   3.2.1 and earlier
*   3.3.0

Description:

A stored cross-site scripting (XSS) vulnerability in Apache Spark 3.2.1 and earlier, and 3.3.0, allows remote attackers to execute arbitrary JavaScript in the web browser of a user, by including a malicious payload into the logs which would be returned in logs rendered in the UI.

Mitigation:

*   Upgrade to Spark 3.2.2, or 3.3.1 or later

Credit:

*   Florian Walter (Veracode)

**CVE-2022-33891: Apache Spark shell command injection vulnerability via Spark UI**

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:

*   3.0.3 and earlier
*   3.1.1 to 3.1.2
*   3.2.0 to 3.2.1

Description:

The Apache Spark UI offers the possibility to enable ACLs via the configuration option spark.acls.enable. With an authentication filter, this checks whether a user has access permissions to view or modify the application. If ACLs are enabled, a code path in HttpSecurityFilter can allow someone to perform impersonation by providing an arbitrary user name. A malicious user might then be able to reach a permission check function that will ultimately build a Unix shell command based on their input, and execute it. This will result in arbitrary shell command execution as the user Spark is currently running as.

Mitigation

*   Update to Spark 3.1.3, 3.2.2, or 3.3.0 or later

Credit:

*   Kostya Torchinsky (Databricks)

**CVE-2021-38296: Apache Spark™ Key Negotiation Vulnerability**

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:

*   Apache Spark 3.1.2 and earlier

Description:

Apache Spark supports end-to-end encryption of RPC connections via spark.authenticate and spark.network.crypto.enabled. In versions 3.1.2 and earlier, it uses a bespoke mutual authentication protocol that allows for full encryption key recovery. After an initial interactive attack, this would allow someone to decrypt plaintext traffic offline. Note that this does not affect security mechanisms controlled by spark.authenticate.enableSaslEncryption, spark.io.encryption.enabled, spark.ssl, spark.ui.strictTransportSecurity.

Mitigation:

*   Update to Spark 3.1.3 or later

Credit:

*   Steve Weis (Databricks)

**CVE-2020-9480: Apache Spark™ RCE vulnerability in auth-enabled standalone master**

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:

*   Apache Spark 2.4.5 and earlier

Description:

In Apache Spark 2.4.5 and earlier, a standalone resource manager’s master may be configured to require authentication (spark.authenticate) via a shared secret. When enabled, however, a specially-crafted RPC to the master can succeed in starting an application’s resources on the Spark cluster, even without the shared key. This can be leveraged to execute shell commands on the host machine.

This does not affect Spark clusters using other resource managers (YARN, Mesos, etc).

Mitigation:

*   Users should update to Spark 2.4.6 or 3.0.0.
*   Where possible, network access to the cluster machines should be restricted to trusted hosts only.

Credit:

*   Ayoub Elaassal

**CVE-2019-10099: Apache Spark™ unencrypted data on local disk**

Severity: Important

Vendor: The Apache Software Foundation

Versions affected:

*   All Spark 1.x, Spark 2.0.x, Spark 2.1.x, and 2.2.x versions
*   Spark 2.3.0 to 2.3.2

Description:

Prior to Spark 2.3.3, in certain situations Spark would write user data to local disk unencrypted, even if spark.io.encryption.enabled=true. This includes cached blocks that are fetched to disk (controlled by spark.maxRemoteBlockSizeFetchToMem); in SparkR, using parallelize; in Pyspark, using broadcast and parallelize; and use of python udfs.

Mitigation:

*   1.x, 2.0.x, 2.1.x, 2.2.x, 2.3.x users should upgrade to 2.3.3 or newer, including 2.4.x

Credit:

*   This issue was reported by Thomas Graves of NVIDIA.

**CVE-2018-11760: Apache Spark™ local privilege escalation vulnerability**

Severity: Important

Vendor: The Apache Software Foundation

Versions affected:

*   All Spark 1.x, Spark 2.0.x, and Spark 2.1.x versions
*   Spark 2.2.0 to 2.2.2
*   Spark 2.3.0 to 2.3.1

Description:

When using PySpark, it’s possible for a different local user to connect to the Spark application and impersonate the user running the Spark application. This affects versions 1.x, 2.0.x, 2.1.x, 2.2.0 to 2.2.2, and 2.3.0 to 2.3.1.

Mitigation:

*   1.x, 2.0.x, 2.1.x, and 2.2.x users should upgrade to 2.2.3 or newer
*   2.3.x users should upgrade to 2.3.2 or newer
*   Otherwise, affected users should avoid using PySpark in multi-user environments.

Credit:

*   Luca Canali and Jose Carlos Luna Duran, CERN

**CVE-2018-17190: Unsecured Apache Spark™ standalone executes user code**

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected:

*   All versions of Apache Spark

Description:

Spark’s standalone resource manager accepts code to execute on a ‘master’ host, that then runs that code on ‘worker’ hosts. The master itself does not, by design, execute user code. A specially-crafted request to the master can, however, cause the master to execute code too. Note that this does not affect standalone clusters with authentication enabled. While the master host typically has less outbound access to other resources than a worker, the execution of code on the master is nevertheless unexpected.

Mitigation:

Enable authentication on any Spark standalone cluster that is not otherwise secured from unwanted access, for example by network-level restrictions. Use spark.authenticate and related security properties described at https://spark.apache.org/docs/latest/security.html

Credit:

*   Andre Protas, Apple Information Security

**CVE-2018-11804: Apache Spark™ build/mvn runs zinc, and can expose information from build machines**

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected

*   2.1.x release branch and earlier
*   2.2.x release branch before Spark 2.2.3
*   2.3.x release branch before Spark 2.3.3

Description:

Spark’s Apache Maven-based build includes a convenience script, ‘build/mvn’, that downloads and runs a zinc server to speed up compilation. This server will accept connections from external hosts by default. A specially-crafted request to the zinc server could cause it to reveal information in files readable to the developer account running the build. Note that this issue does not affect end users of Spark, only developers building Spark from source code.

Mitigation:

*   Spark users are not affected, as zinc is only a part of the build process.
*   Spark developers may simply use a local Maven installation’s ‘mvn’ command to build, and avoid running build/mvn and zinc.
*   Spark developers building actively-developed branches (2.2.x, 2.3.x, 2.4.x, master) may update their branches to receive mitigations already patched onto the build/mvn script
*   Spark developers running zinc separately may include “-server 127.0.0.1” in its command line, and consider additional flags like “-idle-timeout 30m” to achieve similar mitigation.

Credit:

*   Andre Protas, Apple Information Security

**CVE-2018-11770: Apache Spark™ standalone master, Mesos REST APIs not controlled by authentication**

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:

*   Spark versions from 1.3.0, running standalone master with REST API enabled, or running Mesos master with cluster mode enabled; suggested mitigations resolved the issue as of Spark 2.4.0.

Description:

From version 1.3.0 onward, Spark’s standalone master exposes a REST API for job submission, in addition to the submission mechanism used by spark-submit. In standalone, the config property spark.authenticate.secret establishes a shared secret for authenticating requests to submit jobs via spark-submit. However, the REST API does not use this or any other authentication mechanism, and this is not adequately documented. In this case, a user would be able to run a driver program without authenticating, but not launch executors, using the REST API. This REST API is also used by Mesos, when set up to run in cluster mode (i.e., when also running MesosClusterDispatcher), for job submission. Future versions of Spark will improve documentation on these points, and prohibit setting spark.authenticate.secret when running the REST APIs, to make this clear. Future versions will also disable the REST API by default in the standalone master by changing the default value of spark.master.rest.enabled to false.

Mitigation:

For standalone masters, disable the REST API by setting spark.master.rest.enabled to false if it is unused, and/or ensure that all network access to the REST API (port 6066 by default) is restricted to hosts that are trusted to submit jobs. Mesos users can stop the MesosClusterDispatcher, though that will prevent them from running jobs in cluster mode. Alternatively, they can ensure access to the MesosRestSubmissionServer (port 7077 by default) is restricted to trusted hosts.

Credit:

*   Imran Rashid, Cloudera
*   Fengwei Zhang, Alibaba Cloud Security Team

**CVE-2018-8024: Apache Spark™ XSS vulnerability in UI**

Severity: Medium

Versions Affected:

*   Spark 2.1.0 through 2.1.2
*   Spark 2.2.0 through 2.2.1
*   Spark 2.3.0

Description:

In Apache Spark 2.1.0 to 2.1.2, 2.2.0 to 2.2.1, and 2.3.0, it’s possible for a malicious user to construct a URL pointing to a Spark cluster’s UI’s job and stage info pages, and if a user can be tricked into accessing the URL, can be used to cause script to execute and expose information from the user’s view of the Spark UI. While some browsers like recent versions of Chrome and Safari are able to block this type of attack, current versions of Firefox (and possibly others) do not.

Mitigation:

*   2.1.x users should upgrade to 2.1.3 or newer
*   2.2.x users should upgrade to 2.2.2 or newer
*   2.3.x users should upgrade to 2.3.1 or newer

Credit:

*   Spencer Gietzen, Rhino Security Labs

**CVE-2018-1334: Apache Spark™ local privilege escalation vulnerability**

Severity: High

Vendor: The Apache Software Foundation

Versions affected:

*   Spark versions through 2.1.2
*   Spark 2.2.0 to 2.2.1
*   Spark 2.3.0

Description:

In Apache Spark up to and including 2.1.2, 2.2.0 to 2.2.1, and 2.3.0, when using PySpark or SparkR, it’s possible for a different local user to connect to the Spark application and impersonate the user running the Spark application.

Mitigation:

*   1.x, 2.0.x, and 2.1.x users should upgrade to 2.1.3 or newer
*   2.2.x users should upgrade to 2.2.2 or newer
*   2.3.x users should upgrade to 2.3.1 or newer
*   Otherwise, affected users should avoid using PySpark and SparkR in multi-user environments.

Credit:

*   Nehmé Tohmé, Cloudera, Inc.

**CVE-2017-12612 Unsafe deserialization in Apache Spark™ launcher API**

JIRA: SPARK-20922

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:

*   Versions of Apache Spark from 1.6.0 until 2.1.1

Description:

In Apache Spark 1.6.0 until 2.1.1, the launcher API performs unsafe deserialization of data received by its socket. This makes applications launched programmatically using the launcher API potentially vulnerable to arbitrary code execution by an attacker with access to any user account on the local machine. It does not affect apps run by spark-submit or spark-shell. The attacker would be able to execute code as the user that ran the Spark application. Users are encouraged to update to version 2.1.2, 2.2.0 or later.

Mitigation:

Update to Apache Spark 2.1.2, 2.2.0 or later.

Credit:

*   Aditya Sharad, Semmle

**CVE-2017-7678 Apache Spark™ XSS web UI MHTML vulnerability**

JIRA: SPARK-20393

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:

*   Versions of Apache Spark before 2.1.2, 2.2.0

Description:

It is possible for an attacker to take advantage of a user’s trust in the server to trick them into visiting a link that points to a shared Spark cluster and submits data including MHTML to the Spark master, or history server. This data, which could contain a script, would then be reflected back to the user and could be evaluated and executed by MS Windows-based clients. It is not an attack on Spark itself, but on the user, who may then execute the script inadvertently when viewing elements of the Spark web UIs.

Mitigation:

Update to Apache Spark 2.1.2, 2.2.0 or later.

Example:

Request:

    GET /app/?appId=Content-Type:%20multipart/related;%20boundary=_AppScan%0d%0a--
    _AppScan%0d%0aContent-Location:foo%0d%0aContent-Transfer-
    Encoding:base64%0d%0a%0d%0aPGh0bWw%2bPHNjcmlwdD5hbGVydCgiWFNTIik8L3NjcmlwdD48L2h0bWw%2b%0d%0a
    HTTP/1.1
    

Excerpt from response:

    <div class="row-fluid">No running application with ID Content-Type: multipart/related;
    boundary=_AppScan
    --_AppScan
    Content-Location:foo
    Content-Transfer-Encoding:base64
    PGh0bWw+PHNjcmlwdD5hbGVydCgiWFNTIik8L3NjcmlwdD48L2h0bWw+
    </div>
    

Result: In the above payload the BASE64 data decodes as:

    <html><script>alert("XSS")</script></html>
    

Credit:

*   Mike Kasper, Nicholas Marion
*   IBM z Systems Center for Secure Engineering

CVE-2018-11804: Security | Apache Spark

From version 1.3.0 onward, Apache Spark's standalone master exposes a REST API for job submission, in addition to the submission mechanism used by spark-submit. In standalone, the config property 'spark.authenticate.secret' establishes a shared secret for authenticating requests to submit jobs via spark-submit. However, the REST API does not use this or any other authentication mechanism, and this is not adequately documented. In this case, a user would be able to run a driver program without authenticating, but not launch executors, using the REST API. This REST API is also used by Mesos, when set up to run in cluster mode (i.e., when also running MesosClusterDispatcher), for job submission. Future versions of Spark will improve documentation on these points, and prohibit setting 'spark.authenticate.secret' when running the REST APIs, to make this clear. Future versions will also disable the REST API by default in the standalone master by changing the default value of 'spark.master.rest.enabled' to 'false'.

CVE-2018-11770: Security | Apache Spark

Apache Axis 1.x up to and including 1.4 is vulnerable to a cross-site scripting (XSS) attack in the default servlet/services.

**Details**

*   **Type: ** Bug
    
*   **Status:** Resolved
    
*   **Priority: ** Major
    
*   **Resolution:** Fixed
    
*   **Affects Version/s:** None
    
*   **Fix Version/s:** None
    
*   **Component/s:** None
    
*   **Labels:**
    
    None
    

**Description**

I built the trunk and can confirm the fix. See below:

r1831943 | veithen | 2018-05-20 14:10:32 -0600 (Sun, 20 May 2018) | 1 line

Correctly escape namespace URIs in namespace declarations.

Trunk link with maven builds:

https://travis-ci.org/apache/axis1-java 

**Attachments**

**Activity**

CVE-2018-8032: [AXIS-2924] CVE-2018-8032 XSS vulnerability - ASF JIRA

A flaw was found in Wildfly 9.x. A path traversal vulnerability through the org.wildfly.extension.undertow.deployment.ServletResourceManager.getResource method could lead to information disclosure of arbitrary local files.

A user has reported in the forums that there appears to be an issue (since 9.0.x till present 11.0.0 WildFly releases) where files like \`/etc/passwd\` are served by the web container to the clients, when the client requests a crafted URL against a Java EE deployment which has (Java EE) servlet overlays. Please see the referenced forum thread\[1\] for more details.

Although, the steps noted in that thread involves Spring framework and gets triggered in a very specific way, the root cause appears to be the call to \`ServletContext.getResourceAsInputStream\` (which is what the spring framework ends up calling with a path like "/../../../../../../../..//etc/passwd", ends up actually serving the resource even if the path is outside the scope of the deployment to which the servlet context belongs.

I could reproduce this against the latest WildFly in a simple test case that's here \[2\]

\[1\] https://developer.jboss.org/thread/276826  
\[2\] https://github.com/jaikiran/wildfly/commit/ed05258aa824ab91a52ef6554e9707531a2cc83b

P.S: The credit for reporting this issue should go to Laurent Roussel who reported this in the forum thread, but I don't have access to change the "Reporter" field of the JIRA

CVE-2018-1047: [WFLY-9620] ServletContext.getResourceAsStream, for deployments which have (Java EE) servlet overlays, serves files which are outside of the deployment

The Atlassian Hipchat Integration Plugin for Bitbucket Server 6.26.0 before 6.27.5, 6.28.0 before 7.3.7, and 7.4.0 before 7.8.17; Confluence HipChat plugin 6.26.0 before 7.8.17; and HipChat for JIRA plugin 6.26.0 before 7.8.17 allows remote attackers to obtain the secret key for communicating with HipChat instances by reading unspecified pages.

HipChat for JIRA plugin - leaks secret key - HC-32766

Note: As of  September 2014 we are no longer issuing binary bug patches, instead we create new maintenance releases for the major versions we are backporting.

Date of Advisory:  21 Sep 2016 10 AM PDT  (Pacific Time, -7 hours)

CVE ID: 

*   CVE-2016-6668 - The HipChat plugin for various products leaks the secret key it uses to communicate with a linked HipChat instance.

Product: JIRA and the HipChat for JIRA plugin.

Affected HipChat for JIRA plugin versions:

*   6.26.0 <= version < 7.8.17

Affected JIRA product versions:

*   version >= 6.2.5 where the installed HipChat for JIRA plugin version is >= 6.26.0 and < 7.8.17
*   6.4.8 <= version < 7.0.11
*   7.1.0 <= version < 7.1.10

Fixed JIRA product versions:

*   for 7.0.x, JIRA  **7.0.11** has been released with a fix for this issue.
*   for 7.1.x, JIRA **7.1.10** has been released with a fix for this issue.
*   for 7.2.x, JIRA **7.2.0** has been released with a fix for this issue.

****Summary of Vulnerability****

This advisory discloses a **critical severity** security vulnerability which was introduced in version 6.4.8 of JIRA. Versions of JIRA starting with 6.4.8 before **7.0.11** (the fixed version for 7.0.x), from **7.1.0** before **7.1.10** (the fixed version for 7.1.x) are affected by this vulnerability.

**Atlassian Cloud** instances have **already been upgraded** to a version of JIRA which does **not** have the issue described on this page.

**Customers who have upgraded JIRA to version **7.0.11 or** 7.1.10 or **7.2.0**** **are** **not affected****.**

**Customers who have** **downloaded and installed JIRA >= 6.2.5 and have a version of the HipChat for JIRA plugin >= **6.26.0 and less than 7.8.17 installed.****

**Customers who have downloaded and installed **JIRA** >= **6.4.8** less than 7.0.11 (the fixed version for 7.0.x)**

**Customers who have downloaded and installed **JIRA** >= 7.1.0 less than 7.1.10 (the fixed version for 7.1.x)**

Please **upgrade** the **HipChat for JIRA plugin** in your **JIRA** installations **immediately** to fix this vulnerability.

**The HipChat plugin for various products leaks the secret key it uses to communicate with a linked HipChat instance (CVE-2016-6668)**

**Severity**

Atlassian rates the severity level of this vulnerability as **critical**, according to the scale published in our Atlassian severity levels. The scale allows us to rank the severity as critical, high, moderate or low.

This is an independent assessment and you should evaluate its applicability to your own IT environment.

**Description**

The HipChat for JIRA plugin exposed the secret key it used to communicate with a linked HipChat service in various pages. For this vulnerability to affect your JIRA instance you must have a HipChat integration established. To exploit this issue in JIRA versions 7.0.0 and higher, attackers need to have access to a JIRA account. In JIRA versions before 7.0.0, such as 6.4.x, attackers only need access to the JIRA web interface. Using the secret key attackers can gain full control over a linked HipChat instance.

All versions of **HipChat for JIRA plugin** from 6.26.0 before **7.8.17** are affected by this vulnerability. 

All versions of **JIRA** from 6.4.8 before **7.0.11**(the fixed version for 7.0.x) and from **7.1.0** before **7.1.10** (the fixed version for 7.1.x) are affected by this vulnerability are affected by this vulnerability. This issue can be tracked here:  JRA-62496 - Getting issue details... STATUS

**Fix**

We have taken the following steps to address this issue:

1.  Released JIRA version **7.0.11** that updates the bundled copy of the **HipChat for JIRA plugin** to a fixed version.
2.  Released JIRA version **7.1.10** that updates the bundled copy of the **HipChat for JIRA plugin** to a fixed version.
3.  Released JIRA version **7.2.0** that updates the bundled copy of the **HipChat for JIRA plugin** to a fixed version.
4.  Released **HipChat for JIRA plugin version 7.8.17** that contains a fix for this issue.

****What You Need to Do****

**Upgrade (recommended)**

The vulnerabilities and fix versions are described in the description section above. Atlassian recommends that you upgrade to the latest version.

**Upgrade the HipChat for JIRA plugin**

Upgrade the HipChat for JIRA plugin to version **7.8.17 or higher**. For instructions on how to update add-ons like the **HipChat for JIRA plugin** see https://confluence.atlassian.com/display/UPM/Updating+add-ons. The HipChat for JIRA plugin marketplace entry can be found at https://marketplace.atlassian.com/plugins/com.atlassian.labs.hipchat.hipchat-for-JIRA-plugin/server/overview.

**If you cannot upgrade the HipChat For JIRA Plugin to version 7.8.17 or higher then** **upgrade JIRA to version 7.2.0** **or higher.**

If you are running **JIRA 7.1.x** **and** **cannot upgrade to** **JIRA** **7.2.0** **then** **upgrade to version 7.1.10.**

If you are running **JIRA 7.0.x** **and** **cannot upgrade to** **JIRA** **7.2.0 or 7.1.10** **then** **upgrade to version 7.0.11.**

**Next, follow these steps to **rotate the secret key.** **

You need admin permissions for both JIRA and HipChat to do this: 

1.  Log in to JIRA as a user with admin permissions and go to <your-jira-site>/plugins/servlet/hipchat/configure
2.  Click **_Remove integration_**_._ This will sever the link and uninstall the add-on in HipChat.
3.  Once you land back on the HipChat Integration page, click **_Connect HipChat_**. This will re-establish the link between HipChat and JIRA with a new secret key.

For a full description of the latest version of JIRA, see the release notes. You can download the latest version of JIRA from the download centre.

****Mitigation****

If you are unable to upgrade your JIRA server or the HipChat for JIRA plugin, then as a **temporary workaround**, you can disable or uninstall the **HipChat for JIRA plugin** in JIRA.

**Support**

If you have questions or concerns regarding this advisory, please raise a support request at https://support.atlassian.com/.

****References****

Security Bug fix Policy

As per our new policy critical security bug fixes will be back ported to major software versions for up to 12 months for JIRA and Confluence.  We will release new maintenance releases for the versions covered by the new policy instead of binary patches.

**Binary patches will no longer be released.** 

 Severity Levels for security issues

Atlassian security advisories include a severity level and a CVE identifier. This severity level is based on our self-calculated CVSS score for each specific vulnerability. CVSS is an industry standard vulnerability metric. You can also learn more about CVSS at FIRST.org.

 End of Life Policy

 Our end of life policy varies for different products. Please refer to our EOL Policy for details.

CVE-2016-6668: JIRA and HipChat for JIRA plugin Security Advisory 2016-09-21 | Atlassian Support

The Gliffy plugin before 3.7.1 for Atlassian JIRA, and before 4.2 for Atlassian Confluence, does not properly restrict the capabilities of third-party XML parsers, which allows remote attackers to read arbitrary files or cause a denial of service (resource consumption) via unspecified vectors.

This advisory discloses a **critical** security vulnerability that exists in all versions of Confluence up to and including 4.1.9.

*   **Customers** **who have downloaded and installed Confluence** should upgrade their existing Confluence installations to fix this vulnerability.  
*   **Enterprise Hosted customers** need to request an upgrade by raising a support request at http://support.atlassian.com in the "Enterprise Hosting Support" project.
*   **JIRA Studio and Atlassian OnDemand customers** are not affected by any of the issues described in this advisory.

Atlassian is committed to improving product security. The vulnerability listed in this advisory has been discovered by Atlassian, unless noted otherwise. The reporter may also have requested that we do not credit them.   

If you have questions or concerns regarding this advisory, please raise a support request at http://support.atlassian.com/.

**In this advisory:**

**Critical XML Parsing Vulnerability****Severity**

Atlassian rates the severity level of this vulnerability as **crit****ical**, according to the scale published in Severity Levels for Security Issues. The scale allows us to rank the severity as critical, high, moderate or low.

This is an independent assessment and you should evaluate its applicability to your own IT environment.

**Description**

We have identified and fixed a vulnerability in Confluence that results from the way third-party XML parsers are used in Confluence. This vulnerability allows an attacker to:

*   execute denial of service attacks against the Confluence server, or  
    
*   read all local files readable to the system user under which Confluence runs.

The attacker does not need to have an account with the affected Confluence instance.

All versions of Confluence **up to and including 4.1.9** are affected by this vulnerability. This issue can be tracked here: CONF-25077 - Getting issue details... STATUS

The Gliffy for Confluence plugin is also vulnerable to this exploit. If you are using the Gliffy plugin for Confluence with _any_ version of Confluence, you will need to upgrade it (see 'Fix' section below) or disable it.

**Risk Mitigation**

We recommend that you upgrade your Confluence installation to fix this vulnerability.

Alternatively, if you are not in a position to upgrade immediately, you should do **all** of the following until you can upgrade. Please note, these measures will only limit the impact of the vulnerability, they will not mitigate it completely.  

*   Disable access to the SOAP and XML-RPC APIs, if these remote APIs are not required. Note, remote API access is disabled by default. See enabling remote APIs for instructions.  
    Disable the following plugins/plugin modules (see Disabling and enabling apps):  
    *   Office Connector plugin
    *   JUnitReport macro module of the confluence-advanced-macros plugin (called "Advanced Macros" in the interface)  
        
    *   confluence-jira3-macros plugin (called "JIRA Macros" in the interface)  
        
    *   WebDAV
*   Disable public access (such as anonymous access  and public signup) to Confluence until you have upgraded.
*   Ensure that your Confluence system user is restricted as described in best practices for configuring Confluence security.

**Fix**

**Upgrade** 

1.  Upgrade to Confluence 4.2 or later which fixes this vulnerability. For a full description of this release, see the Confluence 4.2 Release Notes. The following releases have also been made available to fix these issues in older Confluence versions.  You can download these versions of Confluence from the download centre.   
      
    *   Confluence 4.1.10 for Confluence 4.1 
    *   Confluence 4.0.7 for Confluence 4.0 
    *   Confluence 3.5.17 for Confluence 3.5
2.   Upgrade the following Confluence third-party plugins, if you are using them. The table below describes which version of the plugin you should upgrade to, depending on your Confluence version. See Updating Add-ons for instructions on how to update a plugin. 
    
    Plugin
    
    Confluence 4.2
    
    Confluence 4.1
    
    Confluence 4.0
    
    Confluence 3.5
    
    Gliffy plugin for Confluence
    
    4.2
    
    4.2
    
    4.2
    
    4.2
    

**Patches**  

There are no patches available for this vulnerability. Due to the extent of the changes required to fix the vulnerability, it is not possible to provide patches that resolve the issue without compromising the reliability of Confluence. You must upgrade to fix this vulnerability.

CVE-2012-2928: Confluence Security Advisory 2012-05-17 | Confluence Data Center and Server 7.17

The WebWork 1 web application framework in Atlassian JIRA before 3.13.2 allows remote attackers to invoke exposed public JIRA methods via a crafted URL that is dynamically transformed into method calls, aka "WebWork 1 Parameter Injection Hole."

Tag

#jira