[BUG] isBlockedEgressHost allows empty hostnames

[code-withkrishna]

Description

## Issue

While reviewing the hosted egress/SSRF guard, I noticed that `isBlockedEgressHost()` treats an empty hostname as allowed.

In `server/utils/hosted-egress-guard.ts`, after trimming the hostname and removing trailing dots, the function contains:

```ts
host = host.replace(/\.+$/, "");
if (!host) return false;

This means:

isBlockedEgressHost("", true)

returns false.

I reproduced this behavior locally against the current main branch.

I don't believe this is currently a direct SSRF bypass because assertAllowedHostedTargetUrl() validates the URL with new URL() before calling the egress guard. However, the behavior appears inconsistent with the guard's fail-closed security model.

How to reproduce

1. Open server/utils/hosted-egress-guard.ts.
2. Locate the isBlockedEgressHost() function.
3. Pass an empty hostname:

isBlockedEgressHost("", true)

4. Observe that it returns:

false

The same behavior occurs with a whitespace-only hostname because the value is trimmed first:

isBlockedEgressHost("   ", true)

Expected Behavior

An empty or whitespace-only hostname should fail closed and be treated as blocked:

isBlockedEgressHost("", true) === true
isBlockedEgressHost("   ", true) === true

This would be consistent with the existing fail-closed behavior for invalid or unresolvable egress targets.

Proposed Fix

Change:

if (!host) return false;

to:

if (!host) return true;

and add regression tests covering empty and whitespace-only hostnames.

Impact

This appears to be a defense-in-depth/correctness issue rather than a currently exploitable SSRF vulnerability in the normal URL-validation flow.

I have not found an existing issue or PR covering this exact case.

Would this be a change the maintainers would be open to? If so, I'd be happy to work on it.

### Don't add anything else

You **don't need a screenshot**, because this is a code-level issue.

And importantly, don't describe it as a **"Critical SSRF vulnerability"**. The wording above is deliberately accurate and technically defensible.

Once you click **Create**, send me the issue number. Then we'll wait for/handle the maintainer response before making the change.

[code-withkrishna]

Hi @matteo8p, I’d like to work on this issue if the proposed behavior makes sense.

I’ve reproduced the current behavior locally and checked the existing egress-guard implementation and related SSRF work. I believe this is best treated as a small defense-in-depth/correctness improvement rather than a direct SSRF vulnerability.

If you’re okay with the proposed approach, I’d be happy to implement the fix and add the regression tests.

[ignaciojimenezr]

Hey @code-withkrishna, approach seems right to me. Happy to assign this to you.