CVE-2025-47945 is a critical flaw (CVSS 9.1) in Donetick, the open-source task and chore manager. Before version 0.1.44, the JWT signing secret had a weak default value, which can let an attacker forge tokens and take over any account. Version 0.1.44 contains the patch. Upgrade, and make sure your deployment does not use a default secret.
What's affected
Per the CVE record and the GitHub advisory, Donetick versions before 0.1.44 are affected. Version 0.1.44 contains a patch.
The record files the problem under CWE-1188 (Insecure Default Initialization of Resource), CWE-453 (Insecure Default Variable Initialization). In plain terms, the application shipped with a default secret for signing login tokens, and left it to the administrator to change it.
The GitHub advisory adds that the issue affected both self-hosted installs and the project's official live instance. Anyone running a self-hosted copy who never changed the default is in the same position, whatever the version, until the secret is replaced.
The base vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N: reachable over the network, no privileges, no user interaction, with high impact on confidentiality and integrity and none on availability.
How to check if you're exposed
Find your Donetick version first. If you run the container image, check the tag in use:
docker ps --format '{{.Names}} {{.Image}}'
If the tag is below 0.1.44, upgrade. If you use a floating tag such as latest, pull the image again and confirm what version you now run in the application itself.
Then check your configuration for the token signing secret. The advisory describes the weakness as a weak default value, so look at whether your config file or environment sets its own long random value, or whether it relies on the shipped default. If you cannot tell, assume it is the default and replace it.
Last, think about who can reach the service. A Donetick instance that is only reachable inside a private network is a lower risk than one on a public address, but a forged token works from wherever the service is reachable.
What to do now
- Upgrade Donetick to 0.1.44 or later. The record and advisory name 0.1.44 as the fixed version.
- Set a long, random, unique token signing secret in your configuration, and do not reuse it anywhere else.
- Restart the service after the change. Tokens signed with the old secret should stop validating, so users will have to log in again.
- Review the user list for accounts you do not recognise, and review recent task or circle changes for activity nobody owns.
- If the service faces the internet and you cannot upgrade today, restrict access with a VPN, an allow list or an authenticating proxy.
- Add the project to your dependency or image inventory so the next release is noticed. You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your projects pull in the affected component.
Why it matters
A JSON Web Token is a signed note that says who you are. The server trusts a token only because it carries a valid signature made with a secret that only the server knows. If that secret is a default value that anyone can look up, then anyone can write a note that claims to be any user, and the server will accept it. That is why the record talks about full account takeover of any user.
The weakness classes here are insecure default initialization and the use of a default value for a security variable. The code can be perfectly correct and still be exposed, because the safe behaviour depends on a step the administrator may never take. The better design is to refuse to start with a default secret, or to generate a random one on first run.
It is not listed in the CISA Known Exploited Vulnerabilities catalog, and the record does not report exploitation in the wild. The score of 9.1 reflects how little is needed: no account, no click, just network access.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is changing the secret enough if I stay on an old version?
Changing the secret closes the forged token problem for that deployment, but the record names 0.1.44 as the patched version, so upgrade as well. Do both.
Do I need to log everyone out?
Replacing the signing secret makes tokens signed with the old one invalid, so users sign in again. That is the intended outcome after a possible compromise.
Sources
- NVD record for CVE-2025-47945
- Donetick GitHub security advisory GHSA-hjjg-vw4j-986x
- Donetick fix commit (listed in the record)
Last reviewed: 18 October 2026.