#js

Red Hat Security Advisory 2024-1319-03 - Red Hat JBoss Web Server 5.7.8 zip release is now available for Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 9, and Windows Server. Issues addressed include HTTP request smuggling and denial of service vulnerabilities.

Red Hat Security Advisory 2024-1318-03 - An update is now available for Red Hat JBoss Web Server 5.7.8 on Red Hat Enterprise Linux versions 7, 8, and 9. Issues addressed include HTTP request smuggling and denial of service vulnerabilities.

Red Hat Security Advisory 2024-1317-03 - Red Hat JBoss Core Services Apache HTTP Server 2.4.57 Service Pack 3 is now available. Issues addressed include buffer overflow, cross site scripting, information leakage, out of bounds read, and use-after-free vulnerabilities.

Red Hat Security Advisory 2024-1316-03 - Red Hat JBoss Core Services Apache HTTP Server 2.4.57 Service Pack 3 is now available. Issues addressed include cross site scripting, information leakage, and out of bounds read vulnerabilities.

Red Hat Security Advisory 2024-1255-03 - Red Hat OpenShift Container Platform release 4.15.3 is now available with updates to packages and images that fix several bugs and add enhancements. Issues addressed include a traversal vulnerability.

Red Hat Security Advisory 2024-0722-03 - An update is now available for Red Hat build of Quarkus. Issues addressed include a denial of service vulnerability.

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

### Summary An attacker can exploit a chain of vulnerabilities, including a Denial of Service (DoS) flaw and in-memory data storage weakness, to effectively bypass the application's brute force login protection. This makes the application susceptible to brute force attacks, compromising the security of all user accounts. ### Details The issue arises from two main vulnerabilities: 1. The application crashes due to a previously described DoS vulnerability caused by unsafe array modifications in a multi-threaded environment. 2. The application saves the data of failed login attempts in-memory, without persistent storage. When the application crashes and restarts, this data is lost, resetting the brute force protections. ```go // LoginAttempts is a timestamped counter for failed login attempts type LoginAttempts struct { // Time of the last failed login LastFailed time.Time `json:"lastFailed"` // Number of consecutive login failures FailCount int `json:"failCount"` } ``` By chainin...