CVE-2015-2775

What it actually does

Directory traversal in GNU Mailman allows remote unauthenticated attackers to supply a crafted list name containing .. sequences that resolves to and executes arbitrary files on the server when static aliases are not in use.

Why it matters to the business

Attackers can run any file on affected mail servers, leading to full system compromise, data theft, or service disruption; the vulnerability has been public for years with working exploits available, increasing risk for unpatched installations still present in many environments.

How an attack unfolds

An attacker sends an HTTP or mail request containing a list name with embedded .. path segments; the server resolves the name without proper sanitization and executes the attacker-chosen file, achieving code execution when the application is configured without static aliases.

How to fix it

Upgrade GNU Mailman to version 2.1.20 or later and enable static aliases; if immediate upgrade is not possible, restrict access to the Mailman interface and monitor for suspicious list-name requests.

How to confirm the fix worked

Confirm Mailman version is 2.1.20 or newer via the version banner or package manager; test that list-name inputs containing .. are rejected; review server configuration to verify static aliases are active.

Typical attack path

1. Identify a Mailman installation that does not enforce static aliases
2. Craft a request containing a list name with .. sequences pointing to a desired executable or script
3. Submit the request over the network to the Mailman CGI or mail interface
4. Server resolves and executes the target file, granting the attacker code execution in the context of the Mailman process

How to detect it

Review web-server and Mailman access logs for list-name parameters containing .. sequences; look for unexpected file executions or process spawns originating from the Mailman CGI or mail processes; correlate with any post-exploitation artifacts such as new user accounts or outbound connections.

What your security team should do

• Prioritize patching all Mailman instances to 2.1.20 or later within the next maintenance window
• Enable static alias mode wherever Mailman is deployed
• Add network or WAF rules to block requests containing .. in list-name parameters
• Scan internal package inventories for any remaining pre-2.1.20 Mailman deployments