CVE-2026-44342: New API CSRF Account Binding Vulnerability

Technical summary

The vulnerability stems from improper HTTP method usage for state-changing operations. The endpoints GET /api/oauth/email/bind and GET /api/oauth/wechat/bind process account binding requests using GET, which violates REST principles and leaves them vulnerable to CSRF attacks. GET requests are cacheable, bookmarkable, and easily triggered via simple HTML navigation (image tags, redirects, etc.) without requiring explicit form submission. In security contexts where Session cookies carry SameSite=None or are otherwise sent cross-site, an unauthenticated attacker can trigger binding via forged requests. The fix involves moving these operations to POST (or PUT/PATCH) and implementing CSRF tokens—standard mitigations absent in the vulnerable code path.

Business impact

Successful exploitation allows attackers to hijack New API accounts by binding OAuth identities or email addresses under attacker control. Once bound, an attacker can use account recovery flows (password resets sent to the attacker's email or OAuth re-authentication) to gain full account access. For organizations using New API for AI model gateway orchestration or sensitive asset management, account compromise could lead to unauthorized access to LLM endpoints, API key theft, model fine-tuning abuse, or exposure of managed AI workflows. The attack requires user interaction, reducing blast radius but not eliminating risk in environments with high user volumes or where phishing campaigns target New API users.

Affected systems

New API versions prior to 0.12.0-alpha.1 are affected. The vulnerability is specific to the email and WeChat OAuth binding endpoints; other parts of the platform are not directly impacted unless they rely on the same code patterns. Organizations running New API for production LLM orchestration, internal AI asset management, or multi-tenant AI services should prioritize inventory of their deployment version.

Exploitability

The vulnerability is practically exploitable but not trivial. An attacker must craft a CSRF payload (typically an HTML page with an embedded link or image pointing to the vulnerable endpoint) and trick a logged-in New API user into visiting it—typically via phishing, social engineering, or malicious site injection. No special network position or authentication is required on the attacker side. However, modern browser security (SameSite cookie defaults in Chrome, Firefox, Safari) reduces the likelihood of cross-site cookie transmission, which may mitigate the issue in some configurations. The CVSS score of 5.3 (MEDIUM) reflects this balance: high integrity impact if successful, but moderate attack complexity and user interaction requirement.

Remediation

Upgrade New API to version 0.12.0-alpha.1 or later, which remedies the issue by converting the email and WeChat binding endpoints to POST requests and implementing proper CSRF token validation. Before upgrading, review your deployment's SameSite cookie policy and ensure it is set to 'Strict' or 'Lax' to reduce cross-site cookie leakage. If immediate patching is not possible, implement a Web Application Firewall (WAF) rule to block GET requests to /api/oauth/email/bind and /api/oauth/wechat/bind, forcing users to use only POST (though this requires client-side changes).

Patch guidance

Update New API to 0.12.0-alpha.1 or later. Since this is an alpha release, confirm stability in a staging environment before production deployment. Review release notes for any breaking changes or behavioral differences. Coordinate the upgrade with your API client applications to ensure they issue POST requests to the corrected endpoints; legacy clients using GET may fail after patching. Plan for a maintenance window if New API handles critical LLM request routing.

Detection guidance

Monitor HTTP logs for unusual GET requests to /api/oauth/email/bind and /api/oauth/wechat/bind, particularly those originating from unexpected referrers (cross-site requests). In Web Application Firewall or API gateway logs, look for patterns: same session, rapid binding operations, or binding requests from different IP addresses than normal user activity. Check New API audit logs for email or OAuth identity changes that do not correlate with user-initiated password resets or account settings changes. Implement alerting for account binding operations tied to authentication events.

Why prioritize this

Although marked MEDIUM severity, account binding vulnerabilities warrant relatively high prioritization because successful exploitation often serves as a stepping stone to full account takeover. In AI/LLM contexts, compromised accounts may provide access to fine-tuning capabilities, API quotas, or model inference endpoints. The fix is straightforward (upgrade to 0.12.0-alpha.1) and does not require architectural changes, making it a low-friction remediation. Prioritize this for any New API instance that supports multi-user access, integrations with external services, or OAuth federation.

Risk score, explained

The CVSS 3.1 score of 5.3 reflects: Network-based attack vector (AV:N), high attack complexity due to user interaction and cookie restrictions (AC:H), no privileges required (PR:N), user interaction required (UI:R), unchanged scope (S:U), no confidentiality impact (C:N), high integrity impact on account binding (I:H), and no availability impact (A:N). The score is elevated by the high integrity risk but tempered by the need for user interaction and moderate attack complexity. In practice, organizations handling sensitive models or multi-tenant AI services may assign higher internal risk due to business context.

Frequently asked questions