WordPress before 5.5.2 allows stored XSS via post slugs.

CVE-2020-28038: SonarSource Blog

In affected Ops Manager versions there is an exposed http route was that may allow attackers to view a specific access log of a publicly exposed Ops Manager instance. This issue affects: MongoDB Inc. MongoDB Ops Manager 4.0 versions 4.0.9, 4.0.10 and MongoDB Ops Manager 4.1 version 4.1.5.



CVE-2019-2388: Ops Manager Server Changelog — MongoDB Ops Manager 6.0

A Denial Of Service vulnerability exists in the safe-svg (aka Safe SVG) plugin through 1.9.4 for WordPress, related to unlimited recursion for a '<use ... xlink:href="#identifier">' substring.

CVE-2019-18854: Changeset 2185438 – WordPress Plugin Repository

A reflected cross-site scripting vulnerability in Jenkins build-metrics Plugin allows attackers to inject arbitrary HTML and JavaScript into web pages provided by this plugin.

This advisory announces vulnerabilities in the following Jenkins deliverables:

*   Bitbucket OAuth Plugin
*   build-metrics Plugin
*   Deploy WebLogic Plugin
*   Dynatrace Application Monitoring Plugin
*   Dynatrace Application Monitoring Plugin
*   fireline Plugin
*   Global Post Script Plugin
*   kubernetes-ci Plugin
*   Libvirt Agents Plugin
*   Mattermost Notification Plugin
*   Sonar Gerrit Plugin
*   Zulip Plugin

**Descriptions****Mattermost Notification Plugin stored webhook endpoint token in plain text**

**SECURITY-1628 / CVE-2019-10459**  
**Severity (CVSS):** Medium  
**Affected plugin: mattermost**  
**Description:**

Mattermost allows the definition of incoming (from the perspective of the service) webhook URLs. These contain what is effectively a secret token as part of the URL.

Mattermost Notification Plugin stored these webhook URLs as part of its global configuration file jenkins.plugins.mattermost.MattermostNotifier.xml and job config.xml files on the Jenkins controller. These URLs could be viewed by users with Extended Read permission (in the case of job config.xml files) or access to the Jenkins controller file system.

Mattermost Notification Plugin now stores these URLs encrypted. As they combine configuration and secret token, they are still shown on the UI.

**Bitbucket OAuth Plugin stored credentials in plain text**

**SECURITY-1546 / CVE-2019-10460**  
**Severity (CVSS):** Low  
**Affected plugin: bitbucket-oauth**  
**Description:**

Bitbucket OAuth Plugin stored a credential unencrypted in the global config.xml configuration file on the Jenkins controller. This credential could be viewed by users with access to the Jenkins controller file system.

Bitbucket OAuth Plugin now stores this credential encrypted.

**Zulip Plugin stored credentials in plain text**

**SECURITY-1621 / CVE-2019-10476**  
**Severity (CVSS):** Low  
**Affected plugin: zulip**  
**Description:**

Zulip Plugin stored a credential unencrypted in its global configuration file jenkins.plugins.zulip.ZulipNotifier.xml, as well as in the legacy configuration file hudson.plugins.humbug.HumbugNotifier.xml on the Jenkins controller. This credential could be viewed by users with access to the Jenkins controller file system.

Zulip Plugin now stores this credential encrypted in its global configuration file. The legacy configuration file is deleted when saving the plugin configuration.

**Dynatrace Application Monitoring Plugin stored credentials in plain text**

**SECURITY-1477 / CVE-2019-10461**  
**Severity (CVSS):** Low  
**Affected plugin: dynatrace-dashboard**  
**Description:**

Dynatrace Application Monitoring Plugin stored a credential unencrypted in its global configuration file com.dynatrace.jenkins.dashboard.TAGlobalConfiguration.xml on the Jenkins controller. This credential could be viewed by users with access to the Jenkins controller file system.

Dynatrace Application Monitoring Plugin now stores this credential encrypted.

**CSRF vulnerability in Dynatrace Application Monitoring Plugin**

**SECURITY-1483 (1) / CVE-2019-10462**  
**Severity (CVSS):** Medium  
**Affected plugin: dynatrace-dashboard**  
**Description:**

Dynatrace Application Monitoring Plugin did not require POST requests on a method implementing form validation. This CSRF vulnerability allowed attackers to initiate a connection test to an attacker-specified server with attacker-specified username and password.

Dynatrace Application Monitoring Plugin now requires POST requests for this form validation method.

**Missing permission check in Dynatrace Application Monitoring Plugin**

**SECURITY-1483 (2) / CVE-2019-10463**  
**Severity (CVSS):** Medium  
**Affected plugin: dynatrace-dashboard**  
**Description:**

Dynatrace Application Monitoring Plugin does not perform permission checks on a method implementing form validation. This allows users with Overall/Read access to Jenkins to initiate a connection test to an attacker-specified server with attacker-specified username and password.

As of publication of this advisory, there is no fix.

**CSRF vulnerability and missing permission check in Deploy WebLogic Plugin**

**SECURITY-820 / CVE-2019-10464 (CSRF), CVE-2019-10465 (permission check)**  
**Severity (CVSS):** Medium  
**Affected plugin: weblogic-deployer-plugin**  
**Description:**

Deploy WebLogic Plugin does not perform permission checks on a method implementing form validation. This allows users with Overall/Read access to Jenkins to send an HTTP HEAD request to a user-specified URL, or confirm the existence of any file or directory on the Jenkins controller.

Additionally, the form validation method does not require POST requests, resulting in a CSRF vulnerability.

As of publication of this advisory, there is no fix.

**XXE vulnerability in fireline Plugin**

**SECURITY-822 / CVE-2019-10466**  
**Severity (CVSS):** High  
**Affected plugin: fireline**  
**Description:**

fireline Plugin accepts XML for part of its configuration. It does not configure the XML parser to prevent XML external entity (XXE) attacks.

A form validation method that accepts XML does not perform permission checks. This allows users with Overall/Read permission to have Jenkins parse a crafted XML file that uses external entities for extraction of secrets from the Jenkins agent, server-side request forgery, or denial-of-service attacks.

As of publication of this advisory, there is no fix.

**Sonar Gerrit Plugin stored credentials in plain text**

**SECURITY-1003 / CVE-2019-10467**  
**Severity (CVSS):** Medium  
**Affected plugin: sonar-gerrit**  
**Description:**

Sonar Gerrit Plugin stores a credential unencrypted in job config.xml files on the Jenkins controller if the 'Override Credentials' option is used. This credential can be viewed by users with Extended Read permission or access to the Jenkins controller file system.

As of publication of this advisory, there is no fix.

**CSRF vulnerability and missing permission checks in kubernetes-ci Plugin allowed capturing credentials**

**SECURITY-1005 (1) / CVE-2019-10468 (CSRF), CVE-2019-10469 (permission check)**  
**Severity (CVSS):** High  
**Affected plugin: kubernetes-ci**  
**Description:**

kubernetes-ci Plugin does not perform permission checks on a method implementing form validation. This allows users with Overall/Read access to Jenkins to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

Additionally, the form validation method does not require POST requests, resulting in a CSRF vulnerability.

As of publication of this advisory, there is no fix.

**Users with Overall/Read access could enumerate credential IDs in kubernetes-ci Plugin**

**SECURITY-1005 (2) / CVE-2019-10470**  
**Severity (CVSS):** Medium  
**Affected plugin: kubernetes-ci**  
**Description:**

kubernetes-ci Plugin provides a list of applicable credential IDs to allow users configuring the plugin to select the one to use.

This functionality does not correctly check permissions, allowing any user with Overall/Read permission to get a list of valid credentials IDs. Those can be used as part of an attack to capture the credentials using another vulnerability.

As of publication of this advisory, there is no fix.

**CSRF vulnerability and missing permission checks in Libvirt Agents Plugin allowed capturing credentials**

**SECURITY-1014 (1) / CVE-2019-10471 (CSRF), CVE-2019-10472 (permission check)**  
**Severity (CVSS):** Medium  
**Affected plugin: libvirt-slave**  
**Description:**

Libvirt Agents Plugin does not perform permission checks on a method implementing form validation. This allows users with Overall/Read access to Jenkins to connect to an attacker-specified SSH server using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

Additionally, the form validation method does not require POST requests, resulting in a CSRF vulnerability.

As of publication of this advisory, there is no fix.

**Users with Overall/Read access could enumerate credential IDs in Libvirt Agents Plugin**

**SECURITY-1014 (2) / CVE-2019-10473**  
**Severity (CVSS):** Medium  
**Affected plugin: libvirt-slave**  
**Description:**

Libvirt Agents Plugin provides a list of applicable credential IDs to allow users configuring the plugin to select the one to use.

This functionality does not correctly check permissions, allowing any user with Overall/Read permission to get a list of valid credentials IDs. Those can be used as part of an attack to capture the credentials using another vulnerability.

As of publication of this advisory, there is no fix.

**Missing permission check in Global Post Script Plugin allowed obtaining configuration data**

**SECURITY-1073 / CVE-2019-10474**  
**Severity (CVSS):** Medium  
**Affected plugin: global-post-script**  
**Description:**

Global Post Script Plugin does not perform permission checks on a method implementing form validation. This allows users with Overall/Read permission to list the files contained in $JENKINS_HOME/global-post-script that can be used by the plugin.

As of publication of this advisory, there is no fix.

**Reflected XSS vulnerability in build-metrics Plugin**

**SECURITY-1490 / CVE-2019-10475**  
**Severity (CVSS):** Medium  
**Affected plugin: build-metrics**  
**Description:**

build-metrics Plugin does not properly escape the label query parameter, resulting in a reflected cross-site scripting vulnerability.

As of publication of this advisory, there is no fix.

**Severity**

*   SECURITY-820: Medium
*   SECURITY-822: High
*   SECURITY-1003: Medium
*   SECURITY-1005 (1): High
*   SECURITY-1005 (2): Medium
*   SECURITY-1014 (1): Medium
*   SECURITY-1014 (2): Medium
*   SECURITY-1073: Medium
*   SECURITY-1477: Low
*   SECURITY-1483 (1): Medium
*   SECURITY-1483 (2): Medium
*   SECURITY-1490: Medium
*   SECURITY-1546: Low
*   SECURITY-1621: Low
*   SECURITY-1628: Medium

**Affected Versions**

*   **Bitbucket OAuth Plugin** up to and including 0.9
*   **build-metrics Plugin** up to and including 1.3
*   **Deploy WebLogic Plugin** up to and including 4.1
*   **Dynatrace Application Monitoring Plugin** up to and including 2.1.3
*   **Dynatrace Application Monitoring Plugin** up to and including 2.1.4
*   **fireline Plugin** up to and including 1.7.2
*   **Global Post Script Plugin** up to and including 1.1.4
*   **kubernetes-ci Plugin** up to and including 1.3
*   **Libvirt Agents Plugin** up to and including 1.8.5
*   **Mattermost Notification Plugin** up to and including 2.7.0
*   **Sonar Gerrit Plugin** up to and including 2.3
*   **Zulip Plugin** up to and including 1.1.0

**Fix**

*   **Bitbucket OAuth Plugin** should be updated to version 0.10
*   **Dynatrace Application Monitoring Plugin** should be updated to version 2.1.4
*   **Mattermost Notification Plugin** should be updated to version 2.7.1
*   **Zulip Plugin** should be updated to version 1.1.1

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:

*   build-metrics Plugin
*   Deploy WebLogic Plugin
*   Dynatrace Application Monitoring Plugin
*   fireline Plugin
*   Global Post Script Plugin
*   kubernetes-ci Plugin
*   Libvirt Agents Plugin
*   Sonar Gerrit Plugin

Learn why we announce these issues.

**Credit**

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

*   **James Holderness, IB Boost** for SECURITY-1546
*   **Oleg Nenashev, CloudBees, Inc.** for SECURITY-1003, SECURITY-1005 (1), SECURITY-1005 (2), SECURITY-1014 (1), SECURITY-1014 (2), SECURITY-1073
*   **Thomas de Grenier de Latour** for SECURITY-820, SECURITY-822
*   **Viktor Gazdag NCC Group** for SECURITY-1477, SECURITY-1483 (1), SECURITY-1483 (2), SECURITY-1490
*   **Wasin Saengow** for SECURITY-1621, SECURITY-1628

CVE-2019-10475: Jenkins Security Advisory 2019-10-23

An exploitable NULL pointer dereference vulnerability exists in the tinysvcmdns library version 2017-11-05. A specially crafted packet can make the library dereference a NULL pointer leading to a server crash and denial of service. An attacker needs to send a DNS query to trigger this vulnerability.

**Summary**

An exploitable NULL pointer dereference vulnerability exists in the tinysvcmdns library version 2017-11-05. A specially crafted packet can make the library dereference a NULL pointer leading to server crash and denial of service. An attacker needs to send a DNS query to trigger this vulnerability.

**Tested Versions**

tinysvcmdns 2017-11-05

**Product URLs**

https://bitbucket.org/geekman/tinysvcmdns

**CVSSv3 Score**

7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

**CWE**

CWE-476: NULL Pointer Dereference

**Details**

The tinysvcmdns library is a MDNS responder implementation optimized for size, and is essentially a mini and embedded version of Avahi or Bonjour.

The main_loop function in mdnsd.c is used to continuously send and receive MDNS packets:

    static void main_loop(struct mdnsd *svr) {
        ...
        ssize_t recvsize = recvfrom(svr->sockfd, pkt_buffer, PACKET_SIZE, 0,        // [1]
            (struct sockaddr *) &fromaddr, &sockaddr_size);
        if (recvsize < 0) {
            log_message(LOG_ERR, "recv(): %m");
        }
    
        DEBUG_PRINTF("data from=%s size=%ld\n", inet_ntoa(fromaddr.sin_addr), (long) recvsize);
        struct mdns_pkt *mdns = mdns_parse_pkt(pkt_buffer, recvsize);               // [2]
        if (mdns != NULL) {
            if (process_mdns_pkt(svr, mdns, mdns_reply)) {                          // [3]
        ...
    }
    

At \[1\] data is received and stored in pkt_buffer, which is then sent to function mdns_parse_pkt at \[2\] for parsing. mdns_parse_pkt will return the parsed packet as an mdns_pkt structure which is later processed at \[3\] by process_mdns_pkt.

    struct mdns_pkt *mdns_parse_pkt(uint8_t *pkt_buf, size_t pkt_len) {
        uint8_t *p = pkt_buf;
        size_t off;
        struct mdns_pkt *pkt;
        int i;
    
        if (pkt_len < 12) 
            return NULL;
    
        MALLOC_ZERO_STRUCT(pkt, mdns_pkt);                              // [4]
        
        pkt->id             = mdns_read_u16(p); p += sizeof(uint16_t);
        pkt->flags          = mdns_read_u16(p); p += sizeof(uint16_t);
        pkt->num_qn         = mdns_read_u16(p); p += sizeof(uint16_t);
        pkt->num_ans_rr     = mdns_read_u16(p); p += sizeof(uint16_t);
        pkt->num_auth_rr    = mdns_read_u16(p); p += sizeof(uint16_t);
        pkt->num_add_rr     = mdns_read_u16(p); p += sizeof(uint16_t);
    
        off = p - pkt_buf;
    
        // parse questions
        for (i = 0; i < pkt->num_qn; i++) {
            size_t l = mdns_parse_qn(pkt_buf, pkt_len, off, pkt);       // [5]
            ...
            off += l;
        ...
    

mdns_parse_pkt in mdns.c internally allocates space for the new mdns_pkt structure at \[4\] which is populated by calling mdns_parse_qn at \[5\] for every defined question (the num_qn field). Note that off is used to keep track of the position of the current MDNS query to parse within the raw packet buffer.

    static size_t mdns_parse_qn(uint8_t *pkt_buf, size_t pkt_len, size_t off, 
            struct mdns_pkt *pkt) {
        const uint8_t *p = pkt_buf + off;
        struct rr_entry *rr;
        uint8_t *name;
       
        assert(pkt != NULL);
    
        rr = malloc(sizeof(struct rr_entry)); 
        memset(rr, 0, sizeof(struct rr_entry));
    
        name = uncompress_nlabel(pkt_buf, pkt_len, off);        // [6]
        p += label_len(pkt_buf, pkt_len, off);
        rr->name = name;                                        // [7]
    
        rr->type = mdns_read_u16(p);
        p += sizeof(uint16_t);
    
        rr->unicast_query = (*p & 0x80) == 0x80;
        rr->rr_class = mdns_read_u16(p) & ~0x80;
        p += sizeof(uint16_t);
    
        rr_list_append(&pkt->rr_qn, rr);
        
        return p - (pkt_buf + off);
    }
    

mdns_parse_qn is used for parsing the MDNS questions section of the packet buffer. At \[6\] the function uncompress_nlabel is called and its return value is stored in the name field of the new rr_entry at \[7\].

The uncompress_nlabel function is used to parse a name label and return its uncompressed form. The compression format implemented is described in RFC 1035. This function takes as parameter the packet buffer, its size, and the offset in the packet where the label to uncompress is found.

    static uint8_t *uncompress_nlabel(uint8_t *pkt_buf, size_t pkt_len, size_t off) {
        uint8_t *p;
        uint8_t *e = pkt_buf + pkt_len;
        size_t len = 0;
        char *str, *sp;
        if (off >= pkt_len)               // [8]
            return NULL;
        ...
    

The check at \[8\] ensures that the offset specified is within the bounds of the packet buffer. If the offset is out of bounds, NULL is returned. As we can see, no checks are performed at \[6\] on the return value of uncompress_nlabel, thus allowing for storing NULL in rr->name at \[7\].

Later on, the name field could get dereferenced, causing a denial of service.

Indeed this happens inside process_mdns_pkt, which is called at \[3\], right after the packet is parsed. Note that other paths that lead to a NULL dereference might exist.

    static int process_mdns_pkt(struct mdnsd *svr, struct mdns_pkt *pkt, struct mdns_pkt *reply) {
        int i;
    
        assert(pkt != NULL);
    
        // is it standard query?
        if ((pkt->flags & MDNS_FLAG_RESP) == 0 && 
                MDNS_FLAG_GET_OPCODE(pkt->flags) == 0) {
            mdns_init_reply(reply, pkt->id);
    
            DEBUG_PRINTF("flags = %04x, qn = %d, ans = %d, add = %d\n", 
                            pkt->flags,
                            pkt->num_qn,
                            pkt->num_ans_rr,
                            pkt->num_add_rr);
    
            // loop through questions
            struct rr_list *qnl = pkt->rr_qn;
            for (i = 0; i < pkt->num_qn; i++, qnl = qnl->next) {
                struct rr_entry *qn = qnl->e;
                int num_ans_added = 0;
    
                char *namestr = nlabel_to_str(qn->name);                  // [9]
                ...
    

The function cycles over the list of parsed MDNS queries, and extracts at \[9\] the name of an rr_entry using nlabel_to_str.

    char *nlabel_to_str(const uint8_t *name) {
        char *label, *labelp;
        const uint8_t *p;
        size_t buf_len = 256;
    
        assert(name != NULL);
    
        label = labelp = malloc(buf_len);
    
        for (p = name; *p; p++) {                   // [10]
            ...    
    

As we can see nlabel_to_str doesn’t expect to receive a NULL name since it is dereferenced at \[10\].

**Exploit Proof-of-Concept**

The following proof of concept shows how to crash the tinysvcmdns daemon.

    $ echo -en "\xff\xff\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00" | nc -u $IP 5353
    

The packet is composed as follows:

    ffff - transaction id
    0000 - flags
    0001 - number of questions
    0000 - number of answers
    0000 - number of authority resource records
    0000 - number of additional resource records
    

Since no “question” chunk is defined at the end of the packet, off will be equal to pkt_len and this will make uncompress_nlabel return NULL.

**Timeline**

2017-11-12 - Vendor Disclosure  
2018-01-16 - Public Release

Discovered by Claudio Bozzato, Yves Younan, Lilith Wyatt <(^\_^)> and Aleksandar Nikolic of Cisco Talos.

CVE-2017-12130: TALOS-2017-0486 || Cisco Talos Intelligence Group

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.

Tag

#bitbucket