The CVSS 5.1 score for this SSRF is misleading. The authentication requirement doesn't limit the attack surface—it expands it. The developers treated 'authenticated administrator' as a proxy for 'this user is trusted with network egress,' which is a fundamental category error. The synchronization worker is network-access code running from the application's context and must enforce its own network boundaries regardless of who configured the remote instance.
The vulnerability works because the original implementation validated URL syntax but not semantics—the HTTP client would follow redirects to internal services, cloud metadata endpoints (169.254.169.254), or link-local addresses without revalidation. Anyone who could store a URL configuration could use the server as a proxy into your internal infrastructure. The patch resolves hostnames at request time rather than storing pre-resolved IPs, forcing manual redirect validation at every step. This tells us the original design likely resolved at configuration time, which means the fix required rearchitecting the request pipeline rather than a simple config-time allowlist.
For defenders: the CVSS score understates the real risk because administrator accounts in Vulnerability-Lookup deployments are often targeted through credential stuffing or phishing—they're not hardened PAM contexts. Once compromised, the attacker gains server-as-proxy access to infrastructure that shouldn't be reachable from the application host. The patch introduces a new 'shared outbound URL policy' that manually validates redirects—this is new, untested code that will require the same review discipline as the original vulnerability. The critical question the CVE doesn't answer is whether this policy applies uniformly to all configured URLs or can be scoped per-instance; if it's uniform, legitimate configuration of internal aggregators may require explicit policy exceptions that weaken the boundary.
The deeper lesson: this is the aggregation-tool SSRF archetype repeating. Jenkins, GitLab, JIRA, and others have the exact same vulnerability class documented since 2013-2014. The pattern—authenticated admin configures a URL, developers assume the admin has vetted the destination, HTTP client silently follows redirects—keeps recurring because institutional knowledge about egress HTTP client security isn't being consulted during design review. Treat every HTTP client created in application context as a potential egress bridge that needs boundary enforcement at execution time, not trust propagation from configuration time.