Silentsobs

**Name of the Vulnerable Software and Affected Versions** EspoCRM versions prior to 9.3.4 **Description** The '/api/v1/Attachment/fromImageUrl' endpoint is susceptible to Server-Side Request Forgery (SSRF) through a DNS rebinding (Time-of-Check to Time-of-Use) condition. This occurs because host validation utilizes the `dns get record()` function, while the subsequent HTTP request uses curl's internal resolver (`gethostbyname()`), potentially resulting in different IP addresses for the same hostname. Additionally, empty DNS results caused by failures, IPv6-only domains, or non-existent hostnames may allow hosts to bypass validation. An authenticated attacker with default attachment creation access can use this to bypass internal IP restrictions, scan internal network ports, identify internal hosts, and interact with internal HTTP-based services. **Recommendations** Update to version 9.3.4.

Name of the Vulnerable Software and Affected Versions libp2p-rendezvous versions prior to 0.56.1 Description The `libp2p-rendezvous` server is susceptible to an Out-of-Memory (OOM) Denial of Service (DoS) condition. The server does not limit the number of namespaces a single peer can register. A malicious peer can repeatedly register unique namespaces, causing the server to allocate memory for each registration without restriction. This can lead to the server crashing due to excessive memory consumption. The vulnerability resides in the `Registrations::add()` function within `protocols/rendezvous/src/server.rs`. The server stores registrations in a BiMap keyed on `(PeerId, Namespace)`, a HashMap, and a FuturesUnordered heap. Namespace strings are validated for length but not count. There is no `max registrations per peer` limit in the configuration. Registrations persist for up to 72 hours, and disconnecting a peer does not remove the entries. A proof-of-concept (PoC) demonstrates that a single peer can register 10,000 unique namespaces, and scaling this attack with multiple sybil peers can quickly exhaust server memory. Any node running `libp2p-rendezvous` server-side is affected, potentially disrupting peer discovery for clients relying on the server. Recommendations Update to a version of `libp2p-rendezvous` that includes a fix for this vulnerability. Implement a `max registrations per peer` limit in the `Config` and enforce it within the `Registrations::add()` function before inserting new registrations.