Xianyu Auto Reply Fix CVE-2026-118691

Three concrete prerequisites must hold: (1) the POST /send-message endpoint is network-reachable; (2) the target instance is running a pre-patch version (≤2.0.7) where the QQ/API send secret is unset or left at one of the published default/test values ('xianyu_qq_reply_2024', 'xianyu_api_secret_2024', 'zhinina_test_key'), since the vulnerable code fell back to the hard-coded API_SECRET_KEY when no secret was configured; and (3) the attacker must know a valid cookie_id for the specific merchant account they want to impersonate - this account-specific identifier is the AT:P requirement and is the main factor limiting mass exploitation. Impact is limited to sending messages (integrity) from the merchant to buyers; no data is read and no code is executed. The fix disables the endpoint by default and additionally requires the owning user's login credential (HTTP 401 if missing/invalid, 403 if the account is not owned by the caller), so patched/properly-configured deployments are not exploitable this way.

This is a genuine but medium-tier issue, not a top-priority emergency. The input CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) scores 6.3 and shows integrity-only impact (VI:L) with no confidentiality or availability effect - consistent with the description, which is about sending spoofed messages, not code execution or data theft. The PR:N reflects that authentication is effectively defeated by publicly known hard-coded default API secrets (confirmed in the source: 'xianyu_qq_reply_2024', 'xianyu_api_secret_2024', 'zhinina_test_key'), while AT:P reflects a real prerequisite: the attacker must supply a valid cookie_id belonging to the target merchant account. No EPSS score and no CISA KEV status were provided, and the input does not confirm working public exploit code, so there is no evidence of active or widespread exploitation. The vuln.today decision label is 'this_month' (not 'act_now'/'emergency'), aligning with a patch-promptly-but-not-drop-everything posture. The dominant risk driver is the trivially public default secret combined with a missing authorization check (CWE-1188); the main mitigating factors are the limited integrity-only impact and the obscure, small-footprint nature of the affected product.

An attacker who learns or enumerates a target merchant's cookie_id sends an unauthenticated POST /send-message request using the publicly known hard-coded api_key, causing the server to send arbitrary Xianyu messages to that merchant's buyers from the merchant's account - useful for scams, phishing, or reputation damage. The input does not confirm working public exploit code, but the default secrets are published in the project source, so reproduction is straightforward for anyone with a valid target cookie_id.