A Discourse forum administrator, Roi, discovered a popup message indicating their site was “hacked by a plugin”—specifically, the discourse-migratepassword plugin from the discoursehosting GitHub repository. Moin suspected the issue stemmed from using plugins from that repository, and Roi confirmed they were using it. The issue was traced to a GitHub vulnerability called “Repojacking”—where an old repository URL was hijacked after the original organization (Discoursehosting) renamed to Communiteq in 2019. RGJ, representing the original plugin maintainer, explained that the hijacked repo contained only a harmless proof-of-concept message and no malicious code, but advised users to immediately update plugin URLs from discoursehosting to communiteq. David implemented a temporary safeguard in Discourse’s Docker setup to block rebuilds referencing discoursehosting, though this was later removed after RGJ regained control of the GitHub org. The hijacker, w3shi, apologized for the disruption and acknowledged violating responsible disclosure practices. Community members like elmuerte raised broader concerns about supply chain security and proposed plugin signing to improve trust. LeoDavidson noted the safeguard didn’t always trigger clearly, but the hijacked repo is now offline. Users are urged to audit and update all plugin URLs referencing discoursehosting to avoid future risks.
A pseudo-security researcher retrieved an old Git repository for a plugin used by the forum and hijacked it to simply display this message.
The repository in question (GitHub - discoursehosting/discourse-migratepassword: A touch of security) has been inspected and no malicious code is present (it’s simply a proof of concept).
This repository had actually changed its URL (it is now available at GitHub - communiteq/discourse-migratepassword: Support migrated password hashes) and the user simply recreated the discoursehosting/discourse-migratepassword repository, which previously redirected to communiteq/discourse-migratepassword, to place unrelated code there. We were using the old URL, which is why we were affected.
If that’s true, okay… I changed the url of the plugin to communiteq and am rebuilding at the moment. But I have to look into this more (as I am not a programmer, I can’t be 100% sure).
This is a Github vulnerability in an exploit class called “Repojacking”.
We recommend everyone to check their Github plugin URLs and rename each and every instance of discoursehosting to communiteq
Background:
We had to rename our company from Discoursehosting to Communiteq in 2019.
If that happens, Github automatically redirects URLs to github repositories to their new location, until someone creates a repository with the same name. At that moment the new repository will take preference.
Github used to mark such repositories as “retired” and prohibited creating a repository with the same name.
A previous exploit is described here. Apparently that fix is no longer effective.
We have filed a Github abuse report and will try to take this repository down with all available means.
At this moment the compromised plugin only shows a message and leaves a harmless file in /tmp.
So nothing bad has happened - yet. It is important to change your plugin URL before you rebuild.
To mitigate the potential impact for users of the standard install, we’ve added code to detect github.com/discoursehosting/ and abort any rebuilds/upgrades.
---
ERROR: The configuration file containers/app.yml contains references to a compromised github organization: github.com/discoursehosting
Please remove any references to this organization from your configuration file.
For more information, see https://meta.discourse.org/t/374703/6
---
I want to sincerely apologize for the disruption caused by my actions regarding the plugin repository. In attempting to highlight a security issue, I made serious mistakes that violated the code of conduct.
Going forward, I will ensure my actions adhere to responsible disclosure practices and I appreciate the opportunity to learn from this.
Again, I am truly sorry for the disruption caused.
The next not-so responsible thing was not reaching out to me or CDCK privately when you gave up the handle, because in the past three hours, someone else could have seen your post and registered it.
You should basically assume that nothing is safe, which doesn’t work well either.
Just a few days ago it came to light that one of the developers behind some ESLint Prettier package’s NPM account was compromised and they published new compromised versions of some popular packages:
These packages were then referenced in other packages, because many claim that you should always update to the latest versions.
After I saw this thread I suggested a feature to introduce signature validation of plugins/theme components while updating them: Plugin and theme component signing
That would not stop a compromised key, but at least make part of the supply chain more trustworthy. In the end it is still possible that compromised third party libraries are pulled in. Additional dependencies are not really visible.
I’m not sure this still works. I had a plugin pointing to the compromised github URL and the error message during rebuild just said it failed to pull the repository, with some further detail about a gem version or something. (Can’t paste the exact info as it’s too far back in my scrollback from all the other noise during subsequent builds.)
Looks like the URL/repository doesn’t exist at all now, which is good (at least until someone else re-creates it) but the error message would’ve saved a lot of time.