@Scott:

As already mentioned on 17/Nov/2021: the problem was indeed that anonymous user access was enabled. After disabling it, the user enumeration was no longer possible.

@mario Can you confirm this is still an issue in 8.18.2?!

Hello Brian Adeloye,

the problem was indeed that anonymous user access was enabled. After disabling it, the user enumeration was no longer possible.

Thank you for your help!

We are seeing the same w/ latest Tenable plugin.

Fyi, Jira is vulnerable at least up to 8.19.0 (even new Tenable plugin doesn't detect, but manual exploit attempt via curl demonstrates).  Patching to 8.20.1 to resolve.

FYI, Tenable has confirmed that plugin 154057 was reporting false positives when scanning non-vulnerable Jira instances. It appears that this has been fixed in the most recent update released for that plugin. Please contact Tenable for information.

c4b9605ba4b2 I'm unable to reproduce this issue against Jira 8.13.13 using the request included in your most recent comment. If you're still able to reproduce this, please contact Atlassian Support to open a case if you haven't already.

Hello,

i have manually tested this with an unauthenticated session in Burp Repeater:

When i send the following request:

GET /secure/QueryComponentRendererValue!Default.jspa?assignee=user:<username> HTTP/1.1
Host:  <host>

the response (Statuscode 200) contains my full name:

...rel=\"username\"  href=\"ViewProfile.jspa?name=username\">FULL NAME</a>....

Best Regards,

Mario

Hello, it seems most tools might be getting false-positive results, reach out to vendor support and confirm. A viable test is to try reproduce this vulnerability through a unauthenticated session in your browser (such as incognito mode).

Alternatively, you may use the CURL command below and verify the response when you are not authenticated to Jira:

curl -H "Accept: application/json" <jiraURL>/secure/QueryComponentRendererValue\!Default.jspa -vvv

If you are able to reach the endpoint anonymously (remember to use a unauthenticated incognito session or similar) and have a response different then a 401 Unauthorized, then have a rundown on the article https://confluence.atlassian.com/adminjiraserver/control-anonymous-user-access-975034642.html and double-check your instance security settings. For example, If you have "Browse Users" permissions granted to "Anyone on the Web" then unauthenticated users might have a way in.

I have manually tested to enumerate users in version 8.13.11 and 8.13.13 and this versions are also affected by the vulnerability.

Therefore this case should not be closed.

Yeah. I viewed the tenable output (8.20.0), and it doesn't appears to be validating the output. I do see group information, but it appears to be generic. None of my custom groups or users are displayed. I believe this to be a false positive with tenable.