Package Instance

Feathers has an open redirect in OAuth callback enables account takeover
The `redirect` query parameter is appended to the base origin without validation, allowing attackers to steal access tokens via URL authority injection. This leads to full account takeover, as the attacker obtains the victim's access token and can impersonate them.

The application constructs the final redirect URL by concatenating the base origin with the user-supplied `redirect` parameter:
```javascript
// https://github.com/feathersjs/feathers/blob/dove/packages/authentication-oauth/src/service.ts#L158C3-L176C4
const { redirect } = query;
...
session.redirect = redirect;

// https://github.com/feathersjs/feathers/blob/dove/packages/authentication-oauth/src/strategy.ts#L98
const redirectUrl = `${redirect}${queryRedirect}`;
```

Where:
- `redirect` = base origin from config (e.g., `https://target.com`)
- `queryRedirect` = user input from `?redirect=` parameter

This is exploitable when the `origins` array is configured and origin values do not end with `/`.  An attacker can supply `@attacker.com` as the redirect value results in `https://target.com@attacker.com#access_token=...`, where the browser interprets `attacker.com` as the host, leading to full account takeover.

**Credits**:  Abdelwahed Madani Yousfi (@vvxhid) / Edoardo Geraci (@b0-n0-b0) / Thomas Rinsma (@ThomasRinsma) From Codean Labs.

Feathers exposes internal headers via unencrypted session cookie
All HTTP request headers are stored in the session cookie, which is signed but not encrypted, exposing internal proxy/gateway headers to clients.

The OAuth service stores the complete headers object in the session:
```javascript
// https://github.com/feathersjs/feathers/blob/dove/packages/authentication-oauth/src/service.ts#L173
session.headers = headers;
```

The session is persisted using `cookie-session`, which base64-encodes the data. While the cookie is signed to prevent tampering, the contents are readable by anyone by simply decoding the base64 value.

Under specific deployment configurations (e.g., behind reverse proxies or API gateways), this can lead to exposure of sensitive internal infrastructure details such as API keys, service tokens, and internal IP addresses.

**Credits**:  Abdelwahed Madani Yousfi (@vvxhid) / Edoardo Geraci (@b0-n0-b0) / Thomas Rinsma (@ThomasRinsma) From Codean Labs.

Feathers has an origin validation bypass via prefix matching
The origin validation uses `startsWith()` for comparison, allowing attackers to bypass the check by registering a domain that shares a common prefix with an allowed origin.

The `getAllowedOrigin()` function checks if the Referer header starts with any allowed origin:
```javascript
// https://github.com/feathersjs/feathers/blob/dove/packages/authentication-oauth/src/strategy.ts#L75
const allowedOrigin = origins.find((current) => referer.toLowerCase().startsWith(current.toLowerCase()));
```

This comparison is insufficient as it only validates the prefix. This is exploitable when the `origins` array is configured and an attacker registers a domain starting with an allowed origin string (e.g., `https://target.com.attacker.com` bypasses `https://target.com`).

On its own, tokens are still redirected to a configured origin. However, in specific scenarios an attacker can initiate the OAuth flow from an unauthorized origin and exfiltrate tokens, achieving full account takeover.

**Credits**:  Abdelwahed Madani Yousfi (@vvxhid) / Edoardo Geraci (@b0-n0-b0) / Thomas Rinsma (@ThomasRinsma) From Codean Labs.