Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable endpoint requiring low-privilege authentication; GET-based approval affects financial integrity only, with no confidentiality or availability impact warranting a non-N rating.
Primary rating from Vendor (vuldb).
CVSS VectorVendor: vuldb
Lifecycle Timeline
2DescriptionCVE.org
A vulnerability was determined in zhinianboke xianyu-auto-reply on Server. Affected by this vulnerability is an unknown functionality of the file /api/v1/payment/withdraw/review?action=approve. Executing a manipulation can lead to trusting http permission methods on the server side. The attack may be launched remotely. The exploit has been publicly disclosed and may be utilized. This patch is called 19fc3282a1bb78a05c34945c088525d20e081cbd. It is best practice to apply a patch to resolve this issue.
AnalysisAI
The payment withdrawal approval endpoint in xianyu-auto-reply executes state-changing financial approval actions in response to HTTP GET requests, violating the HTTP safe-method contract and enabling unintended approvals through automated link-prefetching clients. Any low-privileged authenticated user possessing a valid review token can approve withdrawal requests by issuing a GET to /api/v1/payment/withdraw/review?action=approve, and more critically, email clients or mail-security gateways that automatically prefetch URLs can trigger approvals silently when an administrator receives a notification email. A proof-of-concept has been publicly disclosed per CVSS 4.0 E:P; no CISA KEV listing or confirmed active exploitation was identified at time of analysis.
Technical ContextAI
xianyu-auto-reply is a FastAPI-based Python application (GitHub: zhinianboke/xianyu-auto-reply) providing automated reply and distribution management features, including a payment withdrawal review workflow. The vulnerability resides in backend-web/app/api/routes/payment.py at the /api/v1/payment/withdraw/review endpoint. CWE-650 (Trusting HTTP Permission Methods on the Server Side) describes the root cause: the server assigned business-critical, irreversible approval semantics to an HTTP GET handler, which RFC 7231 mandates be safe and idempotent. The fix in commit 19fc3282a1bb78a05c34945c088525d20e081cbd - explicitly commented in Chinese as 'Safety: GET requests do not directly change the review status, avoiding email prefetch/link scanner mis-triggering approval' - splits the flow so GET only validates the token and renders a confirmation page, while the actual approval is delegated to an explicit POST to /api/v1/payment/withdraw/approve. No CPE string was included in the input data.
RemediationAI
Apply upstream patch commit 19fc3282a1bb78a05c34945c088525d20e081cbd available at https://github.com/zhinianboke/xianyu-auto-reply/commit/19fc3282a1bb78a05c34945c088525d20e081cbd. No released tagged version has been independently confirmed to include this fix - users should verify the commit is present in their deployed branch. As a compensating control prior to patching, restrict network access to /api/v1/payment/withdraw/review to trusted internal IP ranges, preventing external mail security gateways and link scanners from reaching the endpoint; the trade-off is that remote administrator approval workflows will require VPN or equivalent access. Additionally, configuring email clients used by administrators to disable automatic link prefetching eliminates the passive exploitation path without affecting the application itself.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-44575
GHSA-3rf8-mgfc-9vfp