CVE-2026-54735 CrowdStrike LogScale · LogScale

Detect Prebid Server SSRF via Request Forgery (CVE-2026-54735) in CrowdStrike LogScale

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.

MITRE ATT&CK

Tactic
Initial Access Collection Command and Control

LogScale Detection Query

CrowdStrike LogScale (LogScale)
cql 
#event_simpleName=NetworkConnectIP4
| ProcessName=/prebid-server/i
| in(field=RemoteAddressIP4, values=["169.254.169.254"]) OR cidr(field=RemoteAddressIP4, ranges=["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16","127.0.0.0/8"])
| groupBy([ComputerName, ProcessName, RemoteAddressIP4], function=[count(as=connection_count)])
| test(connection_count > 1)
critical severity medium confidence

CrowdStrike CQL query detecting network connections initiated by the prebid-server process to cloud metadata IP or internal IP ranges, consistent with SSRF exploitation of CVE-2026-54735.

Data Sources

Falcon Network Connect eventsProcess execution telemetry

Required Tables

NetworkConnectIP4

False Positives & Tuning

  • Prebid-server legitimately configured to reach internal adapter endpoints
  • Internal orchestration/health-check connections
  • Service mesh sidecar connections
  • Test/staging deployments with internal mock adapters

Other platforms for CVE-2026-54735

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) All platforms (combined) →

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

Last updated: 2026-08-01 Research depth: standard
References (5)

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

Related Techniques

[object Object][object Object][object Object]

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

Tactic Hubs

TA0001Initial AccessTA0009CollectionTA0011Command and Control

Related Techniques

T1190Exploit Public-Facing ApplicationT1552.005Cloud Instance Metadata APIT1595.002Vulnerability Scanning

Same Tactic: Initial Access

Popular Detections