CVE-2026-81179: SysReptor Authentication Bypass Vulnerability

CVE-2026-81179 Overview

SysReptor, a customizable penetration test reporting platform from Syslifters, contains a host header injection vulnerability in its password reset workflow. Installations that enable password reset by email while configuring ALLOWED_HOSTS with a wildcard (*) trust an attacker-controlled Host header when generating password reset links. An unauthenticated attacker can trigger a reset email whose link points to an attacker-controlled system. A victim who follows that link discloses the reset token to the attacker, enabling full account takeover. The issue is fixed in version 2026.58 and is categorized under [CWE-807]: Reliance on Untrusted Inputs in a Security Decision.

Critical Impact

Unauthenticated attackers can hijack SysReptor accounts, including administrator accounts, by exfiltrating password reset tokens through a spoofed Host header when ALLOWED_HOSTS is set to *.

Affected Products

• Syslifters SysReptor prior to version 2026.58
• Installations with FORGOT_PASSWORD_ENABLED and a configured EMAIL_HOST
• Installations with ALLOWED_HOSTS configured as * (wildcard)

Discovery Timeline

• 2026-09-18 - CVE-2026-81179 published to the National Vulnerability Database (NVD)
• 2026-09-18 - Last updated in NVD database

Technical Details for CVE-2026-81179

Vulnerability Analysis

SysReptor's password reset flow constructs the reset URL using the incoming request's Host header. When the Django ALLOWED_HOSTS setting contains a wildcard, the framework accepts any host value the client supplies. An attacker submits a password reset request for a victim's email address, but replaces the Host header with a domain they control.

The generated reset email contains a link pointing to the attacker's domain, appended with the valid single-use reset token. When the victim clicks the link, their browser sends the token to the attacker's server. The attacker then submits the token to the legitimate SysReptor instance and completes the password reset, taking control of the account.

Exploitation requires user interaction (the victim must click the link), a configured email gateway, and a valid email address for the target user. Some reverse proxy configurations that enforce strict Host validation may reject the hostile request before it reaches the application.

Root Cause

The root cause is reliance on an untrusted input, the HTTP Host header, when building security-sensitive URLs [CWE-807]. Django delegates host validation to ALLOWED_HOSTS, and a wildcard entry disables that check entirely. The application then trusts request.get_host() when generating the password reset link, embedding attacker-controlled content into the outbound email.

Attack Vector

The attack is remote, unauthenticated, and requires no privileges. The attacker sends a crafted HTTPS POST to the password reset endpoint with a spoofed Host header pointing to their own domain. The workflow succeeds only when the victim follows the link in the resulting email, disclosing the reset token to the attacker's listener.

# Patch: api/src/sysreptor/api_utils/views.py
# Source: https://github.com/Syslifters/sysreptor/commit/7ecf56a6b8e5c05a2d2212bc8aa340f69855cdea
'forgot_password': (
    license.is_professional()
    and configuration.FORGOT_PASSWORD_ENABLED
    and configuration.LOCAL_USER_AUTH_ENABLED
    and bool(settings.EMAIL_HOST)
    and '*' not in settings.ALLOWED_HOSTS
),

The fix disables the forgot_password feature entirely when ALLOWED_HOSTS contains a wildcard. A companion change in api/src/sysreptor/api_utils/signals.py emits a startup warning advising operators to set ALLOWED_HOSTS to explicit domain names in production.

Detection Methods for CVE-2026-81179

Indicators of Compromise

• Password reset emails referencing hostnames that do not match the organization's SysReptor deployment
• Outbound HTTP requests from user endpoints to unfamiliar domains carrying long token-like query parameters
• Password reset request logs containing Host header values that differ from the canonical SysReptor FQDN
• Successful password changes shortly after a reset request originating from an unrecognized source IP

Detection Strategies

• Inspect application and reverse proxy access logs for POST requests to the SysReptor password reset endpoint with anomalous Host header values
• Alert on any SysReptor deployment where the running configuration includes ALLOWED_HOSTS = ['*'] alongside FORGOT_PASSWORD_ENABLED = true
• Correlate password reset events with subsequent login sessions from new IP addresses or unusual geolocations

Monitoring Recommendations

• Ingest SysReptor application logs and reverse proxy logs into a centralized analytics platform and retain them for post-incident review
• Monitor SMTP gateway logs for outbound reset emails and validate that embedded URLs resolve to approved organizational hostnames
• Track administrative account changes in SysReptor and alert on privilege modifications following any password reset event

How to Mitigate CVE-2026-81179

Immediate Actions Required

• Upgrade SysReptor to version 2026.58 or later, available at SysReptor Release 2026.58
• Remove the wildcard from ALLOWED_HOSTS and set it to the explicit fully qualified domain names used by the deployment
• Audit recent password reset events and invalidate active sessions for any account with suspicious reset activity
• Rotate credentials for administrator accounts if host header tampering is suspected in log review

Patch Information

The fix is delivered in commit 7ecf56a and shipped in version 2026.58. The patch disables the forgot_password feature when ALLOWED_HOSTS contains * and logs a startup warning. Full details are documented in GitHub Security Advisory GHSA-9x2r-5pff-8w6c.

Workarounds

• Configure the upstream reverse proxy (Nginx, Traefik, Caddy) to reject or overwrite Host headers that do not match the canonical SysReptor hostname
• Temporarily set FORGOT_PASSWORD_ENABLED to false until the upgrade to 2026.58 is complete
• Restrict access to the SysReptor password reset endpoint to trusted network ranges via firewall or WAF rules

# Example Nginx configuration enforcing a strict Host header
server {
    listen 443 ssl;
    server_name sysreptor.example.com;

    if ($host != "sysreptor.example.com") {
        return 421;
    }

    location / {
        proxy_set_header Host sysreptor.example.com;
        proxy_pass http://sysreptor_backend;
    }
}