Tautulli Vulnerabilities: v2.17.2 Is the Minimum Safe Version

As of August 17, 2026, the minimum safe version of Tautulli is v2.17.2. This article originally told you to update to v2.17.1, and that guidance is now wrong. v2.17.2, released on June 16, 2026, fixes four additional vulnerabilities whose affected range is "v2.17.1 and below". In other words, a setup that stopped at v2.17.1 still has four known holes open.

You can check the version you are running from Tautulli's own screen: Settings → Help & Info. If the number shown there is lower than v2.17.2, you need to update. If you run it in Docker, pull the image again and recreate the container. Pulling the image alone leaves the running container on the old build.

# If you run it with docker compose
docker compose pull
docker compose up -d

# If you run it with docker run (LinuxServer build)
docker pull linuxserver/tautulli:latest
docker stop tautulli
docker rm tautulli
# re-run docker run with the same options
# (your settings live in the volume you mapped with -v)

# The official image works the same way
docker pull tautulli/tautulli:latest

If you installed it directly on Windows, macOS, or Linux, use the in-app update feature or grab v2.17.2 from the GitHub releases page. That is the whole fix. The rest of this article explains why it matters, and why "I don't expose it to the internet, so this doesn't apply to me" does not hold.

What to do right now

There is one action: update to v2.17.2. That settles the five flaws closed in v2.17.1 and the four closed in v2.17.2, nine in total. On top of that, v2.17.2 fixes a bug where the X-Api-Key header check introduced in v2.17.1 crashes the server. Even setting security aside, there is no upside to staying on v2.17.1.

There are two Docker image families: linuxserver/tautulli, the one the community uses most, and tautulli/tautulli, published by the developers. For either one, pulling the latest tag again and recreating the container gets you the current build. If you drive it from a NAS container UI (Synology, QNAP, and so on), download the image and then stop, delete, and recreate the container — or use the NAS equivalent of "reset and update." Your settings and database live in the volume, so viewing history survives the recreate.

After updating, a quick inspection is worth the time. Look for unfamiliar changes in Tautulli's settings — especially the notification and newsletter template locations and registered email addresses — and for accounts you don't recognize in the admin user list. If you want to be thorough, changing your Plex account password and reissuing the Plex access token that Tautulli holds will invalidate any stolen keys. How hard it is to trace things after a key leaks is something we covered in the home-network monitor Pi.Alert case.

The essentials in one minute

Here is the whole picture in a table. The two things to check are whether your Tautulli is older than v2.17.2, and whether you have guest access enabled.

A self-hosted, open-source tool turning up with several holes at once is not new. The home-network watchdog Pi.Alert's unauthenticated RCE and the company login platform authentik's multiple flaws are in the same family, sharing one trait: "a tool meant to protect you becomes the way in." Tautulli is another case of it.

What happens, in one line

In short: there were several leftover paths that let an attacker walk straight from the guest entrance into the back of the house. Tautulli has endpoints reachable by a low-privilege "guest" user, and some reachable without logging in at all. You were not supposed to get any further from there, but missing input checks and missing identity checks let an attacker step deeper, one stage at a time.

The five closed in v2.17.1 are: an attack that makes the server send requests on the attacker's behalf to peek into your home network (CVE-2026-43986), an attack that runs the attacker's script inside the admin's screen (CVE-2026-43984), an attack that tricks the admin into rewriting settings (CVE-2026-43985), an attack that abuses the templating mechanism to run code on the server (CVE-2026-41065), and a path traversal that climbs out of the intended directory (CVE-2026-40605).

On top of those, v2.17.2 closed four more: arbitrary file write via path traversal in the settings import (CVE-2026-52835, High), reflected XSS on /search (CVE-2026-45381, Medium), stored XSS through a newsletter cron value (CVE-2026-49995, Medium), and an open redirect on /auth/redirect (CVE-2026-54915, CVSS 5.4). As of August 17, 2026 these four are not registered in NVD and have no EPSS score. The thin paper trail makes them easy to miss, but since the affected range is "v2.17.1 and below," v2.17.1 is not a safe version.

Some of this works even if you never exposed Tautulli

The first conclusion most people reach when they look up these flaws is "I don't expose it, so I'm fine." No port forwarding, no reverse proxy, only ever opened from the home Wi-Fi. Therefore not affected. For one of the five, that conclusion is wrong.

That one is CVE-2026-43985, a CSRF rated 8.8. CSRF (Cross-Site Request Forgery) means luring a logged-in user to a trap site so that an action runs with that user's privileges without them noticing. As the CVSS vector's PR:N indicates, the attacker needs no account of their own. All that is required is an admin who is still logged in to Tautulli opening one malicious page.

What that single page does: a request goes to Tautulli's settings endpoint /configUpdate, and the admin username and password are overwritten with values the attacker chose. At that moment the admin panel changes owner. The browser is inside your LAN, so from Tautulli's point of view this looks like an ordinary action by the legitimate admin.

Why does it reach inside the LAN at all? Browsers have a mechanism called SameSite that controls whether login cookies are sent along with requests originating from other sites. The default, Lax, does not send cookies for images or scripts embedded on another site — but it does send them for a "top-level cross-site navigation," where following a link moves the page itself. That gap is what lets a trap page navigate to your Tautulli's home-network address with the logged-in session attached. Closing the router port does not help; putting authentication on a reverse proxy does not help. The admin's browser is already on the inside.

The v2.17.1 fix added a CSRF token (a one-time phrase proving the action came from the real screen) and restricted settings changes to the POST method. Updating is the only way to close this one. No amount of careful network design substitutes for it — that is the defining property of this flaw.

Risk check for your setup

How these five hit you depends on how you run Tautulli. Below are the three common shapes, and whether each of the four main flaws works in them. Decide which row you are in before reading on.

To work out which row you are in, check these three things in Tautulli.

• Do you have guest access enabled? If you share Plex with family or friends and they can also see the Tautulli screen, that counts as enabled. The SSRF and the XSS both use guest privileges for the planting step.
• Did you finish the setup wizard? An install left half-configured is the worst case, for the reason given below.
• Have you set an HTTP username and password? You can check under Settings → Web Interface. If it is unset, Tautulli performs no authentication at all.

A reverse proxy is not a cure-all

A reverse proxy is a gatekeeper server that receives outside traffic and relays it to the app behind it (NGINX and Apache are the usual choices). It is tempting to assume that authentication there makes you safe, but CVE-2026-43986 deserves care. The path that triggers the SSRF, /image/<hash>.png, requires no authentication on Tautulli's side. Unless you explicitly require authentication at the proxy layer, requests to that path pass straight through. The assumption "nothing works unless you log in to Tautulli" simply does not hold for this one path.

A brand-new install is the most dangerous state

CVE-2026-41065 is at its worst on a freshly installed system. When the HTTP password (HTTP_PASSWORD) is unset, Tautulli sets its internal authentication flag AUTH_ENABLED to False. In that state every admin endpoint is open with no authentication. A server left sitting for days halfway through the setup wizard is the worst case for this vulnerability. When installing, finish the setup inside your network, and start on v2.17.2 from the outset.

What are Plex and Tautulli, anyway?

Plex lets you store the movies, shows, music, and photos you own on a home PC or NAS (network-attached storage) and stream them to your phone or TV with a Netflix-like interface. It is used by movie buffs and home-server enthusiasts around the world as a "build-your-own streaming service."

Tautulli, the app at the center of this story, is the "viewing logbook" you bolt onto Plex. It charts who watched what and when, how busy your connection is, and which titles are most popular, and it can email new-release newsletters to family members or push notifications when someone starts watching. It is open source under GPL-3.0, with 6,566 stars and 632 forks on GitHub. Counting its PlexPy days, the project has been going since 2015.

Where people actually run it shows up clearly in the distribution numbers. Docker Hub pulls stand at roughly 990 million for linuxserver/tautulli and roughly 210 million for tautulli/tautulli. Meanwhile the Windows installer was downloaded 10,957 times for v2.17.2 and 9,080 times for v2.17.1. That gap in orders of magnitude is circumstantial evidence that the overwhelming majority of users run Tautulli on Docker or a NAS. Do note that Docker pull counts inflate with every CI run and image refresh, so they cannot be read as a user count. Treat them as a ratio, not a headcount. That ratio is why this article puts the Docker update steps first.

The problem is where Tautulli sits. To collect usage stats, it holds your Plex account information and an access key (token), and it runs inside your server and home network. People who want to check their graphs from outside often expose the Tautulli screen to the internet. "Placing a management tool that knows the inner workings of your home where outsiders can reach it" is exactly the setup that amplifies the impact of these flaws.

When the viewing logbook becomes a foothold, here is what walks out of the house

The number "9.9" can make a home-server admin tool feel like someone else's problem, so let's sketch who would actually target this hole and why. The Tautulli screen is like a guide who knows your household's habits. Once outsiders can steer that guide, it's clear who takes an interest.

The people coming for it are the operators of automated bots that scan the internet around the clock for unguarded admin panels, the residents of piracy communities who trade lists of other people's free-to-watch Plex servers, and the freeloader or ex-housemate sitting on the same Wi-Fi. What they want is not an abstract "personal information." It is your Plex login and server key, a map of which folder holds the family photos and the books you ripped yourself, the tax documents and address lists on the NAS hanging off the same network, and even your router's admin password — concrete things. The moment they reach into an endpoint that forgot to check identity, the data that used to live only inside your house starts flowing out to a stranger.

Technically, this chain is an especially bad combination. The proxied-request hole (SSRF) becomes a foothold for making Tautulli's server reach "devices that should only be visible from the inside." From their own PC the attacker can't reach your router's settings page or NAS admin panel — but through Tautulli, they can. Add the code-execution hole (CVE-2026-41065) and they can run a program directly on the server. The entrance is a humble "just shows you viewing graphs" tool; the exit is your entire home network.

The label "CVSS 9.9" only marks the ceiling of technical severity. For someone running Plex at home, what is really lost is access to a video collection built over years, the safety of the storage packed with family photos, and the very assumption that "my server is mine to control." More than the number, keeping that guide's keys out of a stranger's hands is the part that actually matters.

What the 9.9 actually was, traced through the attack

CVE-2026-43986 did not reach 9.9 simply because it is an SSRF. SSRF (Server-Side Request Forgery) is a flaw that makes the server "go and connect to a place the attacker chooses," and it usually lands lower, because only an authenticated user can set it off. This one climbed because three design flaws lined up so that planting and triggering ended up on separate endpoints.

The three underlying flaws are these. (a) A guest-level user can use the image hash generation feature. (b) That hash can be derived by a fixed procedure from data that is already disclosed and that the attacker can influence. (c) The public path /image/<hash> trusts the database contents unconditionally, with no authentication.

The four stages of the attack

Stages 1 and 2 need guest privileges; stages 3 and 4 need nothing. Once someone who can obtain a single guest account has finished the planting, anyone in the world can trigger it afterwards, as many times as they like.

Three reasons it climbed to 9.9

• It persists. The attacker's URL is written into a database table and stays there. Plant it once and that Tautulli remains a loaded gun.
• It falls back to the admin token. When an unauthenticated request reaches the image proxy, the internal PmsConnect() uses the administrator's Plex token rather than guest credentials. The SSRF therefore runs with admin privileges.
• Scope Changed. The S:C in the CVSS vector means the impact crosses the product's privilege boundary — the assessment is that it can reach Plex itself, the inside of your LAN, and cloud metadata endpoints.

Two commits fixed it, and the second one is the important one

Both landed on April 26, 2026. The first, commit 85f9cc2, is a one-line condition that stops external HTTP URLs from being stored in the database at all. It closes the planting path, which is the fix you would expect.

The interesting one is the second, commit 137c966. It adds database handling that wipes already-planted poisoned entries during the upgrade. The developers did not only stop the planting; they wrote code on the assumption that entries had already been planted.

This is the part that tends not to reach people who are on the fence about updating. It is not "patch and the poison goes away" — it is "the cleanup only happens when you patch." If a single attacker URL was written into a system still running a pre-v2.17.1 build, that row stays there until you update, and it fires every time someone hits /image/. The fact that the developers themselves accounted for "it may already be planted" is the primary evidence for why the update matters.

The five flaws, and why each one is dangerous

Here are the five entries from the v2.17.1 release notes, in order of severity. Each is a problem on its own, but they compound when combined.

CVE-2026-43986: making the server send requests on the attacker's behalf (severity 9.9)

The most serious of the five. Its formal class is CWE-918 (Server-Side Request Forgery, SSRF), CVSS 9.9, vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L. Planting requires guest privileges, but triggering is fully unauthenticated. The attack flow is the one described in the previous section; the fix stopped external image URLs from being stored and added a routine to delete existing poisoned entries.

CVE-2026-41065: code execution through template injection (severity 8.9)

This article originally described this as "arbitrary code execution via the newsletter feature." What it actually is, is template injection. The class is CWE-1336 (improper neutralization of special elements in a template engine). Tautulli builds newsletter layouts with the Mako template engine, and if it is made to load a template the attacker supplied, the expressions written inside it are evaluated as-is and code runs on the server. It is not a matter of executing a file — the template syntax itself is the execution path.

Only a CVSS 4.0 score was assigned: 8.9 HIGH, vector PR:N/UI:N/E:P. The prerequisites come in two tiers — fully unauthenticated where setup has not been completed, admin privileges where it has. This pattern of weak entry validation turning into code execution is one we've seen repeatedly, in the AI tool Langflow's unauthenticated RCE and the file-sharing service Samba's unauthenticated RCE.

CVE-2026-43984: running a script inside the admin's screen (severity 8.9)

The class is stored CWE-79 (Cross-Site Scripting, XSS) — the classic trick of slipping the attacker's script into a web page so it runs in someone else's browser. The vector is PR:L/UI:R/S:C: injection needs guest privileges, and triggering requires the admin to open the log viewer. Tautulli has an endpoint that records front-end errors (log_js_errors) into which a guest-level user could feed arbitrary strings. Those strings were stored unprocessed, and when the admin opens the log viewer, the attacker's script runs as-is. Because it runs with the admin's privileges, it can tamper with settings or hijack the session.

CVE-2026-43985: tricking the admin into rewriting settings (severity 8.8)

The class is CWE-352 (Cross-Site Request Forgery, CSRF), vector PR:N/UI:R/S:U, and the attacker needs no authentication. Luring a logged-in admin to a trap site is enough. The details are in "Some of this works even if you never exposed Tautulli" above; it is the only one of the five that no network design can prevent.

CVE-2026-40605: a path that can delete stored files (path traversal)

The classes are CWE-22 (Path Traversal) and CWE-73 (External Control of File Name or Path). Path traversal means climbing up to folders you should not reach using relative paths like "../". Tautulli's cache-deletion feature had this gap, risking the deletion of files in unintended locations. Only a CVSS 4.0 score exists — 5.7 MEDIUM — and the vector carries PR:L, meaning authenticated access via an API key is required. It has the heaviest prerequisites of the five.

Why they all surfaced together, technically

All five share one root: "a value handed in from outside was used internally without being checked enough." The proxied-request hole took an external address, the code-execution hole took template contents, and the in-page script hole took the contents of an error log — each accepted as input a guest-level party could specify, then passed into processing without validation. The settings-rewrite hole was the inverse: it lacked the mechanism to verify where an action came from. Checking the input, and checking the identity — both basics were missing in places.

And this is not an isolated accident. Lay out Tautulli's own CVE history: four in v2.16.0 (September 2025), five in v2.17.0 (March 2026), the five covered here in v2.17.1 (May 2026), and four in v2.17.2 (June 2026). That is 18 in the last 12 months. Rather than a sudden collapse in quality, the accurate description is a project that outside researchers have started paying continuous attention to. When several researchers examine the same codebase from different angles, similar classes of holes come out in clusters.

That reading is backed by the write-up from Matt Andreko, the researcher behind the v2.17.0 batch. He notes that "many people run Tautulli on their home network, or expose it directly to the internet," and that "if the HTTP password is not set, any web page you visit can steal the API key." From a researcher's point of view, this is a target worth looking at and lightly defended.

Cases where "a handy self-hosted tool turns out to have a cluster of authentication and authorization holes" have been especially visible lately. The way stolen keys and settings get repurposed as stepping stones into other systems is continuous with attack chains that travel through open-source components. The problem of login handling shipping half-built shows up in the analysis tool Jupyter's login-screen flaw, the single sign-on platform Casdoor's auth bypass, and the ticketing system OTRS's authorization bypass, and Tautulli joins that line.

Affected versions and the fix

First, the five closed in v2.17.1, with CWE class, CVSS, and prerequisites. CVSS is the international shared score that expresses severity from 0 to 10. Note that all five scores here are secondary assessments by GitHub; NVD assigned no scores of its own. Note also that CVE-2026-41065 and CVE-2026-40605 have CVSS 4.0 scores only, with no v3.1 score.

The four that v2.17.2 closed on top

These are the reason this article had to be rewritten. v2.17.2, released June 16, 2026, fixes four vulnerabilities whose affected range is "v2.17.1 and below." The build that was supposed to have closed the five above was, at that point, carrying four new ones.

As of August 17, 2026 these four are not registered in NVD and have no EPSS score. Searching for them turns up no NVD page, which makes them easy to overlook. The affected range is still "v2.17.1 and below," and the fixes are stated plainly in the v2.17.2 release notes. v2.17.2 also fixes the bug where the X-Api-Key header check introduced in v2.17.1 crashes the server.

Severity 9.9, yet the odds of actual attack stay low

Everything above is about danger. The actual exploitation picture is quiet. Here are the numbers, honestly.

First, none of the five appear in CISA KEV — the catalog the U.S. cybersecurity agency maintains exclusively for vulnerabilities it has confirmed to be exploited in the wild. That is the result of checking against the 1,665 entries in the August 14, 2026 catalog. Beyond that, Tautulli as a product has never appeared in KEV at all. We covered how to read KEV in this article.

Next, EPSS — the statistical estimate of the probability that a vulnerability will actually be exploited within the next 30 days. All five sit below 0.5%.

The striking line is CVE-2026-43986, the most severe of the set, at an EPSS of 0.00262 — the bottom 18.2nd percentile. CVSS measures "how bad it is if someone pulls it off"; EPSS measures "how likely someone is to try." The two pointing in opposite directions is not unusual. A 9.9 and a low level of attacker interest can coexist.

NVD is quiet too. All five are marked Deferred — meaning NVD will not perform further analysis on them — and nothing has moved since July 22, 2026. As noted above, the CVSS figures are secondary assessments by GitHub, and NVD has assigned no scores of its own to any of the five. No exploitation reports, no victim reports, no honeypot observations, and no botnet scanning reports have been confirmed.

On proof-of-concept code, the precise statement matters. There are zero PoC repositories for these five on GitHub or Exploit-DB. However, the GitHub Security Advisories spell out the attack steps in full. The advisory for CVE-2026-41065 in particular publishes the contents of the malicious template and the three HTTP requests used in the attack, verbatim. "No PoC repository exists, but the attack procedure is public" is the accurate description. On top of that, CVE-2026-41065 and CVE-2026-40605, the two with CVSS 4.0 vectors, both carry E:P (proof-of-concept exists).

For the Japanese picture: none of the five are registered in JVN iPedia. Tautulli itself does get registered there on an ongoing basis — the March 2026 v2.17.0 batch is filed under JVNDB-2026-010979 and others — but this batch is not. No advisories from JPCERT/CC or IPA, and no domestic press coverage, have been confirmed.

What to take from this is not "there is no danger" but "this is not the moment to schedule emergency downtime." Rolling up to v2.17.2 at your next planned maintenance window is enough. The one exception is the CSRF described earlier, which works regardless of exposure — that one is not a reason to defer.

Why you still need to update: the LastPass breach started at Plex

How far does "no exploitation reports, so no rush" actually get you? A real case makes the point faster than an abstract warning.

In 2022, the password manager LastPass suffered a major breach. Its starting point was an unpatched Plex Media Server running on the home PC of one of the company's senior DevOps engineers. A Plex code-execution vulnerability, CVE-2020-5741, was exploited to plant a keylogger — a program that captures keystrokes — on that machine. From there the keys to the company's internal vaults were stolen, and it grew into a breach affecting millions of the password manager's users.

The part worth holding onto is that CVE-2020-5741 had already been fixed in Plex Media Server 1.19.3. Updating would have prevented it. The vulnerability was added to CISA KEV on March 10, 2023. "The hobby server at home" and "the production environment at work" are continuous, because the same person touches both from the same machine.

Does asking people to update work? There is a number for that too. For the Plex Media Server information-disclosure vulnerability published in August 2025 (CVE-2025-34158), Plex went as far as emailing its users, which is unusual. Even so, according to internet-wide scanning by Censys, more than 314,000 servers were still vulnerable as of August 25, 2025. Even direct email from the vendor leaves that many unpatched.

Back to Tautulli: 18 CVEs in the last 12 months. Even where the individual odds of exploitation are low, servers that keep running unpatched accumulate, and somewhere one of them becomes someone's way in. The LastPass case is the record of that "somewhere, someone" actually happening.

Should you expose Tautulli? Read the ranking in the official FAQ

Wanting to check your graphs while away from home is a real need. The official Tautulli FAQ lists three ways to reach it from outside, in a ranked order.

Read that table plainly and something odd stands out. The method the project itself labels "least secure" is the one presented first. There is a reason to order instructions from simplest to hardest, but readers work down the list from the top. And port forwarding, sitting at the top, is precisely the method that produces the worst case in this article — setup unfinished plus direct exposure.

The FAQ does set a precondition: "before doing any of this, set an HTTP username and password under Settings → Web Interface and enable authentication." Where that precondition is not met, Tautulli goes out to the internet with AUTH_ENABLED = False. Matt Andreko's remark quoted earlier — "if the HTTP password is not set, any web page you visit can steal the API key" — describes exactly that state.

Our recommendation is to make the third option, the VPN tunnel, your first choice. It used to be the "least convenient" one, but tools like Tailscale now connect devices directly without touching your router settings. Install the app on your phone, sign in with the same account, and you can open Tautulli at its home-network address from anywhere. Since no port is opened at all, every flaw in this article that depends on external reachability loses its precondition outright.

If you go with a reverse proxy, mind the handling of /image/ as described above: without authentication at the proxy layer, the SSRF trigger path passes through. And to repeat, whichever method you pick, the CSRF remains. Network design is not a substitute for updating.

How this unfolded

Here is the timeline from the fix commits to today. The fix went out first, giving users time to update, and the CVE numbers were published afterward.

← swipe to move

Frequently asked questions

Q. I already updated to v2.17.1. Is that enough?

A. No. v2.17.2, released June 16, 2026, fixes four more vulnerabilities against "v2.17.1 and below" (CVE-2026-52835, CVE-2026-45381, CVE-2026-49995, CVE-2026-54915). As of August 17, 2026 the minimum safe version is v2.17.2.

Q. Is it safe if I only use it inside my home network?

A. It is not. CVE-2026-43985 (CSRF, severity 8.8) requires no authentication on the attacker's side, and works when an admin who is still logged in to Tautulli merely opens a malicious page. Because the browser's SameSite=Lax setting permits top-level cross-site navigations, the trap page reaches your LAN-side Tautulli with the logged-in session attached. Whether you forwarded a port is irrelevant.

Q. I put authentication on a reverse proxy. Doesn't that cover it?

A. Not fully. The trigger path for CVE-2026-43986 (SSRF), /image/<hash>.png, requires no authentication on Tautulli's side, so it passes through unless you explicitly require authentication at the proxy layer. And the CSRF, as above, is not something a proxy can prevent.

Q. Why is a 9.9 sitting in the bottom 18.2nd percentile of EPSS?

A. Because the two indices measure different things: CVSS asks "how bad if someone pulls it off," EPSS asks "how likely someone tries within 30 days." CVE-2026-43986 requires the attacker to obtain one guest account first, and the install base is mostly home servers. The numbers reflect a target attackers do not consider worth the effort.

Q. Is there public proof-of-concept code?

A. There are zero PoC repositories on GitHub or Exploit-DB. However, the GitHub Security Advisories spell out the attack procedures in full. The advisory for CVE-2026-41065 in particular publishes the malicious template contents and the three HTTP requests verbatim. "No PoC repository, but the procedure is public" is the accurate statement.

Q. I heard a freshly installed server is the most dangerous. Why?

A. Because when the HTTP password (HTTP_PASSWORD) is unset, Tautulli sets AUTH_ENABLED = False and every admin endpoint opens with no authentication. In that state CVE-2026-41065 works fully unauthenticated. A system abandoned partway through setup is the worst case, so finish the initial setup inside your network when installing.

Q. I use Plex but not Tautulli. Am I affected?

A. These flaws are on the Tautulli side, so if you don't run Tautulli there is no direct impact. That said, Plex itself has had serious vulnerabilities: CVE-2020-5741 was the starting point of the 2022 LastPass breach. Keep Plex Media Server current as well.

Current minimum safe version

Revision History

References

• ▸ Tautulli v2.17.2 release notes (four additional fixes, X-Api-Key crash fix) (June 16, 2026)
• ▸ Tautulli v2.17.1 release notes (security fixes) (May 5, 2026)
• ▸ Tautulli releases (GitHub)
• ▸ GitHub commit 85f9cc2 - stop storing external HTTP URLs in the database (April 26, 2026)
• ▸ GitHub commit 137c966 - database routine that wipes existing poisoned entries on upgrade (April 26, 2026)
• ▸ Tautulli GitHub Security Advisories (advisory text including attack procedures)
• ▸ NVD - CVE-2026-43986 Detail (SSRF, 9.9, Deferred)
• ▸ NVD - CVE-2026-41065 Detail (template injection, CWE-1336)
• ▸ NVD - CVE-2026-43984 Detail (stored XSS)
• ▸ NVD - CVE-2026-43985 Detail (CSRF, no authentication required)
• ▸ NVD - CVE-2026-40605 Detail (path traversal, CWE-22 / CWE-73)
• ▸ Tautulli official FAQ (the three external-access methods and the HTTP authentication precondition)
• ▸ Matt Andreko - Tautulli Security Findings (the researcher behind the v2.17.0 batch) (March 27, 2026)
• ▸ CISA Known Exploited Vulnerabilities Catalog (August 14, 2026 edition, checked against 1,665 entries)
• ▸ FIRST - EPSS (exploit prediction scoring system)
• ▸ NVD - CVE-2020-5741 Detail (Plex Media Server code execution, starting point of the 2022 LastPass breach, in CISA KEV)
• ▸ NVD - CVE-2025-34158 Detail (Plex Media Server information disclosure, August 2025)
• ▸ Docker Hub - linuxserver/tautulli (about 990 million pulls)
• ▸ Docker Hub - tautulli/tautulli (about 210 million pulls)
• ▸ Tautulli official repository (GitHub, 6,566 stars / 632 forks / GPL-3.0)
• ▸ Plex official site