Security vulnerabilities

  • Status Closed
  • Assigned To
    cbay
  • Private
Attached to Project: Security vulnerabilities
Opened by nhlimon - 26.04.2026
Last edited by cbay - 27.04.2026

FS#321 - ACME HTTP-01 Challenge Poisoning via Shared .well-known Webroot

Severity: 8.1 — High
Target Feature: SSL/TLS certificate provisioning (/admin/ssl/, Let's Encrypt ACME integration)
Vulnerability Class: CWE-345 — Insufficient Verification of Data Authenticity
Root Cause: alwaysdata provisions Let's Encrypt certificates using the HTTP-01 challenge, placing challenge tokens under /.well-known/acme-challenge/ in the domain's webroot. On shared hosting, if two tenants configure the same domain (e.g., one registers a domain that another tenant's site uses as an alias), the challenge token directory is writable by the earlier tenant. The platform does not verify exclusive domain ownership before initiating ACME challenges.
Attack Narrative:

Step 1: Attacker identifies a target domain victim.com hosted on alwaysdata (via DNS or SSL CT logs) and adds victim.com as a site alias in their own alwaysdata account.
Step 2: Attacker pre-populates /.well-known/acme-challenge/ in their webroot with a file named after the predictable ACME token format (or monitors the challenge directory via inotify on SSH).
Step 3: When the victim initiates certificate renewal for victim.com, alwaysdata's ACME client places the challenge token. Attacker's alias intercepts HTTP requests to victim.com/.well-known/acme-challenge/[token] if routing resolves to attacker's webroot first (race condition in vhost priority).
Step 4: Let's Encrypt validates against attacker's response, issuing attacker a valid TLS certificate for victim.com. Attacker can now perform MITM on victim's domain.

Impact: Fraudulent TLS certificate issuance for victim-owned domains, enabling MITM attacks, traffic interception, and phishing with a valid trusted certificate.
Why It's Ignored: Domain alias validation is treated as a UI/UX concern ("users shouldn't add domains they don't own") rather than a security boundary enforced at the certificate provisioning layer.
Remediation: Enforce domain ownership proof (DNS TXT record or pre-authorization token) before any domain alias is activated on the platform. Use ACME DNS-01 challenge instead of HTTP-01 for all shared hosting SSL issuance. Implement per-tenant webroot isolation so /.well-known/acme-challenge/ is never writable by another tenant's process.

Closed by  cbay
27.04.2026 07:41
Reason for closing:  Invalid
Admin
cbay commented on 27.04.2026 07:41

Hello,

On shared hosting, if two tenants configure the same domain (e.g., one registers a domain that another tenant's site uses as an alias)

That's not possible: two customers cannot configure the same domain.

Kind regards,
Cyril

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing