Action required: Atlassian Connect vulnerability allows bypass of app qsh verification via context JWTs

[cmacneill]

Hi @KrishnaK,

If you are getting qsh mismatches that would not be due to these contextJWT changes, where you will ether not get a qsh claim at all or you will get a qsh claim with a fixed value.

It’s odd, of course, if this has been working for a while. I’m not sure of the nature of your patch and what else you may have updated in your Python env that could affect calculations or URL normalization.

I have not seen any other reports of qsh mismatches. If your DecodeError can include the two qsh values it would be good to see the values actually triggering the error to confirm this is a qsh mismatch.

I would also note that you should only accept context-qsh as a qsh claim on endpoints which you explicitly expect to be accessed using a context JWT. Other endpoints and, in particular, lifecycle endpoints should not accept such JWTs.

[OtavioMedeiros]

@cmacneill since Jun 21 i can’t see any tenant generating context JWTs without the fixed qsh. Is it safe now to verify in our backend that the context JWTs qsh must not be empty?

[cmacneill]

@OtavioMedeiros The rollout is now done. You can now add verification in your backend.