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/01/tumbleweed-review-of-the-week-2026-3/

Esta semana, las snapshots de Tumbleweed han encontrado un pequeño bache en el camino. Aunque se ha conseguido publicar tres nuevas snapshots (0109, 0112 y 0113), la cadena de liberación está actualmente pausada.

Las pruebas para la snapshot 0114 identificaron una regresión en la reciente actualización postfix, que impide que el servicio se inicie. Se ha presentado un informe de error y actualmente se está trabajando en ello; una vez resuelta, Tumbleweed debería reanudar las versiones de snapshot.

Las actualizaciones más destacadas de esta semana:

• Linux kernel 6.18.4 & 6.18.5
• Más paquetes relacionados con actualizaciones de GNOME 49.3
• KDE Gear 25.12.1
• KDE Frameworks 6.22.0
• AppArmor 4.1.3
• Polkit 127
• XZ 5.8.2
• Qemu 10.2.0
• wireplumber 0.5.13: Nota para los usuarios de GNOME: Se han reportado errores con dispositivos Bluetooth.

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

• Eliminación de Python 3.12
• El intérprete de Ruby 3.4 está programado para ser retirado después de que se pase a Ruby 4.0 a principios de este mes
• Un montón de cambios en paquetes para soportar la instalación en sistemas transaccionales, es decir, ningún archivo escrito en directorios fuera de snapshot, es decir, sin /var
• Agama 19 preview
• run0-wrapper, disponible como reemplazo opcional de sudo y pkexec

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, Tumbleweed snapshots have hit a small bump in the road. While we managed to release three snapshots (0109, 0112, and 0113), the release pipeline is currently paused. Testing for snapshot 0114 identified a regression in the recent postfix update, which prevents the service from starting. A bug report has been filed and is currently being worked on; once resolved, Tumbleweed should resume snapshot releases.

The three published snapshots contained these changes:

• Linux kernel 6.18.4 & 6.18.5
• More GNOME 49.3-related package updates
• KDE Gear 25.12.1
• KDE Frameworks 6.22.0
• AppArmor 4.1.3
• Polkit 127
• XZ 5.8.2
• Qemu 10.2.0
• wireplumber 0.5.13: Note for GNOME users: We have seen reports about crashes with Bluetooth devices. See and follow https://bugzilla.opensuse.org/show_bug.cgi?id=1256740

Despite the current snapshots being blocked by the postfix issue, we are continuing to merge changes into Factory and let them be tested by openQA. The following updates are being tested:

• Removal of Python 3.12: in preparation of the python-* packages being enabled (soon) for python 3.14, we will lower the load on the packages first by removing Python 3.12
• Ruby 3.4 interpreter is scheduled for removal after we moved to Ruby 4.0 earlier this month
• A bunch of changes on packages to support installation on transactional systems, i.e no files written to directories outside of snapshot, i.e. no /var
• Agama 19 preview
• Run0-wrappers as a replacement for sudo and pkexec, currently waiting on https://bugzilla.opensuse.org/show_bug.cgi?id=1256515

Cada cierto tiempo me gusta hablar de Slimbook, la marca de dispositivos 100% compatibles con GNU/Linux por varias razones, entre las que destacan que soy usuario habitual de la marca y que tengo la convicción de que debemos promocionar las empresas que confían en el Sotware Libre. En la recta final del año pasado ya les dediqué un par de artículos, uno sobre el KDE Slimbook VII y otro sobre sus ofertas de Black Friday. Pero es que debería dedicarles más porque no paran. Es por ello que me complace compartir con vosotros que han sido renovada la gama Executive de Slimbook, dentro de su serie de ultrabooks de alta gama ¿Tienes curiosidad? Sigue leyendo.

Renovada la gama Executive de Slimbook

Aunque en el mundo de las ordenadores de sobremesa o de escritorio la posibilidad de disfrutar de un sistema operativo libre es algo relativamente sencillo. De hecho, su conquista apenas tiene el problema del arranque y las tarjetas gráficas, el resto se soluciona rápido y bien (aunque las impresoras pueden ser un dolor de muelas).

No obstante siempre es de agradecer que algunas compañías como Slimbook se preocupen no solo de ofrecerte una alternativa que asegura su compatibilidad absoluta con los sistemas del GNU y el pingüino sino que te los afinen como solo los profesionales saben hacer (y si no me creéis os remito a este artículo donde un producto puesto a punto por los chicos y chicas de Slimbook barría en las pruebas de rendimiento a ordenadores en principio más potentes).

De esta forma me congratula compartir con todos vosotros que recientemente han renovado la gama Executive de Slimbbok, una revisión de este modelo de alta gama que viene con su sello de calidad tradicional

.

En palabras de la compañía:

Slimbook presenta el nuevo Executive, la última evolución de unos de nuestros portátiles más icónicos. Manteniendo la línea de elegancia y ligereza que lo ha hecho reconocido, ahora llega más premium que nunca, con acabados cuidados al detalle y una sensación al tacto suave que no querrás perderte.

Entre sus características más destacadas nos encontramos con:

• cabado Silk Skin: Superficie en negro mate con un tacto suave y sedoso que aporta mayor confort durante la jornada.
• Chasis de magnesio: Estructura que combina alta durabilidad con un peso ultraligero de solo 1,2 kg.
• Procesador Intel Core ULTRA 7 255H: CPU de alto rendimiento optimizada para tareas exigentes y procesos de IA.
• Memoria masiva: Capacidad de hasta 128 GB de RAM, ideal para la creación y gestión de máquinas virtuales.
• Batería de 99 Wh: La máxima capacidad permitida en vuelos, diseñada para ofrecer autonomía durante todo el día.
• Potencial de IA: Optimización inteligente para acelerar la edición de contenidos y mejorar resultados en aplicaciones de texto e imagen.
• Conectividad avanzada: Incluye puerto USB-C 4.0 (40 Gbps), múltiples puertos USB-A, HDMI 2.1 y lector de tarjetas SD.
• Conexión de red: Incorpora puerto RJ45 para conexiones por cable estables.
• Privacidad reforzada: Dispone de bloqueo físico de webcam y opción de deshabilitarla por completo desde la BIOS/EC.
• Refrigeración eficiente: Sistema de disipación térmica diseñado para mantener el equipo fresco en sesiones intensas.

Por cierto, y como suelo comentar en estos casos, esto tampoco es una entrada patrocinada. Mi relación con Slimbook es de cliente habitual, amistad e intereses mutuos (el dominio del mundo por parte de la filosofía GNU/Linux).

Más información: Slimbook Executive | Nuevo Slimbook Executive |

La entrada Renovada la gama Executive de Slimbook se publicó primero en KDE Blog.

No es noticia que el entorno de trabajo Plasma de la Comunidad KDE es increíblemente personalizable. Prueba de ello es las 12 acciones que puedes hacer con los bordes de pantalla en Plasma, desde bloquear la pantalla hasta ejecutar Krunner. ¿Quieres conocerlos todos? Sigue leyendo este artículo que podemos categorizar como de la serie cómo.

Los bordes de pantalla en Plasma, algo más que un límite

Aunque personalmente me gusta más utilizar el teclado, mucha gente está acostumbrada a utilizar el ratón para hacer la mayoría de las cosas en el escritorio Plasma.

Y una de las cosas que te permite el escritorio de al Comunidad KDE es activar ciertas acciones con el ratón pero sin hacer clic, algo parecido a lo que hacemos con nuestros teléfonos móviles cuando vamos a la parte superior de la pantalla y deslizamos el dedo hacia abajo.

Por ejemplo, por defecto viene activado que si pones el ratón en la esquina superior izquierda aparece un mosaico con las ventanas que hay abiertas en el escritorio con la posibilidad de buscar y la opción de ir a otro escritorio, eso se llama Vista General, una forma de buscar exactamente la que buscas de un vistazo.

De esta forma la pantalla en Plasma tiene 8 zonas de interacción donde si sitúas el ratón el sistema puede realizar alguna acción. Estas zonas son las 4 esquinas de la pantalla y las 4 puntos medios de los laterales, como se puede ver en la imagen inferior.

La activación se muestra iluminando levemente la zona y se activa dejando un tiempo configurable (por defecto 75 ms) el ratón quieto en esa zona, para evitar activaciones no deseadas.

12 acciones que puedes hacer con los bordes de pantalla en Plasma

Para acceder a esta opción debemos seguir el siguiente camino: Preferencias del Sistema–> Pantalla y Monitor–>Bordes de Pantalla.

Si seguimos dicho secuencia nos aparecerá la siguiente pantalla:

Como vemos nos muestra una pantalla con los 8 puntos de interacción. Pulsando en cada uno de ellos nos aparecen las 12 acciones que podemos realizar. Evidentemente solo tenemos que pulsar sobra la acción deseada y pulsar en el botón Activar situado en la parte inferior.

Las acciones que podemos realizar son las siguientes:

1. Mostrar el escritorio (fondo + plasmoides).
2. Mostrar las ventanas del escritorio actual.
3. Mostrar las ventanas de todos los escritorios.
4. Mostrar las ventanas del la aplicación actual.
5. Mostrar todos los escritorios virtuales.
6. Vista general (muestra no solo las ventanas que hay abiertas en el escritorio con la posibilidad de buscar y la opción de ir a otro escritorio virtual).
7. Ejecutar Krunner.
8. Ejecutar el lanzador de aplicaciones.
9. Gestor de actividades.
10. Bloquear la pantalla.
11. Activar la conmutación de aplicaciones.
12. Activar la conmutación de aplicaciones alternativo.

Otras cosas que podemos configurar en este pantalla son las siguientes, numeradas del 1 al 9:

1. Maximiza: Si mueves una ventana al borde superior se maximiza.
2. Mosaicos: Si mueves una ventana a los bordes izquierdos o derechos se dimensiona en un cuarto de pantalla.
3. Comportamiento: para evitar interrupciones accidentales mientras juegas o ves contenido multimedia a pantalla completa.
4. Activador de mosaico en cuartos: controla cómo se comportan las ventanas cuando las arrastras hacia las esquinas de la pantalla.
5. Cambia de escritorio en el borde: permite o no saltar al escritorio virtual contiguo simplemente empujando el cursor del ratón contra el borde lateral de la pantalla.
6. Retardo de la activación: tiempo que tiene que estar el cursor quieto para activar la acción.
7. Retardo de la reactivación: ajuste de tiempo que sirve para evitar que una acción de borde se dispare varias veces seguidas por error.
8. Barrera de esquina: configuración diseñada específicamente para sistemas con más de un monitor, aunque también afecta a la precisión en un solo monitor. crea una pequeña resistencia física en los píxeles de las esquinas y que hace que se active el efecto o que simplemente el cursor pase al otro monitor. En otras palabras, para pasar el cursor del Monitor A al Monitor B, tienes que mover el ratón con un poco más de velocidad o fuerza. Si lo mueves muy despacio, el cursor se detendrá en el borde como si hubiera una pared.
9. Barrera de borde: lo mismo que la barrera de esquina, además nos permite definir la distancia a la que se activa la acción.

Como vemos, aunque el funcionamiento es simple por defecto, se puede ajustar todo lo que se quiera. De hecho, tras la redacción de este artículo he dejado activa el lanzador de aplicaciones en el borde inferior izquierdo, lo que me va a ahorrar clics innecesarios y, de momento, para el borde superior he activado lanzar krunner, aunque es posible que lo quite, no estoy convencido que se adapte a mi forma de trabajar.

La entrada 12 acciones que puedes hacer con los bordes de pantalla en Plasma se publicó primero en KDE Blog.

This is a roundup of articles from the openSUSE community listed on planet.opensuse.org.

The below featured highlights listed on the community’s blog feed aggregator are from Jan. 9 to Jan. 15.

Blogs this week highlight a strong mix of KDE desktop development, openSUSE security work, gaming on Linux, and thoughtful reflections on software sustainability and AI.

Coverage includes multiple Plasma updates and previews, KDE Frameworks and Gear release planning, an openSUSE security retrospectives, Tumbleweed snapshot reviews, and discussions on reducing e-waste through responsible software policies.

Here is a summary and links for each post:

KDE Express Episode 63: Year-End Special – KDE Express 25.12

The KDE Blog shares the latest episode of KDE Express, a community-driven video series that recaps KDE developments and highlights from December 2025. Episode 63 features a festive year-end review, covering major releases like Plasma 6.5 updates, early previews of Plasma 6.6, and reflections on KDE’s progress in accessibility, theming, and application maturity. The hosts also thank contributors and users alike, setting an optimistic tone for KDE’s roadmap heading into 2026.

My 12 Desktop Fridays of 2025

The KDE Blog celebrates a year of community creativity with a curated showcase of the author’s favorite “Desktop Friday” (#ViernesDeEscritorio) setups from 2025. Each entry highlights unique KDE Plasma customizations. The post serves as both a nostalgic recap and an inspiration for users looking to personalize their own Linux workspaces in 2026.

KDE Gear 26.04 Release Schedule Announced

The KDE Blog outlines the official release timeline for KDE Gear 26.04. Key milestones include the feature freeze and first beta on March 5 followed by the release candidate on March 27. The final code tagging on April 9, and the stable release on April 16.

SUSE Security Team Spotlight – Autumn 2025

The SUSE Security Team provides a detailed retrospective on their autumn 2025 activities to include covering code reviews, vulnerability disclosures, and security hardening efforts across multiple projects.

Plasma 6.6 Beta Released

The KDE Blog announces the beta release of Plasma 6.6. The version is expected to include further panel customization options, smoother animations, and deeper integration with KDE’s ecosystem of apps and frameworks.

Fifth Update for Plasma 6.5 Released

The KDE Blog announces the fifth maintenance update for Plasma 6.5. The update is strongly recommended for all Plasma 6.5 users, as it refines the desktop experience without altering core functionality.

Changes in the syslog-ng Elasticsearch Destination

Peter Czanik details recent improvements to syslog-ng’s Elasticsearch integration. The update aligns the driver’s behavior with modern Elasticsearch practices and improves compatibility with existing configurations. Documentation gaps have also been addressed by incorporating clearer configuration logic directly inspired by recent OpenSearch destination updates in syslog-ng 4.11.0.

Pixel Wheels 1.0.0 Released

Victorhck announces the stable 1.0.0 release of Pixel Wheels, which is an open-source, retro-style arcade racing game built with libGDX and fully compatible with Linux. The game features local multiplayer support, procedurally generated tracks, and a charming pixel-art aesthetic, all under a permissive Apache 2.0 license. Designed to be lightweight and accessible, Pixel Wheels is now considered feature-complete and ready for use.

3 Native Real-Time Strategy (RTS) Games for Linux

The KDE Blog showcases three native real-time strategy games that run natively on Linux. The list includes both classic and modern titles that leverage open-source engines or are fully developed for Linux. These games demonstrate that Linux continues to be a viable platform for RTS enthusiasts who value freedom and cross-platform play.

Set Up a Timer and Much More in KDE Plasma

Victorhck explores the versatility of KDE Plasma’s built-in timer and stopwatch utilities, showing how they integrate seamlessly into the desktop workflow via the Digital Clock widget or standalone apps. Beyond basic timing functions, he demonstrates advanced features like custom alarms, recurring notifications, and keyboard shortcuts that enhance productivity.

Software Policies Can Fuel Waste

The openSUSE News team examines how restrictive software policies like forced obsolescence, lack of long-term support, and vendor lock-in—contribute to electronic waste and environmental harm. The article advocates for a more responsible approach to software design and deployment.

FutureofGamming.com – A New Hub for Open Gaming Insights

NintyFan introduces FutureofGamming.com, a new website dedicated to exploring the future of gaming with a focus on open-source technologies, Linux compatibility, and community-driven development. The platform aims to cover game porting efforts, performance benchmarks on open systems, and interviews with indie developers embracing open ecosystems.

Update Your Windows 10—Switch to Linux

The KDE Blog encourages Windows 10 users facing the end of official support to consider migrating to Linux as a secure, modern, and user-friendly alternative. The post highlights KDE Plasma’s polished desktop experience, strong hardware compatibility, and seamless integration with everyday tools. It also provides practical tips for trying Linux without immediately abandoning Windows, such as using live USBs or dual-boot setups.

An Internet Artisan Facing the AI Prompt

Victorhck reflects on maintaining a personal blog in the age of AI, rejecting the idea of using AI to generate or suggest content for his posts. He contrasts the deliberate, skill-based craft of traditional computing with the convenience (and opacity) of large language models, expressing both admiration for AI’s power and concern over its impact on deep technical understanding.

Car of the Year Edition Arrives in Plasma This Week

The KDE Blog announces a “Car of the Year” themed edition for this week, featuring custom wallpapers, widgets, and system sounds inspired by automotive design. The limited-time release celebrates KDE’s tradition of playful seasonal and event-based desktop themes. There is also a video on how Mercedes is using QT.

Twenty-Second Update of KDE Frameworks 6

The KDE Blog reports on the release of KDE Frameworks 6.22, the twenty-second monthly update since the major transition from Qt5/KF5 to Qt6/KF6 in February 2024. This update continues KDE’s commitment to delivering predictable, incremental improvements that underpin Plasma 6 and KDE applications. The post also introduces a new series explaining the 83 libraries that make up KDE Frameworks, which is categorized into four tiers based on dependency complexity and functionality.

OpenCV 4.13.0: Performance, Robustness, and Maturity for Production Computer Vision

Alessandro de Oliveira Faria highlights the release of OpenCV 4.13.0, emphasizing its enhanced performance, improved stability, and expanded support for production-grade computer vision applications. The article details deep optimizations across x86, ARM, RISC-V, and other platforms, and improvements to classic algorithms and DNN modules. It also notes enhanced bindings (Python, JavaScript, Java), better video and codec support, and future-oriented features like CUDA 13.0 compatibility.

openSUSE Tumbleweed Weekly Review – Week 2 of 2026

Victorhck and dimstar summarize the openSUSE Tumbleweed snapshots released during the second week of January 2026. The updates include key package upgrades such as GCC 14, systemd 257, and Mesa 25.0, alongside routine maintenance and security fixes.

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

Table of Contents

• 1) Introduction
• 2) The methodology
  • Some numbers about the codebase
  • The activity tracking
  • The setup
  • The attacker’s corner
  • The reporting method
• 3) Audit results
  • CVE-2024-49502: spacewalk-web: Reflected XSS in Setup Wizard, HTTP Proxy credentials pane
  • CVE-2024-49503: spacewalk-web: Reflected XSS in Setup Wizard, Organization Credentials
  • CVE-2025-23392: spacewalk-java: reflected XSS in SystemsController.java
  • CVE-2025-46809: Plain text HTTP Proxy user:password in repolog accessible from the UYUNI 5.x webUI
  • CVE-2025-46811: Unprotected websocket endpoint
  • CVE-2025-53883: spacewalk-java: various XSS found on search page
  • CVE-2025-53880: susemanager-tftpsync-recv: arbitrary file creation and deletion due to path traversal
  • Other minor findings
• 4) Conclusions
• 5) What’s next?
• 6) Links

1) Introduction

UYUNI is an open source system management solution, forked from Spacewalk and upstream community project from which SUSE Multi-Linux Manager is derived.

The audit started in January 2024 with the perimeter definition. Since it’s not feasible to audit everything, a list of packages was chosen and submitted to UYUNI product owner. The criteria for including a package in the perimeter were:

• the package implementing UYUNI web UI
• the package implementing API or websocket layer
• the package implementing UYUNI backend
• the salt package (fundamental for UYUNI server and minions interaction)
• packages not included in previous UYUNI audits

In March 2024 the code scanning activities effectively started.

2) The methodology

Auditing a complex codebase like UYUNI is not just running a static analysis tool and waiting for it to complete. It is a complex and long-running journey that took one year and a half to complete.

Some numbers about the codebase

The codebase is big with a lot of sub-packages. Each sub-package was treated as a standalone audit with its own Bugzilla bug, its own list of affected vulnerabilities and its own report. The final report was produced by combining the reports of all sub-packages.

The audited codebase is more than 4.5 millions lines of code, with at least 7 different programming languages.

As you may wonder, using a single catch-all tool to analyze such a heterogeneous codebase is not possible.

Every package in the scanning perimeter was audited looking at the source both using tools and by manual inspection. The running server was continuously inspected dynamically looking for low-hanging fruit like cross-site-scripting (XSS), SQL injection and similar, and for business logic flaws.

Each security issue was then triaged and if necessary a CVE identifier was assigned and the vulnerability put under EMBARGO. Using the openSUSE coordinated disclosure policy as a framework, we coordinate with upstream and disclose the issue when solved.

The activity tracking

We use Bugzilla as tracking authority for audits and vulnerabilities found during the activity. A master bug (boo#1218619) was created with the purpose of acting as a main container for all sub-packages audit bugs.

Each audit bug contains all affecting vulnerabilities and, of course, a vulnerability bug can be set as blocker to more sub-packages.

The setup

For the activity, a set of KVM-powered machines were created:

• a UYUNI server instance
• a UYUNI proxy instance
• a couple of minions, Linux workstations attached and managed centrally by the master.

The server is the main UYUNI component orchestrating minions attestation and enabling system administrators to launch commands and interact with minions using the web interface.

A minion, in the UYUNI slang, is a Linux-powered machine (ideally it is a client in a local network), connected to the server.

A UYUNI proxy is a particular kind of server, used to fetch packages from software distribution channels and centrally store software packages for an efficient distribution to minions. Distribution channels are software repositories and a system administrator subscribes his own UYUNI instance to different repositories.

Each server was running openSUSE MicroOS as underlying operating system and minions were running either openSUSE Tumbleweed or Ubuntu Linux distributions.

The attacker’s corner

For the testing activities we used two different machines. A virtual machine running openSUSE Tumbleweed, used for source code inspection and a virtual machine running Kali Linux installed to help in penetration testing activities.

The tools

Burp Suite community was the main tool used trying to spot security issues in the running application.

To help, during the UYUNI application browsing, a custom tool was developed. While browsing the web UI trying to find business logic flaws, I felt the need for something running in the background spotting low-hanging fruit in web pages form, cookies and more. The tool eventually became an OSS project named nightcrawler-mitm. It’s a mitmproxy extension implementing both an active and a passive scanner running several security controls in the background.

Also for auditing the source code, opensource tools were used. Some of the tools used are famous OSS projects, like:

• bandit
• semgrep
• npm audit

To help me during the activities, I also used some SAST tools previously written by myself, like:

• dr_source
• dawnscanner

The reporting method

As discussed before, every finding was tracked on a separate bugzilla bug. Each bug was linked, marking as a blocking bug, to any sub-package audit bug affected by the associated vulnerability.

Of course, every vulnerability was confirmed by a successful exploitation, before being added to our Bugzilla tracking system. Vulnerabilities were assigned to UYUNI developers and tracked until a fix was released. A CVE was also assigned if required by the issue severity.

The standard CVSS version 4 was used as a scoring system and to assign a severity. The rationale is that if a CVSS is lower than 5, then the severity is low, it is medium if CVSS is between 5 and 7 and high otherwise. The same approach was used to assign a triage score to each sub-package. The triage score will be used in the future to decide if the sub-package must be in future audit perimeter or not.

At the end of the audit, the list of issues and the triage score created a technical report sent to UYUNI developers.

3) Audit results

During the audit, seven CVEs were found and fixed, and numerous minor issues were addressed, improving the product’s reliability and overall security posture.

CVE-2024-49502: spacewalk-web: Reflected XSS in Setup Wizard, HTTP Proxy credentials pane

A reflected cross-site scripting has been found in the HTTP proxy pane of the setup wizard UI element. Tracked in boo#1231852

CVE-2024-49503: spacewalk-web: Reflected XSS in Setup Wizard, Organization Credentials

A reflected cross-site scripting has been found in the Organization Credentials pane of the setup wizard UI element. Tracked in boo#1231922

CVE-2025-23392: spacewalk-java: reflected XSS in SystemsController.java

Some URLs, served by the SystemsController.java class are vulnerable to a reflected XSS vulnerability. Some example of vulnerable URLs are listed in the Github advisory as well. The advisory was filed by an external independent researcher following our coordinated disclosure policy. Tracked in boo#1239826

CVE-2025-46809: Plain text HTTP Proxy user:password in repolog accessible from the UYUNI 5.x webUI

Credentials to be used in UYUNI HTTP proxy are disclosed in the error log in case of wrong port number or misspelled hostname. Tracked in boo#1245005

CVE-2025-46811: Unprotected websocket endpoint

During an internal assessment, a customer found an issue with the remote-commands websocket endpoint (/rhn/websocket/minion/remote-commands). Using websockets, anyone with the ability to connect to port 443 of SUSE Manager is able to run any command as root on any client with no authentication. The customer using our coordinated disclosure policy as a reference, reported the issue which was then fixed and publicly disclosed. Tracked in boo#1246119

CVE-2025-53883: spacewalk-java: various XSS found on search page

During an internal assessment, a customer found that some reflected cross-site scriptings were possible due to improper input validation. The issue was tracked in the private SUSE bugzilla instance, since some customer sensitive information was included. However the issue is described in the public CVE-2025-53883 page.

CVE-2025-53880: susemanager-tftpsync-recv: arbitrary file creation and deletion due to path traversal

A Path Traversal vulnerability in the tftpsync/add and tftpsync/delete scripts allows a remote attacker on an adjacent network to write or delete files on the filesystem with the privileges of the unprivileged wwwrun user. Although the endpoint is unauthenticated, access is restricted to a list of allowed IP addresses. The unprivileged user has write access to a directory that controls the provisioning of other systems, leading to a full compromise of those subsequent systems. Tracked in boo#1246277

Other minor findings

Additional vulnerabilities were identified that, while valid, did not meet the criteria for CVE assignment:

• boo#1231900: VUL-0: arbitrary log messages in API can lead to a disk space exhaustion (and so to a denial of service)
• boo#1245740: VUL-0: Default venv-salt-minion environment is activated on the different user accounts
• boo#1243679: VUL-0: Insecure communication in TFTP proxy sync.
• boo#1243768: VUL-0: Potential Command InjectionPattern in check_push Function. No activity: a follow-up was requested.
• boo#1239636: VUL-0: log pollution in class TraceBackEvent
• boo#1237368: VUL-0: unhandled exception when dealing with numeric request parameters
• boo#1243087: VUL-0: spacewalk-search: unexploitable XSS in XML RPC Server.
• boo#1227577: VUL-0: spacecmd and spacewalk-backend: usage of unsafe third party library for XML.

Last but not least, during the audit also some codebase improvements were suggested to raise the security posture even further:

• boo#1228945: AUDIT-FIND: spacewalk-utils: Sensitive information disclosure in backup file
• boo#1223313: AUDIT-FIND: Possible deserialization issue in spacewalk-client-tools (affecting only SUMA 4.x)
• boo#1228116: AUDIT-FIND: spacewalk-admin: mgr-monitoring-ctl doesn’t sanitize PILLAR parameter
• boo#1231983: AUDIT-FIND: spacewalk-web: generatePassword() improve namespace entropy
• boo#1246941: AUDIT-FIND: saline: Hardening Against Insecure Deserialization
• boo#1247015: AUDIT-FIND: saline: Race Condition in Service Startup Allows for IPC Hijacking on Systems with a Permissive umask
• boo#1227579: AUDIT-FIND: spacecmd: get rid of pickle to read and parse configuration files.

4) Conclusions

The UYUNI audit was an intense and rewarding run. The good results in term of number of found vulnerabilities and the fast reaction to release the fixes, confirmed UYUNI as a solid and reliable product for the community.

As all software, of course it can be improved in terms of code quality by applying safe coding patterns, using secure and reliable third-party libraries and consolidating the usage of one or two programming languages. This is an important step, because it creates a common ground for engineers and a solid codebase for the community to entice contributions and pull requests.

A vibrant codebase, using a balanced mix between standard and cutting edge technologies can increase adoption of the product and it can attract developers and contributors.

It also helps in adopting safe coding best practices that are widely updated and developed for newer technologies rather than ancient and not actively used programming languages.

The low number of vulnerabilities found, and the reaction time in fixing the serious ones, indicate that the project is well-curated and actively maintained. The security posture is good and it can be safely deployed in production.

5) What’s next?

Like every journey, the final destination is not the reward itself. The UYUNI project is actively under development with a monthly (more or less) release cycle.

The next audit will start in the first quarter of 2026 and it will be another one year and a half rollercoaster ride, with rabbit holes, false positives, suspected CVEs turning out to be not exploitable and real root dance issues.

The fun part is to audit code written in multiple languages, with different stacks and libraries.

It’s not rewarding only from a security perspective, it’s a real learning experience.

6) Links

• The master Bugzilla bug.
• The latest stable version 2025.10 of UYUNI containing all the relevant fixes.
• The nightcrawler-mitm tool, written to actively and passively scan the web application in the background.
• The dr_source tool, written as a SAST companion tool mainly for Java but improved with support for other programming languages.
• The UYUNI source code on Github
• The openSUSE coordinated disclosure policy

Me congratula presentaros el episodio 63 de KDE Express, titulado «Fin de año en KDE Express 25.12« con una avalancha de noticias de la mano de David Marzal. Un podcast del año pasado y que se había quedado en el tintero. A ver si me pongo al día.

Episodio 63 de KDE Express: Fin de año en KDE Express 25.12

Comenté hace ya bastante tiempo que había nacido KDE Express, un audio con noticias y la actualidad de la Comunidad KDE y del Software Libre con un formato breve (menos de 30 minutos) que complementan los que ya generaba la Comunidad de KDE España, aunque ahora estamos tomándonos un tiempo de respiro por diversos motivos, con sus ya veteranos Vídeo-Podcast que todavía podéis encontrar en Archive.org, Youtube, Ivoox, Spotify y Apple Podcast.

De esta forma, a lo largo de estos 63 episodios, promovidos principalmente por David Marzal, nos han contado un poco de todo: noticias, proyectos, eventos, etc., convirtiéndose (al menos para mi) uno de los podcast favoritos que me suelo encontrar en mi reproductor audio.

En palabras de David:

No podíamos empezar las fiestas sin nuestra dosis de noticias correspondiente. La comunidad KDE no para de darnos un ecosistema mejor día a día y, por lo tanto, aquí tenemos un resumen de lo que David Marzal nos ha querido destacar.

KDE Gear 25.12

• Itinerary permite extraer y almacenar más datos como billetes de tren…
• KJournald te permite ver tus logs de manera más visual y ahora soporte unidades (units) de usuario
• Dolphin no manda a la papelera las carpetas temporales borradas y te deja ocultar ficheros desde el menu contextual
• Kate mejora el soporte GIT, justo lo que yo más echaba en falta
• Konqueror permite exportar páginas a PDF con alta calidad
• Falkon adquiere un botón para activar o desactivar el bloqueador de anuncios.
• https://ubunlog.com/kde-gear-25-12-llega-con-mejoras-en-dolphin-kate-fotos-navegacion-y-mucho-mas/

Kdenlive 25.12 nos trae:

• Docking system renovado para configurar la interfaz a nuestro gusto
• Pantalla de bienvenida para facilitar iniciar un proyecto.
• Menús reestructurados para hacerlos más intuitivos
• Monitor de audio refrescado que ahora incluye un minimapa
• Se ha renombrado en la línea de tiempo «guides» a «markers» para que sea menos confuso
• Arreglada la aceleración por HW VAAPI en la versión AppImage.

KDE Plasma 6.5.4 con unos cuantos parches

Se retoma el desarrollo de KioT

Parrot (la distro enfocada en seguridad y testing ) adopta por defecto Plasma en su versión 7

Ubuntu Studio 26.04 prepara cambios en la distribución de su escritorio Plasma

• Y Se despiden los spin/variantes Mate y Unity

Fedora Games Lab quiere modernizarse y de paso pasar a Plasma

Peertube 8

• Nuevo reproductor web, aunque se puede volver al tema antiguo.
• Maneja tus canales en equipo, puedes designar miembros de tu plataforma como colaboradores.

Firefox 146 trae escalado fraccional completo en Wayland, experimentos accesibles para todes, pestaña con el tiempo meteorológico en la EU…

Y 147 por fin soportara el estándar XDG BAse Directory de Freedesktop junto con mejoras de aceleración por HW en AMD

Thunberbird 146

• Posibilidad de elegir tu servidor de claves OpenPGP preferido
• Mejoras en la importación de vCards

Fairphone y su apuesta por el open source

No existe el Open Source Comercial por Agustín Benito.

Por cierto, también podéis encontrarlos en Telegram: https://t.me/KDEexpress

La entrada Episodio 63 de KDE Express: Fin de año en KDE Express 25.12 se publicó primero en KDE Blog.

Creo que ya he encontrado la forma de hacer las recopilaciones de mis viernes de escritorio que cada cierto tiempo prometo pero que pocas veces cumplo. Y es que en este inicio de año es un buen momento para dar una vista atrás del año que hemos dejado para mostrar mis 12 viernes de escritorio de 2025, un vistazo al interior de mi entorno de trabajo y una muestra de las grandes opciones de personalización que tiene Plasma de la Comunidad KDE.

Mis 12 viernes de escritorio de 2025 #viernesdeescritorio

Hace casi más de un año realicé una entrada recopilatoria con mis 12 viernes de escritorio de 2024, una tradición que inicié en 2022. Hoy os presento mis 12 viernes de escritorio del 2025. Igual que el año pasado no voy a comentar cada una de los meses del año ya que para eso está en enlace que os lleva a la entrada en particular donde podréis pinchar en el mes si queréis ampliar , pero si que realizaré un comentario si es necesario.

A modo de introducción simplemente comentar definitivamente me he aficionado a los temas oscuros frente a los claros y los estilos de reloj son mis fetiches. Espero que os gusten.

Enero

Empiezo el año mostrando mi Slimbook Pro con el tema global básico Brisa Oscuro, con los iconos Deepin2022-Dark, la barra de actividades de la derecha a la izquierda ya que es más cómodo a la hora de utilizar las barras de desplazamiento.

Puse el reloj-calendario Cock Asitoki Color deZayronoxio, que le queda de fábula sobre un fondo muy «Gandalf llegando a la Comarca buscando a Frodo»

Febrero

Seguí febrero con el Slimbook Pro con el mismo aspecto: tema global básico Brisa Oscuro, los iconos Deepin2022-Dark y la barra de actividades de la derecha a la izquierda. Simplemente cambié el reloj-calendario a Modern Clock de Prayagjain bastante modificado que le queda de fábula sobre un fondo muy colorido ya que este último mes necesitaba contraste para seguir con mi gris y ajetreada vida.

Marzo

Otro mes mostrando mi Slimbook Pro volviendo al tema global básico Brisa Claro, con los iconos por defecto. Seguí con el reloj-calendario Modern Clock de Prayagjain pero en esta ocasión en su forma básica sobre el fondo por defecto de Plasma 6.3.

Abril

En abril vuelvo a mi ordenador de escritorio con el tema global básico Brisa Oscuro e iconos estándar (Brisa Oscuro). La barra de tareas a la izquierda a la que he añadido una serie de barras de colores para separar las diferentes secciones de la misma: aplicaciones, bandeja de sistema, hora con un pequeño bloc de notas y el lanzador de aplicaciones. Si quieres más información lee este artículo donde explico este separador de widgets.

Mayo

En mayo vuelvo a mi Slimbook Pro con tema global básico Brisa Oscuro e iconos estándar. La barra de tareas a la izquierda se ha quedado para siempre. Para el fondo he puesto uno de oscuro pero de alto contraste sobre el que he puesto el plasmoide Clock Asitoki Color, personalizado para utilizar un naranja del fondo y el azul dominante del tema global. También he puesto un plasmoide llamado Weather Widget Plus, bajo del reloj de la barra de tareas, que me indica la temperatura del exterior de mi casa.

Junio

Un mes más con el Slimbook Pro pocos cambios destacables. El primero en cambio de fondo y los colores.

Por otra parte, la barra de tareas se complementa, además de con el plasmoide Weather Widget Plus del mes pasado , con el selector de colores.

Julio

Pleno verano y continúo con el ultrabook Slimbook, la misma barra de tareas pero con una novedad. Para el fondo de pantalla utilizo el widget llamado Random AI Wallpaper que pone un fondo aleatorio, generados por alguien gracias a la IA y de calidad (la IA puede genera fondos pero que sean de calidad es decisión de una persona), que se guardan en un Gitlab y que podéis encontrar más detalles en esta entrada.

Para finalizar, cambié mi reloj de escritorio por otro creado por una desarrollador de Plasma que me indica la hora aproximada, que queda estupendo en temas oscuros. Una maravilla y, además, es exclusivo.

Agosto

Pocos cambios para el mes de agosto, simplemente cambia el fondo de pantalla, que como podéis observar sigue siendo de calidad.

Septiembre

Empieza el curso escolar y vuelvo al Slimbook Kymera, con el tema global básico Brisa Oscuro e iconos estándar. La barra de tareas la he pasado a mi ordenador de sobremesa: a la izquierda, y justo antes del lanzador de aplicaciones, un pequeño bloc de notas para acceder de forma rápida a esas cosas que pasan por mi mente y necesito apuntar para recordar después. Todo ello separados por barra coloreadas.

Para el fondo he escogí uno llamativo de la KDE Store, donde cada día se publican decenas de fondos con lo que es sencillo encontrar uno que te llame la atención. Es esta ocasión he seleccionado «butterfly-Abstract creative design wallpaper» de maduu.

Además el fondo muestra el plasmoide que muestra las fases de la luna llamado Luna 3 de Samuel Jiménez.

Octubre

De aquí a final de año realizo las capturas en el ordenador de escritorio y con el tema global creado por el gran Jorge Dangelo, conocido también como Jomada. Se trata de con el tema global Bart (oscuro, con transparencias y con resaltado de color naranja) combinado con el paquete de iconos Tela Nord Dark.

Para el fondo seleccioné el que viene por defecto con el tema Global Bart llamado «Astronaut Girl»

Noviembre

Como decía, seguí en mi Slimbook Kymera utilizando eltema global Bart (oscuro, con transparencias y con resaltado de color naranja) combinado con el paquete de iconos Tela Nord Dark. Como se puede apreciar, la barra de tareas ha pasado a la izquierda ya que me resulta más cómodo para realizar las clase en línea.

Para el fondo seleccioné el segundo que viene por defecto con el tema Global Bart llamado «Green Eyes» (que por cierto tiene entrada propia en el blog de Jomada)

Diciembre

Finalizo el año sin apenas cambios respecto al año pasado. Simplemente realizao un cambio para el fondo de escritorio, seleccionando uno nevado acorde con un efecto de escritorio que genera nieve, algo apropiado para dichas fechas

La entrada Mis 12 viernes de escritorio de 2025 #viernesdeescritorio se publicó primero en KDE Blog.

Fieles a los periodos cuatrimestrales que los propios desarrolladores se han marcado, acaba de ser anunciado el calendario de lanzamientos KDE Gear 26.04, el síntoma inequívoco de la continua evolución de la Comunidad KDE y su compromiso por la constancia y mejora continua.

Tener un plan de trabajo pre-establecido es algo fundamental para que los equipos funcionen. Este calendario de trabajo debe contener la respuesta a dos preguntas muy explícitas: qué hay que hacer y cuándo debe estar hecho. Además, en sus aplicaciones internas se responde a otra pregunta que también es sumamente importante: quien lo va a hacer.

Esta metodología de trabajo la tienen perfectamente clara y establecida los desarrolladores de KDE que, como viene siendo habitual, no solo se lo marcan en sus agendas sino que lo hacen público. De hecho, esta entrada es un calco de la que hice hace ya mucho tiempo con KDE Aplicaciones 20.04, KDE Gear 23.08, KDE Gear 25.04, etc.

Calendario de lanzamientos KDE Gear 26.04 de KDE

Si tenéis un calendario a mano y tenéis interés en los lanzamientos de KDE Aplicaciones os aconsejo que  anotéis en él las fechas principales de lanzamientos de KDE Gear 26.04. Hay que destacar que en esta ocasión se ha querido simplificar mucho el proceso en aras de ser más claros y efectivos. En anteriores lanzamientos ha resultado bastante acertado.

De este modo tenemos:

• Jueves, 5 de Marzo de 2026:  Congelamiento de KDE Gear 26.04, marcado y lanzamiento de la primera beta
• Jueves, 27 de Marzo de 2026: Marcado y lanzamiento de KDE Gear 26.04 RC (Versión Candidata)
• Jueves, 9 de Abril de 2026 Marcado de KDE Gear 26.04
• Jueves, 16 de Abril de 2026: Lanzamiento de KDE Gear 26.04 definitivo

En fin, un equipo incansable que nos ofrece la colección de aplicaciones más útil, integradas y funcionales para el escritorio libre más bello, funcional y dinámico que puede habitar en tu PC o portátil… y esperemos que pronto en otros dispositivos.

Más información: KDE Techbase | TSDgeos’ blog

La entrada Calendario de lanzamientos KDE Gear 26.04 de KDE se publicó primero en KDE Blog.

Table of Contents

• 1) Introduction
• 2) Completion of systemd v258 Code Review
• 3) D-Bus Issues in Unreleased plasma-setup KDE Package
  • org.kde.initialsystemsetup.createnewuserautostarthook
  • org.kde.initialsystemsetup.setnewuserhomedirectoryownership
  • org.kde.initialsystemsetup.setnewusertempautologin
  • Upstream Fixes
• 4) Discussion about Granting setgid Privileges to the plocate Binary
• 5) Local Root Exploit in OpenStack’s non-production virtualbmc Project
  • Lack of Authorization and Input Validation in vbmcd
  • Reproducer
  • Further Concerns
• 6) Revisit of the snapd Package Manager
• 7) Conclusion

1) Introduction

The winter season has already begun for most of the people in our team and with the Christmas holidays behind us, which granted us some well-earned rest, we want to take a look back at what happened in our team during the autumn months. During this time we already published a few dedicated review reports:

• trivial local Denial-of-Service in the OpenSMTPD mail transfer agent.
• unauthenticated D-Bus API in the scx scheduler project allowing for a major local Denial-of-Service.
• minor privilege escalation from lightdm to root in lightdm-kde-greeter leading to major improvements of its D-Bus code.
• major local vulnerabilities in the D-Bus interface of smb4k, resulting in upstream fixing a series of long-standing issues in the affected component.

In this post, as usual in the spotlight series, we will look into some topics that did not justify dedicated reports. First we will discuss our continued efforts to review privileged components found in the systemd v258 release, which involved diving deep into some low-level aspects of the Linux kernel API. Section 3 looks at D-Bus issues we found in plasma-setup, a new component for the KDE desktop. Section 4 covers recent discussions about granting special setgid permissions to the plocate package. Section 5 gives insight into security issues found in the virtualbmc OpenStack project, which turned out to be for testing purposes only. Section 6 discusses revived efforts to bring the Snap package manager to openSUSE.

2) Completion of systemd v258 Code Review

We already discussed our systemd v258 review efforts in the previous spotlight edition. At the time we found a local root exploit in the systemd-machined API, which could be fixed before the final release of v258. For the addition of this new major version of systemd to openSUSE Tumbleweed, we still needed to look more closely into a number of other D-Bus and Varlink services that have been added.

During autumn we completed the review of changes in systemd-mountfsd and systemd-nsresourced. Some of the changes introduced with these services allow unprivileged users to perform a number of container-related operations without requiring special privileges.

The io.systemd.MountFileSystem.MountDirectory API call in mountfsd, for example, allows to obtain a mount file descriptor for a directory owned by the calling user, on which a user and group ID mapping is applied corresponding to a user namespace file descriptor also owned by the caller. Some newer, little-known Linux system calls like open_tree() and mount_setattr() are used to achieve this. This niche topic and the low-level nature of the involved APIs result in quite complex code which needed careful reviewing. We are happy to report that we could find no issues in this area, however.

The nsresourced service, among other features, allows unprivileged users to obtain a dynamic range of user and group IDs for use with user namespaces. The tools newuidmap and newgidmap already allowed this for a longer time based on static configuration files. The nsresourced service applies dynamic limits and ID ranges to processes in the system, however, which makes things quite more complicated. This even includes an EBPF program, which keeps track of the uses of the resulting user namespace file descriptors. Despite this complexity we could not find any issues in this component either.

What kept us busy for a longer time was logic invoked by mountfsd to obtain the user and group ID mapping tied to the user namespace file descriptor passed by the unprivileged client. To retrieve this information, the utility function ns_enter_and_pin() forks a short-lived child process which joins the user namespace provided by the client. The parent process then reads the child’s uid_map and gid_map nodes from /proc/<child-pid>.

The mountfsd daemon runs with root privileges (although some sandboxing is applied to it as well), which will be inherited by the short-lived child process. Once the child process joins the user namespace provided by the unprivileged client, the security domain of this process changes, however, because the client owning the namespace is supposed to have full control over processes associated with it.

One consequence of this is that the owner of the user namespace can send arbitrary signals to the short-lived systemd process, e.g. to kill it. This would only result in a kind of Denial-of-Service against the client itself and should not cause any security issues.

We expected another important ramification of this to be in the area of the ptrace() system call. The following is stated in the “ptrace access mode checking” section of the ptrace(2) man page:

(3)  Deny access if neither of the following is true:

            •  The real, effective, and saved-set user IDs of the target
               match the caller's user ID, and the real, effective, and
               saved-set group IDs of the target match the caller's group
               ID.

            •  The caller has the CAP_SYS_PTRACE capability in the user
               namespace of the target.

According to the second item, the unprivileged client, which owns all capabilities in its user namespace, should be able to trace the short-lived systemd process which joins the client-controlled user namespace. This ability would have allowed for an interesting privilege escalation, because tracing capabilities also include the ability to modify the target process, e.g. to change its code and data. While trying to reproduce this, the kernel always denied ptrace() access to this short-lived process, however, and we were not sure why. Unclarity in such aspects is not a good thing when it concerns security, thus we set out to get to the bottom of this.

After diving deep into the Linux kernel’s ptrace() code, we found the commit which is responsible for the rejection of tracing access in this scenario. The background of this commit actually is to prevent owners of unprivileged user namespaces from accessing the executable of processes created in the initial namespace. ptrace() access to the target PID is now only allowed if the target process performed an execve() while being a member of the newly joined user namespace. In summary this means the following:

• if a process only performs fork() and setns() to join a user namespace, then ptrace() access to this process is denied to the owner of the user namespace.
• if a process performs fork(), setns() and execve(), then ptrace() access to this process is granted to the owner of the user namespace.

This detail is not documented in the ptrace() man page and it took us a while to fully understand what was going on. With this well understood we could finally move on, knowing that the logic in mountfsd is robust.

3) D-Bus Issues in Unreleased plasma-setup KDE Package

This new KDE component was first named KISS (KDE initial system setup), but meanwhile has been renamed to plasma-setup. Its purpose is to perform initial system configuration based on a graphical wizard, when a Linux system has been freshly installed.

Our openSUSE KDE packagers asked for a review of this new component, expecting it to be part of a major KDE release in autumn. It turned out that this had not been planned by upstream after all (or plans changed). Still the review we performed turned out to be useful, since we identified various security problems in the existing code which could be fixed by upstream before the new component had seen production use.

The following report is based on the plasma-setup source code as of upstream commit 08ed810e0e7. While the graphical components of plasma-setup run with low privileges, there exists a D-Bus helper service running as root, kde-initial-system-setup-auth-helper, which allows to perform a number of operations with elevated privileges. These operations are guarded by Polkit authorization rules. The dedicated user account kde-initial-system-setup is allowed to invoke any of these actions without authentication. Beyond this, any locally logged-in users are also allowed to invoke the operations without authentication. The latter is quite problematic, as will be outlined below.

The implementation of the D-Bus callbacks for these actions is found in src/auth/authhelper.cpp. The following sub-sections discuss issues in a couple of these actions.

org.kde.initialsystemsetup.createnewuserautostarthook

This action receives a “username” parameter from the unprivileged D-Bus client. The username is not verified by the privileged helper, it only needs to be convertible to QString. The helper then creates all the directory components of /home/<username>/.config/autostart. After this, the file /home/<username>/.config/autostart/remove-autologin.desktop is created and fixed data is written into it.

This action allows local users to create arbitrary world-readable directories owned by root. This can be achieved by passing a string like ../../my/desired/path as “username”. Furthermore, by placing a symlink at the expected location of remove-autologin.desktop, arbitrary files in the system can be overwritten, leading to a local Denial-of-Service.

The implementation of the action also causes the created directories and files to be owned by root:root, and not by the user that actually owns the home directory, which is unclean.

Suggested Fixes

Apart from restricting access to the helper to the kde-initial-system-setup user, the implementation of this action should verify whether the passed-in username actually exists. Furthermore, the home directory of this account should be obtained via the getpwent() API, instead of assuming that /home/<username> will always be the correct home directory.

When the execution of this helper is actually limited to the initial setup context, it could be technically acceptable to operate as root in the newly created user’s home directory. For reasons of prudence and giving a good example, we still recommend to drop privileges to the target user account before actually writing the .desktop file in the user’s home directory.

org.kde.initialsystemsetup.setnewuserhomedirectoryownership

The method call associated with this action also receives a “username” parameter which is not verified. The following command line is invoked based on the “username” parameter:

chown -R <username>:<username> /home/<username>

This is on the verge of a local root exploit, save for the fact that chown expects a valid user and group account to give the ownership to, which at the same time needs to result in the proper path to operate on. A username containing path elements will fail, because the necessary characters like / are by default denied in usernames.

This action still allows to potentially change ownership of all files of arbitrary other users’ home directories. Fortunately the recursive chown algorithm is not subject to symlink attacks these days. If somebody would be able to place a symlink in place of their home directory in /home/<username>, then the symlink would still be followed, however.

The username could also be interpreted as an arbitrary command line argument to chown, thwarted only by the fact that the <username>:<username> argument is constructed here instead of just passing <username>, which will prevent proper command line arguments from being passed.

Suggested Fixes

As for the previous action, the implementation should verify if the username is valid and determine the proper home directory and group via getpwent(). The assumption that username and group are equivalent is also problematic here.

Why this operation would be needed at all for a newly created home directory is questionable. When new user accounts are created, file ownership should already be correct. If this action is supposed to fix the ownership of files created by other plasma-setup actions in the home directory as root (as is seen in the createnewuserautostarthook action), then this is only a hack which should be removed in favor of not creating files as root in unprivileged users’ home directories in the first place.

org.kde.initialsystemsetup.setnewusertempautologin

Again this method receives a “username” parameter which is not verified. The implementation writes the following content to the file /etc/sddm.conf.d/99-kde-initial-system-setup.conf:

[Autologin]
User=<username>
Session=plasma
Relogin=true

This SDDM configuration snippet is supposed to automatically login the given user account. For some reason that we did not investigate more deeply, the configuration was not effective during our tests on openSUSE Tumbleweed. We could verify that the configuration file created this way was parsed and evaluated in SDDM, however, so something else must have been amiss.

The automatic login is supposed to work, though, and if it does, then any local user account can call this action with root as username, which should cause an automatic login of the root user the next time SDDM runs.

By passing crafted strings for “username”, the content of the drop-in configuration file can even be fully controlled by local users. The following “username” would create a General section with a crafted “RebootCommand”, for example:

user\n[General]\nRebootCommand=/home/myuser/evil

Provided the configuration snippet is actually in effect in SDDM, this action allows for a local root exploit.

Suggested Fixes

As for the other actions, the implementation should verify whether the passed “username” is valid and does not equal root.

Upstream Fixes

We privately approached KDE security on 2025-09-22 with a detailed report about these findings. As a result we established contact with the plasma-setup developer and discussed fixes for the issues. It was decided to perform the bugfix in the open, since the component was not yet part of a stable release of KDE. We reviewed an upstream merge request during the course of two weeks and upstream managed to arrive at a much improved version of the KAuth helper component.

As of commit e6eb1cd9a8d the privileged helper carefully scrutinizes the input parameters received via D-Bus, and it also drops privileges to the calling user before operating in the unprivileged user’s home directory. Also the KAuth actions provided by the helper are now restricted to the plasma-setup service user and no longer accessible to all locally logged-in users. The latter would still be problematic, since it would allow to setup automatic login for arbitrary other users in the system, for example.

4) Discussion about Granting setgid Privileges to the plocate Binary

An openSUSE community member approached us about granting special setgid privileges to the plocate binary. plocate is a modern and fast replacement for the classic locate program. Upstream supports operation of the plocate program with the setgid bit assigned to the plocate group. This means that the program is granted plocate group privileges during execution.

When updatedb, locate’s utility for indexing files, would be invoked with full root privileges, then the database in /var/lib/plocate would contain information about all files in the file system. This way locate would grant all users in the system read access to this information, resulting in an information leak, because users can see paths that they would not normally be allowed to list, like all the files stored in the /root home directory. For this reason the plocate-updatedb system service on openSUSE Tumbleweed runs as nobody:nobody, resulting in a system-wide plocate database which only contains information about publicly accessible paths in the system. For being able to locate their own private files, users need to create their own user-specific databases instead.

The purpose of the setgid privilege is to address this locate database access issue. plocate supports a mode in which updatedb is invoked with full root privileges, but the ownership of the central database is changed to root:plocate and file mode 0640. When plocate is installed as setgid-plocate then it is still allowed to access the central database. The program drops the special group credentials quickly again, right after opening the database. The program then ensures that the calling user will only be able to retrieve information about files that it is allowed to access based on its real credentials.

There is a minor security issue found in this approach. Since the plocate database does not contain metadata about the files it indexed, the plocate program needs to check the ownership of files in the file system at the time the search query runs. This is a sort of a TOCTOU (time-of-check time-of-use) race condition. There can be situations when the verification in plocate yields wrong results:

root# mkdir --mode=1777 /shared
root# mkdir --mode=0700 /shared/secret-dir
root# touch /shared/secret-dir/secret-file
root# updatedb

# root will be able to locate any files in secret-dir
root# locate /shared/se
/shared/secret-dir
/shared/secret-dir/secret-file

# non-root cannot locate the secret-file
user$ locate /shared/se
/shared/secret-dir

# now consider root deletes the secret-dir again
root# rm -rf /shared/secret-dir

# now the unprivileged user takes ownership of this path
user$ mkdir --mode=0755 /shared/secret-dir

# this only works before `updatedb` is called again, because then it will
# notice that secret-file no longer exists and delete it from the database.
#
# when the unprivileged user calls locate this time, the secret-file will show
# up, since the "secret-dir" is now controlled by the unprivileged caller.
user$ locate /shared/se
/shared/secret-dir
/shared/secret-dir/secret-file

This problem likely cannot be easily fixed in the plocate code, since it would require changing the database format radically, increasing database size as a result, only to fix an unlikely problem.

The information leak is minor and should rarely be exploitable. For this reason we left it up to the openSUSE plocate package maintainer whether the setgid-plocate approach should be used, or not.

5) Local Root Exploit in OpenStack’s non-production virtualbmc Project

By way of our efforts to monitor newly introduced systemd services in openSUSE Tumbleweed, the python-virtualbmc package caught our attention. The program allows to emulate a board management controller (BMC) interface for use with libvirt.

Part of the package is a daemon running with full root privileges, listening for ZeroMQ API requests on localhost. A number of unauthenticated API calls in this context raised our suspicions, which is why we scheduled a full review of this package. A closer look showed that the unauthenticated API calls were indeed problematic, even allowing for a full local root exploit.

We filed a detailed private bug report on LaunchPad for the OpenStack project, but had difficulties getting a response. After some weeks we reached out to an individual member of the OpenStack security team and learned from the reply that the virtualbmc project was not intended for production use at all, but is rather a utility intended for use in testing environments. This is also documented in the repository’s README, which was overlooked by us. As a result we filed a delete request for the python-virtualbmc package in openSUSE Tumbleweed, and the package has already been removed.

For completeness, a detailed report of the security issues in the virtualbmc daemon follows below.

Lack of Authorization and Input Validation in vbmcd

When the virtualbmc systemd service is started, then /usr/bin/vbmcd runs with full root privileges. It offers a ZeroMQ-based network API, listening on localhost port 50891 by default. Any local user in the system can talk to the daemon this way.

A simple request which can be sent to the daemon (in JSON format) is the following stop command, for example:

{
        "command": "stop",
        "port": 1234,
        "domain_names": ["../../home/myaccount/mydomain"],
}

The domain_name passed here will be used by the daemon to lookup a supposedly trusted per-domain configuration file, which is by default located in /root/.vbmc/<domain>/config. Since the daemon does not scrutinize the input domain_name, a local attacker can include directory components in the name, to trick the daemon into accessing an attacker-controlled configuration file.

In the context of the stop command used here, the daemon will try to update the domain’s configuration file in case a change of domain state is detected. The path for writing out the updated configuration file will be constructed using the domain_name found in the input configuration file. Thus the local attacker can place data like this into /home/myaccount/mydomain/config:

[VirtualBMC]
domain_name = ../../etc/sudoers.d
port = 1234
active = true
address = some
  evil stuff
  myaccount ALL=(ALL:ALL) NOPASSWD: ALL

The daemon will now believe that the domain’s state changed, because the input configuration file contains active = true, while the daemon was asked to stop the domain. This will trigger logic to write out an updated configuration file with the new state of the domain configuration. The logic for this is found in the _vbmc_enabled() member function.

Since the domain_name found in the crafted configuration file is set to ../../etc/sudoers.d, the daemon will write the new configuration file into /root/.vbmcd/../../etc/sudoers.d/config. To get an advantage from this, the attacker must get the daemon to write out at least one valid sudoers configuration line into the new configuration file.

The attacker has only a limited degree of freedom at this stage, because the daemon will write out the new configuration file via the Python configparser module and will only consider the [VirtualBMC] section as well as any of the configuration keys listed in the VBMC_OPTIONS list defined in the daemon’s code.

To help with the exploit, the configparser multiline syntax comes to the rescue: any lines following an assignment which are indented will be accepted as part of the configuration value. When writing the settings out to a new configuration file, these multiline settings will be preserved. This is put to use in the example above, which contains a final line myaccount ALL=.... This line will now appear along with the rest of the configuration data in /etc/sudoers.d/config.

As a result, when the attacker now invokes sudo su -, a couple of sudoers parsing errors will appear, but in the end, access is granted and a root shell will be obtained by the attacker.

This approach of using a sudoers drop-in configuration file is just one of the more obvious approaches that came to mind. There’s a lot of different ways to exploit this, however, for example by overwriting shell scripts or script snippets in /etc or /usr/bin and then waiting for a privileged process to run them. This would be even easier, because shell scripts have less strict syntax requirements compared to the sudoers configuration file. The effect would not be immediate, however, like in the sudoers approach.

Reproducer

We offer a Python script for download, which is a Proof-of-Concept (PoC) to reproduce the local root exploit in the context of an arbitrary unprivileged user on the system, when vbmcd is running with its default configuration. sudo needs to be installed, naturally, for the exploit to work.

Further Concerns

In general, the API offered by vbmcd on localhost is missing input sanitization and authorization. Authorization seems only to be performed indirectly via libvirt. In this context clients can also pass crafted libvirt_uri parameters, for example, which seem to make it possible to let the daemon connect to arbitrary URLs via SSH. There also is no isolation between different users’ domain configurations, e.g. the “stop” command used above can be issued for any domain configured by another user in the system.

To make this API safe, we believe there needs to be an ownership model for each domain’s configuration, a verification of the client’s credentials in some form (a UNIX domain socket would allow this more easily) and sanitization of all input parameters to avoid any unexpected side effects.

Since the daemon listens on an unprivileged port on localhost, other unprivileged users can try to bind to this port first and provide a fake vbmcd service. Since the API requests can also contain secret credentials, this would pose a major local information leak. For safe operation, the API would need to bind to a privileged port on localhost instead.

6) Revisit of the snapd Package Manager

In 2019 we received a request to add the snapd package manager to openSUSE, which involved a review of the setuid-root program snap-confine. At the time we were generally satisfied with the code quality and design of the program, but still found a few low to medium severity security issues and gave recommendations on how to improve the code in some spots. The packagers have meanwhile been busy with other topics and we never saw an updated openSUSE package containing the necessary changes, which is why we closed the related bugs after a period of inactivity.

In August we received a follow-up request for addition of an updated snapd package. We revisited the privileged components and again provided feedback to upstream. This time all remaining issues could be resolved and the new package has been allowed to become part of openSUSE Tumbleweed. We are happy to see these old efforts not going completely to waste, and welcome the possibility to use Snap packages on openSUSE Tumbleweed in the future.

7) Conclusion

Again we hope we’ve been able to give you some additional insight into our efforts to maintain the security of SUSE distributions and open source software. We are looking forward to the next edition of the spotlight series, which will be published in about three months from now.