NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
MEDIUM severity

monetr: Protected Transactions Deletable via PUTGHSA-hqxq-hwqf-wg83

MEDIUM

GHSA-hqxq-hwqf-wg83 is a medium-severity (CVSS 5.7) CWE-285 vulnerability in github.com/monetr/monetr. A fix is available for github.com/monetr/monetr — see the affected versions and patch details below.

Also known asCVE-2026-39901GO-2026-5434
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-hqxq-hwqf-wg83.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk+0.01%
Lower risk than most CVEs23th percentile — riskier than 23% of all scored CVEsHighest risk
0.00%0.28%0.55%0.83%0.0%0.3%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected
🐹github.com/monetr/monetr

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

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:

  • DELETE was denied with the expected protection error for non-manual links
  • PUT with a user-supplied deletedAt value succeeded and returned 200 OK
  • a subsequent transaction list no longer showed the transaction
  • GET by transaction ID still returned the record with deletedAt populated

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

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/monetr/monetrall versions1.12.3go get github.com/monetr/monetr@v1.12.3

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/monetr/monetr, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/monetr/monetr to 1.12.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hqxq-hwqf-wg83 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

### 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: del
O3 Security · Impact-Aware SCA

Is GHSA-hqxq-hwqf-wg83 in your dependencies?

Find it across Go, including transitive dependencies.

Scan my dependencies How O3 SCA works
monetr: Protected Transactions Deletable via PUT