Once again deserialization and RCE through an unprotected viewstate, its kinda silly that this sort of issue continues to persist.The normal `_VIEWSTATE` field is used by some .NET applications to contain a ton of information about the current view state...
Really straight forward bug, `NimForums` uses the rather feature-full Restructured Text (RST) format for its user-generated content, which has an `include` directive that can be used to include local files. What is atleast slightly interesting here is that the code authors seemed aware of the potential vulnerabilities and included a couple comments in relevant code:
Exactly as the title puts it, cross-site scripting through content injected from the `X-Forwarded-Host` header. Its interesting that this one was paid out as without some other issue like cache poisoning it would be impossible as far I am aware to exploit this as you cannot control the headers of a random user's requests.
An inability to decode the character in a user's post, leading to HTTP 500 response.
Just send an email pretending to be part of another report and the system will make you part of it.Its really that simple, sending an email using your the email associated with your Researcher portal account with the subject `VULN-`will get that email added to the report and be copied on future updates...
This is almost an intended feature, basically if an attacker can craft a their own State cookie, they can trick the `StateFilter` into reading the `forwardPath` and forwarding their request to another servlet directly. The interesting side-effect here is that the redirect will bypass any other filters left in the chain and go directly to the other servlet.
While the hostnames were being validated for this vulnerability, injecting a `@` into the path argument was sufficent to mislead the final URL parser and actual code making the HTTP request to go to an unapproved domain by tricking it into thinking the path is actually the host and everything before the `@` is just credentials.
The gist of this is that an attack can use their own Time-based One-Time-Password (TOTP) code on another user's account.
Combination of a local file inclusion bug and a file write bug.Firstly, the `user/loader.php` and `/user/index.php` pages had some interesting code where it would take a `scripts` GET parameter to construct an include path in PHP...
The logout endpoint provided by the Shibboleth plugin for an Identity Provider to log a user out of services had an odd way of finding the right sessions to destroy that lead to the request originator being logged into another seemingly random account.