Bug Bounty is not a Replacement for Security Contacts

This post describes a frustrating experience I had recently, when I wanted to forward a vulnerability report to Atlassian. I am aware that my customer perspective is incomplete, and that I'm missing internal context of the security team handling the issue. Still, I wanted to share my conclusions from this episode. I believe the lapses I observed are symptoms of excessive rationalization, that are typical in corporate environments.

Some context first: I've been working for Swisscom in the bug bounty team for some years. The program is self-managed, i.e. it's not hosted on a bug bounty platform and triage of issues is performed in-house. Bug hunters are invited to submit their findings via a customer portal implemented on a Jira Service Management instance. Recently, we migrated to Atlassian's SaaS offering, due to their forced push to the cloud along with the ever increasing Data Center (i.e. on-prem) license prices.

I needed to contact Atlassian regarding a security issue with high technical impact. Both a vulnerability disclosure policy as well as security contacts according to RFC 9116 (security.txt) are provided. As a customer, you are redirected to the support portal, which in turn redirects to the different bug bounty programs hosted on Bugcrowd.

As a security researcher, you are also invited to submit the vulnerability details through the bug bounty program. In addition, the security contact security@atlassian.com is provided, same as in the security.txt:

There are several reasons to avoid an external bug bounty program when reporting a vulnerability. For example, researchers might not agree to the the terms and conditions imposed by the mandated bug bounty platform, they may value exposure over the financial reward, or simply want to stay anonymous. In this case, the vulnerability was initially discovered by a participant of the Swisscom bug bounty program. The intention was to bring the vulnerability to the attention of the Atlassian security team, both to ensure it was fixed and to provide proper recognition to the researcher. Therefore, I chose the e-mail contact, see timeline below. Unfortunately, Atlassian's response was below my expectations.

• 2025-08-22 15:26 (Friday) Researcher submits vulnerability report on Swisscom bug bounty program
• 2025-08-22 23:21 Swisscom acknowledges vulnerability report
• 2025-08-22 23:53 Swisscom forwards report to security@atlassian.com and to the security contact of their Atlassian reseller, requesting a timeline of events, a retrospective assessment of potential exploitation, and a confidence of results (e.g. is log coverage sufficient to exclude exploitation)
• 2025-08-22 23:54 Automated response from Atlassian security team: "Thank you for contacting Atlassian's security team. We have received your report. Please note that we may not provide individual responses to all submissions."
• 2025-08-25 08:46 (Monday) Reseller confirms receipt of report, acknowledges the vulnerability and offers support in communication with Atlassian
• 2025-08-25 07:12 Swisscom contacts researcher to clarify if a bug report was submitted on Bugcrowd
• 2025-08-25 08:52 Researcher shares Bugcrowd submission ID of the newly created report
• 2025-08-25 12:20 Researcher informs that the submission was rejected by teapot_bugcrowd, and that a reevaluation was requested

• 2025-08-25 13:49 Swisscom requests a second confirmation of receipt from Atlassian security team, and informs that the researcher's submission was rejected on Bugcrowd
• 2025-08-25 14:56 Swisscom shares vulnerability infos with NCSC-CH 
• 2025-08-25 15:17 NCSC-CH confirms receipt of vulnerability information
• 2025-08-26 09:50 (Tuesday) NCSC-CH offers to coordinate the vulnerability disclosure process, and to publish an advisory within its constituency (Swiss critical infrastructure operators) if the vendor remains un-responsive, based on Art. 73c, §2 of the Information Security Act (ISG)
• 2025-08-27 06:28 (Wednesday) Swisscom requests a third confirmation of receipt from Atlassian security team and informs that NCSC-CH is involved
• 2025-08-27 06:39 Reseller's security team suggests that Swisscom opens a support ticket
• 2025-08-27 06:50 Swisscom opens a support ticket, subject to given support levels
• 2025-08-27 08:49 Atlassian support acknowledges support ticket and assigns L4 (2 business days)
• 2025-08-29 08:50 (Friday) Atlassian support transitions ticket to "Altassian Investigating"
• 2025-09-01 06:12 (Monday) Atlassian security acknowledges the vulnerability, informs that the issue was remediated, and that the Bugcrowd submission will be reopened so that the researcher is rewarded

Finally, after a week's time, the report was acknowledged (and fixed!). I'm really glad that Atlassian provided the researcher a due reward for the finding.

In my impression, the security contact security@atlassian.com was not actionable. Only raising a customer support ticket got the expected attention instead, yet only with delayed handling. Also, the AI-based triage of Bugcrowd failed to identify and acknowledge the researcher's report. In my opinion, the whole point of VDP, security.txt, bug bounty, etc., is to make the process of reporting vulnerabilities as smooth as possible. I understand that the rise of beg bounties and AI slop necessitates coarser filtering measures, however the main focus should remain on removing roadblocks for legitimate reports. So unfortunately, both internal and external channels failed. 

Regarding the communication following Atlassian's compromise assessment: Atlassian does not provide access to application logs, leaving tenants with zero observability into actions within their instances, and therefore impairing their ability to perform independent security investigations. Initially, Atlassian stated they would only inform affected customers. I insisted to receive results regardless of our instance being affected or not. On 2025-09-12 06:10, Atlassian security informed that they concluded their investigation, and found no evidence of exploitation other than the bug hunter's activity. Unfortunately, they did not provide any details regarding the confidence of this information, as initially requested.

Under the constant pressure of rationalization, costs are cut, processes are optimized, and resources are often eliminated without replacement. The focus shifts excessively toward measurable outcomes, overseeing essential elements to the organization. Trust is one of those essential things that's not quantifiable...

The researcher described the technical details of the vulnerability here: A Critical Zero-Day in Atlassian Jira Service Management Cloud: Password Reset Account Takeover. Many thanks Mo Salah for your collaboration ❤️ and congratulations for this finding! 🏆

waiting for the @atlassian.bsky.social security team to react to a report of a product security vulnerability 😐

[image or embed]

— Baklava Monster, CISSP (@ant0i.net) August 27, 2025 at 7:06 AM

Yes, but... @yesbut.bsky.social

[image or embed]

— Baklava Monster, CISSP (@ant0i.net) August 27, 2025 at 8:39 AM

AI doing exactly what AI was designed for #rant

[image or embed]

— Baklava Monster, CISSP (@ant0i.net) August 27, 2025 at 8:52 AM

how i see atlassian security team

[image or embed]

— Baklava Monster, CISSP (@ant0i.net) August 28, 2025 at 6:54 AM

atlassian security team, 404 not found

[image or embed]

— Baklava Monster, CISSP (@ant0i.net) August 29, 2025 at 7:23 AM

no compassion with the atlassian security team

[image or embed]

— Baklava Monster, CISSP (@ant0i.net) August 29, 2025 at 5:40 PM