EUVD-2026-20641
GHSA-hqxq-hwqf-wg83
Severity by source
AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N
Lifecycle Timeline
4DescriptionGitHub Advisory
Summary
A transaction integrity flaw allows an authenticated tenant user to soft-delete synced non-manual transactions through the transaction update endpoint, despite the application explicitly blocking deletion of those transactions via the normal DELETE path. This bypass undermines the intended protection for imported transaction records and allows protected transactions to be hidden from normal views.
Details
The issue affects the transaction update path for synced transactions associated with non-manual links. The intended policy is clearly enforced in the DELETE handler: deletion of synced transactions for non-manual links is rejected with an error indicating that such transactions cannot be deleted.
However, the PUT update path still accepts a client-controlled full Transaction object and persists fields that should be server-managed, including deletedAt. The update logic appears to restrict only selected fields, which leaves deletedAt attacker-controllable.
Verified behavior on the same synced transaction showed:
DELETEwas denied with the expected protection error for non-manual linksPUTwith a user-supplieddeletedAtvalue succeeded and returned200 OK- a subsequent transaction list no longer showed the transaction
GETby transaction ID still returned the record withdeletedAtpopulated
This demonstrates a policy bypass: although the server explicitly defines synced transactions on non-manual links as non-deletable through the dedicated delete route, the same outcome can still be achieved through the update route by setting the soft-delete field directly.
The vulnerability is therefore not a simple UI inconsistency. It is a server-side authorization and integrity flaw caused by trusting a client-supplied full transaction object and failing to protect sensitive server-managed fields from modification.
PoC
The issue can be reproduced by identifying a synced transaction on a non-manual link, confirming that the normal DELETE route rejects deletion, then submitting an update request that sets the transaction’s deletedAt field. The transaction will then disappear from normal listing views even though direct retrieval still shows the record as soft-deleted.
Impact
- Type: Authorization bypass / integrity violation
- Who is impacted: Authenticated tenant users and any deployment relying on synced transaction immutability for non-manual links
- Security impact: Attackers can hide or effectively delete protected imported transactions that should not be deletable, compromising transaction history, bookkeeping integrity, and trust in audit-relevant server-managed fields
- Attack preconditions: The attacker must be authenticated and able to access a synced transaction within their own tenant/account scope
AnalysisAI
Monetr allows authenticated tenant users to soft-delete protected synced transactions through the PUT update endpoint by directly setting the deletedAt field, bypassing the explicit DELETE protection that prevents such operations. This authorization bypass compromises transaction history integrity and audit trail reliability for imported transactions that should be immutable. The vulnerability requires authentication and user interaction but enables attackers to hide critical financial records from normal views while the soft-deleted data remains accessible via direct retrieval, affecting any Monetr deployment relying on synced transaction immutability.
Technical ContextAI
Monetr is a Go-based personal finance application (pkg:go/github.com_monetr_monetr) that manages synced transactions imported from external financial institutions via non-manual links. The vulnerability stems from inconsistent field-level access control between two HTTP endpoints: the DELETE handler correctly enforces authorization by rejecting deletion of synced transactions on non-manual links with an explicit error, but the PUT update handler accepts a full client-controlled Transaction object and fails to filter sensitive server-managed fields before persistence. The deletedAt field, which should be server-controlled and immutable from the client perspective, is not included in the restricted field whitelist applied during updates. This represents a CWE-285 (Improper Authorization) vulnerability where the application enforces a policy in one code path but fails to enforce it consistently across a functionally equivalent operation, allowing attackers to circumvent the intended business logic through an alternative route.
RemediationAI
Upgrade Monetr to version v1.12.3 or later, which addresses the field-level authorization bypass by restricting client-controlled modification of server-managed fields including deletedAt. The patch enforces consistent authorization policy across both DELETE and PUT endpoints for synced transactions on non-manual links. Detailed advisory information is available at https://github.com/monetr/monetr/security/advisories/GHSA-hqxq-hwqf-wg83. No workarounds are available for earlier versions; upgrading is the only reliable remediation. Administrators should verify the upgrade by confirming the installed version matches v1.12.3 or later and should review transaction history logs to detect any unauthorized soft-deletes that may have occurred prior to patching.
Same weakness CWE-285 – Improper Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today