CVE-2026-39901: 
vulnerability analysis and mitigation

CVE-2026-39901 is an improper authorization vulnerability in monetr, an open-source personal finance application, that allows authenticated tenant users to soft-delete synced non-manual transactions via the transaction update (PUT) endpoint — bypassing the explicit deletion protection enforced on the DELETE route. The vulnerability affects monetr versions up to and including v1.12.2, and was patched in v1.12.3. It was published on April 7–8, 2026, with the GitHub Security Advisory (GHSA-hqxq-hwqf-wg83) assigned by elliotcourant. The CVSS v3.1 base score is 5.7 (Medium) (Github Advisory, monetr Advisory).

The root cause is classified as CWE-285 (Improper Authorization): the PUT transaction update endpoint accepts a full client-controlled Transaction object and persists server-managed fields — including deletedAt — without validating or stripping them. While the DELETE handler correctly rejects deletion of synced transactions on non-manual links with an explicit error, the PUT handler's field restriction logic is incomplete, leaving deletedAt attacker-controllable. An authenticated user can submit a PUT request with a populated deletedAt timestamp, causing the transaction to be soft-deleted and hidden from normal listing views, even though a direct GET by transaction ID still returns the record with deletedAt set. The attack requires network access, low privileges (authenticated user), and user interaction, with low attack complexity (Github Advisory, monetr Advisory).

Successful exploitation allows an authenticated attacker to effectively hide or soft-delete imported financial transaction records that are explicitly protected from deletion, compromising transaction history, bookkeeping integrity, and the reliability of audit-relevant data. There is no confidentiality or availability impact — the vulnerability is limited to integrity, specifically the unauthorized modification of server-managed fields. Deployments relying on synced transaction immutability for compliance, auditing, or financial record-keeping are most at risk (Github Advisory).

No public exploit code or weaponized tooling has been identified for this vulnerability. The EPSS score is approximately 0.01% (1st percentile), indicating a very low probability of exploitation in the wild within 30 days. There is no evidence of in-the-wild exploitation, no threat actor attribution, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an authenticated session within the target tenant's scope, limiting the attacker pool to insiders or compromised accounts (Github Advisory).

1. Authenticate: Log in to a monetr instance as a valid tenant user with access to at least one synced (non-manual link) transaction.
2. Identify a protected transaction: Browse or query the transaction list to locate a synced transaction associated with a non-manual bank link.
3. Confirm DELETE is blocked: Attempt to delete the transaction via the standard DELETE /api/transactions/{transactionId} endpoint and confirm it returns an error indicating the transaction cannot be deleted.
4. Craft a malicious PUT request: Construct a PUT /api/transactions/{transactionId} request with the full transaction object in the body, adding or modifying the deletedAt field to a valid timestamp (e.g., "deletedAt": "2026-04-07T00:00:00Z").
5. Submit the request: Send the PUT request; the server returns 200 OK and persists the deletedAt value.
6. Verify soft-deletion: Confirm the transaction no longer appears in normal transaction listing views, effectively hiding it from standard financial reports and audit views, while a direct GET /api/transactions/{transactionId} still returns the record with deletedAt populated (monetr Advisory).

• Network: Unexpected PUT requests to transaction update API endpoints (e.g., /api/transactions/{id}) containing a deletedAt field in the request body, particularly for transactions on non-manual bank links.
• Logs: API access logs showing PUT requests to transaction endpoints returning 200 OK for transactions that subsequently disappear from listing views; absence of corresponding DELETE requests for the same transaction IDs.
• Application Behavior: Discrepancy between transaction count in list views and direct GET lookups by ID; transactions retrievable by ID with a non-null deletedAt field that were not deleted through the normal DELETE workflow.
• Database: Synced transaction records with a populated deletedAt timestamp that have no corresponding deletion audit log entry or DELETE API call in server logs (monetr Advisory).

Upgrade monetr to version v1.12.3 or later, which includes a fix that prevents unauthorized fields (including deletedAt) from being modified via the PUT transaction update API. The fix was released on April 7, 2026, and is described in the release notes as correcting the ability to PUT unauthorized fields. No configuration-based workaround is documented; upgrading is the only recommended remediation (monetr Release, Github Advisory).

The vulnerability was reported by security researchers QiaoNPC and Across-Verticals-Malaysia, with remediation review by th3fallen and development by elliotcourant (the project maintainer). The advisory was published quietly with no notable broader media coverage or significant social media discussion, consistent with the moderate severity and limited scope of the affected software (monetr Advisory).