TeamCity
Powerful CI/CD for DevOps-centric teams
Insights and Timeline: Our Approach to Addressing the Recently Discovered Vulnerabilities in TeamCity On-Premises
This is a follow-up to the vulnerability announcement we published on March 4, 2024.
It’s important that we properly communicate the timeline for fixing the CVE-2024-27198 and CVE-2024-27199 vulnerabilities from JetBrains’ side.
All times below are expressed in CET.
February 19
6:54 pm – Rapid7 reached out to us, saying they had discovered significant security issues in TeamCity.
11:33 pm – We answered them, suggesting an appropriate way to communicate further.
February 20
2:57 pm – Rapid7 shared a detailed report regarding both vulnerabilities and how to replicate them.
3:15 pm – We confirmed that we had received the report.
4:37 pm – We made the initial investigation of the report, reproduced both issues, and communicated this to the Rapid7 team.
February 21
3:24 pm – We suggested to Rapid7 the following approach to publicly communicating the fixes:
- We would release the fix version and a workaround – a TeamCity security patch plugin for those who can’t upgrade quickly.
- At the same time, we’d communicate the vulnerabilities to our customers via email.
- A few days after the email communication, we’d publish the CVE records and release a blog post about the vulnerabilities.
- As soon as a significant number of customers have upgraded, we’d publish technical details of the vulnerabilities.
This approach is aligned with the Coordinated Disclosure Policy we follow when dealing with security issues discovered in JetBrains products.
6:16 pm – Rapid7 declined our suggested approach because they consider it as “silent patching”, which is against their policy.
February 22
2:41 pm – We asked the Rapid7 team to clarify the meaning of a “silent patch” and explained our position, which is as follows:
- We publish CVE records and notify customers via email and our blog once the fixed version is released. These notifications contain information about the root cause of the issue (like authentication bypass), severity, and CVSS score. We believe this allows our customers to make informed decisions about the risk and upgrade their TeamCity instances as soon as possible.
- At the same time, a full disclosure allows less skilled attackers with nefarious intentions to attack TeamCity instances that haven’t been upgraded yet.
- We don’t want to disclose the full details at the same time as releasing a fixed version to provide our customers with some time to upgrade.
February 23
6:32 pm – The Rapid7 team confirmed our approach is against their policy, and they want to make a “coordinated disclosure”, which means publishing full technical details of the vulnerabilities once the fixed version is released.
10:28 pm – The Rapid7 team asked us to share the CVE identifiers assigned to the issues, CVSS scores, and affected versions.
At this point, we made a decision not to make a coordinated disclosure with Rapid7 as we strongly believe that publishing all technical details at the same time as releasing a fix allows anyone to immediately exploit the issue before all customers have had a chance to patch their servers.
Our highest priority is to ensure our customers are notified of any critical security issues and have time to install a security patch or upgrade before more technical details are made public.
March 1
3:48 pm – The Rapid7 team once again asked us to share the CVE identifiers assigned to the issues, CVSS scores, and affected versions.
4:35 pm – We provided the CVE identifiers and CVSS scores for both issues.
March 4
3:00 pm – We released TeamCity 2023.11.4, including installation files and updated Docker images, plus a security patch plugin. This new version and the associated security patch plugin address both vulnerabilities.
3:05 pm – We started emailing all TeamCity On-Premises customers and JetBrains Security Bulletin subscribers to warn them of the security vulnerabilities. We advised them to upgrade or install the security patch as a matter of urgency.
3:06 pm – We published a blog post about the release. This blog post intentionally didn’t mention the security issues in detail as we had prepared a separate blog post describing both vulnerabilities, which was published at 15:59 after we had emailed all customers.
3:59 pm – We published a separate blog post describing both vulnerabilities and shared this on our social media channels.
4:12 pm – Rapid7 contacted us, saying they would make all of the details public in the following hours.
7:07 pm – We made the CVEs public and added both issues at https://www.jetbrains.com/privacy-security/issues-fixed/.
8:23 pm – Rapid7 published their blog post disclosing all technical details of the vulnerabilities. They also shared the blog post on X (formerly Twitter).
To reiterate, we never had any intention to release a fix silently without making the full details public. As a CVE Numbering Authority (CNA), we assigned CVE IDs for both issues a day after receiving the report.
We suggested disclosing the details of the vulnerabilities in the same way we have followed in the past (with a time delay between releasing a fix and making a full disclosure), which allows our customers to upgrade their TeamCity instances.
This suggestion was rejected by the Rapid7 team who published full details of the vulnerabilities (and how to exploit them) a few hours after we had released a fix to TeamCity customers.
Subscribe to TeamCity Blog updates
