security.txt: Expires field is in the past (2026-01-01), invalid per RFC 9116

[kobihikri]

Applies To

• https://goteleport.com/.well-known/security.txt

Details

Thank you for publishing a security.txt — it's a helpful, standards-friendly touch.

I noticed its Expires field is in the past, which makes the file formally expired under RFC 9116 §2.5.5 (the field must be a single date in the future):

$ curl -sSL https://goteleport.com/.well-known/security.txt
Contact: https://hackerone.com/teleport
Contact: mailto:security@goteleport.com
Expires: 2026-01-01T00:00:00.000Z

Today is 2026-07-15, so Expires passed ~6 months ago. Some security scanners and researcher tooling treat an expired security.txt as stale/invalid and may disregard the advertised contact channels.

The contact channels themselves (HackerOne, security@goteleport.com) look correct and current — this is purely the expiry date.

How will we know this is resolved?

curl -sSL https://goteleport.com/.well-known/security.txt returns an Expires value in the future (RFC 9116 recommends refreshing it at least annually).

Related Issues

I searched open and closed issues for "security.txt" and found none covering this.

---

For transparency: I used AI assistance to help spot and draft this; I verified the live file myself with the command above.

[rob-picard-teleport]

Thanks for flagging this. I'll take a look and update!