This page looks best with JavaScript enabled

Security issue in Parcellite <= 1.2.1

 ·   ·  ☕ 5 min read

Parcellite clipboard manager might cause your copied secrets to be stored in the plain-text form in the system logs.


I am an avid user of clipboard managers. In fact, I cannot image how I could stop using that feature (and how can people live without it ;-) ). An ability to be able to refer to the previously copied text entries is a productivity booster in many cases. Unfortunately, modern Linux desktop environments complicate the thing (precisely Wayland - a “new” display server protocol), ironically, due to the security concerns, not providing any sensible alternative.

Some time ago, I was experimenting with some alternative clipboard managers. Parcellite was one of them and I have discovered not a very pleasant behavior.


parcellite 1.2.1 on Fedora (tested with F34 and parcellite-1.2.1-6.fc34.x86_64) is by default automatically started using a .desktop file. That result in having it caught by the journal systemd daemon and the output (stdout and stderr) is in a default configuration kept in the journal files. It can be:

… parcellite-startup.desktop[5354]: xdotool:'/bin/sh -c ‘xdotool mousedown 2 && xdotool mouseup 2’’
… foobar parcellite-startup.desktop[5354]: text:‘xxx’

where 'xxx' can be anything copied by an user, including user’s passwords and API keys. The entries are user accessible (via journalctl), so every (potentially
malicious) application could read it. The old journal files - depending on the system configuration - can be kept for months (or longer), so systems with an unencrypted hard disc provide also an alternative vector of attack.

The output is generated in that place :

cmd = g_strconcat("/bin/sh -c 'xdotool ", action, NULL);

which was added as an enhanced debug statement back in 2013 . This suggests that versions 1.1.7 to 1.2.1 can be affected.

That behavior does not require persisting clipboard entries across system restarts (which generates similar security risk and is disabled by default).

As the aforementioned .desktop file is provided by the upstream project, the other Linux distributions using it to automatically start Parcellite on user log in most likely are also affected.


Upgrade to 1.2.2 (once released) or to the patched versions of 1.2.1 if available in your distribution repository.

As a workaround, disable auto start for Parcellite using the .desktop file and run it manually.

Affected systems/users

The issue can only affect desktop users using Parcellite 1.1.7 to 1.2.1 (1.2.2 with the fix is not yet released at the time of publishing that advisory) on X.Org Server (Parcellite does not work with Wayland).

The problem was originally reproduced with Fedora 34 (the newest version at the time of discovery), but probably the majority of other distros using systemd with the modern journal are also affected. Please let me know (via mail or in comments) if your distro is affected and I will update that section.

If unsure, copy some text into clipboard and check journalctl -u parcellite-startup.desktop for the copied value. If found, the system is affected.

Dealing with (potentially) compromised credentials

It is best to roll/change all the credentials (and other secret) copied into a clipboard when Parcellite was running. The journalctl -u -ball parcellite-startup.desktop command might be useful.

If changing the secrets is problematic or not possible (e.g. your SSN or your credit card number), it is possible to:

  • remove the affected journal files
  • rewrite the history in the affected journal files (which is not easy, but is possible )


A legend: TPM - the Parcellite maintainer.

  • 20210919 - me - an initial email to TPM
  • 20210921 - me - another email to TPM
  • 20210927 - TPM - a response suggesting to create a regular GitHub issue
  • 20210927 - me - information to TPM what the issue is and how could be fixed + a suggestion to create a security advisory using GitHub
  • 20211005 - TPM - the issue fixed in master
  • 20211011 - me - a question to TPM about the new version
  • 20211020 - me - another question to TPM
  • 20211028 - me - yet another question to TPM
  • 20220626 - me - information to TPM about my intention to reveal the issue anyway (as the new version is not yet released after 9 months)
  • 20220628 - me - release the vulnerability description on my blog and in the public issue on GitHub
  • 20230311 - TPM - release Parcellite 1.2.2, containing the fix

Further actions

  1. Convince the Parcellite author to finally release 1.2.2.
  2. Notify the package maintainers to upgrade the version (or apply a patch )
  3. Request for the CVE number - it would be good to be obtained by the project author, possibly using the mechanism provided by GitHub - UPDATED. I was unable to get one :-(.

Updated 2020-05-21. Mention recent Parcellite 1.2.2 release, rename TPA to TPM + update the “further actions”.


I am just an off-the-clock security researcher, but having some (potentially) security-related problems (accidentally) spotted, I like to have it reported and fixed to do not expose other people and systems at risk. Thanks to my previous findings the users of (among others) Travis and Gradle can sleep (slightly more) peacefully :-).

Lead photo by tsmr, published in Pixabay, Pixabay License.
Share on

Marcin Zajączkowski
Marcin Zajączkowski
Software Craftsman & Software Architect
An experienced architect aiming for high quality solutions. Very engaged in evangelising Software Craftsmanship, Clean Code and Test-Driven Development as a conference speaker and a trainer. A specialist in Continuous Delivery and Continuous Inspection of Code Quality. An enthusiast of Reactive Systems and broadly defined concurrency.

Besides, open source author and contributor, a proud Linux user.

Don't want to use the Utterance bot? Comments can be also placed directly on GitHub.
What's on this Page