Leaderboard

@softworkzWhile I can't find any evidence on either of my two servers that this actually affected me in any way I will say that if I went to use one and it had been shut down by the emby team although it would have been frustrating and annoying until I understood what was going on I will say that I fully support the actions you took and would have if it HAD inconvenienced me. Emby is now a part of my life. I use it every day, I add stuff to it every day and as such I cannot imagine life without it so I thank you for protecting us and the community as a whole. There are a bunch of great and helpful people here. I'm sure a few will complain but something tells me the majority is aware of the potential of no action being taken. You have my permission to get such info from any of my servers. Thanks for keeping emby the best out there.

We didn't disable it. We prevented it from starting to make sure that affected users understand what happened and what they need to do: remove the malware, carefully analyze and check, change passwords etc. Why is this frustrating? Should we have left the infected servers running for however long as the admin might never notice or look on the dashboard and hope that the user gets attention before something worse happens? Those systems we have shutdown were COMPROMISED, INFECTED, HIJACKED by a VIRUS or TROJAN or BACKDOOR however you want to call it. And then you find it "frustrating" that we shut them down? None of us liked to do this, I can tell you that. But when you install software from a 3rd party, there's always a certain amount of trust required. Because it doesn't make a difference whether it gets auto-installed or you do it manually: In both cases, you can't "see" what's inside the update you are installing. It was a tough decision. Details and reasons will be explained, then you might understand a bit better why we did what we did.

@moviefan We do not allow this type of attacking to other members, but you went a head and start attacking our mod's team I disable your post for today as a warning, if this happens again, you risk a ban on your account. This for any member whom start to attack another members or the mod's team here.

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

Hello, i know this not the right thread to ask this, but its also security related. My question is, do we get also a fix for the image leaking problem of emby? This is a long time known issue and i dont want to share my private images publicly. Image leaking without authentication: http://xxx:8096/emby/Items/xxxx/Images/Primary? King Regards, pektoral

To circle back, after a full backup, I changed both of those settings to true and restarted. After doing a rescan of the movie library, Emby did a full metadata refresh. Watch state was not affected. Folder items in the library disappeared. All is well. The only downside was, the preview thumbnails (bif files) also disappeared and will all be recreated, which will take a while, but no big deal.

Apparently it was just a matter of waiting or possibly a reboot of the NAS. I went back to it a little while ago and it's now letting me add the libraries. Thanks for your assistance. One issue I'm having now is that I'm getting the Continue Watching section on the Home Screen but I'm not seeing the individual libraries under that the way I did before. Any thoughts? They aren't options in the Home Screen drop downs in the server manager either.

Emby have said they didn't collect any information which would enable them to answer this. They have said it was. Please try to keep your responses to the lamentable failure to plug the vulnerability and to their response to an infection separate. Of course the response shouldn't have been necessary - but you'll see when they publish the details (the full report is being prepared) that what they did was justified and how they did it was appropriate and well executed. Paul

You nailed it. Hopefully the Emby devs have learned something from the current debacle.

It's not Voldemort you can say Jellyfin

Just want to mention that this type of thing is possible with literally any application that receives updates.

I was out of town when this happened and my wife understands bupkis about this so if this exploit had happened to me I would have been helpless to do anything about it even if I was made aware. I for one am grateful the emby team took action. I am not savvy enough on this stuff to fully understand what could have happened but I have over 60TB of what amounts to a lot of work online at the moment, some hard to replace, and if I could have lost any of it then that is far worse than the emby team executing an action without my knowledge to protect me from such loss. Thanks again guys.

Yes, it had to be like that. This wasn't a virus which acts autonomously. It was a backdoor to turn Emby Servers into BotNet nodes. In case of a BotNet, there are people sitting at the other end, having lists of their active nodes in front of them and the ability to quickly execute arbitrary scripts or binaries which can be transmitted and this needs to be setup just once and then it can be assigned to an arbitrary number of nodes for execution. Of course, those hackers are monitoring the forums and seeing the same things like you and me. If we had made the updates we provided to execute on arrival, then they would have seen "their" nodes disappearing slowly one after another (within 24h). They could and would have taken measures, like blocking our actions from getting deliverer, or installing additional backdoors - whatever is needed in order not to lose "their" servers. The same applies if we would have informed users: they would have noted it and taken measures, and the whole thing would have ended really badly for a large number of Emby users. We only had a single chance to save (almost) all Emby servers. It had to happen in a way that they don't see it coming. All happened within 60 seconds only. There was no other way to get all these servers saved. There will be a document with more details in a while.

Gibberish was not even the person you were quoting. Your post contained nothing meaningful. Settle down.

@BASplease lend your support here as i believe this would fix the duplication's in CW

The problem is that you informed no one. Posting a banner on the web site of the forums is not notification any more than my stapling my resume to a utility pole would count as notifying every local business that I am looking for work.

People do not usually enter the forum, most people doesn't even know it exists. Full disclosure to everyone possible is always the best approach, because there are people affected that might not realize they are affected. Yes, I get that you don't have the email of everyone that ever downloaded Emby, but doing a reasonable attempt to inform registered customers is the lowest bar possible and you have not cleared it. And yes, you will be innundated, thats on you because you had three years to patch this. You did not take down a botnet, you took down the part of the botnet that you had access to, but there's probably lots of compromised systems out there that have no idea what's going on. If you are trying to argue that informing less people of your security issues is better than more people, then I think your approach to security is severely out of date.

Hi @Luke@softworkz, First of all thanks for your investigation. I would like to ask couple of question to make sure I got this right and also give some suggestions. SCENARIO: I have in the setting: Local Network Access => Require a password on the local network I DON'T have the EmbyHelper.dll or helper.dll in the plugin folder. I exposed emby through a reverse proxy (SWAG) Emby starts fine and no strange stuff in the Emby logs nor in the swag logs. I checked my server DNS logs and the domain listed in the advisory is NOT present. The questions are: Given the points listed above is it safe to consider that I was NOT affected by the hack? Is emby connect affected as well? SUGGESTIONS: While I appreciate this post with the details you have provided I would do some stuff differently next time. Give the severity of this I would have sent an email warning your users (all of them). I was able to find out about this by pure luck by reading the news. The informations about actions to take to check if someone got hacked or actions to take to resolve the issue are NOT very clear (at least to me) and scattered among various thread in the forum. Would be nice to have detailed information on which exact file/DNS record to check (Name, hashes, version, etc.). Remember who reads the advisory has no background information/clue about what you are talking. I can see a lot of users here are not tech savy so a FAQ included in the advisory would come in handy. (Example: Windows user....check the following path, linux users...check this other path). Timeline: When do you first discovered about the issue? How did you discovered it? If someone got hacked we want to check every log not only the last one. Having a timeline greatly reduces efforts needed by administrators to properly check their systems and take remedial action. Why the proxy variable vulnerability reported in 2020 was NOT fixed earlier?? Despite the misconfig some of us might have, this was key for a successful exploitation. I also discovered about this vulnerability just because of what happened. If you can't fix something for whatever reason just warn your user so we know and we as user/server owners can decide on the action to take. Thanks for taking the time to read my post. Hopefully this is not interpreted as criticism rather as a suggestion by a concerned user for the future in hope something like this will never happen again.

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

This is a security release which all Emby Server users are recommended to update to. Here are the changes: Fix 172.X addresses always being considered private Don't allow local network addresses to be specified in x-forwarded-for and x-real-ip Adjust web app html tags to avoid false detection from Chrome as impersonating the Emby domain

So it just means changing your port lol. And yes I did setup port forwarding. Didn’t know “public facing router port” meant just changing your port from 8096 to something else.

BAS, is that you?? Wow, blast from the past if it is! Amazing! I spent quite a bit of time thinking about how to fix these issues from inside the plugin. Unfortunately, because the top pick is just pointing back to the actual item, it doesn't allow us to alter the state of the top pick. I thought about letting the code alter the state of the original metadata, but it's tricky, and figured it might not go over well. The ironic thing is, the top pick mirrors the library item, but it creates its own entry into the database, which causes it to show up in the 'continue watching' row... twice I mean talk about a 'lose, lose' situation. If something changes in the future, that allows me to remedy these things, I'll add it right away. Or, if someone has some ideas about metadata and .strm/.nfo files in emby... I'd be very interested in hearing any ideas. I'd write and test anything in the code to fix the duplicate issues. It also drives me nuts.

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.

A savvy user noticed odd behaviour on his system, and cooperated with Emby to let them analyse what was happening on their system. After that analysis, they realised they had to find a way to get information from other compromised servers, and a way to deal with them. Paul

No. But we did not look for anything like that. Also this would all have been none of our business. Scanning file systems or collecting data anywhere beyond of the Emby installation would have been completely inappropriate and inacceptable - to say the least. Please also note that we never "looked into" any Emby server actively, we never established a connection to any customer server. Those investigations need to be done by the admin/owner of the system and nobody else - definitely not us. That's one of the many reasons for the shutdowns: Nobody can know what happened on the system so it must be carefully investigated before running it normally again. Further: What can be found on one system doesn't mean that it's the same on other systems. So: When you see somebody telling that nothing malicious was found on HIS server - it doesn't mean that the same applies to YOUR server!

A port scan (for a single port) over the full IPv4 address range takes about a day nowadays. But AFAIR, that figure applies when you have a provider-scale infrastructure available. So - yes, most likely port scans done by another BotNet or even by those servers which they already had. We didn't include any identifiable information in the reports so we have no IP addresses, host names and ports and I can't even tell whether all the hacked servers had 8096 or 8196 as ports or whether they had found others. Generally, I would recommend to never use 8096 or 8196 publicly. Either use ports without a known specific service type or use 80 and 443. Using the latter makes it much more difficult to find Emby servers - because: When you find an 8096 or 8196 port, then there's a high probability that it's an Emby server. That means that you can find Emby servers with those ports alone through the portscan But when you publish via 80/443, a portscan doesn't help much, because like every 2nd or 3rd device has a webserver included Now, you need to establish a TCP connection, make a request to the web server and analyze what you get in return This procedure is more expensive by magnitudes compared to the port scan So it's much less likely that your server will quickly be found

FWIW: I am a firm believer in having backups, both content and options. I have been negligent in regards to backup app choices lately. I made the choice to never ever use Plex again some time ago but well after I started using Emby for all my local playback. I did not make a decision of what my backup would be if Emby ever became unusable or otherwise disabled or inconvenient to use. That is a lack on my part. After this issue cropped up (I typed "crapped" there and I almost chose to leave it that way) I did investigate some alternatives and I have found exactly one that would be good for me. That one is CH-DVR. Their interface is vastly inferior to Emby's and they do not have a Roku app, some at Emby will understand that they found that the Roku device is too under powered for their app. It is usable but not much more than that. BTW: Anyone wanting to use "remote" features will not want to use CH-DVR as they do not have, as far as I can tell, remote functionality. However the shine in live TV functionality. There are others like Servio that I have not investigated deeply but all other apps I have looked at fall well short of the ideal and most make Plex look friendly and easy to use. I am sticking with Emby for now. (with a CH-DVR backup) It would take a lot more to drive me away. My suggestion to users very upset about this is to spend some time and find out just how bad the alternatives are and then make an informed choice. Emby is handling this about as well as can be expected and, if this actually drives users away it is the user's choice but as serious as this has been it "could" have been a LOT worse for everyone. Thank you Emby for making hard choices and making them about as correct as they could be. Once again, thanks.

@chef Howdy. I'm checking this plugin out and was running into this duplicate entry in continue watching as well. Another thing I'm after is top picks to ignore the home screen system based toggle "Hide fully played content from latest media" I do take advantage and use that toggle but it causes top picks to only generate a few items in its latest media row if that toggle is on and I've watched it all. Hugs and kisses, BAS

No... I'm mad that they believe that turning my server off served was completely within their right to do AND served as sufficient "notification" of this issue. The fact that I even FOUND the information posted on this site was completely by luck and the direct result of being fortunate for deciding to search for a very specific error message that I was able to locate in my logs only when I was repeatedly trying to start the server up. With regard to being logged out of compromised accounts... that's happened. And do you know how I know? I get an email telling me what happened, telling me my account needs its password to be reset, and a link to go do it. Even with the banner here, the directions were incomplete, had directions to do things that were actually impossible, and had steps in the wrong order. I'm a pretty seasoned Linux admin with a fairly elaborate home lab and it took me almost an hour to bring my server back on line with the directions they provided.

And how is it that they "dealt" with affected customers? By turning their servers off? I am going to state it again - turning my server off and writing some vague entry to a log file that I -never- look at does not constitute "notification!" Let me put this a different way... What the hell right does the Emby team have to shut down my server? I understand that their "hearts were in the right place", but that is 100% -MY- property and they have absolutely no right to do ANYTHING to render it inoperable. EVER. I paid for a lifetime Premiere license. So long as I stay within what I am licensed for and licensed to do, NO ONE has a right to touch my property in any way. Do I -want- to be participating in a botnet? No. But, instead of writing code and pushing it to my server to crash it, they should have actually NOTIFIED ME of the issue and let ME decide how and when to deal with it. There was absolutely no though put into recognizing the most important people to them - their PAYING customers. They told absolutely NO ONE what was going on and then slapped a banner on a web site that isn't even USED by most of their users and isn't frequented by most of the ones that DO have accounts here. I'm sick and tired of the "spin" being put on everything and the Emby team not standing up and admitting that they screwed up.

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

First of all, the analogy is terrible, because if Apple and Microsoft had a blunder that big (a known exploit well known for over 3 years not patched creating a botnet and granting admin privileges), I would definitely receive more than one e-mail from multiple newsletters and it would be all over the news, so yeah, I would find out. Also, those companies make SURE everyone finds out whenever they find a huge vulnerability like this one. Your point makes no sense. What you don't seem to get is that there is for sure a ton of affected or still vulnerable systems that have no idea they have to patch their system or that it was affected and dead in the first place which should find out. I don't usually respond to nonsensical white knighting but given that you quoted me, I feel like this was warranted. This is not just people shouting because we are mad. I'm not mad or crazy or angry, but there's basic stuff that needs to be done to handle this better and it's not being done because apparently security through obscurity is still a thing somewhere.

I am in 100% agreement and frustration that this flaw was known for years and ignored. That is astonishing and hard to believe. It makes me feel like the developers do not take security seriously and makes me wonder what else are they maybe ignoring? Flaws can happen and things can get by. Look at what happened to Plex. That affected millions. You can never be 100% all the time, but this one hits totally different. I also agree some more needs to be done within Emby to notify everyone. Not just those who they think are affected. I just happened to be checking reddit and I saw a notice about this. The only thing that saved me I believe was that I had set passwords for local accounts. To me this is just common sense. I don't know why people haven't done this. Just because you are local doesn't mean you should be less safe. I would suggest to the developers @Lukeetc that they make it required/forced people must have passwords for local accounts. Do not leave it as optional. For now I am keeping Emby as the work to migrate to something else at this time would be too much work for me. I hope those affected are able to get back up and running quickly.

Whatever is finally decided it would be well for Emby to keep in mind that there are people, I believe many people, that have no need of any form of increased security and "increased" security implies that there will be increased complications. There should be a way to turn off and/or avoid any increased complications for those of us that do not want need the "enhancements." Under no circumstances do I believe that I should have to perform extra actions because others "need" the enhancements. I only have one user, me. I only access one server, mine. I do not use or turn on remote access at all. I do not want to have to log in every time I use a client. I do not want to have to login to access my local server and make changes. In fact the only time I should have to log in is a first start up, if I need to do a refresh of credentials. For me everything is local and I do not need any more so called security. The only thing more security would do for me is make my life using Emby harder. I strongly hope the vocal people that need or want greater security do not overwhelm those of us that are very happy with what we have and I hope Emby keeps it simple for those of us that like it simple. Emby, you should be sure that you do not worsen the experience for those of us that like Emby just the way it is.

Shutting my server down was not "notification." I have had numerous shutdowns of Emby having to do solely with the fact that updating the server software would prevent it from starting because the install always overwrote the startup script and changed the "runas" user. Every. Single. Time. I don't look at the server logs. Ever. I have no cause to. When the server doesn't start, I immediately go looking for the startup script issue because that is what the problem has been every single time in the past. This time around took me a LOT more effort because... yep... you guessed it... I wasn't actively notified of anything. The fact that you refuse to understand that shutting down the server is not, nor ever will it be, a form of "notification" is frustrating. Please just stop justifying your actions and accept the fact that, plainly, a lot of people were and are pretty pissed off about how this was handled. Figure it out. Put the downloads behind a registration page, require a login to get to them, put a banner across the admin page or the various apps telling them to go sign up for a mailing list, modify the server software in a way that allows it to still start up but shows a notification message that all services are down... Personally, I don't care HOW it gets done, but it needs to get done. I was never offered any mechanism other than purchasing the Premiere license (which DOES require my email address) and joining this forum - neither of which actually brought ANY information my way until it was far too late. It isn't the consumer's job to figure this sort of stuff out - it's the vendor's.

As I said before, you obviously cannot inform everyone, but you CAN inform paid customers, everyone subbed to the forum, emby connect users, etc. That would be vastly more than what they have done. Only thing people are asking is to make a reasonable effort to inform as many people potentially affected as possible.

That's the point, the "oh well, what's done is done" attitude is no good because you can STILL inform via e-mail to everyone that might be affected but have no idea what's going on. There's still stuff you can do to improve the situation, you are just refusing to do it. Now that the main wave has passed would be a good time to let people know if, as you said, wanted to help people directly affected but not be "innundated". It's not that you can't but you just won't for reasons that don't really make much sense to me or others.

Maybe this will help getting more security now like the for years open request for 2FA/MFA instead of getting all time the same answer "good idea for the future, thanks"

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.

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.

We agree to disagree, there's tons of people that could've simply updated their system and be done with it. The fact that you are flooded with requests for help right now is because of the specific approach you took to fixing this (breaking people's installs that they cannot fix on their own) not because of the issue per se. You did not inform all affected people, only the ones that noticed their system was broken. That is not the same and it's not what I would consider a directed approach. And don't get me started on the fact you very poorly chose to inform this at the beginning with a post saying how you "took down a botnet in 60 seconds ". That is in terribly poor taste. Not even an apology.

I appreciate the quick fix (if it really wasn't a 3 year old exploit that you all have known about). However, a simple email to all addresses that you did have would have been the right course of action. A simple, we are aware and are working to fix this and if you have questions here's a link to the forum post where our staff can best answer your questions would have been great. It does make people antsy and I guess that's where everyone is going with this. You can't please everyone and you all made a decision that you thought was in everyone's best interests. Right or wrong you stand by it, learn from it and move on. More communication with your customer base is never a bad thing. You have a great product... broadcast that when everything is going great and broacast it as well when things are broken. People value transparency more than anything.

I also was not directly notified, but I -was- seemingly affected. I went to watch a show and couldn't connect to my server and found the article by pure luck (I have repeatedly had issues with auto-update because I run as user with the same overall permissions as "emby'" but not as a user named "emby" - every update requires me to modify the start script to fix this. I am also of the camp that, once the servers had an update pushed to them that would keep them offline, an email should have been sent to everyone that's registered as a user somehow/somewhere. As a Lifetime Premium license holder, Emby has my contact information and I'm extremely disappointed that I was not viewed as being a user that should have received a direct email communication.

I don't have a problem with updating to fix it. I have a problem with having to go in and fix by adding and deleting system files. That should be done with an update. I have never had windows shut my system down. They have always fixed it with an update.

damnit. I tested from a device that was within the lan, but still had my vpn enabled giving it a non lan ip. Checking again from localhost and I can login without a pass once that's set. It does still reset itself to require a pass though.

Thank you so much @softworkzand team! It's such a relief to see you and others at Emby not only protecting our privacy, but also protecting the security of our personal servers. I'm so glad Emby has mechanisms in place to combat these attacks AND act quickly to prevent further damage. Thank you!!!

All I can say is they did - a significant amount of investigative analysis and testing was done before the action was taken and then subsequent follow up communication. Clearly it would not be in the best interests to communicate first and apply the action later - for obvious reasons.. It is up to emby what they wish to share, and lets be honest here, while there are no longer any immediate threats, emby have some security 'concerns' they need to address asap. imo openly listing these is not in the best interests of the users and is just providing information for hackers to find the next exploit. To be clear here, I'm not defending emby due to the lack of acknowledgement/action on the original disclosure but I am very much hoping this is a big wake up call for them to put security at the top of their priority list and keep it there ..

There is nothing in the changelog attached to: https://github.com/MediaBrowser/Emby.Releases/releases/tag/4.7.12.0 to signify this is a critical security release. I would suggest that as a matter of standard practice any security fixes be tagged as such so that the community and upstream who follow only Github for releases are aware.

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.

Is it possible to have the two things split to: display in continue watching on home-screen and display as latest media. This could solve the problem of the same movie showing twice when you are using certain plugins. Also would like to maybe remove latest movies but would like to show up in continue watching.