Different URL parser may treat mistakes in the URL differently, leading to behaviour differences that can be used. This research paper focused on five potential areas where parses disagreed on how to understand the URL
if you're going to apply a blacklist to remove content...perform it recursively.
Not all SSRF vulnerabilities are equal, a common mitigation is to limit the locations that can be accessed; in the case of WebSphere Portal, this is exactly what was found, yet it could still be exploited.
Rocket.Chat will open links to the same domain within the main application window, with the abilitry to upload files an attacker can run Javascript and gain RCE (thanks to `nodeIntegration` being enabled).
If you log untrusted data using log4j...you might have an RCE.I wasn't able to find a good root cause of this bug but the issue itself is pretty readily understood...
There are two things at play with this vulnerability, first is the Symfony has support for `trusted_headers` to indicate which headers the framework is okay to trust, and recently support for the `X-Forwarded-Prefix` header was added and could be used regardless of whether or not it was in `trusted_headers` list.This could create a situation where cache poisoning would be possible as a request could be treated differently on the application trusting an untrusted header...
Fairly weak vulnerability to have, the URL of a remote stylesheet has minimal domain validation on it that was easily bypassed allowing an attacker to load their own stylesheets. It is a bit of a fun issue to have however as this can allow exfiltrating page content and potentially sensitive information like CSRF tokens and use it for a more complicated attack.
A partially authentication user could remove MFA from their account. During the login process when enrolled in the MFA program, a user who logged in with the correct credentials, but had not yet provided the MFA token could access the `/mfa/unenrollment` endpoint and remove MFA from the account.
Starts off by detailing a self XSS through JupyterLabs Notebook's `/lab` endpoint, where an attacker can control the page contents.In and of itself this isn't an issue, an attacker can only control the page contents of a notebook instance they own...
Two straight-forward command injection issues in Gerapy.