[SECURITY BUG] Unauthorized Creative / Dev-Level Access on Non-Creative Dedicated Server

[Happivaje]

Version

2.5(32)

Platform

Windows

Summary:


Two external players gained access to Creative / Dev-level functionality on a non-creative dedicated server without being granted admin rights. This is confirmed by server logs and should not be possible.





Server setup:


Dedicated server, Creative OFF, no admin tools enabled at time of incident, crossplay enabled (Steam + EOS + EAC).





Offending players (NOT admins):

• insegt
  SteamID: 76561198996443610
  EOS ID: EOS_00024ff69acd4a259a64d075e34ec50d
  IP: 38.57.237.8
  Auth: Steam OK / EOS OK / EAC OK
• LIsland (also seen as lland / Lsland)
  SteamID: 76561198350780269
  EOS ID: EOS_0002d01c5f974a7cb53f61f6e6a685ef
  Auth: Steam OK / EOS OK / EAC OK

NOT involved (legitimate admins):


Snalle, HappiVaje, Izqu — confirmed by logs, different SteamIDs/IPs. Admin tools were enabled only after the incident for investigation.





Timeline (from logs):

• 2026-02-03 ~16:21: insegt logs in via normal authentication path
• ~16:22: LIsland joins
• Both players perform Creative / Dev-level actions despite having no admin permissions
• Behavior observed before any admin tools were enabled
• Server was manually shut down by owner to prevent further impact

Why this is not admin error:


Creative disabled, no permissions granted, no overlap with admin logins, unauthorized actions occurred prior to admin tool usage.





Why this is a security issue:


Normal user authentication resulted in access to restricted dev/creative functionality. Indicates permission leakage or unintended authorization path (possibly EOS/crossplay related).





Attachments:


Full server logs included (timestamps preserved).





Request:


Please escalate to dev/security team to review creative/dev permission gating and authorization boundaries.



Log(files) in this post

— Server Admin Team

 

[Jugginator]

Unfortunately, anti-cheat is always a "catch new exploit, patch, catch new exploit(...)", and this relies on EAC. However, your telnet traffic is rather suspicious and I conject is the attack vector. I suggest using something like Putty and disabling Telnet if you need remote access.

 

[Happivaje]

Unfortunately, anti-cheat is always a "catch new exploit, patch, catch new exploit(...)", and this relies on EAC. However, your telnet traffic is rather suspicious and I conject is the attack vector. I suggest using something like Putty and disabling Telnet if you need remote access.

The server is hosted on Nitrado (dedicated / crossplay), which is a managed platform and should not leak access without a fault in the infrastructure or integration. Telnet settings have not been modified, ports remain at default, and no third-party tools or software have been installed. All management is done through Nitrado’s web panel, which requires login via their website and uses HTTPS with third-party certificates.


If unauthorized access occurred, it is unlikely to be caused by server misconfiguration and more likely stems from a platform-level issue, a possible exploit in the Nitrado integration, or an unforeseen vulnerability in the game server itself. This cannot be reproduced by altering Telnet or any local settings, and it does not indicate user error.


As someone with knowledge of networking and game design, my insight ends here, since even with better settings I cannot inspect what’s happening on Nitrado’s side. So, wherever some leftover code or issue might be, it’s beyond my view. Would you consider looking into this? Thanks in advance

 

[Jugginator]

The server is hosted on Nitrado (dedicated / crossplay), which is a managed platform and should not leak access without a fault in the infrastructure or integration. Telnet settings have not been modified, ports remain at default, and no third-party tools or software have been installed. All management is done through Nitrado’s web panel, which requires login via their website and uses HTTPS with third-party certificates.


If unauthorized access occurred, it is unlikely to be caused by server misconfiguration and more likely stems from a platform-level issue, a possible exploit in the Nitrado integration, or an unforeseen vulnerability in the game server itself. This cannot be reproduced by altering Telnet or any local settings, and it does not indicate user error.


As someone with knowledge of networking and game design, my insight ends here, since even with better settings I cannot inspect what’s happening on Nitrado’s side. So, wherever some leftover code or issue might be, it’s beyond my view. Would you consider looking into this? Thanks in advance

Ah okay that makes more sense then with Telnet, but it definitely is very... unusual from what I see in the logs. Telnet can be sniffed which could lead to credential stealing. But, more likely it's a case of an EAC bypass exploit, which would be on EAC. Sadly, as I said, no anti cheat is perfect and each one has ways cheaters exploit to bypass. I can take a look at code, but (not to repeat myself here ) EAC is put in place to prevent such things, but there are plenty of "dark side of the internet" places where you can get a bypass exploit for anticheat software for "reasonable" prices.

My suggestion for now is to whitelist your server, or put a password on it. After a little while they will move on and you can remove the password.

 

[Happivaje]

I’ve been thinking about this while dealing with recent hacker issues, and I think there’s an opportunity to make Discord integration in 7 Days to Die much more effective.


If Discord integration went deeper and was server-specific, it could be used as an additional access and trust layer. Players would link a verified Discord account, and the server could require Discord membership (and roles) to join. This wouldn’t replace existing platform auth, but work alongside it.


From a security point of view, this would help keep hackers and bots under control. Discord already has verification, rate limiting, and anti-automation in place, so tying server access to Discord identities would raise the bar significantly and reduce anonymous abuse.


It would also make moderation simpler: one identity, one control point. Ban or restrict on Discord, and server access is handled automatically.


Just an idea, but for community and crossplay servers especially, this could make a real difference.

 

[Jugginator]

I’ve been thinking about this while dealing with recent hacker issues, and I think there’s an opportunity to make Discord integration in 7 Days to Die much more effective.


If Discord integration went deeper and was server-specific, it could be used as an additional access and trust layer. Players would link a verified Discord account, and the server could require Discord membership (and roles) to join. This wouldn’t replace existing platform auth, but work alongside it.


From a security point of view, this would help keep hackers and bots under control. Discord already has verification, rate limiting, and anti-automation in place, so tying server access to Discord identities would raise the bar significantly and reduce anonymous abuse.


It would also make moderation simpler: one identity, one control point. Ban or restrict on Discord, and server access is handled automatically.


Just an idea, but for community and crossplay servers especially, this could make a real difference.

Huh, yeah that is an interesting idea. Would require a lot of work on Discord's end. An issue I can see with that though is the somewhat common issue of people falling for the various scams and getting their Discord account stolen

 

[Happivaje]

Huh, yeah that is an interesting idea. Would require a lot of work on Discord's end. An issue I can see with that though is the somewhat common issue of people falling for the various scams and getting their Discord account stolen

Yeah, Discord’s security itself is actually pretty solid. You’ve got 2FA, device and session management, IP checks, and the ability to revoke sessions or disconnect apps almost instantly. Most Discord account takeovers don’t happen because Discord is insecure — they happen because of UI and user-behavior issues: phishing links, fake bots, and people clicking stuff they shouldn’t.


That’s kind of why a deeper Discord integration could reduce the burden on the studio instead of increasing it. If authentication and permissions are handled through Discord (OAuth with limited scopes), the responsibility for account security and recovery stays on Discord’s side. The studio doesn’t need to store passwords, deal with recovery requests, or carry extra security liability.


Another big plus is that users can disconnect apps themselves with one click if something feels off. That’s way safer than a traditional in-game account that just sits there if credentials get compromised.


On top of that, stronger account verification and security requirements would also clean up the studio’s own Discord. Unverified accounts, sketchy bot traffic, and abuse of webhooks would largely disappear if access to deeper integrations required verified accounts and proper permissions. That improves both user safety and moderation quality.


So the core issue isn’t Discord’s security — it’s how interactions and permissions are presented to users. Better UI, clearer warnings, verified accounts, and tighter permission scopes solve most of the real risks. The current integration wouldn’t need to be replaced — it would just need to be expanded and used more intelligently.

Honestly, this is one of those things that feels boring only because it works. In Finland we’re kind of used to that — a lot of everyday tech ideas were figured out early, spread everywhere, and now people barely notice them… until security comes up and someone proudly “reinvents” the password as qwerty again

 

[Happivaje]

Huh, yeah that is an interesting idea. Would require a lot of work on Discord's end. An issue I can see with that though is the somewhat common issue of people falling for the various scams and getting their Discord account stolen

Side note: I’m mostly a macOS + Linux user (M2 Mac as my daily driver and a Steam Deck on Linux), and I have a bad habit of “just quickly fixing” things when I spot an issue… which somehow always turns into way more time spent than planned If you ever need testing or someone to overthink edge cases, I’d be up for it.

 

[K_3_F_1_R]

The server is hosted on Nitrado (dedicated / crossplay), which is a managed platform and should not leak access without a fault in the infrastructure or integration. Telnet settings have not been modified, ports remain at default, and no third-party tools or software have been installed. All management is done through Nitrado’s web panel, which requires login via their website and uses HTTPS with third-party certificates.


If unauthorized access occurred, it is unlikely to be caused by server misconfiguration and more likely stems from a platform-level issue, a possible exploit in the Nitrado integration, or an unforeseen vulnerability in the game server itself. This cannot be reproduced by altering Telnet or any local settings, and it does not indicate user error.


As someone with knowledge of networking and game design, my insight ends here, since even with better settings I cannot inspect what’s happening on Nitrado’s side. So, wherever some leftover code or issue might be, it’s beyond my view. Would you consider looking into this? Thanks in advance

Unfortunately, not everything is ideal here. I have information about this, and I wrote about it, and through internal correspondence, this message was relayed to EAC.
This cheat stopped working for a while on version 2.4, but version 2.5 was released, and it became active again and is now fully functional once more.

Post automatically merged: 54 minutes ago

As far as I've seen and from the screenshots I was sent, the cheat works via Discord through an overlay.

Windows Post in thread 'Information about a dangerous private cheat bypassing EAC, ServerTools, and custom protections'

Sep 25, 2025

You could send the info via private message to any of the developers or testers in this forum. @schwanz9000 would be a good choice.

Since 7days depends on steam EAC for their security I would assume the only thing they can do would be to forward this to steam (provided they know who to contact) and hope that EAC is hardened to this. Once EAC is bypassed there is always a way to cheat as it seems too many of the calculations are done on the clients.

Thank you for providing the information - I have written to this employee and passed on all the information in full.

• K_3_F_1_R

• 

 

[K_3_F_1_R]

I’ve been thinking about this while dealing with recent hacker issues, and I think there’s an opportunity to make Discord integration in 7 Days to Die much more effective.


If Discord integration went deeper and was server-specific, it could be used as an additional access and trust layer. Players would link a verified Discord account, and the server could require Discord membership (and roles) to join. This wouldn’t replace existing platform auth, but work alongside it.


From a security point of view, this would help keep hackers and bots under control. Discord already has verification, rate limiting, and anti-automation in place, so tying server access to Discord identities would raise the bar significantly and reduce anonymous abuse.


It would also make moderation simpler: one identity, one control point. Ban or restrict on Discord, and server access is handled automatically.


Just an idea, but for community and crossplay servers especially, this could make a real difference.

Unfortunately, there are regional restrictions and somewhere Discord is not available at all (for example, Russia)