Multiple security issues in GNU Screen

Nice write-up.<p>&gt; Screen offers a multi-user mode which allows to attach to Screen sessions owned by other users in the system (given the proper credentials). These multi-user features are only available when Screen is installed with the setuid-root bit set. This configuration of Screen results in highly increased attack surface, because of the complex Screen code that runs with root privileges in this case<p>I wasn&#x27;t aware of such a feature but I guess it&#x27;s what makes stuff like tmate possible. Speaking of which, I wonder if tmux is affected by the same kind of vulnerability.

Note: In Debian, GNU screen is <i>not</i> installed with setuid-root privileges.

Here&#x27;s the rendered blog post:<p><a href="https:&#x2F;&#x2F;security.opensuse.org&#x2F;2025&#x2F;05&#x2F;12&#x2F;screen-security-issues.html" rel="nofollow">https:&#x2F;&#x2F;security.opensuse.org&#x2F;2025&#x2F;05&#x2F;12&#x2F;screen-security-iss...</a>

I emailed the author of GNU Screen about the lack of proper documentation about the logging to a file feature:<p><a href="http:&#x2F;&#x2F;www.zoobab.com&#x2F;screenrc" rel="nofollow">http:&#x2F;&#x2F;www.zoobab.com&#x2F;screenrc</a><p>GNU need a better issue tracking system :-)

Zellij is a really nice, modern alternative to screen and tmux, and they&#x27;ve done a great job at having good defaults as well as making the UI easily discoverable. I&#x27;d highly recommend it to anyone else who felt dubious about the benefit-to-effort ratio of terminal multiplexers.<p><a href="https:&#x2F;&#x2F;zellij.dev" rel="nofollow">https:&#x2F;&#x2F;zellij.dev</a> <a href="https:&#x2F;&#x2F;github.com&#x2F;zellij-org&#x2F;zellij">https:&#x2F;&#x2F;github.com&#x2F;zellij-org&#x2F;zellij</a>

It&#x27;s surprising that upstream was involved in this. Around 5 years ago, I came to the (sad) conclusion that GNU screen development had completely halted. Is that still not the case?<p>Does screen have the functionality to add a new window to an existing screen without attaching to the screen yet?

Rendered version: <a href="https:&#x2F;&#x2F;security.opensuse.org&#x2F;2025&#x2F;05&#x2F;12&#x2F;screen-security-issues.html" rel="nofollow">https:&#x2F;&#x2F;security.opensuse.org&#x2F;2025&#x2F;05&#x2F;12&#x2F;screen-security-iss...</a>

tmux is in OpenBSD base since 4.6 IIRC and is&#x2F;has been audited. It&#x27;s a good alternative for those who want something a bit more secure.

&gt; The observed behaviour has been present in Screen versions since at least the year 2005.<p>and it&#x27;s been an anti-pattern and covered by tools like rkhunter for around least that long, as well<p>but pretty sure screen was setuid root in the 90s too

1. How many developers run all the most popular open source tools?<p>2. How much money is in the industries that use those tools?

Setuid binaries existing in 2025 is not acceptable. There needs to a movement to remove all of them as time and time again it&#x27;s shown that it leads to severe vulnerabilities.

I use byobu (for the keybinds) on top of tmux. But Zellij (modern Rust-based alternative to tmux) has been looking quite interesting for a while.

so it appears that packaged Debian `screen` is not installed with root execution, therefore this entire situation is not a problem on Debian?

Funny you should mention screen and setuid. In one installation, I had to give screen chmod u+s perms to solve some weird issue, thinking what a gross thing to do.<p>Turns out, it has features dependent on setuid, and some systems ship it that way? Yikes!<p>(But, after I gave u+s to screen, it reads root&#x27;s ~&#x2F;.screenrc instead of mine (which I accepted as part of the workaround). Maybe that particular build of screen I&#x27;m using doesn&#x27;t react properly to setuid; maybe it has to be built a certain way also to enable that support.)

Can screen just get completely tossed and converted into a compatibility-layer wrapper around tmux?

So ... my tmux lifestyle is objectively superior in this one respect. Excellent.

I love GNU Screen, daily usage.<p>A good sign, that they called for help. Hope they can attract some more new developers, carefully maintaining it.

In 1990 we got told to stop using screen because other people could get into your sessions. Never used it again after that.

Everyone I know has switched to tmux a long time ago. Screen is obsolete and shouldn&#x27;t be used

Are there any official RedHat CVE pages for any of these screen vulns yet? Haven&#x27;t found anything so far

What advantages does screen offer compared with multiple tabs in your terminal emulator?

If you&#x27;re worried about security, A less than 10k lines of SOC is your aim. mtm, abduco, dvtm achieve this. screen? Impossible for it to ever be secure. You&#x27;ll be playing an endless game of whack-a-mole.

Then:<p>Unix: Small, light, mediocre OS for underpowered microcomputers. Either crash silently, or cut down the bloat.<p>MIT&#x2F;GNU: Correct systems first. Plenty or resources. Lisp. Detect the errors, fix and step over them, continue the process.<p>Now:<p>GNU=Ugly bloated umUnix like, mega light Elisp editor but s l o w and prone to lock. Good FS&#x27; on Linux. FDo it&#x27;s mainly Red Hat bloatware. Screen does too much.<p>OpenBSD=Correctness, ISC licensed mainly. Unix bound, small tools, but so-so FFSv2. Sndio works. Audio, video and so on perms work, no DBUS needed. CWM it&#x27;s really fast and much easier than I3. Dumb config, fvwm looks like rocket science. Tmux, no screen(1) except for ports. Snappy, easy to config and script. Use damn cu(1) for serial, thanks.

I brought up some security issues similar to these years ago to the Screen community and they laughed at me saying I was being paranoid. Nice to see they&#x27;re finally doing something about it.

Only tangentially related, but I&#x27;m always fascinated that mailing lists are still a thing in 2025.