ghsa

OpenCRX version 5.2.0 is vulnerable to HTML injection via the Activity Search Criteria-Activity Number.

OpenCRX version 5.2.0 is vulnerable to HTML injection via Product Name Field.

git-urls version 1.0.1 is vulnerable to ReDOS (Regular Expression Denial of Service) in Go package.

### Summary The json-web-token library is vulnerable to a JWT algorithm confusion attack. ### Details On line 86 of the 'index.js' file, the algorithm to use for verifying the signature of the JWT token is taken from the JWT token, which at that point is still unverified and thus shouldn't be trusted. To exploit this vulnerability, an attacker needs to craft a malicious JWT token containing the HS256 algorithm, signed with the public RSA key of the victim application. This attack will only work against this library is the RS256 algorithm is in use, however it is a best practice to use that algorithm. ### PoC Take a server running the following code: ```javascript const express = require('express'); const jwt = require('json-web-token'); const fs = require('fs'); const path = require('path'); const app = express(); const port = 3000; // Load the keys from the file const publicKeyPath = path.join(__dirname, 'public-key.pem'); const publicKey = fs.readFileSync(publicKeyPath, 'utf8'); ...

### Summary This vulnerability occurs when application is not checking access of each type of users as per their role and it autorizing the users to access any feature. When user access his Device dashboard in librenms, one request is going to graph.php to access image of graphs generated on the particular Device. This request can be accessed by lower privileged users as well and they can enumerate devices on librenms with their id or hostname. ### Details _Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._ ### PoC 1. Login with Lower privilege user 2. Go to /graph.php?width=150&height=45&device=1&type=device_ping_perf&from=1699022192&legend=no&bg=FFFFFF00&popup_title=ICMP+Response 3. If its showing image with "device*ping_perf" which confirms that there is device with id 1 4. Now you can change device parameter in above URL with hostname to check if that Hostname/IP exist or not like http://127.0.0.1:8000/graph.php?wi...

### Summary XSS attacks occurs when application is not sanitising inputs properly and rendering the code from user input to browser which could allow an attacker to execute malicious javascript code. ### PoC 1. Login 2. Create a device group in /device-groups 3. Name it as `"><img src=x onerror=alert(1);>` 4. save it 5. Go to services and create a service template and add that device group into that and save it 6. After that go back to device groups and delete that device, you will see XSS payload popup in message <img width="1043" alt="Screenshot 2023-11-08 at 9 15 56 PM" src="https://user-images.githubusercontent.com/31764504/281489434-9beaebd6-b9ce-4098-a8e0-d67b185062b5.png"> ### Vulnerable code: https://github.com/librenms/librenms/blob/63eeeb71722237d1461a37bb6da99fda25e02c91/app/Http/Controllers/DeviceGroupController.php#L173C21-L173C21 Line 173 is not sanitizing device name properly <img width="793" alt="Screenshot 2023-11-08 at 9 26 14 PM" src="https://user-images.githubus...

### Impact Currently, in many Vendure deployments it's possible to select any currencyCode (really any, doesn't need to be assigned to the channel) and pay through Mollie and Stripe in that particular currencyCode. The prices are not transformed. The result is the Order is in Payment Settled in the foreign currency. See SS, CZK is not in the channel. I've tested with Mollie and Stripe it both works. **Further notes** After looking into this further and with help from the comments below, the root cause of this vulnerability is the ability to specify an arbitrary `currencyCode` as a query parameter to an API call, and then Vendure will use this and pass it to the rest of the system as `RequestContext.currencyCode`. The solution is to add validation to the passed `currencyCode` to ensure that it matches one of the available `availableCurrencyCodes` of the active Channel. Furthermore, an additional check has been added for when the currencyCode changes during the AddingItems stage - i...

### Impact Deserialization of untrusted data in IPC and Parquet readers in PyArrow versions 0.14.0 to 14.0.0 allows arbitrary code execution. An application is vulnerable if it reads Arrow IPC, Feather or Parquet data from untrusted sources (for example user-supplied input files). This vulnerability only affects PyArrow, not other Apache Arrow implementations or bindings. Note that Ibis itself makes **extremely limited** use of `pyarrow.parquet.read_table`: 1. `read_table` is used in tests, where the input file is entirely controlled by the Ibis developers 2. `read_table` is used in the `ibis/examples/__init__.py` as a fallback for backends that don't support reading Parquet directly. Parquet data used in `ibis.examples` are also managed by the Ibis developers. This Parquet data is generated from CSV files and SQLite databases. 3. The Pandas and Dask backends both use PyArrow to read Parquet files and are therefore affected. Ibis **does not** make use of APIs that directly read fro...

### Summary Application is using two login methods and one of them is using GET request for authentication. There is no rate limiting security feature at GET request or backend is not validating that. ### PoC Go to /?username=admin&password=password&submit= Capture request in Burpsuite intruder and add payload marker at password parameter value. Start the attack after adding your password list We have added 74 passwords Check screenshot for more info <img width="1241" alt="Screenshot 2023-11-06 at 8 55 19 PM" src="https://user-images.githubusercontent.com/31764504/280905148-42274f1e-f869-4145-95b4-71c0bffde3a0.png"> ### Impact An attacker can Bruteforce user accounts and using GET request for authentication is not recommended because certain web servers logs all requests in old logs which can also store victim user credentials.

Concrete CMS before 8.5.13 and 9.x before 9.2.2 allows stored XSS on the Admin page via an uploaded file name.