CVE-2026-118691 in xianyu-auto-reply-fix
Summary
by MITRE • 10/28/2026
xianyu-auto-reply-fix through 2.0.7 contains a missing authorization vulnerability in the POST /send-message endpoint that allows unauthenticated attackers to send messages from other users' accounts using publicly known default API secrets. Attackers can supply the hard-coded api_key and another user's cookie_id, plus chosen chat_id, to_user_id and message values, to send arbitrary Xianyu messages to buyers from that merchant account.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in xianyu-auto-reply-fix versions through 2.0.7 represents a critical failure in access control mechanisms within the application's messaging infrastructure. Specifically, the POST /send-message endpoint lacks proper authorization checks, allowing any actor with network connectivity to interact with this functionality without valid authentication credentials for the target user account. This flaw is compounded by the use of hard-coded default API secrets that are publicly known or easily discoverable, which serves as a weak form of authentication that can be trivially bypassed. The combination of missing authorization and predictable credentialing creates an environment where unauthenticated attackers can fully impersonate legitimate merchants on the Xianyu platform.
From a technical perspective, the exploitation vector relies on constructing specific HTTP POST requests to the vulnerable endpoint. An attacker supplies three key components: the hard-coded api_key associated with the application's default configuration, and two identifiers belonging to a victim merchant—the cookie_id which typically maintains session state or identifies the user context, along with the chat_id that specifies the conversation thread. By also providing arbitrary values for the to_user_id field indicating the recipient of the message and the message content itself, the attacker can inject text into any active buyer-seller interaction associated with the compromised merchant account. The system processes these requests because it validates the presence of a valid api_key but fails to verify that this key is being used by an authorized entity for the specific user context defined in the cookie_id or chat parameters.
The operational impact of this vulnerability is severe, as it enables direct compromise of business integrity and customer trust on the Xianyu marketplace. Attackers can send arbitrary messages from a merchant's account to buyers, which facilitates phishing campaigns where fraudulent offers are presented under the guise of legitimate commerce. This could involve directing users to malicious external websites for credential harvesting or malware distribution. Furthermore, attackers may use this capability to spread spam, conduct social engineering attacks by offering fake discounts or products, or damage the reputation of the affected merchant through inappropriate or defamatory communications sent to their customer base. The ability to send messages from multiple accounts simultaneously using different cookie_ids allows for large-scale abuse campaigns that are difficult to trace back to a single source if proper logging and rate limiting are not in place.
This vulnerability aligns with CWE-287, which describes Improper Authentication, specifically the failure to verify identity before granting access to resources. It also maps closely to CWE-306, Missing Authorization Check, as the application does not enforce that the authenticated entity (via api_key) has permission to perform actions on behalf of the specified user context. In terms of offensive security frameworks, this behavior is consistent with MITRE ATT&CK technique T1584.002, Compromise Accounts via Default Credentials, and can be leveraged for lateral movement within the platform's ecosystem if multiple merchant accounts are targeted to expand the attack surface or amplify spam distribution.
Mitigation strategies must address both the authentication weakness and the authorization gap immediately. The most critical step is to remove all hard-coded default API secrets from the application codebase and enforce unique, randomly generated credentials for each deployment instance that cannot be guessed by external actors. Additionally, strict access control checks must be implemented on the POST /send-message endpoint to ensure that the api_key presented in a request corresponds strictly to the user identity associated with the provided cookie_id or chat context. Input validation should also verify that the sender of the message is authorized to act as the merchant identified by the session data. Implementing multi-factor authentication for administrative actions and enforcing rate limiting on messaging endpoints can further reduce the risk of automated abuse while these core architectural flaws are remediated in a subsequent software update.