GLib plugs Windows app-launch argument injection flaw

GLib has fixed CVE-2026-102038, an argument-injection bug in how GWin32AppInfo launches applications from Windows registry command lines.

The old path substituted field codes such as %f and %u, shell-quoted some of those values, rewrote every backslash to a slash, then split the result with POSIX-style argument parsing. That slash rewrite undid the escaping shell quoting had added around apostrophes, so a crafted name like x' --injected 'z.txt could become extra arguments. Unquoted field codes also broke any path that contained spaces.

Those rules were the wrong model for Windows. The fix drops the shell round trip. Registry command lines are now split the way the Microsoft C runtime parses arguments (the same rules GLib already uses when spawning), and each field code is expanded inside the argument that contains it. Values are inserted as-is: they are not re-quoted or re-parsed, backslashes stay backslashes, and a single field code cannot add, split, or join arguments. Standalone multi-value codes such as %F or %* still expand to one argument per item; inside a larger argument their values are joined with spaces.

Which file or URI each code receives is unchanged. The change ships with expanded tests covering spaces, apostrophes, quotes, trailing backslashes, and the cases that triggered the CVE. Anyone using GLib-based launchers on Windows for untrusted paths or URIs should take the update.