Atlassian-connect-express (ace) vulnerability in deprecated dependency

Hello community,

I bring to your attention the following vulnerability in ACE request’s dependency.


This was reported to the Github Advisory Database about three days ago as well as Snyk’s vulnerabilities DB.

It is important to note that this dependency has been deprecated for more than 3 years. A pull request exists from a community’s volunteer to bring attention to it as the description indicates to treat it more as a Jira Issue than an actual PR with the definite solution.

ACE is greatly embedded in our plugins so it is of utmost importance that this vulnerability is fixed.


Can we please get a response from Atlassian? I don’t get why security questions are ignored here in this forum. Are we supposed to open support requests?


Does the vulnerability in request have any security impact on apps using atlassian-connect-express? As far as I understand, request is used to make requests against Confluence/Jira and against the Atlassian Authorization Server. I don’t see how SSRF would be possible there. And is anyone even using a custom agent for this?

It could be great to get Atlassian response here, given all the above.
Again, I think we will need to bring TPM’s attention to it.

1 Like

You probably want to ping @JakeComito, @mhart or @cmacneill


and @kkercz

Hi @Archer and others, thanks for bringing this to our attention and for your interest, and please accept our apologies for the slow reply.

First of all, we’ve looked into this and it seems that apps that could be affected are those that use request to make GET requests to user-provided URLs, with the default request behaviour of following redirects (and those who make other kinds of requests who have explicitly configured requests to follow these). If this isn’t your app, there’s likely no risk to your app.

If this is you, there seems to be a fairly low-risk and straightforward workaround - see this branch off the standard ACE template for details.

This should be enough to keep atlassian-connect-express apps secure from this particular vulnerability, but we’re happy to hear your concerns or feedback if you think more needs to be done to address the immediate risk.

Secondly, there is the broader question of what is to be done about atlassian-connect-express having a dependency on the no-longer-maintained (as of 2020) request library. We’d especially like your thoughts on this one. I’ve already put my thoughts on the pull request linked above but haven’t received any input there.

In short: dropping request would be a big breaking change because the HTTP client API exposed by atlassian-connect-express is inextricably coupled to the request API. It is not feasible for us to write our own adapter compatible with the request API surface, so what we’d likely do instead is provide library-agnostic methods for generating request particulars such as authentication headers, for app implementers to make use of along with their http client of choice. I’m loathe to just wrap a different library such as axios, for fear that we end up in the same situation a couple of years hence.

Would you be willing to make the necessary adaptations to this breakage in order to shed the request dependency?

Thanks again,

James Hazelwood
Principal Developer
Atlassian Ecosystem Platform


PS: If there are no objections, I’ll look into integrating the redirect blocking workaround into the default configuration of the api-supplied client in the forthcoming major ACE version for the benefit of app developers who don’t catch word of the workaround.

1 Like

No obejctsions at all.

But it will keep ACE failing under security scans.

1 Like

@jhazelwood Have you thought of using fetch (or node-fetch) as a a library? All the Atlassian API documentation already uses it, and this seems to be the new “standard”.
And indeed I would recommend against using something like axios, which will be outdated in some time also.


Hi @marc, you make a fair point: given that fetch is part of the browser API, node-fetch probably is a safer bet than something like axios. I’ll consider this with the team. Are you saying you’d be prepared to rewrite your code from request to fetch, then?

I’ll discuss this further with the team.


Hi @jhazelwood ,
Sure, I would be happy to rewrite, given an extended deprecation period.
I believe our code only uses request through httpClient and Atlassian libs.

However that might be different for other vendors.

Probably longer term fetch is the best bet for stability.


Hi @jhazelwood ,
because so many vendors (and maybe even internal developers) have built apps on ACE, I believe the only viable solution would be to “fork” ACE before replacing request, and then maintain both versions for at least 2 years. Which, with a fork, should be fairly painless.

1 Like

Hi All, the change to block cross-protocol redirects has been released in ACE 8.0.0

Thank you :slight_smile:

1 Like

Hi @JamesD and @jhazelwood ,
There’s another vulnerability in the deprecated request package for ACE: