ghsa

A SSRF vulnerability using the Aegis DataBinding in versions of Apache CXF before 4.0.4, 3.6.3 and 3.5.8 allows an attacker to perform SSRF style attacks on webservices that take at least one parameter of any type. Users of other data bindings (including the default databinding) are not impacted.

### Impact Vela pipelines can use variable substitution combined with insensitive fields like `parameters`, `image` and `entrypoint` to inject secrets into a plugin/image and — by using common substitution string manipulation — can bypass log masking and expose secrets without the use of the commands block. This unexpected behavior primarily impacts secrets restricted by the "no commands" option. This can lead to unintended use of the secret value, and increased risk of exposing the secret during image execution bypassing log masking. Given by the following substitution examples: using `parameters` ```yaml steps: - name: example image: <some plugin> secrets: [ example_secret ] parameters: example: $${EXAMPLE_SECRET} ``` using `image` tag ```yaml steps: - name: example image: <some plugin>:latest${EXAMPLE_SECRET} secrets: [ example_secret ] ``` using `entrypoint` as a shim for `commands` ```yaml steps: - name: example image: <some plugin> secre...

discordrb is an implementation of the Discord API using Ruby. In discordrb before commit `91e13043ffa` the `encoder.rb` file unsafely constructs a shell string using the file parameter, which can potentially leave clients of discordrb vulnerable to command injection. The library is not directly exploitable: the exploit requires that some client of the library calls the vulnerable method with user input. However, if unsafe input reaches the library method, then an attacker can execute arbitrary shell commands on the host machine. Full impact will depend on the permissions of the process running the `discordrb` library and will likely not be total system access. This issue has been addressed in code, but a new release of the `discordrb` gem has not been uploaded to rubygems. This issue is also tracked as `GHSL-2022-094`.

Whoogle Search is a self-hosted metasearch engine. In versions 0.8.3 and prior, the `element` method in `app/routes.py` does not validate the user-controlled `src_type` and `element_url` variables and passes them to the `send` method which sends a `GET` request on lines 339-343 in `requests.py`. The returned contents of the URL are then passed to and reflected back to the user in the `send_file` function on line 484, together with the user-controlled `src_type`, which allows the attacker to control the HTTP response content type leading to a cross-site scripting vulnerability. An attacker could craft a special URL to point to a malicious website and send the link to a victim. The fact that the link would contain a trusted domain (e.g. from one of public Whoogle instances) could be used to trick the user into clicking the link.The malicious website could, for example, be a copy of a real website, meant to steal a person’s credentials to the website, or trick that person in another way. ...

Whoogle Search is a self-hosted metasearch engine. Versions 0.8.3 and prior have a limited file write vulnerability when the configuration options in Whoogle are enabled. The `config` function in `app/routes.py` does not validate the user-controlled `name` variable on line 447 and `config_data` variable on line 437. The `name` variable is insecurely concatenated in `os.path.join`, leading to path manipulation. The POST data from the `config_data` variable is saved with `pickle.dump` which leads to a limited file write. However, the data that is saved is earlier transformed into a dictionary and the `url` key value pair is added before the file is saved on the system. All in all, the issue allows us to save and overwrite files on the system that the application has permissions to, with a dictionary containing arbitrary data and the `url` key value, which is a limited file write. Version 0.8.4 contains a patch for this issue.

Whoogle Search is a self-hosted metasearch engine. In versions 0.8.3 and prior, the `window` endpoint does not sanitize user-supplied input from the `location` variable and passes it to the `send` method which sends a `GET` request on lines 339-343 in `request.py,` which leads to a server-side request forgery. This issue allows for crafting GET requests to internal and external resources on behalf of the server. For example, this issue would allow for accessing resources on the internal network that the server has access to, even though these resources may not be accessible on the internet. This issue is fixed in version 0.8.4.

Whoogle Search is a self-hosted metasearch engine. In versions prior to 0.8.4, the `element` method in `app/routes.py` does not validate the user-controlled `src_type` and `element_url` variables and passes them to the `send` method which sends a GET request on lines 339-343 in `request.py`, which leads to a server-side request forgery. This issue allows for crafting GET requests to internal and external resources on behalf of the server. For example, this issue would allow for accessing resources on the internal network that the server has access to, even though these resources may not be accessible on the internet. This issue is fixed in version 0.8.4.

When using axios, its dependency library follow-redirects only clears authorization header during cross-domain redirect, but allows the proxy-authentication header which contains credentials too. Steps To Reproduce & PoC axios Test Code const axios = require('axios'); axios.get('http://127.0.0.1:10081/',{ headers: { 'AuThorization': 'Rear Test', 'ProXy-AuthoriZation': 'Rear Test', 'coOkie': 't=1' } }).then(function (response) { console.log(response); }) When I meet the cross-domain redirect, the sensitive headers like authorization and cookie are cleared, but proxy-authentication header is kept. Request sent by axios image-20240314130755052.png Request sent by follow-redirects after redirectimage-20240314130809838.png Impact This vulnerability may lead to credentials leak. Recommendations Remove proxy-authentication header during cross-domain redirect Recommended Patch follow-redirects/index.js:464 removeMatchingHeaders(/^(?:autho...

Apache Airflow, versions 2.8.0 through 2.8.2, has a vulnerability that allows an authenticated user with limited permissions to access resources such as variables, connections, etc from the UI which they do not have permission to access.  Users of Apache Airflow are recommended to upgrade to version 2.8.3 or newer to mitigate the risk associated with this vulnerability

Insecure Direct Object Reference (IDOR) in Bagisto v.1.5.0 allows an attacker to obtain sensitive information via the invoice ID parameter.