Back Gamingonlinux Luanti (formerly Minetest) reveal a major ContentDB security incident
The team behind Luanti (formerly Minetest), just recently announced a security incident with their ContentDB system.
What is ContentDB? ContentDB (short for "Content Database") is the official way to download content such as mods, games, texture packs are more for Luanti.
Unfortunately, as the developer said: "an attacker gained unauthorized access to ContentDB’s servers, including emails, hashed passwords, and uploads". The attacker exploited two vulnerabilities, one of which was a third-party component used that the Luanti developers have reported. As they explained:
What happened? An attacker broke into ContentDB by exploiting two vulnerabilities. One of these vulnerabilities was in a third-party component that we have reported to the maintainer. We will more once they have been fixed and made public. From 22nd October 13:00 UTC, the attacker had access to ContentDB’s internal configuration. We have confirmed that they used this to sign into a staff account. This configuration also allowed modifying uploads and sending emails, but we do not have any evidence that this took place. At 22nd October 17:35, coincidentally, we deployed a patch for one of the vulnerabilities. At this point, we did not know that it had been exploited already. From 24th October 23:00, the attacker began to probe the system for remote code execution vulnerabilities. From 26th October 00:15, we have confirmed that the attacker gained full access to run commands on our server inside a docker container. This means that they will have had full access to the database and may have modified code that ran inside this container. We discovered the break-in in the morning and took ContentDB offline at 09:00. We revoked all secrets. What may have been accessed? The attacker had full access to the secrets, database, redis, and uploads: Account information: usernames, emails, and hashed passwords. Passwords are stored as salted hashes (bcrypt2) and never in plain text. Strong, unique passwords are hard to recover from these hashes, but weak or common ones can be guessed. IP addresses, not linked to any account, of people who downloaded packages from ContentDB or viewed them in-game in the two weeks before 26th of October. Uploaded packages and release files. With the secret key, they could act on the behalf of any account. We’ve checked every upload against our backups and have found no changes. However, we haven’t ruled out the possibility that the attacker caused ContentDB to serve malicious uploads during the vulnerable period.
An attacker broke into ContentDB by exploiting two vulnerabilities. One of these vulnerabilities was in a third-party component that we have reported to the maintainer. We will more once they have been fixed and made public.
From 22nd October 13:00 UTC, the attacker had access to ContentDB’s internal configuration. We have confirmed that they used this to sign into a staff account. This configuration also allowed modifying uploads and sending emails, but we do not have any evidence that this took place.
At 22nd October 17:35, coincidentally, we deployed a patch for one of the vulnerabilities. At this point, we did not know that it had been exploited already.
From 24th October 23:00, the attacker began to probe the system for remote code execution vulnerabilities.
From 26th October 00:15, we have confirmed that the attacker gained full access to run commands on our server inside a docker container. This means that they will have had full access to the database and may have modified code that ran inside this container.
We discovered the break-in in the morning and took ContentDB offline at 09:00. We revoked all secrets.
What may have been accessed?
The attacker had full access to the secrets, database, redis, and uploads:
Account information: usernames, emails, and hashed passwords. Passwords are stored as salted hashes (bcrypt2) and never in plain text. Strong, unique passwords are hard to recover from these hashes, but weak or common ones can be guessed.
IP addresses, not linked to any account, of people who downloaded packages from ContentDB or viewed them in-game in the two weeks before 26th of October.
Uploaded packages and release files.
With the secret key, they could act on the behalf of any account.
We’ve checked every upload against our backups and have found no changes. However, we haven’t ruled out the possibility that the attacker caused ContentDB to serve malicious uploads during the vulnerable period.
Ouch. Hopefully Luanti and the ContentDB can come back stronger from this with enhanced security. They're not the only ones dealing with this, especially with the recent PHP issues which we're still seeing the fallout from.
Thanks to AI, we're likely to see a lot more vulnerabilities being exploited going forwards. Thanks to how easy AI agents make poking and prodding servers, what used to be quite difficult can now be quite easily automated.
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
