Prebid Server Java Has a CVSS 10 SSRF — Your Ad Server Can Reach the Cloud

• The Mess: Prebid Server Java had a critical SSRF caused by bidder adapters interpolating attacker-controlled parameters into outbound URLs without properly validating the resulting hostname and path.
• The Damage: An attacker can make the server send requests to internal services, cloud metadata endpoints and other destinations reachable from the server’s network.
• The Fix: Upgrade Prebid Server Java to 3.43.0 or newer and disable affected bidder adapters if an immediate upgrade is impossible.

The ad server became the network pivot

CVE-2026-54734 was published on September 17, 2026.

It affects Prebid Server Java versions before 3.43.0 and carries a CVSS 3.1 score of 10.0:

AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

The interesting part isn’t the number.

It’s what the server can be forced to request.

Prebid Server processes bid requests as part of real-time advertising auctions. Certain bidder adapters construct outbound URLs using values supplied through those requests.

The vulnerable adapters failed to pass the resulting URL through the expected HttpUtil validation for the hostname and path. That created an SSRF primitive.

The attacker supplies the input.

Prebid Server makes the request.

The network connection originates from the server.

That’s the entire problem.

SSRF turns the server into the attacker’s proxy

The basic attack path looks like this:

Attacker
   ↓
crafted bid-request parameters
   ↓
Prebid Server Java
   ↓
vulnerable bidder adapter
   ↓
attacker-controlled URL
   ↓
internal service / metadata endpoint

The attacker does not need direct network access to the destination.

That’s what makes SSRF useful.

A firewall may block an external attacker from reaching an internal administration interface.

But if the Prebid Server host can reach that interface, the attacker can potentially make Prebid Server reach it on their behalf.

The request now comes from inside the trusted network.

Cloud metadata is the obvious target

The official advisory specifically calls out metadata endpoints as a potential destination.

That matters enormously in cloud deployments.

Cloud instances frequently expose metadata services through addresses that are intended to be reachable from workloads running on the instance.

Depending on the cloud platform, configuration and available permissions, metadata can expose information such as:

• instance identity
• temporary credentials
• IAM-related information
• workload configuration
• tokens
• deployment metadata

The vulnerability does not automatically mean an attacker gets cloud administrator credentials.

That depends on what the metadata service exposes and which identity the Prebid Server workload is running under.

But SSRF against metadata is precisely the kind of primitive defenders don’t want sitting on an Internet-facing application.

The bug is in bidder adapters

This is where the vulnerability gets slightly unusual.

Prebid Server itself isn’t simply taking an arbitrary url= parameter and fetching it.

The vulnerable path involves specific bidder adapters.

Those adapters receive parameters from bid requests and use them while constructing outbound requests.

The problem was that some of those dynamic hostnames and paths were not passed through the common validation mechanism.

Prebid fixed the issue by adding URL domain/path validation to the affected bidder adapters. The 3.43.0 release notes explicitly describe the change as validation of URLs to prevent hostname forgery.

That means an installation can be affected depending on which bidder adapters it actually enables.

No authentication required

The CVSS vector says:

PR:N

Privileges Required: None.

It also says:

UI:N

User Interaction: None.

The attacker therefore doesn’t need a Prebid administrator account or a victim to click anything.

They need to be able to supply bid-request parameters that reach the vulnerable processing path.

That’s an important distinction from many internal SSRF vulnerabilities.

This one sits in a server designed to process large volumes of external advertising traffic.

Why the CVSS reaches 10.0

The official GitHub advisory assigns:

CVSS 10.0 — Critical

with:

AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

The Scope Changed component is significant.

The vulnerable Prebid Server can be used to interact with resources outside the server’s immediate security authority.

That’s exactly what SSRF does when it crosses into internal infrastructure.

An attacker isn’t merely reading a URL from Prebid.

They are potentially making another security boundary perform the request.

The patch is already available

Prebid Server Java 3.43.0 contains the security fix.

The project release explicitly calls out:

“Validate url domain and path”

and links the change to pull request #4522.

The security advisory lists:

Affected: < 3.43.0
Fixed: 3.43.0

There is no ambiguity here.

Upgrade.

If you cannot upgrade immediately

Prebid’s own advisory provides a temporary workaround:

disable the affected bidder adapters.

That’s much better than pretending that a network firewall alone solves the problem.

You should also restrict the network privileges of the Prebid process.

If the service doesn’t need access to:

• cloud metadata,
• internal databases,
• Kubernetes APIs,
• management interfaces,
• internal HTTP services,

then it shouldn’t have that network access.

A compromised or SSRF-abused application should not be able to talk to everything behind the firewall.

Kubernetes makes SSRF more interesting

A Prebid deployment running inside Kubernetes deserves additional attention.

The vulnerable application may have access to:

• cluster services,
• internal HTTP endpoints,
• service discovery,
• cloud metadata through the node or workload environment,
• other workloads reachable through the pod network.

That doesn’t mean CVE-2026-54734 automatically becomes a Kubernetes compromise.

It means the network reachability of the Prebid pod becomes part of the vulnerability’s impact.

The more privileged the network position, the more useful SSRF becomes.

Don’t confuse this with CVE-2026-54735

There is another Prebid Server vulnerability, CVE-2026-54735, affecting the Go implementation.

It is also an SSRF caused by bidder adapters and carries CVSS 10.0.

But it is not the same product component.

CVE-2026-54734 affects:

Prebid Server Java

while CVE-2026-54735 affects:

Prebid Server

with fixes in the Go project’s version 4.4.0 branch.

That’s worth mentioning because administrators running both implementations should not assume that patching one automatically patches the other.

What administrators should check

1. Find the installed version

Check whether your deployment is running Prebid Server Java below 3.43.0.

2. Inventory bidder adapters

Identify which adapters are enabled and whether any of the affected dynamic-hostname functionality is actually used.

3. Upgrade

Move to:

3.43.0+

4. Restrict outbound network access

The Prebid process should not have unrestricted access to internal HTTP services.

5. Protect metadata services

Use the cloud provider’s recommended metadata protections and avoid granting unnecessary workload permissions.

6. Review outbound HTTP logs

Look for requests from Prebid Server to destinations that have nothing to do with normal bidder traffic.

Interesting targets include:

127.0.0.1
localhost
169.254.169.254
RFC1918 addresses
internal DNS names
Kubernetes service addresses
management interfaces

These indicators are not proof of exploitation. They are places worth investigating.

What we know about exploitation

There is currently no reliable evidence in the primary advisory that CVE-2026-54734 is being actively exploited in the wild.

The vulnerability was published September 17, and the fix was already available in Prebid Server Java 3.43.0.

So the technically accurate situation is:

CVSS: 10.0
Type: SSRF
Unauthenticated: Yes, according to the CVSS vector
User interaction: None
Affected: <3.43.0
Fixed: 3.43.0
Cloud metadata exposure: Possible
Internal network access: Possible
Confirmed active exploitation: Not established in the sources checked

That distinction matters.

A CVSS 10 SSRF is serious without pretending there is already an exploitation campaign.

Why this is a good example of modern attack surface

Prebid Server is designed to connect things.

Bid requests come in.

Adapters communicate with external bidders.

Responses come back.

That means the server naturally has outbound network access.

SSRF attacks exactly that assumption.

The attacker doesn’t have to break the network.

They convince an application that already has network access to use it against an unintended target.

The dangerous part isn’t the HTTP request itself.

It’s who is making it.

Bugstoday’s take

Prebid Server Java wasn’t supposed to become an internal network scanner.

It wasn’t supposed to query cloud metadata.

And it certainly wasn’t supposed to let untrusted bid parameters decide where its outbound HTTP connections go.

Yet that’s exactly the security boundary CVE-2026-54734 attacks.

The fix is already available, and the project gives administrators a clear fallback: disable affected bidder adapters until they can upgrade.

The ad-tech stack is full of systems with massive outbound connectivity.

That makes SSRF more than a theoretical web bug.

Patch Prebid. Restrict its network. Assume every unnecessary outbound connection is another attack surface.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

• Prebid Server Java — GitHub Security Advisory GHSA-fr2c-g2f8-qchg
• Prebid Server Java — Release 3.43.0
• Prebid Server Java — Pull Request #4522
• CVE — CVE-2026-54734
• NVD — CVE-2026-54734