Vulnerabilities in various GTK-based PDF readers [LWN.net]

LWN<br>.net<br>News from the source

Content Weekly Edition<br>Archives<br>Search<br>Kernel<br>Security<br>Events calendar<br>Unread comments

LWN FAQ<br>Write for us

User:<br>Password: |

Log in /<br>Subscribe /<br>Register

Vulnerabilities in various GTK-based PDF readers

[Posted May 21, 2026 by corbet]

Michael Catanzaro has disclosed a<br>command-injection vulnerability affecting a number of GTK-based PDF<br>readers; exploits included:

They contain a script for building malicious polyglot PDFs that are<br>simultaneously both valid PDF files and also valid ELF<br>binaries. When the user opens the PDF in the PDF viewer and clicks<br>on a malicious link embedded in the PDF, the PDF abuses the command<br>injection vulnerability to load itself as a GTK module using the<br>`--gtk-module` command line flag. It can then execute arbitrary<br>code via its library constructor. That flag was removed in GTK 4,<br>which is why the vulnerability is much less serious for Papers than<br>it is for Evince, Atril, and Xreader.

to post comments

A careful programmer...

Posted May 22, 2026 3:56 UTC (Fri)<br>by ccchips (subscriber, #3222)<br>[Link]

should be able to use an AI to suggest fixes. A not-so-careful programmer could allow the AI to fix the problem itself and make mistakes!

A hurdle for the attacker?

Posted May 22, 2026 5:56 UTC (Fri)<br>by rrolls (subscriber, #151126)<br>[Link] (3 responses)

While I don't want to understate the severity of this flaw, I think it's worth pointing out something, if I'm reading the writeup correctly: the malicious PDF has to contain its own absolute path for the exploit to work.

That would usually mean having to guess/know the victim's username if it's going to be delivered via a browser download (as it'd likely end up in /home/username/Downloads), and any delivery that gives it a random temp name will not work out for obvious reasons. Likely still very useful for spear phishing, but perhaps we won't be seeing this one used for indiscriminate opportunistic attacks.

A hurdle for the attacker?

Posted May 22, 2026 6:06 UTC (Fri)<br>by josh (subscriber, #17465)<br>[Link]

Wouldn't have to be full spearphishing. If you know the user's name, or GitHub handle, or similar information, you could guess some likely possibilities for their local username. Many sites might have enough information to guess that.

"Try my fun tool to generate artwork in a PDF. Create an account to try the advanced features."

A hurdle for the attacker?

Posted May 22, 2026 8:14 UTC (Fri)<br>by cjwatson (subscriber, #7322)<br>[Link]

Do any of the PDF readers keep a file descriptor open on the PDF? If so, perhaps /proc/self/fd/... would also work.

A hurdle for the attacker?

Posted May 22, 2026 14:02 UTC (Fri)<br>by mcatanzaro (subscriber, #93033)<br>[Link]

Unfortunately that's the first version of the exploit. The follow-up version removes that requirement using %f, which works because the command line is actually processed as a desktop file Exec line.

With hindsight, it was a code smell anyway

Posted May 22, 2026 6:34 UTC (Fri)<br>by epa (subscriber, #39769)<br>[Link] (2 responses)

The exploit is ingenious but an audit of the code base, by hand or perhaps with some simple heuristics, would surely have spotted this:

g_string_append_printf (cmd, " --page-label=%s",<br>ev_link_dest_get_page_label (dest)); // unquoted

String pasting like that should always be protected by paranoia about the characters contained (in a scripting language, I would make a regular expression matching known safe strings), and that it’s obviously constructing a shell command line is an even bigger red flag.

Perhaps it would make more sense to run the AI over the codebase looking for this kind of problem: code which is wrong in principle, and file bugs for that. The code could be quietly tightened up over a few months. Only if the project refuses to fix the bug (and it is a bug, anyway, if a filename containing shell characters does something weird) would it be necessary to demonstrate an exploit.

With hindsight, it was a code smell anyway

Posted May 22, 2026 6:37 UTC (Fri)<br>by epa (subscriber, #39769)<br>[Link]

P.S. I do take the point that with widely accessible LLMs there is not much point in embargoes. Someone else could find the same exploit. I guess what I’m saying is that all of these code smells ought to be fixed, not just those for which we have managed to find an exploit so far.

With hindsight, it was a code smell anyway

Posted May 22, 2026 16:49 UTC (Fri)<br>by NYKevin (subscriber, #129325)<br>[Link]

I would go further. There is way too much use of the shell to do things that you could just as easily do by hand. In my book, there are only two legitimate reasons to invoke the shell:

* You are implementing a launcher or the like, and passing a user-input command line directly to the shell with little or no modification.

* You are executing a shell script (possibly one that you wrote), and that shell script has gone through the usual linters (shellcheck and...