If you thought that #8770 was an obscure redirect vulnerability, this is even more obscure. Our imaginative vulnerability tester has discovered that is possible to corrupt the content of the `rp_origin_id` cookie by re-playing a request to `/oxauth/authorize.htm` with a different (possibly invalid) value for the `redirect_uri` query parameter. For example: `https://foo.com/oxauth/authenticate.htm?redirect_uri=https%3A%2F%2Fbadguy.com` This is possible because `AuthorizeAction.java` seems to accept the request_uri query parameter at [face value](https://github.com/GluuFederation/oxAuth/blob/a24335a29f468abf755d834867e8d5d3ec21c3db/Server/src/main/java/org/gluu/oxauth/authorize/ws/rs/AuthorizeAction.java#L533-L535) and then proceeds to use it to [set the cookie](https://github.com/GluuFederation/oxAuth/blob/a24335a29f468abf755d834867e8d5d3ec21c3db/Server/src/main/java/org/gluu/oxauth/authorize/ws/rs/AuthorizeAction.java#L292). The corrupted cookie then could potentially result in [redirecting the user](https://github.com/GluuFederation/oxAuth/blob/8d651cd434483bf7561e5e3d83912d79d1c9e845/Server/src/main/java/org/gluu/oxauth/service/ErrorHandlerService.java#L90) to a malicious URL. `AuthorizeAction.java` should probably be re-validating the redirect_uri. On a related note, the content of the `rp_origin_id` is not being URL encoded, so it is also possible to corrupt the HTTP header that sets it with something like this: `https://foo.com/oxauth/authenticate.htm?redirect_uri=https%3A%2F%2Fgoodguy.com;Path=/foo; domain=badguys.com`