SUMMARY DBus generated notifications containing HTML are not escaped by default by Plasma, allowing for arbitrary HTML injection. For instance an advocate could generate an event, where a notification containing ` <img src="file:///dev/random"/>` is displayed to the user, resulting in rendering an infinite file, eventually filling up all RAM. Please see: * https://gitlab.gnome.org/GNOME/glib/-/issues/3720 * https://dev.gajim.org/gajim/gajim/-/issues/12349 STEPS TO REPRODUCE 1. pip install https://github.com/phuhl/notify-send.py for instance 2. run ``` notify-send.py 'Title: <img src="file:///absolute/path/to/any/local/image.png">' 'Body: <img src="file:///absolute/path/to/any/local/image.png">' ``` OBSERVED RESULT The title is escaped, the body shows a picture. EXPECTED RESULT Everything is escaped. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 42 KDE Plasma Version: 6.4.2 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 Graphics Platform: Wayland
Rendering some tags is defined expected behaviour. See https://specifications.freedesktop.org/notification-spec/1.3/markup.html We escape other tags, we don't allow arbitrary HTML injection. As far as I am aware we are compliant with that spec, please let me know if not. The issue with opening /dev/urandom is indeed valid.
> Rendering some tags is defined expected behaviour. See > https://specifications.freedesktop.org/notification-spec/1.3/markup.html > We escape other tags, we don't allow arbitrary HTML injection. That's great, I will rephrase the title. ---- > As far as I am aware we are compliant with that spec, please let me know if not. I think GLib maintainer Philip Withnall has posted a qualified answer https://gitlab.gnome.org/GNOME/glib/-/issues/3720#note_2491853 > Fundamentally I think this is a problem with the xdg notification specification: > * In the top-level ‘Markup’ section it says the notification server should filter out > markup tags if it doesn’t support them, which suggests the client > should be able to unconditionally send markup. > * In the capabilities table, however, it says that the client > should strip out markup if the server doesn’t advertise the body-markup capability. > Those two statements are slightly contradictory, > although it would be possible to get them both to work. > (...) I guess body-markup is advertised and therefor clients are free to unconditionally send markup in case of Plasma, correct? ---- > The issue with opening /dev/urandom is indeed valid. Quoting from above mentioned comment: > If a server implementation reads an image without imposing some kind of size limit on what it reads, > that’s a server bug. Yes, this is then hopefully the only real threat here.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5667
Git commit fe2d07b21403d20202514a5e5860698d52610da3 by David Edmundson. Committed on 23/09/2025 at 12:50. Pushed by davidedmundson into branch 'master'. Sanitize images in notifications Notifications are allowed to show local URLs. It's possible to break plasma by loading an image with a URL of file:///dev/urandom. This could be sent from a remote source; applications emitting notifications should sanitize their input, but we shouldn't solely rely on that. This adds a few extra checks that the image is a valid local file. Timing attacks are still possible, but only with locally running code, so not something to be concerned with. M +20 -3 libnotificationmanager/autotests/notifications_test.cpp M +21 -1 libnotificationmanager/notification.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/fe2d07b21403d20202514a5e5860698d52610da3
Git commit b21323c647ef263b150096965ca4ab934b32aa0b by Nate Graham, on behalf of David Edmundson. Committed on 26/09/2025 at 20:44. Pushed by ngraham into branch 'Plasma/6.5'. Sanitize images in notifications Notifications are allowed to show local URLs. It's possible to break plasma by loading an image with a URL of file:///dev/urandom. This could be sent from a remote source; applications emitting notifications should sanitize their input, but we shouldn't solely rely on that. This adds a few extra checks that the image is a valid local file. Timing attacks are still possible, but only with locally running code, so not something to be concerned with. (cherry picked from commit fe2d07b21403d20202514a5e5860698d52610da3) 3cd7bb2f Sanitize images in notifications Co-authored-by: David Edmundson <kde@davidedmundson.co.uk> M +20 -3 libnotificationmanager/autotests/notifications_test.cpp M +21 -1 libnotificationmanager/notification.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/b21323c647ef263b150096965ca4ab934b32aa0b
Git commit b91489b1628fed1efc242ed5524253176d461d39 by David Edmundson, on behalf of Nate Graham. Committed on 29/09/2025 at 15:12. Pushed by ngraham into branch 'Plasma/6.4'. Sanitize images in notifications Notifications are allowed to show local URLs. It's possible to break plasma by loading an image with a URL of file:///dev/urandom. This could be sent from a remote source; applications emitting notifications should sanitize their input, but we shouldn't solely rely on that. This adds a few extra checks that the image is a valid local file. Timing attacks are still possible, but only with locally running code, so not something to be concerned with. (cherry picked from commit fe2d07b21403d20202514a5e5860698d52610da3) 3cd7bb2f Sanitize images in notifications Co-authored-by: David Edmundson <kde@davidedmundson.co.uk> M +20 -3 libnotificationmanager/autotests/notifications_test.cpp M +21 -1 libnotificationmanager/notification.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/b91489b1628fed1efc242ed5524253176d461d39