Post mortem on Typefully security incident on June 9th, 2026

Late on June 8 into the early hours of June 9, 2026 (UTC), an attacker exploited a vulnerability in the third-party content system behind Typefully's public changelog. They published a malicious entry that ran unauthorized code in the browsers of people who viewed it. Because the content was not properly sanitized, the code could read an active Typefully login session and access account details. Based on our investigation, 153 users were affected.

The attacker used stolen sessions to access Typefully as affected users. Based on our investigation, we observed access to account details (such as name, email, and username) and attempts to exfiltrate that data. This did not expose the access credentials for any connected social account. Those credentials are stored encrypted on our servers and are never transmitted to clients. We found no evidence that the attacker posted, scheduled content, or otherwise took actions on behalf of any of the 153 affected users.

We promptly detected the attack while it was still active, took the affected system offline, and invalidated every login session within about an hour of discovery. The failure was clear: an internal auxiliary service was allowed to put unsanitized content in front of logged-in users. That should not have been possible, and we're fixing both the immediate issue and the conditions that allowed it.

What you need to do

No action is needed. This incident is fully contained. We logged out every user when we rotated our authentication secret, so being asked to sign in again is expected and does not mean your account was affected.

We blocked the attack while exfiltration was still in progress and found no evidence that the attacker published posts, scheduled content, or took other actions on any of the 153 affected users.

If you're one of the affected users, we're emailing you directly with specifics. If you don't hear from us, you were not in the affected group we identified. If you're unsure, contact us at support@typefully.com. Because email addresses were exposed for this group, stay alert for phishing — we will never ask for your password or API key by email.

Timeline (UTC)

• June 8, late evening — Attacker activity begins.
• June 9, 00:12 — Malicious changelog entry published.
• June 9, 00:32 — We discover the attack and open an incident.
• June 9, 00:49 — We take the affected system offline.
• June 9, 01:23 — We rotate our authentication secret; all users are logged out.
• June 9, ~01:25 — Observed attacker activity tapers off.
• June 9, shortly after — We remove the attacker's access; later attempts are blocked.

Impact

What was exposed. We identified 153 users whose sessions were replayed during the attack window. For those users, the attacker could read account details including email address and basic profile information such as name and username. Affected users are being contacted directly.

This did not expose passwords. We also found no evidence that any Typefully API key was exposed or created as part of this incident. It did not expose credentials for your connected social accounts (X, LinkedIn, and so on).

What we did not observe.

• In our logs and investigation, we found no evidence that the attacker changed any account or posted on anyone's behalf.
• We also found no evidence of access to our production database or systems beyond the content service and the session replay described above.

What we did

We took the following steps immediately:

• disabled the changelog across our website and app,
• took the affected content system offline while preserving data for the investigation,
• rotated our authentication signing secret, which invalidated every login session,
• removed the attacker's access and the artifacts they created.

We continued to see access attempts for a short period afterward, but they were blocked.

What we're doing next

• Rebuilding the changelog on a hardened, properly sanitized rendering path before we turn it back on.
• Hardening our authentication system to prevent this kind of attack, even in the event of an internal service compromise.
• Strengthening our logging so future investigations are faster.
• Strengthening signup and abuse protections.

Closing

An internal auxiliary service was allowed to put unsanitized content in front of logged-in users. That's on us. The fix is both specific — rebuild the changelog behind proper sanitization and locking down the content system — and structural: hold every service, including secondary ones, to the same security standard as our core product.