ghsa

### Summary Nokogiri upgrades its dependency libxml2 as follows: - v1.15.6 upgrades libxml2 to 2.11.7 from 2.11.6 - v1.16.2 upgrades libxml2 to 2.12.5 from 2.12.4 libxml2 v2.11.7 and v2.12.5 address the following vulnerability: CVE-2024-25062 / https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-25062 - described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/604 - patched by https://gitlab.gnome.org/GNOME/libxml2/-/commit/92721970 Please note that this advisory only applies to the CRuby implementation of Nokogiri, and only if the packaged libraries are being used. If you've overridden defaults at installation time to use system libraries instead of packaged libraries, you should instead pay attention to your distro's libxml2 release announcements. JRuby users are not affected. ### Severity The Nokogiri maintainers have evaluated this as **Moderate**. ### Impact From the CVE description, this issue applies to the `xmlTextReader` module (which underlies `Nokogiri::XML::...

### Impact All historical installations of django-wiki are vulnerable to maliciously crafted article content, that can cause severe use of server CPU through a regular expression loop. ### Patches ### Workarounds Close off access to create and edit articles by anonymous users. ### References _Are there any links users can visit to find out more?_

### Summary Symfony 1 has a gadget chain due to vulnerable Swift Mailer dependency that would enable an attacker to get remote code execution if a developer unserialize user input in his project. ### Details This vulnerability present no direct threat but is a vector that will enable remote code execution if a developper deserialize user untrusted data. For example: ```php public function executeIndex(sfWebRequest $request) { $a = unserialize($request->getParameter('user')); } ``` We will make the assumption this is the case in the rest of this explanation. Symfony 1 depends on Swift Mailer which is bundled by default in `vendor` directory in the default installation since 1.3.0. Swift Mailer classes implement some `__destruct()` methods like for instance `Swift_KeyCache_DiskKeyCache` : ```php public function __destruct() { foreach ($this->_keys as $nsKey=>$null) { $this->clearAll($nsKey); } } ``` This method is called when php destroy the object in...

### Impact ZITADEL uses Go templates to render the login UI. Due to a improper use of the `text/template` instead of the `html/template` package, the Login UI did not sanitize input parameters. An attacker could create a malicious link, where he injected code which would be rendered as part of the login screen. While it was possible to inject HTML including javascript, the execution of such scripts would be prevented by the Content Security Policy. ### Patches 2.x versions are fixed on >= [2.47.3](https://github.com/zitadel/zitadel/releases/tag/v2.47.3) 2.46.x versions are fixed on >= [2.46.1](https://github.com/zitadel/zitadel/releases/tag/v2.46.1) 2.45.x versions are fixed on >= [2.45.1](https://github.com/zitadel/zitadel/releases/tag/v2.45.1) 2.44.x versions are fixed on >= [2.44.3](https://github.com/zitadel/zitadel/releases/tag/v2.44.3) 2.43.x versions are fixed on >= [2.43.9](https://github.com/zitadel/zitadel/releases/tag/v2.43.9) 2.42.x versions are fixed on >= [2.42.15](ht...

### Impact In Cilium clusters with WireGuard enabled and traffic matching Layer 7 policies: - Traffic that should be WireGuard-encrypted is sent unencrypted between a node's Envoy proxy and pods on other nodes. - Traffic that should be WireGuard-encrypted is sent unencrypted between a node's DNS proxy and pods on other nodes. ### Patches This issue affects: * In native routing mode (`routingMode=native`): * Cilium v1.14 versions before v1.14.8 * Cilium v1.15 versions before v1.15.2 * In tunneling mode (`routingMode=tunnel`): * Cilium v1.14 versions before v1.14.4 * Cilium v1.14.4 if `encryption.wireguard.encapsulate` is set to `false` (default). This issue has been resolved in: * In native routing mode (`routingMode=native`): * Cilium v1.14.8 * Cilium v1.15.2 * In tunneling mode (`routingMode=tunnel`): * Cilium v1.14.4. **NOTE** `encryption.wireguard.encapsulate` must be set to `true`. ### Workarounds There is no workaround to this issue. ### Acknowledgements...

### Impact In Cilium clusters with IPsec enabled and traffic matching Layer 7 policies: - Traffic that should be IPsec-encrypted between a node's Envoy proxy and pods on other nodes is sent unencrypted - Traffic that should be IPsec-encrypted between a node's DNS proxy and pods on other nodes is sent unencrypted **Note:** For clusters running in native routing mode, IPsec encryption is not applied to connections which are selected by a L7 Egress Network Policy or a DNS Policy. This is a known limitation of Cilium's IPsec encryption which will continue to apply after upgrading to the latest Cilium versions described below. ### Patches This issue affects: - Cilium v1.15 before v1.15.2 - Cilium v1.14 before v1.14.8 - Cilium v1.13 before v1.13.13 - Cilium v1.4 to v1.12 inclusive This issue has been resolved in: - Cilium v1.15.2 - Cilium v1.14.8 - Cilium v1.13.13 ### Workarounds There is no workaround to this issue. ### Acknowledgements The Cilium community has worked together ...

### Impact Cilium's [HTTP policies](https://docs.cilium.io/en/stable/security/policy/language/#http) are not consistently applied to all traffic in the scope of the policies, leading to HTTP traffic being incorrectly and intermittently forwarded when it should be dropped. ### Patches This issue affects: * Cilium v1.13 between v1.13.9 and v1.13.12 inclusive * Cilium v1.14 between v1.14.0 and v1.14.7 inclusive * Cilium v1.15.0 and v1.15.1 This issue has been patched in: * Cilium v1.15.2 * Cilium v1.14.8 * Cilium v1.13.13 ### Workarounds There is no workaround for this issue – affected users are strongly encouraged to upgrade. ### Acknowledgements The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @romikps for discovering and reporting this issue, and @sayboras and @jrajahalme for preparing the fix. ### For more information If you have any questions or comments about this advisory, please reach out on [Slack](http...

### Impact OctoPrint versions up until and including 1.9.3 contain a vulnerability that allows malicious admins to configure or talk a victim with administrator rights into configuring a webcam snapshot URL which when tested through the "Test" button included in the web interface will execute JavaScript code in the victims browser when attempting to render the snapshot image. An attacker who successfully talked a victim with admin rights into performing a snapshot test with such a crafted URL could use this to retrieve or modify sensitive configuration settings, interrupt prints or otherwise interact with the OctoPrint instance in a malicious way. ### Patches The vulnerability will be patched in version 1.10.0. ### Workaround OctoPrint administrators are strongly advised to thoroughly vet who has admin access to their installation and what settings they modify based on instructions by strangers. ### PoC Below are the steps to reproduce the vulnerability: 1. Create a URL that r...

### Summary An attacker can effectively bypass the rate limit and brute force protections by exploiting the application's weak cache-based mechanism. This loophole in security can be combined with other vulnerabilities to attack the default admin account. This flaw undermines a previously [patched CVE](https://argo-cd.readthedocs.io/en/stable/security_considerations/#cve-2020-8827-insufficient-anti-automationanti-brute-force) intended to protect against brute-force attacks. ### Details The application's brute force protection relies on a cache mechanism that tracks login attempts for each user. This cache is limited to a `defaultMaxCacheSize` of 1000 entries. An attacker can overflow this cache by bombarding it with login attempts for different users, thereby pushing out the admin account's failed attempts and effectively resetting the rate limit for that account. The brute force protection mechanism's code: ```go if failed && len(failures) >= getMaximumCacheSize() { log.Wa...

### Summary An attacker can exploit a critical flaw in the application to initiate a Denial of Service (DoS) attack, rendering the application inoperable and affecting all users. The issue arises from unsafe manipulation of an array in a multi-threaded environment. ### Details The vulnerability is rooted in the application's code, where an array is being modified while it is being iterated over. This is a classic programming error but becomes critically unsafe when executed in a multi-threaded environment. When two threads interact with the same array simultaneously, the application crashes. The core issue is located in [expireOldFailedAttempts](https://github.com/argoproj/argo-cd/blob/54601c8fd30b86a4c4b7eb449956264372c8bde0/util/session/sessionmanager.go#L302-L311) function: ```go func expireOldFailedAttempts(maxAge time.Duration, failures *map[string]LoginAttempts) int { expiredCount := 0 for key, attempt := range *failures { if time.Since(attempt.LastFailed) > maxAge*time.Sec...