#vulnerability

Versions of the package black before 24.3.0 are vulnerable to Regular Expression Denial of Service (ReDoS) via the lines_with_leading_tabs_expanded function in the strings.py file. An attacker could exploit this vulnerability by crafting a malicious input that causes a denial of service. Exploiting this vulnerability is possible when running Black on untrusted input, or if you habitually put thousands of leading tab characters in your docstrings.

### Impact Vulnerability in **SecureProps** involves a regex failing to detect tags during decryption of encrypted data. This occurs when the encrypted data has been encoded with `NullEncoder` and passed to `TagAwareCipher`, and contains special characters such as `\n`. As a result, the decryption process is skipped since the tags are not detected. This causes the encrypted data to be returned in plain format. The vulnerability affects users who implement `TagAwareCipher` with any base cipher that has `NullEncoder` (not default). ### Patches The patch for the issue has been released. Users are advised to update to version **1.2.2**. ### Workarounds **The main recommendation is to update to the latest version as there are no breaking changes.** If that's not possible, you can use the default `Base64Encoder` with the base cipher decorated with `TagAwareCipher` to prevent special characters in the encrypted string from interfering with regex tag detection logic. This workaroun...

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