# HTTP Connection Contamination

> How to test for HTTP connection contamination vulnerabilities in web applications. Use this skill whenever you need to audit HTTP/2+ connection coalescing, test reverse proxy routing, investigate potential security issues with wildcard TLS certificates, or assess shared infrastructure risks. Make sure to use this skill when you mention HTTP/2, HTTP/3, connection coalescing, reverse proxy misconfiguration, wildcard certificates, or any scenario involving multiple subdomains on shared infrastructure.

- Skill: `abelrguezr/http-connection-contamination` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add abelrguezr/http-connection-contamination`
- Raw SKILL.md: https://api.skillmd.com/api/skills/abelrguezr/http-connection-contamination/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: abelrguezr (https://skillmd.com/u/abelrguezr)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/abelrguezr/http-connection-contamination

---


# HTTP Connection Contamination Testing

This skill helps you identify and test for HTTP connection contamination vulnerabilities, where browsers reuse HTTP/2+ connections across different websites through connection coalescing, potentially causing request misrouting in reverse proxies.

## Understanding the Vulnerability

### What is HTTP Connection Coalescing?

Web browsers can reuse a single HTTP/2+ connection for different websites when:
- They share the same IP address
- They have a common TLS certificate (e.g., wildcard certificate like `*.example.com`)

### The Attack Vector

When combined with **first-request routing** in reverse proxies, this can cause:
- Subsequent requests to be directed to the back-end determined by the first request
- Security vulnerabilities like XSS, information disclosure, or authentication bypass
- Requests to `secure.example.com` being wrongly processed by a different back-end (e.g., WordPress)

### Why HTTP/3 Makes This Worse

HTTP/3 proposals relax the IP address match requirement, potentially broadening the attack surface without needing a MITM attack.

## Detection and Testing

### Step 1: Identify Potential Targets

Look for these conditions:
1. Multiple subdomains on the same IP address
2. Wildcard TLS certificates (`*.example.com`)
3. Reverse proxy infrastructure (nginx, Apache, HAProxy, etc.)
4. Different applications behind the same proxy

### Step 2: Check for Connection Coalescing

Use Chrome's Network tab or Wireshark to observe if requests to different subdomains share the same connection.

### Step 3: Test for First-Request Routing

Run the connection contamination test to see if requests get misrouted.

## Testing Scripts

### Basic Connection Contamination Test

Use the `test-connection-coalescing.js` script to test if two subdomains share a connection:

```bash
node test-connection-coalescing.js --subdomain1 sub1.example.com --subdomain2 sub2.example.com
```

This script:
1. Makes a request to the first subdomain
2. Immediately makes a request to the second subdomain
3. Reports whether connection coalescing occurred

### Advanced Testing with curl

For manual testing, use curl with connection reuse:

```bash
# First request to establish connection
curl -v --http2 https://sub1.example.com/

# Second request on same connection (if coalescing works)
curl -v --http2 --keepalive-time 30 https://sub2.example.com/
```

### Automated Detection Script

Use `detect-contamination.sh` to automate the detection process:

```bash
./detect-contamination.sh --domain example.com --subdomains sub1 sub2 sub3
```

This script:
1. Checks if subdomains share IP addresses
2. Verifies TLS certificate coverage
3. Tests for connection coalescing
4. Reports potential contamination vectors

## Analysis Checklist

When analyzing potential vulnerabilities, check:

- [ ] Do multiple subdomains share the same IP?
- [ ] Is there a wildcard TLS certificate?
- [ ] Are different applications behind the same reverse proxy?
- [ ] Does the reverse proxy use first-request routing?
- [ ] Can you observe connection reuse in browser dev tools?
- [ ] Do requests to one subdomain affect another?

## Remediation Guidance

### For Server Administrators

1. **Avoid first-request routing** in reverse proxies when possible
2. **Use separate certificates** for different applications instead of wildcards
3. **Implement proper Host header validation** on back-end servers
4. **Consider HTTP/2 connection isolation** for sensitive applications
5. **Monitor for unusual request patterns** that might indicate contamination

### For Security Auditors

1. **Document all subdomains** and their back-end services
2. **Map certificate coverage** across infrastructure
3. **Test connection coalescing** during penetration tests
4. **Review reverse proxy configurations** for routing logic
5. **Assess HTTP/3 readiness** and potential new attack vectors

## Common Scenarios

### Scenario 1: WordPress + Admin Panel

If `wordpress.example.com` and `admin.example.com` share infrastructure:
- Test if admin requests can be routed to WordPress
- Check for XSS or information disclosure possibilities
- Verify session isolation between applications

### Scenario 2: API + Web Frontend

If `api.example.com` and `app.example.com` share infrastructure:
- Test if API requests can be misrouted to the web frontend
- Check for authentication bypass possibilities
- Verify CORS and origin header handling

### Scenario 3: Multiple Customer Portals

If `customer1.example.com` and `customer2.example.com` share infrastructure:
- Test for cross-tenant data access
- Verify proper isolation between customer environments
- Check for session hijacking possibilities

## References

- [PortSwigger Research: HTTP/3 Connection Contamination](https://portswigger.net/research/http-3-connection-contamination)
- [HTTP/2 Connection Coalescing](https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing)
- [RFC 7540: HTTP/2 Specification](https://tools.ietf.org/html/rfc7540)

## Notes

- This vulnerability is currently limited due to the rarity of first-request routing
- HTTP/3 changes may expand the attack surface significantly
- Regular testing and awareness of these interconnected vulnerabilities are crucial
- Always test in controlled environments before production assessment