You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[SECURITY] - An attacker can write files with exact names to arbitrary locations on the filesystem #714
Xreader 4.6.3 (commit ef5a50d) passes the raw PDF attachment filename directly to g_file_get_child() when saving attachments via "Save Attachment As...". Since g_file_get_child() resolves ../ sequences, an attacker-controlled filename can escape the user-selected target directory and write files to arbitrary locations with the exact filename specified by the attacker — no random suffix.
This is the most critical of the attachment vulnerabilities, as it enables writing .desktop files (or any other file) with precise names to arbitrary locations, leading to arbitrary code execution.
Both the local and remote save paths use the unsanitized attachment name.
Steps to Reproduce
Generate a malicious PDF using the PoC script from the full report — the attachment is named ../Desktop/test.desktop and contains a valid .desktop entry that executes an arbitrary command
Open poc.pdf in xreader
In the sidebar, right-click the attachment and select "Save Attachment As..."
Select any directory (e.g., ~/Documents/)
test.desktop is written to ~/Desktop/ instead of the selected directory
Double-clicking the .desktop file executes the embedded command
Suggested Fix
Extract the basename before passing to g_file_get_child() in both code paths:
// line 7374-save_to=g_file_get_child(target_file, ev_attachment_get_name(attachment));
+gchar*basename=g_path_get_basename(ev_attachment_get_name(attachment));
+save_to=g_file_get_child(target_file, basename);
+g_free(basename);
// line 7400-dest_file=g_file_get_child(target_file, ev_attachment_get_name(attachment));
+gchar*basename=g_path_get_basename(ev_attachment_get_name(attachment));
+dest_file=g_file_get_child(target_file, basename);
+g_free(basename);
Impact
An attacker can write files with exact names to arbitrary locations on the filesystem. By writing a .desktop file to ~/Desktop/, arbitrary code execution is achieved when the user double-clicks it. The only user interaction required is opening the PDF, right-clicking the attachment, selecting "Save As", and choosing any directory.
Was this not already fixed with 4.6.4 with 50052ea?
I think No, commit 50052ea (released as 4.6.4) fixes a different vulnerability argument injection in ev_spawn (shell/ev-application.c). The 2 issues I reported are in backend/epub/epub-document.c, libdocument/ev-attachment.c, shell/ev-sidebar-attachments.c, and shell/ev-window.c. None of these files have been modified between ef5a50d (the commit my report was filed against) and tag 4.6.5. The reported vulnerabilities are still present in the current code.
Activity
yochananmarqos commentedon May 25, 2026
Was this not already fixed with 4.6.4 with 50052ea?
rodtvs commentedon May 31, 2026
I think No, commit 50052ea (released as 4.6.4) fixes a different vulnerability argument injection in ev_spawn (shell/ev-application.c). The 2 issues I reported are in backend/epub/epub-document.c, libdocument/ev-attachment.c, shell/ev-sidebar-attachments.c, and shell/ev-window.c. None of these files have been modified between ef5a50d (the commit my report was filed against) and tag 4.6.5. The reported vulnerabilities are still present in the current code.
yochananmarqos commentedon May 31, 2026
Oh, I was just going by this GNOME blog post.
clefebvre commentedon Sep 4, 2026
EPUB support was removed from Xreader and reimplemented in Xepub: https://github.com/xapp-project/xepub.
clefebvre commentedon Oct 6, 2026
Sorry, I closed this one by mistake while closing epub related issues.