Feathersjs is a popular JavaScript and TypeScript framework for building web APIs and real-time applications. In versions prior to 5.0.40, the framework's origin validation mechanism is flawed due to the use of the startsWith() method to verify if the Referer header matches any allowed origin. This method only checks if the Referer begins with an allowed origin string, which is insufficient because an attacker can register a malicious domain that prefixes the allowed origin string (for example, https://target.com.attacker.com). This bypasses the origin validation check, allowing the attacker to initiate OAuth authentication flows from unauthorized origins. While tokens are still redirected to configured origins, in certain scenarios this flaw enables attackers to exfiltrate OAuth tokens, resulting in full account takeover. The vulnerability is categorized under CWE-346 (Origin Validation Error) and has a CVSS 4.0 score of 7.6, indicating high severity. Exploitation requires user interaction but no privileges or authentication. The issue was publicly disclosed and fixed in Feathersjs version 5.0.40. No known exploits are currently reported in the wild.

This vulnerability poses a significant risk to organizations using Feathersjs versions below 5.0.40, especially those implementing OAuth authentication flows. Successful exploitation can lead to unauthorized token exfiltration and full account takeover, compromising user accounts and potentially exposing sensitive data. The flaw undermines the integrity of origin validation, a critical security control in web authentication. Organizations relying on Feathersjs for API and real-time application development may face data breaches, unauthorized access, and reputational damage. The attack requires user interaction but no prior authentication, broadening the scope of potential victims. Given Feathersjs's adoption in various industries, the impact could be widespread, affecting both enterprise and consumer-facing applications.

The primary mitigation is to upgrade Feathersjs to version 5.0.40 or later, where the origin validation logic has been corrected. Until upgrading is possible, organizations should implement stricter origin validation mechanisms that do not rely on prefix matching, such as exact string comparison or using standardized libraries for origin checks. Reviewing and restricting OAuth redirect URIs and origins to trusted domains is critical. Additionally, monitoring OAuth flows for anomalous origin headers and implementing multi-factor authentication can reduce risk. Developers should audit their applications for similar origin validation patterns and avoid using startsWith() or similar prefix-based checks for security-critical validations. Security teams should also educate users about phishing risks that could trigger malicious OAuth flows.