CVE-2026-54734: Critical SSRF in Prebid Server Java

CVE explainers 2026-09-17 10 min read

Security Research Desk Expert reviewed

Threat intelligence · Human-verified · Updated 2026-09-17

▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.

CISOBrief · 30-second brief

TL;DR - CVE-2026-54734 is a CVSS 10.0 server-side request forgery (SSRF) vulnerability in Prebid Server Java versions before 3.43.0. - Deployments accepting attacker-controlled bid-request parameters may be affected. - Upgrade to Prebid Server Java 3.43.0 or later and restrict unnecessary outbound access. - No confirmed active exploitation or working public proof of concept was identified in the supplied data.

Vulnerability at a Glance

Field	Details
CVE ID	CVE-2026-54734
CVSS score	10.0
CVSS vector	Not supplied in the available NVD response
Attack vector	Not independently specified; exploitation requires reaching a bid-request interface and supplying crafted parameters
Authentication required	Not specified in the available record
Vulnerability type	Server-side request forgery (SSRF)
Affected product	Prebid Server Java
Affected versions	All versions before 3.43.0
Patch available	Yes
Fixed version	3.43.0
CISA KEV status	Not listed
Confirmed exploitation	None identified in the supplied NVD or CISA KEV data
Confirmed public PoC	None identified

CVE-2026-54734 is a critical Prebid Server Java SSRF vulnerability. Certain bidder adapters use values from bid requests when constructing outbound URLs. Before version 3.43.0, the resulting domain or path segment was not consistently validated through the project’s HttpUtil validation logic.

The immediate priority is inventory and remediation. Organizations should identify every Prebid Server Java deployment, determine whether it accepts attacker-controlled bid requests, review enabled bidder adapters, and upgrade to 3.43.0 or later. Network restrictions should remain in place after patching because SSRF risk is strongly influenced by the server’s outbound reachability.

Security teams can also document the affected application and fixed component in an SBOM inventory to support vulnerability tracking and future CVE remediation.

What Is This Vulnerability?

The root cause is unsafe interpolation of user-supplied bid-request parameters into outbound request URLs. In affected code paths, a bidder adapter could construct a URL from attacker-influenced data without validating the resulting destination and path segment using the project’s intended URL validation controls.

That behavior allows a remote actor who can supply relevant bid-request parameters to influence where the Prebid Server Java process sends an HTTP request. The request originates from the server, not directly from the attacker, so it may reach destinations that are inaccessible from the public internet.

Potentially reachable targets include internal administrative services, private network endpoints, loopback services, link-local addresses, and cloud-provider metadata endpoints. The exact impact depends on the enabled adapters, request routing, egress firewall rules, cloud environment, and permissions available to any service contacted through the SSRF request. The supplied material does not establish a specific data-exfiltration path or authentication bypass.

Technical Notes

The vulnerable request flow can be represented as:

Attacker-controlled bid request
        |
        v
Bidder adapter interpolates a parameter into an outbound URL
        |
        v
URL is not adequately validated through HttpUtil
        |
        v
Prebid Server Java makes the request from its own network position

The key security boundary is the destination selected by the server. A request to an external bidder endpoint may be expected behavior, while a request to 127.0.0.1, an RFC 1918 address, a link-local address, or a cloud metadata service indicates a potentially dangerous redirect of server-side network access.

AnalystImpact · assess the risk

Who Is Affected?

The affected product is Prebid Server Java, with the affected version range documented as:

Prebid Server Java < 3.43.0

The fixed release is:

Prebid Server Java 3.43.0

The available NVD record does not provide a narrower adapter-by-adapter version range. It identifies certain bidder adapters as vulnerable code paths, but the supplied information is insufficient to name every affected adapter or establish that disabling one particular adapter fully eliminates exposure.

Organizations are most exposed when their Prebid Server Java instance accepts bid requests containing attacker-controlled parameters and has broad outbound network access. Internet-facing deployments, shared advertising infrastructure, and environments running in cloud networks should receive priority. Internal-only deployments are not automatically safe if an untrusted tenant, application, partner, or client can submit bid requests.

Deployment condition	Risk consideration
Version before 3.43.0	Vulnerable version range
Version 3.43.0 or later	Fixed according to the supplied remediation record
Relevant bidder adapters enabled	May expose vulnerable URL-construction paths
Public or partner-accessible bid endpoint	Increases ability to supply crafted parameters
Broad egress access	Increases possible SSRF impact
Cloud-hosted deployment	Metadata endpoints may be reachable unless blocked

CVSS Score Breakdown

The reported CVSS base score is 10.0, which places CVE-2026-54734 in the critical severity category. However, the supplied NVD response did not include the CVSS vector string. Without that vector, the individual base metrics—including attack complexity, privileges required, user interaction, scope, confidentiality, integrity, and availability—cannot be stated reliably.

The score should therefore be used as a prioritization signal, not as evidence for unreported metric values. Defenders should not assume a specific authentication requirement or scope configuration solely from the 10.0 score. The practical exploitability described by the vulnerability record depends on the ability to submit or influence bid-request parameters and on the server’s network permissions.

CVSS element	Available information
Base score	10.0
Vector string	Not returned in the supplied NVD response
Attack vector metric	Unknown from the available record
Attack complexity metric	Unknown from the available record
Privileges required metric	Unknown from the available record
User interaction metric	Unknown from the available record
Confidentiality, integrity, availability metrics	Not individually available

Until the authoritative vector is available, organizations should conservatively treat reachable, attacker-controlled deployments as high priority. Network segmentation and egress controls can materially reduce the impact even when the application itself has not yet been upgraded.

Exploitation Status

No confirmed in-the-wild exploitation was identified in the supplied NVD or CISA Known Exploited Vulnerabilities data. CVE-2026-54734 is not currently listed in CISA KEV, so there is no CISA catalog confirmation, due date, required action, or ransomware-campaign designation associated with this CVE in the provided information.

Public remediation material does exist. The record references two corrective commits, pull request #4522, release 3.43.0, and GitHub security advisory GHSA-fr2c-g2f8-qchg. Those references demonstrate that the issue was publicly remediated, but they do not establish the existence of a working exploit.

The available search results did not identify a confirmed public proof of concept. Defenders should distinguish between public patch or advisory material and an operational exploit. SSRF exploitation may still be straightforward in a permissive deployment, particularly when an attacker can control the relevant parameters and the server can reach sensitive internal services.

ResponderRunbook · act now

How to Detect CVE-2026-54734

Detection should focus on outbound requests from Prebid Server Java to destinations that are not part of the organization’s approved bidder and service inventory. Review proxy, firewall, DNS, and application telemetry for requests to loopback, private, link-local, and metadata address ranges.

Useful destinations to investigate include:

127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
IPv6 loopback and link-local ranges
Cloud metadata addresses such as 169.254.169.254

The application may not log the complete outbound URL, so network-layer telemetry is important. Correlate inbound bid-request timestamps with outbound connections from the Prebid Server host or container. Look for unusual Host headers, requests to administrative ports, DNS lookups for internal names, unexpected response sizes, and repeated requests targeting multiple private address ranges.

Technical Detection Query

A generic Splunk-style query for proxy or egress logs can identify suspicious destinations:

index=proxy OR index=firewall
src="prebid-server*"
| eval dst_ip=coalesce(dest_ip, dst_ip, destination.ip)
| where cidrmatch("127.0.0.0/8", dst_ip)
    OR cidrmatch("10.0.0.0/8", dst_ip)
    OR cidrmatch("172.16.0.0/12", dst_ip)
    OR cidrmatch("192.168.0.0/16", dst_ip)
    OR cidrmatch("169.254.169.254/32", dst_ip)
| table _time src dst_ip dest_port http_method url status

A representative network detection condition is:

IF source_asset = Prebid_Server
AND destination_ip IN (
  RFC1918 ranges,
  127.0.0.0/8,
  169.254.0.0/16,
  IPv6 loopback,
  IPv6 link-local
)
THEN alert "Possible Prebid Server SSRF"

These patterns are starting points rather than a complete signature. Legitimate internal calls may exist in some environments, so responders should compare findings with approved architecture and known bidder endpoints.

Security operations teams can route these alerts to their SOC processes and monitoring controls for triage and escalation.

Mitigation and Patching

The definitive remediation is to upgrade Prebid Server Java to version 3.43.0 or later. The supplied record identifies 3.43.0 as the fixed version. After upgrading, verify that the deployed artifact, container image, or package actually contains the fixed release rather than relying only on a source repository branch or build label.

If an immediate upgrade is not possible, reduce exposure by:

Disabling affected or unnecessary bidder adapters.
Restricting who can submit bid requests.
Placing the service behind an authenticated or otherwise trusted ingress path where operationally feasible.
Limiting outbound traffic to required bidder and platform endpoints.
Blocking cloud metadata services and other sensitive internal destinations.

These controls reduce the likelihood of exploitation but should not be treated as a substitute for upgrading because the supplied record does not identify every vulnerable adapter path.

Source Upgrade

For a source checkout, use the fixed release explicitly:

git fetch --tags origin
git checkout 3.43.0
./mvnw clean verify

Container Upgrade

For a containerized deployment, update the image reference to the project’s 3.43.0 image or a later release, then redeploy according to the organization’s normal process. Because the exact image registry and tag convention are deployment-specific, do not assume an unverified image name.

Confirm the running version after deployment using the service’s documented health or version endpoint, image metadata, or release artifact inventory.

Network Restrictions

Temporary network controls should block unnecessary egress from the Prebid Server workload. At minimum, deny access to cloud metadata services and restrict outbound traffic to an allowlist of required bidder and platform endpoints.

Example Linux firewall controls for IPv4 metadata and IPv6 link-local access are:

sudo iptables -A OUTPUT -d 169.254.169.254/32 -j REJECT
sudo ip6tables -A OUTPUT -d fe80::/10 -j REJECT

Apply equivalent controls through cloud security groups, Kubernetes network policies, service-mesh egress policies, or a forward proxy where those controls are authoritative. Test the controls carefully because an application-level proxy, sidecar, or NAT gateway may be the actual enforcement point.

For endpoint investigation and malware-response workflows that complement network monitoring, organizations may also evaluate Malwarebytes security tools. Such tooling does not replace the Prebid Server patch or egress restrictions.

Recommended Response Checklist

Use the following checklist to prioritize remediation:

[ ] Inventory all Prebid Server Java deployments.
[ ] Identify instances running versions before 3.43.0.
[ ] Determine whether each instance accepts untrusted or partner-supplied bid requests.
[ ] Review enabled bidder adapters and their outbound destinations.
[ ] Upgrade vulnerable deployments to 3.43.0 or later.
[ ] Verify the running artifact, package, or container version.
[ ] Block cloud metadata and unnecessary private-network access.
[ ] Review proxy, DNS, firewall, and application logs for suspicious outbound requests.
[ ] Investigate requests to loopback, RFC 1918, link-local, and metadata addresses.
[ ] Record the fixed component in vulnerability and SBOM inventories.
[ ] Continue monitoring for updated NVD, vendor, and project advisory information.

References

The primary vulnerability record is the NVD entry for CVE-2026-54734. It documents the affected version range, the 10.0 CVSS score, the SSRF description, and version 3.43.0 as the remediation release:

The remediation history also references the following public changes. These links are useful for reviewing implementation details, validating backports, and comparing locally built artifacts with the upstream fix:

The supplied data does not include a CVSS vector, verified exploit code, adapter-specific version boundaries, or confirmed exploitation telemetry. Defenders should track updated NVD, project advisory, and vendor information for changes to those fields.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.