Leaderboard

Does this mean that not only myself, but the developers will no longer have to read this rambling of nonsense and respond to the tantrum being exhibited for all to see. If my server is shut down, the world does not stop spinning. This is a "personal" server for the use of family and (pushing it a bit) friends. If you are getting complaints from your "users" that have probably paid the fees you impose, then you are probably doing something wrong. While I was not affected, I did see the warnings that popped up on my server dashboard. Good job guys. It got me to dig a little deeper to determine what was going on. Seems like that is the role of a good administrator. I agree with comments above that what I purchased when I bought a Lifetime license is that I bought a "Right to Use". I don't own anything except that right. I have yet to purchase any software that ownership of anything more than the media (disks) it was provide on was transferred to me. Considering the fact that I purchased my "lifetime" license in 2016, there was a clause in the agreement that stated the "lifetime" was until such time that a significant change to the software was introduced. In 7 years, I have seen a very significant change to the software and yet my "lifetime" license is still valid. Developers were damned if they do, damned if they don't. I would much rather have a developer, knowing there is a potential "hack" of my system, shut it down. As opposed to receiving an e-mail that may go unseen for a period of time. Even if I don't log into the server for days at a time, I am sure one of my family members would give me a call to let me know I have an issue. I personally would like to send a "GREAT JOB" to those involved in resolving this issue. Not everyone will be happy, but there is one Administrator out there that is extremely happy with the response and my right/privilege license to use" Emby. KEEP UP THE GREAT WORK!!! P.S. After posting this, I pulled up my e-mail receipt from the day I bought my license. I'm am so glad they did what they did as opposed to doing nothing but send an e-mail. Imagine my surprise when I saw this: No warranty of suitability, functionality or support of any kind is offered in relation to this transaction. We hope you find the software useful and worth what you provided for it.

If your issue is with the lack of reaction to the initial vulnerability, that is justified, and Emby have, we hope, learnt their lesson. But if your issue is with the steps they took to prevent this becoming a much, much bigger problem within days or even hours, then you are wrong. I hope they will soon publish their reasoning behind what they did (which I have seen), and then maybe you'll understand where they were coming from. You may still disagree, but they had a justified belief that doing it any other way than what they did would have had worse and more widespread consequences. Paul

Unfortunately my original advisory text has been softened as it would have scared people. I said it MUST scare people because it's a serious and scary situation that needs to be understood in full length: In case Emby Server has been shutdown the system is COMPROMISED! What's most important in this situation is to understand what it means and which consequences it has and which steps are required. Getting Emby Server to start again is the very last and least problem in that case. Unfortunately it now appears as if we would just want to bother people by letting them go through a complicated procedure for starting Emby again while the really important steps appear just like an optional bonus task that may be omitted and can be overread like the typical security bla bla in those instruction manuals for kitchen gadgets. So once again clearly: When your system is COMPROMISED, your task is not about getting Emby starting again You have a lot of big things to do and consider. Restarting Emby is just a tiny little bit at the very end, and only when you decide not to re-install the system.

GENERAL NOTE - PLEASE READ Guys, I know that there are a lot of things still unexplained. This has been an incredibly tough effort for all of us, I had no sleep for days until Thursday and still pretty damaged. I'll try to answer all questions over the next days, the responses need to prioritized in a way that we are helping affected users first to get going again. But there are answers to all questions you have, and some might be surprising and might make things that some are criticizing appear in a different light. Thanks for your understanding.

It's a bit funny how people are complaining about Emby trying to find a Solution to this situation, and they needed to decide quick this is nothing they had time to plan it over weeks. And now people are complaining about turning off their servers and write a info in the emby server log, because they are not able to notify everyone per mail because free users don't need to provide any contact informations. Think about it had to happen fast, and this is the way they decided to do it. From my perspective as an IT Guy, i know you need to do things really quick sometimes and normally if the emby server is not starting up anymore, i look at the emby logs, server logs or go to their support site, so this is where people will find the information. But as i know there are so many people with that less tech knowledge we even could be happy they are able to turn on their computers every day, they now start to complain about it. I would like to see your posts if all your files has been gone because the emby devs wouldn't have done anything and all your files got deleted. I am pretty sure, if this would happen, it would be more than enough for you to prevent it by stopping your server from starting up. So think about you haven't lost any data and now life goes on instead of you have 0 movies, shows and music at all because they just don't react because "IT IS YOUR SERVER AND THEY HAVE NO RIGHT TO DECIDE WHAT HAPPENS TO YOUR STUFF" I really would see what you guys would have done in this situation and if the first users start to flood your forum because all files are gone Then they can give you the answer you wanna hear from them now: It is your server, we are not responsive for your files and the security on your server.

I understand your position. I can assure you that the decision hasn't been made light-heartedly. It had been clear to us that this kind of intervention will be seen controversial, but there were reasons for why we chose to go that far and shutdown infected servers as the ultimate last resort. I wrote an article which is detailing the decision process, I hope it will be published soon.

Open DSM as usual in a web browser. Once logged in Open Control Panel. Click on the Users & Groups menu on the left. Most likely the admin account will be deactivated. We are going to activate it for our use as well as change the password (if we do not remember it). Click on the admin username to highlight it, then click the edit tab. Click the box above next to "Deactivate this account" if needed so there is not a checkbox. If you do not remember the admin password, click the Change Password button above to get this: Type a secured password in both places and click the Save button. Use lower and uppercase letters, a number or two as well as a special character. Click the Save button on the user screen as well to save our changes and we should now have a valid activated admin account to use for SSH. Next, we need to enable SSH access to the NAS. We do this easily by clicking on the left menu "Terminal and SNMP" Make sure the checkbox is enabled for SSH and set the port to 22 if needed. Click the Apply button to save this info. You will need to know the IP address of your NAS. If you're not sure, click the Network menu item, then the Network tab for a similar screen to this: You might see a "bond" or individual NIC cards which isn't that important as we just need to know the IP address. We are now ready to SSH into our NAS. You can use a terminal from a Mac or Linux or a command shell on Windows 10 & 11. In Windows hold with Windows Key while pressing R Type cmd and click the OK button. From your shell or terminal type you will launch an SSH session with the following command. Change 10.69.0.31 to use the IP of your NAS. SSH admin@10.69.0.31 If this is the first time you have SSHed into your NAS you may be asked to save a secured encryption key or similar so answer by typing yes (3 letters), not just y. You will now be prompted to type your admin password. Type it and hit enter. Go Super User Once logged in type sudo -i Navigate to Emby Server App Location We can now navigate to the top level directory of our Emby Server using: cd /volume1/@appdata/EmbyServer we can view the directory using: ls -l Change Directory If we wanted to change directory to the plugins folder we could do this: cd plugins or cd /volume1/@appdata/EmbyServer/plugins List Directory's Files and Subdirectories To view items we can do ls -l Deleting/Removing File If there was a plugin name that is not wanted you could delete it using the rm name followed by the dll name (case matters). If you had 2 dlls you wanted to remove named helper.dll and EmbyHelper.dll you could remove these using: rm helper.dll rm EmbyHelper.dll If you had a file named EmbyScripterX.xml you wished to remove that was in the config folder you could change directory up to the parent from the plugins directory using: cd .. Then to the config directory with: cd config You could now view this directory contents with ls -l To delete the file mentioned above you would type: rm EmbyScripterX.xml If you had a file in the config directory name ReadyState.xml that you wanted to remove you would use: rm ReadyState.xml Listing the Data Directory and all your Emby Database Files If you wanted to see how big your database files are you could navigate back up to the parent and then to the data directory with: cd .. cd data or cd /volume1/@appdata/EmbyServer/data ls -lh (note we added an h to the above command line to give us human readable file sizes) If you had an Emby Server that starts and immediately stopped and wanted to see what the latest log file contains you could navigate to the logs directory with: cd .. cd logs or cd /volume1/@appdata/EmbyServer/logs ls -lh View the current Log File while Emby is Running You can display the whole file quickly using: tail -f embyserver.txt (ctrl-c to quit) Copy a File to a New Location You could also copy the log file to a location you can access easily in a browser using cp embyserver.txt /volume1/homes/admin Viewing the Admin Password Reset File Knowledge Base: https://emby.media/support/articles/Admin-Password-Reset.html cat /var/lib/emby/passwordreset.txt or cat /volume1/@appdata/EmbyServer/passwordreset.txt Finishing Up When you are finished close your SSH connection. Reverse the first couple steps we did by deactivating the admin account until we need it again. We can also turn off SSH again until we need it! I hope you found the tutorial and examples useful, Carlo

There's no pain involved. It was just the answer he deserved.

Requiring a password to perform administrative activities is simply good security. Having the option to not use a password for the admin account was a bad idea to begin with. I can't imagine you are regularly administrating your server via your streaming devices. I assume you are doing this with a browser. And in the case of a browser, you simply have to check the remember me checkbox after typing in a password one time, and the cookie logs you in for future browser sessions. So, you have to type a password one time. This really doesn't seem very onerous to me.

...and by the APIs and functionality that the malware exposes. It doesn't do anything by itself, but you can do everything with it when you have control, also it hides itself and has functions to hide its activities and clean the logs from it in a targeted way.

The most likely theory I've seen expressed is that this attack was building a botnet for later exploitation, perhaps initially being sold on to more directly malignant actors. This is supported by the lack of any evidence (so far) of effects that reached beyond Emby itself. Paul

Have discovered a workaround to the issue. When adding a library, in the folder path dialogue box: Typing \\localservername\music (for example) does not resolve servername (though as stated above \\localhost\music does) However, by first scrolling to the bottom of the available folders/shares and selecting Network, brings up smb://localservername. Selecting this does resolves to the local host! However, selecting media shares this way adds the path smb://localservername/music which is, I believe, not portable between linux and windows. But manually entering \\localserver\music now works correctly and is resolved.

While I do agree that the specifics of the attack chain could have been made more clear, I don't agree with you that this is typical of the industry in vulnerability disclosures. As the level of infiltration in this attack did require a multi-chain process involving first exploiting Emby and then leveraging the scripting plugin to escalate privileges and potentially carry out more damaging attacks, the level of disclosure here, and the steps taken to taken to actually shut down the offending service are some of the most high-handed tactics I've ever seen. The fact that the actual vulnerability was reported and ignored for over three years is both embarrassing and quite upsetting; but the response since the team realized it was being exploited in the wild has actually been okay. Emby is never going to know the extent of the damage caused by this particular attack. But I have been trying to get across in my previous responses that this is the worst type of vulnerability that can exist. I haven't looked up the CVE they reported for this, but this should be reported as a 9.9 or 10.0. This is the WORST thing that can happen. It is a full RCE that can be scanned for and is likely being scanned for on the internet. The entire attack chain can be automated at this point. Meaning someone can run a program without interacting with it that can detect a vulnerable Emby instance, and then run commands in succession to gain control of your system and automatically add it to an ever growing botnet of systems fully under control of one user. Again, EVERYTHING is at risk here. Emby will never have the full scope of impacted assets. And, even if they do, they aren't going to share it because it doesn't serve any purpose. If your server was impacted, reset every password that the system had access to and rebuild the system where it was installed. That is the only way you can be mostly confident that you have addressed this.

You can't imagine how much I hated having to do it this way. It regularly upsets me that Chrome, Edge and Firefox are installing Scheduled Tasks on Windows which allow them to execute things with elevation. Same goes for all other updates which install without asking for consent. The problem in this case was that it had to happen all at once for all Emby servers in the world. That was the only way to take that BotNet down - by giving them no time to adapt and take measures. You can disable automatic restart after plugin updates.

It seems like you are more upset with the inconvenience of your server being turned off than your system being compromised. I agree only in that I do not think they went far enough to getting everyone notified about what was happening. I think they acted appropriately in turning off the systems affected. This happens all the time in other compromised situations where you may be temporarily logged out of your account whereby you will need to reset credentials. At the end of the day, you do not own Emby. They do. If you don't like how they do something, of course, you are free to do whatever you want in terms of using their software or not. Many mistakes were made here, but turning off the affected systems wasn't one of them, IMHO.

Again, many many THANKS! You and your team and everyone here are the BEST. Thanks so much for taking the time to help me and many others. I owe you many many beers. Cheers!

I see a lot of deflecting, a lot of explanation, and a lot of justification. What I don't see is any sort of acknowledgement that anything is being done to improve the process. Combine that with the "marketing spin" being put on this and leaves a VERY bad taste in the mouths of users. As has been mentioned, Emby did not "take down a botnet", it took down a specific number of servers around the world that were participating in a botnet. It is also massively misleading to claim that it was taken down "in 60 seconds" - while that may have been how long it took to post the plugin update and begin the process of pushing it out, it took TWO WEEKS from the initial hack, and more than three years since the vulnerability was exposed, before anything was "done." Further, how many servers around the world are still running affected code and have been compromised? To think that there are a whopping 1200 servers GLOBALLY that were impacted by this is not at all reasonable. I came to Emby because the front-end functionality was significantly more reliable than that of Plex. Due to Emby being insanely slow to implement very basic, repeatedly asked for features on the back end, I have continued to run my entire Plex setup solely for the purpose of the DVR functions. It looks like I will be needing to entirely rethink my entire setup once again because this overall response it not at all well-seasoned for a commercial entity.

Ok, so let's get this straight because the more I think about it the more it irks me: 1)The vulnerability was KNOWN, REPORTED AND ACKNOWLEDGED by the Emby team for 3 years. It was 3 years out there in the open in this very same forum and they did not patch it until someone just decided to mess things up. Jellyfin, their free open source competitor had this patched a long, long, long time ago. 2)They had to make the choice of forcing an update to clients that will break their setups just to do damage control, which in an of itself is a big issue because tons of users (and paid customers might I add) have no idea how to fix this themselves, as we can see in the posts here. Don't get me wrong, I get the lesser evil thing, but I honestly don't like the idea of the devs being able to decide to shut down my system 3)As of today, no e-mail was sent, no communication other than the security update (which you can easily miss if you are not checking), the forum post (which, again, I don't visit the website every day) and the broken setup (which you can easily miss if you are not using Emby daily, if you are on holidays, etc). There might be people out there with compromised systems and credentials that have not found out yet because they are not super regular users, or systems that might be turned off but when turned on will have an outdated an still insecure version of Emby. 4)Again, and this is crazy, they frame this as a good thing "We saved you from the evil BotNets!". No! You had a huge vulnerability exposed, out in the open on your forums go unpatched for 3 YEARS. I have not seen anyone from the dev team either apologize or explain this. A post explaining how did this happen and what steps will be taken so that security vulnerabilities are taken seriously AND patched is definitely in order. The issue is not that there was a security vulnerability, that's just the cost of developing software, but that after it was disclosed it was not fixed (again, 3 years, I can't state this enough times), it was mishandled and it was not properly disclosed to ALL users, but rather they were more worried on getting their own spin on the news than on actually alerting everyone their systems might be compromised. PLEASE, send a damn e-mail letting people know what happened, NOT EVERY EMBY USER MIGHT NOW AND THERE'S PROBABLY VULNERABLE SYSTEMS UNPATCHED OUT THERE WITH PEOPLE'S DATA.

Given the latest events, isn't it about time the development team took this a little more seriously and stopped kicking it down the road? All internet facing systems in 2023 should have the option for MFA.

General We at Emby believe in privacy, and as such we don't have any telemetry in place, we do no datamining, we do not store and correlate any connection data, user information and server ids - which means that we have no way to identify and know anything about the owner of a specific server. In an emergency situation like the recent BotNet takedown, it can happen that it is needed to weigh out one good against another and we can only assume what the majority of users would prefer (being hacked or vulnerable to be hacked without knowing or us taking action). In this case - for taking action - it was crucial to get reliable data and information for proper assessment. We don't know about your servers and we don't have any way to access them. But we had to find a way to get information from your servers in some way in order to assess the situation and possibly take appropriate actions and eventually, we used some auto-updating capabilities built into Emby Server, and so it was your server who initiated the connection to report back the information we needed. Conditions The local detection that we ran, performed a categorization into the following thee cases: Systems that got hacked Systems that are in danger of getting hacked Systems that are not vulnerable We have decided to report back only in cases 1 and 2. In case 3, no action was taken and no report was sent back to us. Collected Data Here's an example of the data that got reported: { "Id": "b649349bacf411a9a945eaa7aa675146", "Version": "4.7.11.0", "OperatingSystemDisplayName": "Win32NT", "OperatingSystem": "Windows", "SystemUpdateLevel": "Release", "Plugins": [{ "Name": "EmbyHelper, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null", "Version": { "Major": 1, "Minor": 0, "Build": 0, "Revision": 0, "MajorRevision": 0, "MinorRevision": 0 }, "AssemblyFilePath": "file:///C:/Users/user/AppData/Roaming/Emby-Server/system/System.Private.CoreLib.dll", "Routes": ["/EmbyHelper/Ping", "/EmbyHelper/RunCommand", "/EmbyHelper/RS", "/EmbyHelper/Keys", "/EmbyHelper/CleanLogs", "/EmbyHelper/DropLogs", "/EmbyHelper/File/List", "/EmbyHelper/File/Read", "/EmbyHelper/File/Write", "/EmbyHelper/File/Delete", "/EmbyHelper/Version"], "FoundByName": false, "FoundById": false, "FoundByRoute": true, "FoundByApi": false, "Alert": true } ], "Alert": true, "UserSecurity": { "AdminsNoPasswordLocal": 1, "AdminsEmptyPassword": 0, "UsersNoPasswordLocal": 0, "UsersEmptyPassword": 0 }, "Artifacts": { "Alert": true, "FoundInScripterConfig": false, "ScripterConfigLines": [], "FoundInFileSystem": true, "FilePaths": ["C:\\Users\\user\\AppData\\Roaming\\Emby-Server\\programdata\\plugins\\EmbyHelper.dll"] } } FAQ As there have been user questions about this, I want to clarify the following: At no point in time did we access any user's Emby server from outside We don't know your server, we don't know how to access them and we have no means to access them The data we collected (see above) does not include any personal information No user names No e-mail addresses No host names No IP addresses No Emby Premiere keys We did not log the IP addresses from which the reports came from The data exists in form of log entries in a cloud project only It won't be further processed or imported into a database The whole project will be dropped in a while and all data will be deleted

@quickmic I will glady set you up as a user so you could try on one of your kodi instances and see what you get if you were willing to go that length.

solved: update to latest beta 8.1.4 full kodi database resync.

That's okay. You will just have to reload 4.7.12, but using the version compiled for DSM 7.2 the second time After upgrading to DSM 7.2 your NAS will say that Emby package is incompatible with DSM 7.2 and Emby server won''t start. Then just download Emby 4.7.12 for DSM 7.2 and install it over top. Works fine.

That's pretty much on-point. That theory about passwords being used elsewhere is nonsense. Like @ember1205said: when there's no e-mail address associated, then there's no point in trying those credentials elsewhere. The way how they are forwarding those credentials tells more: This is including all other login details like device id, device name, internal and external IP addresses etc. That's all information that is needed to gain access to the same server again at a later time, also for example after the vulnerability has been fixed and the original way doesn't work anymore, or security has been tightened, passwords changed, etc. It's their re-entry ticket to the server. (but maybe they are trying whether these are identical with OS credentials, that's realistic)

DSM 7.2 is rolling out in phases just like always. You can wait, or you download and upgrade now. Release notes: https://www.synology.com/en-us/releaseNote/DSM?model=DS220%2B#7_2 Download: https://www.synology.com/en-us/support/download/DS220+?version=7.2#system Use the Emby server 7.2+ link to upgrade Emby after upgrading to DSM 7.2 or higher. Use the other link until then. It's up to you.

Gotcha. Thanks so much for steering me in the right direction. Is it safe to assume that the default values in Emby changed over the years and that's why the older server has different settings? I don't see either of those options in the gui settings for the server or the library. I'll do a full backup before changing it and will report back with my findings here. Thanks so much.

ok thanks - let me check this tomorrow - it's late here in the UK...

And which sites would those be? Or, is the expectation that the hackers will just randomly try my user/password combo on every site on the Internet? I don't have an email address tied to my accounts, so even trying the option of requesting a PW reset to try and at least know if I have an account on any site on the Internet is simply incomprehensible.

Well I will be darned! Thank you very much!

Hi, by any chance does this help resolve the issue? https://sourceforge.net/p/vnc-tight/mailman/message/13357114/

Thank you, you magnificent Emby team! It works! Beautious!

Take a look at the link in red at the top of the page. You may be affected by that.

Thanks, seems normal again.

Happy to help out, if I can. One last tip. If you want to see which recordings failed, go to the log folder in Windows explorer. Under advanced options, make sure File Contents is checked. In the search area put OPERATION NOT PERMITTED. You will get a list of all the log files where the recording failed. I do this regularly to clean up my library and throw away recordings that didnt complete. Nothing worse than watching something with the end missing! I also noticed that many streaming providers specifically say they do NOT support recording (including the one I use, sadly). This is probably because they dont want to deal with the complaints of their streams dropping out. So Im looking forwarded to these changes happening and perhaps recordings will stay "alive" longer.

The fact this was reported years ago and wasn't resolved before it became a big problem, they deserve some egg on their face for that. The rest of this is really just a lot of hair splitting, salivating and hand wringing over the potential for a public apology/shaming from people who haven't had their favorite feature request implemented yet. Notifying the effected servers through their logs and putting them in a position where their server is safe but they have to seek out more information was a fine response to a situation with no good answer.

Howdy everyone, I'm late to post here, but have been keeping an eye on the subject-matter since the 11th . We had someone attempt to gain access on the 11th as well. MOST users had a local password set already so we were okay but our logs did show someone attempted to access the server by spoofing the local IP 127.0.0.1. The one user (with minimum access) was accessed due to no local password (a new account that was being setup the day prior so that slipped past my watch) so we deleted that user profile for safety measures and they had to use a new user name/password. I also no longer list names locally either. It doesn't look like they went through our domain so i got a new IP from my ISP as an extra precaution and im rerouting the IP associated with our domain name so users won't have to even notice the change. Also with the attempt on the 11th, i setup fail2ban to work with emby and it also looks at local IPs and will ban them for invalid attempts as well as global IPs. I would highly recommend folks to set up fail2ban. I followed a few of the posts i found in this forum to set mine up and did a few duckduck searches 2 get the cloudflare synchronization with it working as well (in case they ever did go through the domain name in the future). I wish I could post the steps I took but I had help setting it up since I just recently jumped ship from windows a few months ago so I'm still learning. Emby team, thanks so much for your quick response & patch. I just updated my server today when I woke up. edit: ps. after very close careful examination of our log files, there was no plugins added and those .dll files were not installed thankfully. Zander

I didn't even realize all this was going on until 4.7.12 popped up on my dashboard, kinda surprised me since I wasn't expecting another update until 4.8 releases so I came on here and found quite the snafu. Glad that it seems like I wouldn't have been a target in this one. Always feels like you can do more to secure your setup and every so often with an intrusion like this you get that warm, fuzzy feeling that you're actually doing a decent job lol. I know the Emby team isn't very large. People think once you ask for money, you must have all the resources and manpower in the world with an expectation that get things handled perfectly... when in this case at least, it's more likely a few individuals working around the clock assessing a serious situation. At the end of the day it sounds like the team did their best to resolve the issue and protect users systems quickly, and they've been upfront here on the forums with what they did and why. I appreciate that. Good job guys.

This is normal though right ? The browser is saving the emby password (if you ask it to) like it does with any website out there ? Jeez - if I had to type in my passwords then I'd be there all day - infact I do not KNOW my Admin passwords at all - I have no idea, they come from a passwrd manager are are 20 chars at the very least .. On a device where the password is not saved (locked to that 'user session/browser/hardware), then of course you'll need to enter it again.

You can still set it, but it will reset itself again shortly (with the same notice in the alerts), and even while set it will refuse to auth with a pin/without a pass. (did a bunch of testing last night)

So your saying re-broadcasting copyrighted content without a license to do so is legal in your country? I'm sure the big studios/tv networks would disagree about that! Downloading is one thing.. maybe a small fine/slap on the wrist but re-broadcasting copyrighted content without a license is a different story and can lead to a huge fine or some time in jail in most countries. You've got to be intelligent for 5 minutes...

Thanks softy!! And appreciate the openness of this. I’ve always known Emby has never collected any user data or stats, right from day dot of VB and MB. I’m on board with this and think its a very responsible action to take. so thanks emby team

Si entras como Administrador sí que te aparece la ruta de la película, pero si entras como un usuario normal creo que no se ve. En mi caso con un usuario que no tiene derechos de administrador se ve así:

The "insecure configuration" is a huge convenience. From what I understand, that is the feature that allows to bypass the password on your local network. I, and probably many others do this because who wants to type in a password through an on-screen keyboard every time they select themselves to login? Passwords aren't supposed to be easy or reused either. I certainly don't want to type in a 12 digit complex password just to switch between me and the wife's account. The steps they took seemed reasonable to me. Shutting down your server (in most cases they shutdown someone's docker container) doesn't stop you from turning it back on. It was done to get your attention, and it did. We know there are people who don't update anything for months at a time, and if they didn't do that (and let it spread further), the forum would have been full of people saying they should have done more after they found all their media deleted one day... Like I said, I'm not saying it isn't frustrating, but I think they did pretty good at shutting this down. Let's not forget that many much larger (and better funded) companies have had hacks, so they can't "just plug holes" to fix everything. It doesn't work that way in the connected world. Bugs upstream, convenience vs. security, bad user practices... It all plays a role. They could make the servers "bulletproof", but you wouldn't be able to remotely access your media either. I can remember when Kronos, who does payroll for half the world, had their entire infrastructure encrypted with ransomware making people go back to punch cards for six months. I'm just reminding people that this isn't a huge corporation, but they handled it better than many with more resources do in similar situations. We should all update, review our server security, and sit back and watch a movie...

I would add that with all the "cyber-issues" out there in the world, the Emby team did a great job getting the word out on this, and fixing it quick. It's easy to get "upset" about this kind of stuff, but don't forget that software is complicated, and all we can do is react to new threats as they happen. They did that. Just practice good security measures, and keep on truckin'... I woke up to a notification that an update was available, and done... Thanks guys!

I for one am appreciative of how quickly you acted regarding this hack. I run Emby in docker (on Unraid) and it doesn't appear anything has been compromised and I didn't see any unusual activity in Emby but as your blog suggested I changed everyone's passwords as a precaution. Thank you for being diligent.

I love this thread. "Hi, I am trying to commit crimes. Please allow me to commit crimes."

Who cares what I like or don't like? We are talking about respect for the user. See Netflix which is losing thousands of users in France since yesterday following their stupid rule forbidding the connection on multi-site, I really feel that the people who manage Emby are from the same schools. The respect of the user, it is to bring him a solution when he is blocked and that he does what he can to respect an arbitrary rule which does not make any sense. I RESPECT THE RULE. I expect my license to be reactivated immediately.

Please apologize. I've been working more than two days non-stop on that matter, and I guess it's time for a rest.

how long exactly do we have to wait for that?

The purpose of these "splinters" is precisely to allow the emby team to realize that their economic model is no longer adapted to the use that the users make of it. A project that doesn't listen to its community (and your message proves that I'm not the only one to complain) is doomed to disappear in the short or long term. I'm not a fan of changing creamery every 4 mornings. I prefer to trust a tool that I use and that I am satisfied with most of its features. But when something goes wrong, I say it clearly. Having only happy people in front of you doesn't allow you to know the true thinking of the majority of your audience towards you. Accepting criticism and confronting opposing opinions is much healthier than locking yourself in your bubble of benevolence. To conclude, I confirm you that I migrated on Jellyfin, which is maybe not as successful as Emby, but which has the merit to be clear about its license: it is free. And the mere fact that this fork exists shows that I am far from being the only one to think that this licensing system is pure theft. I will be able to contribute to the project by integrating some features from Emby to make it more complete. It seems that this is also the strength of capitalism: having to adapt to a competitor who can become better than you. Good luck for the future of your project, as far as I'm concerned, it will stop here (well in 1 year for some devices since I paid the license like a fool for the year, I might as well use it to the maximum of what it allows me...).