Leaderboard

A suggestion. Would it be more efficient for people needing help to start or post to a thread in the sub-forums for their OS/platform? Perhaps creating threads with the subject/title "Security Advisory Help: <OS/platform>" in those sub-forums could bring help from others familiar with those systems. It's getting a bit crowded in here with multiple reports and requests for help across the wide variety of Emby installations. Hard to keep track and contribute.

Yeah, I mean, the whole "How we took down a BotNet" is more like "How we actually helped create a BotNet and had to scramble to fix our own mistakes because of a huge vulnerability that was exploited on our paid software". I am running Emby on docker, did not find any of those two files, passwords were deactivated on the local network BUT all the users had passwords. Will be changing passwords anyway just in case anyway. Oh, also, might have something to do that I'm using a reverse proxy (npm) to access Emby. EDIT 2 because I don't mean to spam: How is it possible that an e-mail has not been sent to all registered users and everyone on the emby db either community, paid user, etc. I found out only because I was about to update my server and wanted to see what were the new features. Everyone should be notified ASAP.

No. Jellyfin is not currently vulnerable to this particular issue. It was fixed in our 10.7.0 release in March 2021. Also no. The Emby team has never communicated any known security issues to us.

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 haven't been effected by this and like to think I have a reasonable level of security for an internet-facing system, but this is a pretty damaging situation for emby. I think the red banner needs to be reworded as the word 'potential' is somewhat disingenuous given it has been exploited on some system. It is a vulnerability, not a potential one

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.

apparently not! BUT instead of asking rhetorical questions you may want to apologize for your failures and help me fix your mistakes instead of acting like I'm the A-hole here.

They knew that potentially all of it was at risk; but they have found no evidence of any data actually being taken than they have already described, in the systems they have access to analyse. In general, how far the danger extends depends on the user's setup. The vulnerability itself enables external access to be made to appear local, but this has no significant effect unless there are users who could log in without password on the local system - this still only gives access to looking at movies and so on unless there is an admin user which can be logged in locally without password, when it becomes possible for the hacker to install a plugin that happens to be able to download other code - but even this is still restricted to the Emby system itself, unless the Emby server is being run under an OS admin account, at which point the whole machine becomes vulnerable. So no - they can't know just how much at risk your system was - that's for you to determine, as you know about those settings which Emby doesn't. Paul

Hi. That's the only thing we're sure of but there is really no way to know what else may have been done. We haven't positively identified anything else at this point. We have no evidence that anything outside of Emby credentials were taken/compromised. Many people use the same credentials on multiple sites. The supposition would be that the Emby credentials might be duplicated elsewhere where there would be more value to them.

That's a nice idea, but then we have people like myself who run Emby (and many other apps) in Docker, which causes other issues. The lack of information about the DLL file that was injected was also frustrating my work, because due to Docker, I had no way to bring up the server without network access. While I appreciate the work that they did to shut down the botnet, the 'full story to come' with next to no 'partial story to start with' is incredibly frustrating. It gave me no useful information to help understand what kind of threat my server was under. A few other things I'm now also noting: The infection for me (and others I've seen here) started on May 11th, 2023, using an exploit first laid out on February 2nd, 2020. Not only is there the question of why an exploit allowing for high level penetration was allowed to languish until after it was actually weaponized, but I remember that same day I got a ton of issues with other sites. My Emby does have a FQDN for outside home-access. The day the attack happened all of my other subdomains suddenly got 'malicious attack' warnings from Google and Firefox, and a YouTube video that had a link on one of the other subdomains got a community strike for 'scam activity'. I appealed the community strike because, based on the lack of any other information, I saw nothing suggesting it wasn't anything more than a technical hiccup. Maybe an IP change at Cloudflare, or a momentary cert error with LetsEncrypt, or something. I asked YouTube for more information, and while the strike was removed, I never got any technical feedback. This is an issue with the larger Internet, where small time domain holders may not have the resources to find out when they're threatened.

Just my personal opinion. This whole episode of server compromising was a cluster f*ck that no one wanted and desired it. At this point the Devs don't need more should have could have. For me since I have been using their content organization solution since MediaBrowser, they earned a OK, we screwed up. I consider this as them just paying a boatload of tuition at the school of hard knocks. Note to self, dial down the rhetoric and up the helpful suggestions.

Closing loop - backup data, reset Asustor NAS, reinstalled with 4.7.12 package. Emby is back. Still rebuilding and re-configuring.

Just as an addendum, a properly configured reverse proxy should do this, but it's entirely possible to have a poorly configured one. Without adding those headers its possible Emby would see every remote connection as coming from the local address of the reverse proxy itself.

I can partially agree here, but will also say that the staff of Emby needed to fully understand what this compromise represented before they took action like was done. In other words... The process that was used to deem this "critical enough" to shut down everyone's system would ALSO have afforded a lot more detail that can now be shared with users.

Let's take it over here and I can try to help you.

On a Linux system (I am supposing that's what you have), you are not the only user... there are a lot of them. One of them in particular is "emby" and will own all of the content. Your user account won't have write permission to most of the files. Use PuTTY or similar to access the machine via SSH (which is what WinSCP is using). Once logged in, you will need to change users to the root user or similar. THEN navigate the filesystem... Which underlying OS you are running will dictate exactly how you become the superuser. My guess would be that you're running Ubuntu and the process to directly become the superuser is to execute the command "sudo su". Be Careful. This user can literally do whatever they want, including completely crash the system.

I don't know what you think could have been done differently? I'm not trying to fight with you, I just think these cyber-threats have a lot of moving parts, and they took the needed steps to stop it. I updated the two servers I have running, and it took less than five minutes. Keep in mind, the moment the team starts sending notifications and posting on the forums about the steps they are taking, they are also telling those conducting the attack what they plan to do. In this case, they shut it down, then dealt with getting people updated. Seems reasonable is what I'm saying. If you were affected, they shut your system down before any more damage could be done, like deleting your media... I'm good with that.

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.

Synology Users: You can use WinSCP to check if the malicious files are present. I looked on mine and they were not. Hope anyone affected is able to clean things up and get back to normal again.

I just wanted to share what our firewall had caught since the 11th (when this all began) from what I can tell. I'm guessing they published at least my server info somewhere as I have since been getting multiple attempts to find more ways in. shown in the attached log. These are attempts and blocked, I do not know what may have gotten through. if anyone might see these or like addresses and attacks may be able to narrow down the source and targets 2008R210Today.txt

Yes, I was using local passwords.

I agree. I appreciate that people are responding to help us all, but many of us are complete novices and receiving small bits and pieces on how to do something is only leading to more and more frustration. I have been working at this on my own for hours and have not been able to successfully resolve anything.

Can you update us on your status? To be honest, I doubt any Emby dev or team member has given Jellyfin a thought as we work with the original and modern Emby server version. It's got about 4+ years of different code added to the version of Emby they started with. That makes for plenty enough changes or differences that we really have no idea. You would really want to ask the Jellyfin peeps about their vulnerabilities.

This is what helped me, a Linux newby to get to the directory from where to delete the DLLs and also where to delete the two other files in the configuration directory. First off you have to stop Emby server and then use Putty to do the navigation. Never used so many times the cd (Chang Directory) command plus the ls (List) command to find what I want. Finally the rm (Remove) command to delete files. Follow the navigation by PenkethBoy Finally the editing of the hosts file. In the Putty window type vi /etc/hosts that starts the editor now press the i button and enter this line after the last entry: 127.0.0.1 emmm.spxaebjhxtmddsri.xyz Press the ESC button and type a colon followed by wq and hit enter. Watch the YouTube video on how to edit the hosts file and save it. https://www.google.com/search?client=firefox-b-1-d&q=editing+a+host+file+in+qnap#fpstate=ive&vld=cid:23ebf603,vid:Kl6Kwvc-EYs,st:47 After finishing start the Emby server and it should work. I had no problem following the instructions here and get the server back running

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