If you are on Ghost < 6.19.1, you REALLY need to update

Developer help Self-hosting
1

Hey self-hosting folks,

REMINDER: I don’t work for Ghost. The content below is my own opinion, not that of the Ghost Foundation, blah blah blah. Might be wrong, and possibly worth only what you paid for it (nothing).

In case you’ve missed it, Ghost had a baaad security vulnerability back in February, disclosed here:

That’s a bad one. Specifically, it allows an attacker to read your whole site, include admin api keys, and once they’ve got the admin api key, there’s a lot that can go wrong.

So, if you’re self hosting, you should IMMEDIATELY upgrade. Do not pass go, do not collect $200, just upgrade. (The vulnerability is there all the way back to 3.x, so older sites are not safe.)

If you updated right when 6.19.1 was released, it might be ok to assume that your site wasn’t compromised before you updated, since the vulnerability probably wasn’t widely known… maybe. If you’re still at < 6.19.1 NOW, you need to seriously consider the possibility that attackers might already have your admin api key, and that upgrading will remove the ability to get a key, but not fix any existing key leakage.

My possibly over-cautious thought is that (after you upgrade - do that first!) you should probably roll all your keys, including staff tokens. I’m not sure if this is overly alarmist, but better safe than sorry?

NOTE: If you have services connected through these keys, you WILL break them by doing this. You’ll need to revisit each service and provide the newly regenerated key/token. Yes, that sounds like a pain.

Staff tokens can be regenerated from the individual staff profile (only for the logged in user). Scroll down and click ‘regenerate’. Suspend any admin or enhanced editor users you can’t get to regenerate their own tokens. (Editors with the enhanced editor role can read the members list.)

Your Admin API keys in custom integrations can be regenerated from /ghost > settings > custom - click into each integration and regenerate.

You also need to regenerate your Zapier token - in /ghost > settings > integrations, click ‘configure’ next to zapier and regenerate the token. I’ve seen two reports of sites being compromised via Zapier token, specifically. I’m not sure it’s from this vulnerability instead of a Zapier vulnerability/leak, but I’m suspicious.

That’s all I know. Wanted to get it out there in case it helps someone. Even if key rolling sounds like too much to do today, please please please do yourself a favor and update to >= 6.19.1.

2

Thank you @Cathy_Sarisky,

You help us as always.

3

FYI this warning is legitimate and the vulnerability is being exploited in the wild. My ghost instance got compromised yesterday, the attacker used my admin key to create an Editor account, and then they updated the code injection settings on every historical post to inject malicious obfuscated javascript that popped up a fake captcha trying to trick Windows users into installing malware via the command line.

We also found that a Harvard hosted Ghost site got hit with the same malware.

In my opinion, Ghost should really do what other self hosted services like Mastodon do and have the software automatically email admins to notify them of critical security updates.

I filed an issue on github here: unauthorized editor account creation => malicious code injection · Issue #27640 · TryGhost/Ghost · GitHub

4

Ghost does this − it’s in the “check update” service:

How do I know this? Well, lots of Magic Pages customers got this email when 6.19.1 was released (while an update was rolling out – which takes about 1-2 hours for all our sites).

That said, the privacy.useUpdateCheck config must be set to true (in the JSON or env-based configuration) for Ghost to check these.

5

And transactional email needs to be working.

6

This is confusing. The documentation here claims that the update check feature is enabled by default. “All features inside the privacy.md file are enabled by default.”

7

It is enabled by default, yeah. Mentioning it from my end was rather a “don’t be surprised if you have it disabled and didn’t get the message”.

And this :backhand_index_pointing_up:

8

I could use some help figuring out how to completely clean up my compromised instanced because it seems to have been compromised again even after upgrading and rotating my user tokens. I posted a new topic here: Rotating all integration and user API keys on compromised instance