A Dangling CNAME and a Domain-Wide Session Cookie

Two independent facts combine. First, a DNS record for status.lumenfreight.com still points at a Heroku name that no longer exists, so whoever registers that name controls the hostname's content - a subdomain takeover. Second, the cookie is scoped with Domain=.lumenfreight.com. A domain-scoped cookie is not restricted to the host that set it: the browser sends it to every host in that domain, including status.lumenfreight.com. The moment the researcher controls that host, any visitor with a live session who requests it - including the employee who happened to browse it - presents lf_session to her server.

HttpOnly only prevents JavaScript from reading document.cookie. It does not stop the cookie being transmitted to a host inside the cookie's domain, so the team's first assumption is wrong. She can also set a cookie with the same name and domain, overwriting the real one and fixing the session to a value she knows.

The WAF assumption is also wrong: promo and status are DNS-only, so their traffic never traverses Cloudflare and no WAF rule can apply to them. The Referer check is equally weak - Referer is client-supplied, easy to forge or strip, and it would break legitimate deep links. Both containment claims fail, and neither addresses the DNS record that is actively leaking sessions.

Order by what stops ongoing credential exposure fastest, not by what is cleanest.

1. Delete or reclaim the dangling record now (status.lumenfreight.com), and sweep every other record for CNAMEs pointing at deprovisioned SaaS names. Until this is done nothing else matters, because the cookie keeps leaking.
2. Invalidate the exposure. Rotate the session-signing key or flush the session store so every currently valid lf_session dies. Assume the stolen employee cookie and any others from the takeover window are compromised. This is disruptive, so do it in the same window rather than later.
3. Re-issue as __Host-lf_session from app.lumenfreight.com with Path=/, Secure, and no Domain attribute. The __Host- prefix forces host-only scoping in the browser, so a future takeover on any sibling name can neither receive nor overwrite the cookie. Users re-authenticate; that is the point of the change, not a side effect.
4. Only then harden: registrar lock, MFA on the DNS provider, CAA records, and an inventory that alerts when a proxied hostname is switched to DNS-only.

The cookie change sits at step 3 rather than step 1 because it does not stop the current leak - the record does - but it must land in the same 24 hours, before anyone forgets. The proposed WAF rule should be dropped, not tuned: it depends on a forgeable header and gives false assurance.

The governing principle is that the registrable domain is the cookie boundary. Any host under .lumenfreight.com is inside the security perimeter of every cookie scoped to that domain, regardless of who operates it, whether it is proxied, or what it serves. You cannot outsource a subdomain and keep the parent domain's cookies safe.

Recommendation: move marketing to a name on a separate registrable domain (for example lumenfreight-offers.com or a vendor-supplied domain) so that a compromise there shares no cookie scope with the portal. DNS-only is acceptable for a vendor-hosted property only when that property is outside the cookie boundary.

If a cross-domain move is impossible in the short term, the minimum acceptable posture is: host-only cookies on the portal (already required by step 3), no sensitive cookie ever scoped to the parent domain again, a documented owner and review date for the vendor CNAME, and monitoring that alerts on record changes at the DNS provider. Document the residual risk explicitly.

The tempting middle ground - keeping promo under the parent domain but adding edge rules - does not work, because the DNS-only record never reaches the edge. The choice is structural: either the name is outside the cookie boundary, or it is inside your trust boundary and must be treated as such.