ghsa

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

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

OpenCRX version 5.2.0 is vulnerable to HTML injection via the Accounts Group Name Field.

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...