Phantom disclosure: when security.txt points to a dead mailbox

Summary

RFC 9116 formalized security.txt as the standard way for organizations to publish a vulnerability disclosure contact. In practice, the file is often created once during a compliance push and never touched again. Contact addresses get decommissioned during personnel changes, mail migrations, or team reorganizations, while the security.txt file itself keeps quietly pointing researchers, and attackers, to an inbox nobody reads. The result is a disclosure channel that looks functional to automated scanners but is functionally dead, and that gap is exploitable.

How the misconfiguration happens

security.txt is a static file, typically served at /.well-known/security.txt, that declares a Contact field (an email address, URL, or phone number) along with optional fields like Expires, Encryption, Policy, and Preferred-Languages. Because it's static and rarely wired into any operational system, it drifts out of sync with reality in a few common ways:

• Org changes without file updates. [email protected] is set up during initial adoption, tied to a distribution list managed by a security team of two. Eighteen months later that team is dissolved, folded into IT, or outsourced, and the alias is deleted or left unmonitored. Nobody remembers to update security.txt.
• Domain/brand consolidation. After a merger or rebrand, mail routing for the old domain lapses, but the security.txt file, often copied verbatim from a template or another property, still references the legacy address.
• Third-party ownership expiry. Some organizations point Contact at a vendor-managed bug bounty triage inbox. If the contract ends and DNS/mail forwarding isn't cleaned up, the address either bounces or, worse, becomes available for re-registration.
• Copy-paste from RFC examples or another company's file. This sounds implausible until you've seen it happen: a security.txt file lifted from a public example repository, with the example domain's contact left in place.

A representative broken security.txt:

Contact: mailto:[email protected]
Expires: 2023-01-01T00:00:00.000Z
Encryption: https://company.com/pgp-key-that-404s.txt
Preferred-Languages: en
Canonical: https://company.com/.well-known/security.txt

Every field here signals disclosure maturity: RFC compliance, encryption support, canonical location. But the one field a researcher actually needs, Contact, routes into a void.

The attack path

The exploitation here isn't a technical exploit against security.txt itself. It's a trust and timing attack against the disclosure process.

1. Reconnaissance. An attacker (or a researcher operating in bad faith) enumerates security.txt across a target's domain portfolio. This is trivial to automate at scale, since the file lives at a fixed, well-known path. Bulk scanning tools already do this for legitimate bug bounty triage; the same tooling works for adversarial recon.
2. Contact validation. The attacker checks whether the listed address actually resolves and receives mail: sending a low-signal probe, checking MX records for the domain, or, in the domain-abandonment case, checking whether the domain or subdomain is even still registered to the organization.
3. Exploiting the silence. Once a dead or unmonitored channel is confirmed, the attacker has several profitable options:
   • Delay remediation deliberately. If the attacker has already found the vulnerability, they now know that reporting it through the "official" channel guarantees silence, buying time to weaponize the finding before the vendor becomes aware through other means (public disclosure, exploitation in the wild by someone else).
   • Harvest competing reports. If the mailbox bounces to an external delivery failure that leaks internal routing information, or if the domain has lapsed and the attacker re-registers it, every legitimate researcher who dutifully follows RFC 9116 and reports through the listed contact is now handing their findings, potentially including working proof-of-concept exploits, directly to the attacker instead of the vendor.
   • False confidence for the vendor. The organization believes it has a working responsible-disclosure program because the file exists and passes a checkbox audit, so it deprioritizes other detection investment (bug bounty, SOC monitoring) on the assumption this channel is covering that gap.

What it costs

The direct cost is delayed patching: every day a real vulnerability report sits in a dead mailbox is a day of exposure the security team doesn't know it has. The indirect costs compound:

• Reputational damage when a researcher goes public after a "we tried to report this responsibly and got no response" experience, a scenario that regularly ends up in security news and erodes goodwill with the researcher community.
• Regulatory exposure for organizations under frameworks (NIS2, PCI DSS 4.0, various sector-specific mandates) that expect a demonstrably working vulnerability disclosure process, not just a published one.
• Compounding risk from domain takeover, where an abandoned contact domain gets re-registered by an unrelated (or malicious) party who now controls a channel your customers and researchers were told to trust.

How validation and monitoring catch it

A security.txt check that only verifies file presence and syntax misses all of this. Effective validation has to test the contact channel's liveness, not just its shape:

• Syntax and structure validation: confirm Contact, Expires, and other fields conform to RFC 9116 (correct URI schemes, ISO 8601 timestamps, HTTPS delivery).
• Expiry enforcement: flag any file where Expires is in the past, since RFC 9116 explicitly says consumers should treat an expired file as untrusted.
• Mailbox liveness signals: for mailto: contacts, verify the domain's MX records still resolve and are consistent with the organization's mail infrastructure, not a bare A record, not a defunct third party.
• Domain and DNS provenance checks: for contact domains that differ from the primary domain (a common pattern with vendor-managed triage inboxes), confirm the domain is still registered to the organization and hasn't lapsed into availability.
• Encryption key reachability: if an Encryption field points to a PGP key URL, confirm it resolves with a 200 and returns a valid key, not a 404.
• Change-drift alerting: snapshot security.txt on a schedule and alert when Contact changes, disappears, or its target domain's mail infrastructure changes, since silent changes are exactly how a takeover or misconfiguration goes unnoticed.

On SetEnforce, the SECURITY_TXT standard runs these checks as part of continuous domain compliance monitoring rather than a one-time scan, specifically because contact rot is a slow-moving failure that a single point-in-time audit will not catch.

Mitigation and implementation steps

1. Treat security.txt as operational infrastructure, not a compliance artifact. Assign it an owner and a review cadence (quarterly at minimum) tied to the same process that reviews DNS records or TLS certificates.
2. Set a near-term Expires value and honor it. RFC 9116 recommends an expiry no more than a year out. Shorter cycles (90 to 180 days) force periodic re-verification instead of letting the file go stale for years.
3. Route Contact through a monitored, redundant channel. Use a shared distribution alias with multiple active members rather than a single person's mailbox, and pair it with a web form or ticketing system as a secondary channel so mail delivery failure isn't a single point of failure.
4. Automate liveness checks, not just file presence. Wire MX record checks and PGP key reachability into the same monitoring that watches DNSSEC, DANE, and TLS configuration for the domain.
5. Audit contact domains during any merger, rebrand, or team reorg. Add security.txt to the standard checklist for domain decommissioning and organizational change, the same checklist that should already cover DNS, mail, and certificate transitions.
6. Validate the encryption key chain. If you publish a PGP key reference, confirm it's reachable and matches the key actually used to decrypt incoming reports; a broken key link pushes reporters toward unencrypted disclosure of sensitive findings.
7. Log and alert on file changes. Any unexpected modification to security.txt, especially a changed Contact value, should trigger the same scrutiny as a DNS record change, since it's an equally viable vector for hijacking trust.

Key takeaways

• security.txt is only as trustworthy as the mailbox behind it; a syntactically valid file with a dead contact is worse than no file, because it actively misdirects legitimate disclosure.
• Attackers exploit the gap between "file exists" and "channel works" to delay remediation or intercept reports meant for the vendor.
• Point-in-time compliance checks won't catch contact rot. It requires continuous liveness validation of MX records, expiry dates, and key reachability.
• Ownership, expiry discipline, and change monitoring turn security.txt from a static checkbox into a disclosure channel that actually functions when it matters.