You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Injected creatives + IAS brand-safety pixel carry the TS edge host instead of the publisher domain #936
On the SSAT inline-creative injection path, the server-side auction builds its OpenRTB Site from the raw incoming Host header (the Trusted Server edge domain, e.g. ts.example.com) instead of the configured publisher domain (www.example.com). As a result, every injected creative and the IAS brand-safety pixel carry the staging edge host, not the real publisher host.
The /auction endpoint path is unaffected — it already sources the host from config — which is why an /auction request capture looks correct while injected creatives do not.
Root cause
There are two AuctionRequest builders that populate publisher.domain / site.domain from opposite sources:
Correct — convert_tsjs_to_auction_request (crates/trusted-server-core/src/auction/formats.rs:235 and :245) uses settings.publisher.domain (from [publisher] domain config). Used by the /auction endpoint.
Wrong — build_auction_request (crates/trusted-server-core/src/publisher.rs:3037 and :3051) uses request_info.host, the raw incoming Host header. On the SSAT proxy model that is the TS edge domain.
The wrong builder is called on both navigation paths:
Downstream, PrebidAuctionProvider::request_bids builds the OpenRTB Site directly from these fields (crates/trusted-server-core/src/integrations/prebid.rs:1812-1818), so PBS and any IAS brand-safety integration keyed on site.domain / site.page receive the edge host and reflect it into creative markup and the pixel URL.
PR #934 ("Fix ext.trusted_server.request_host to use the publisher domain", commit 5d7f696c2) only changed ext.trusted_server.request_host inside the Prebid provider (crates/trusted-server-core/src/integrations/prebid.rs:2274) to read from request.publisher.domain. That does not fix this path, because:
On the navigation path, request.publisher.domain is itself the poisoned edge host (set by build_auction_request).
So the leak into injected creatives + the IAS pixel remains.
Note: PR #916 (optional creative rewriting) is unrelated — that rewriter only makes asset URLs relative and is not the source of the host.
Suggested fix
Make build_auction_request (crates/trusted-server-core/src/publisher.rs:3012) source publisher.domain, site.domain, and page_url from settings.publisher.domain — the way convert_tsjs_to_auction_request already does — rather than from request_info.host.
Affected branch
Found on the rc/july release-candidate branch (PR #919).
Confirming this on the live production route, not just rc/july.
Reproduced today on www.prospect-a.com (TS v358, cookie-gated ts-tester=true + basic auth). Injected creatives carry url=https://ts.prospect-a.com/ and the IAS pixel carries custom2=ts.prospect-a.com, exactly as described. The auction itself is healthy (real winning CPMs across ix / msft / ozone / pubmatic / rise), so this is purely the page-context/host leak into creative markup + the IAS pixel. Raising priority since it is shipping in production, not only on the RC branch.
One thing worth pinning down for the fix: the browser request went to www.prospect-a.com (:authority: www.prospect-a.com), yet the creatives carry ts.prospect-a.com. That is consistent with the raw-Host root cause only if the production VCL route presents Host: ts.prospect-a.com to the Compute guest. If the guest instead sees Host: www.prospect-a.com, the ts.prospect-a.com value is coming from a stale settings.publisher.domain in the deployed config, and sourcing site.domain/page from settings.publisher.domain (the suggested fix) would not resolve it on its own.
Suggest verifying both before/with the fix: (1) the Host the Compute guest actually sees on the prod www route, and (2) that the deployed settings.publisher.domain is www.prospect-a.com, not ts.prospect-a.com.
Activity
jevansnyc commentedon Jul 20, 2026
Confirming this on the live production route, not just
rc/july.Reproduced today on
www.prospect-a.com(TS v358, cookie-gatedts-tester=true+ basic auth). Injected creatives carryurl=https://ts.prospect-a.com/and the IAS pixel carriescustom2=ts.prospect-a.com, exactly as described. The auction itself is healthy (real winning CPMs across ix / msft / ozone / pubmatic / rise), so this is purely the page-context/host leak into creative markup + the IAS pixel. Raising priority since it is shipping in production, not only on the RC branch.One thing worth pinning down for the fix: the browser request went to
www.prospect-a.com(:authority: www.prospect-a.com), yet the creatives carryts.prospect-a.com. That is consistent with the raw-Hostroot cause only if the production VCL route presentsHost: ts.prospect-a.comto the Compute guest. If the guest instead seesHost: www.prospect-a.com, thets.prospect-a.comvalue is coming from a stalesettings.publisher.domainin the deployed config, and sourcingsite.domain/pagefromsettings.publisher.domain(the suggested fix) would not resolve it on its own.Suggest verifying both before/with the fix: (1) the
Hostthe Compute guest actually sees on the prod www route, and (2) that the deployedsettings.publisher.domainiswww.prospect-a.com, notts.prospect-a.com.Use configured publisher domain for navigation-path auction requests (I…