Hello,
I have found a hardcoded api key for opsgenie. I am not sure who it belongs to but I'd like to report it so it can get revoked.
Please let me know the official process
@M , I promised to take this to the Community Managers, and they came back on Friday with a direct answer.
For someone with no Atlassian site and no Bugcrowd account, email the Security team at security@atlassian.com. That is the route the Atlassian Community Management team confirmed for exactly your situation.
What to put in the email:
That closes the gap I described above: a support ticket needs a site, Bugcrowd needs a researcher account, and this address needs neither. I have also asked for it to be added to the public Report a Vulnerability page so the next person does not need a forum thread to find it. If you send the email and hear nothing within a few working days, say so here and I will follow up with the Community Managers again.
Thanks for sticking with it; the leak is better reported late than left.
@M,
Short update for anyone landing here later: I asked the Community team whether the non-customer route (security@atlassian.com) could be documented on the Report a Vulnerability page. Their answer (20 Oct): that page belongs to Atlassian’s Product Security and Trust team, and the recommendation has been passed to them. Until it appears there, the email route in the accepted answer above stands.
API Keys can be revoked by the Org Administrator of the given Org it lives in - or a Ops Genie Administrator for the Integration/Alert/Alarm policy/configuration in question.
https://support.atlassian.com/organization-administration/docs/manage-an-organization-with-the-admin-apis/
For OpsGenie (Or Operations) - they (Team Manager/Ops Admin) need to check the Integrations/Connections/Various Policies and reissue/remake the Key to revoke the old one. These keys are usually used for app to app communication - not user. Generally very limited access and usually safe.
Hopefully its the Org Admin revoking type - as that will be a quick solution.
Also the User that owns the key can revoke/rotate their own key as well.
Note: Account (Including Service Accounts) API Keys have a limited lifespan of 1 year maximum - it will die sooner or later - not that I'm saying you can sit on it - but they are not permanent either.
The key doesn't belong to my org and I don't know who the admin is. Consider the key found in an public leak.
Thanks for your answer
You could attempt to contact Atlassian support - but odds are they will not disclose anything in terms of privacy rules and other stipulations.
https://support.atlassian.com/contact#/
That links takes me here. There is no such thing as support email in that link
You'll have to open a ticket without being logged in if you do not have an Org/Domain with Atlassian.
There's no email address to submit too.
open a ticket where? I followed the link and it takes me to this forum where I can only post questions
M,
The link you want is not the forum and not the general support page. It is Atlassian’s Report a Vulnerability page, which gives two routes that work without being a customer:
The page also offers Atlassian’s PGP key if you want to encrypt the submission. For a credential, use it: send the key, where you found it (repository, paste site, date), and nothing else. Do not test the key against the Opsgenie API to see what it opens; that turns a good-faith report into unauthorised access.
Set expectations: Atlassian will not tell you whose key it is or what they did, for the privacy reasons Matthew gave. What they can do is identify the owning org from the key and notify them, and Opsgenie integration keys can be regenerated by that org’s Opsgenie admin in seconds. One honest note: the page does not list leaked credentials as an in-scope item by name, so title the ticket as “exposed Opsgenie API key found in a public leak” so it lands with the right team.
Thanks for doing the right thing with it.
Thank you for your time supporting my issue. I have followed the approach #1 and this is where I get to, see screenshot attached.
I don't see any option different than opening a community question
@M thanks for coming back with the screenshot, that is useful.
What you hit is the form’s entitlement gate: once you pick Opsgenie under “Which app is this for?”, it wants a Site URL it can tie to a paying Opsgenie account, and with none it routes you to “Ask the community”. The route I gave you works for customers and for researchers who already hold an account with a site; it does not work for a third party holding someone else’s key, which is your case. My mistake for not spelling that out.
Two ways through:
1. Bugcrowd, the Opsgenie programme (the one that fits you). Atlassian’s Report a Vulnerability page lists bugcrowd.com/opsgenie as the submission channel for Opsgenie, and the engagement page is open and in progress. You need a free Bugcrowd researcher account, then Submit report. Title it “Exposed Opsgenie API key found in public source”, give the key, where you found it and when, and state that you have not used it. You are not asking for a bounty, so the “only bounty submissions are paid” line on the page does not matter here; what matters is that a Bugcrowd submission lands with Atlassian’s security triage rather than product support, and that queue does not need a site URL.
2. The same Contact Support form, different first answer. Untested by me today, so take it as a suggestion: under “Which app is this for?”, try an option that is not tied to a site (the account or “other” style entries) rather than Opsgenie, keeping “Security concern” as the reason. If it still ends at “Ask the community”, stop and use route 1.
Either way, keep to the same hygiene as before: do not test the key, and expect no feedback on who owned it. If route 1 works for you, a one-line note here would help the next person who finds a stray key.
M, I hear you, and after two attempts I will not pretend the gap is not real: Atlassian’s public pages give a customer route (the support form, which gates on a site) and a researcher route (Bugcrowd, which needs an account on a bounty platform), and nothing in between for a member of the public holding someone else’s credential. That is a documentation and process gap, not something you are doing wrong.
Two things I can do. First, if the Bugcrowd form is the blocker (account creation, scope wording), say which step stopped you and I will look at it with you. Second, I will raise this with the Community Managers directly: a non-customer who finds a leaked Atlassian key should have a plain address to send it to, and the people who run this forum can route that question to the security team in a way neither of us can. I will post back here with whatever answer comes.
If you would rather not hold the key any longer, the safe fallback is to send it to the organisation it belongs to, if the leak location tells you who that is, and to delete your copy.
Many thanks @Sami Shaik for your time and effort, and for finally providing a solution to my issue. I am marking your answer as the solution for this thread
It looks like you're new here. Sign in or register to get started.
