ghsa

### Impact The verification of the second factor had too long a session expiry. The long session expiry could be used to circumvent rate limiting of the second factor. ### Patches This issue has been addressed in Weblate 5.13.1 via https://github.com/WeblateOrg/weblate/pull/16002. ### References Thanks to Nahid Hasan Limon for reporting this issue responsibly.

The langchain-ai/langchain project, specifically the EverNoteLoader component, is vulnerable to XML External Entity (XXE) attacks due to insecure XML parsing. The vulnerability arises from the use of etree.iterparse() without disabling external entity references, which can lead to sensitive information disclosure. An attacker could exploit this by crafting a malicious XML payload that references local files, potentially exposing sensitive data such as /etc/passwd. This issue has been fixed in 0.3.27 of langchain-community.

Kaleo Forms Admin in Liferay Portal 7.0.0 through 7.4.3.4, and Liferay DXP 7.4 GA, 7.3 GA through update 27, and older unsupported versions does not restrict the saving of request parameters in the portlet session, which allows remote attackers to consume system memory leading to denial-of-service (DoS) conditions via crafted HTTP request.

### Summary [Python class pollution](https://blog.abdulrah33m.com/prototype-pollution-in-python/) is a novel vulnerability categorized under [CWE-915](https://cwe.mitre.org/data/definitions/915.html). The `Delta` class is vulnerable to class pollution via its constructor, and when combined with a gadget available in DeltaDiff itself, it can lead to Denial of Service and Remote Code Execution (via insecure [Pickle](https://docs.python.org/3/library/pickle.html) deserialization). The gadget available in DeepDiff allows `deepdiff.serialization.SAFE_TO_IMPORT` to be modified to allow dangerous classes such as `posix.system`, and then perform insecure Pickle deserialization via the Delta class. This potentially allows any Python code to be executed, given that the input to `Delta` is user-controlled. Depending on the application where DeepDiff is used, this can also lead to other vulnerabilities. For example, in a web application, it might be possible to bypass authentication via class po...

### Impact The attacker can validate if a user exists by checking the time login returns. This timing difference can be used to enumerate valid usernames, after which an attacker could attempt brute force attacks. ### Patches This vulnerability has been patched, implementing a timing-safe form login authenticator that ensures consistent response times regardless of whether a user exists or not. ### Technical Details The vulnerability was caused by different response times when: - A valid username was provided (password hashing occurred) - An invalid username was provided (no password hashing occurred) The fix introduces a `TimingSafeFormLoginAuthenticator` that performs a dummy password hash verification even for non-existent users, ensuring consistent timing. ### Workarounds No workarounds are available. Users should upgrade to the patched version. ### References - https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/03-Identity_Manag...

## Summary A Cross-Site Scripting (XSS) vulnerability allows an attacker to execute arbitrary JavaScript in the context of another user’s session. This occurs because user-supplied input is reflected back in the server’s response without proper sanitization or escaping, potentially enabling malicious actions such as session hijacking, credential theft, or unauthorized actions in the application. ## Details The vulnerability resides in the “Tags” input field on the /s/ajax?action=lead:addLeadTags endpoint. Although the server applies sanitization before storing the data or returning it later, the payload is executed immediately in the victim’s browser upon reflection, allowing an attacker to run arbitrary JavaScript in the user’s session. ## Impact A Reflected XSS attack can have a significant impact, allowing attackers to steal sensitive user data like cookies, redirect users to malicious websites, manipulate the web page content, and essentially take control of a user's session wi...

### Summary _A user with administrator rights can change the configuration of the mautic application and extract secrets that are not normally available._ ### Impact _An administrator who usually does not have access to certain parameters, such as database credentials, can disclose them._

### Summary Users with webhook permissions can conduct SSRF via webhooks. If they have permission to view the webhook logs, the (partial) request response is also disclosed ### Details When sending webhooks, the destination is not validated, causing SSRF. ### Impact Bypass of firewalls to interact with internal services. See https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/ for more potential impact. ### Resources https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html for more information on SSRF and its fix

### Summary A flaw in the `getPath` utility function could allow path confusion and potential bypass of proxy-level ACLs (e.g. Nginx location blocks). ### Details The original implementation relied on fixed character offsets when parsing request URLs. Under certain malformed absolute-form Request-URIs, this could lead to incorrect path extraction. Most standards-compliant runtimes and reverse proxies reject such malformed requests with a 400 Bad Request, so the impact depends on the application and environment. ### Impact If proxy ACLs are used to protect sensitive endpoints such as `/admin`, this flaw could have allowed unauthorized access. The confidentiality impact depends on what data is exposed: if sensitive administrative data is exposed, the impact may be High (CVSS 7.5); otherwise it may be Medium (CVSS 5.3). ### Resolution The implementation has been updated to correctly locate the first slash after "://", preventing such path confusion.

### Impact It was not clear that it is not possible to change `min_signers` (i.e. the threshold) with the refresh share functionality (`frost_core::keys::refresh` module). Using a smaller value would not decrease the threshold, and attempts to sign using a smaller threshold would fail. Additionally, after refreshing the shares with a smaller threshold, it would still be possible to sign with the original threshold; however, this could cause a security loss to the participant's shares. We have not determined the exact security implications of doing so and judged simpler to just validate `min_signers`. If for some reason you have done a refresh share procedure with a smaller `min_signers` we strongly recommend migrating to a new key. ### Patches Updating to 2.2.0 will ensure that the `min_signers` parameter will be validated. However it won't restore the security of groups refreshed with a smaller `min_signers` parameters. ### Workarounds You don't need to update if you don't us...