CVE-2011-2767

What it actually does

mod_perl permits arbitrary Perl code execution in the Apache process context when untrusted users can write .htaccess files, because the only available configuration options that enable Perl handlers for request processing also grant the same capability to any user-controlled .htaccess.

Why it matters to the business

Attackers can obtain full control of the web server and any data or systems reachable from the account running Apache, leading to data theft, service disruption, or use of the server for further attacks; the vulnerability affects many long-lived Apache deployments still running mod_perl.

How an attack unfolds

An attacker who can write files into a directory processed by Apache places a .htaccess containing PerlRequire, PerlModule, or Perl*Handler directives that load and run attacker-supplied Perl code; the code executes with the privileges of the Apache worker process on every matching HTTP request.

How to fix it

Disable mod_perl or remove the ability for users to supply .htaccess files (AllowOverride None); migrate to a supported mod_perl release or alternative such as mod_perl-free Apache with FastCGI or PSGI deployments; apply vendor patches where available for the listed distributions.

How to confirm the fix worked

Review httpd.conf and all .htaccess files for Perl* directives; confirm that AllowOverride does not permit Options or FileInfo in any user-writable tree; test that attempts to load Perl handlers from .htaccess are rejected.

Typical attack path

1. Identify a writable directory under an Apache DocumentRoot or user home directory served by mod_perl
2. Upload a malicious .htaccess file containing Perl code via FTP, WebDAV, or another upload mechanism
3. Trigger the code by sending an HTTP request that matches the .htaccess location or handler
4. Execute commands or exfiltrate data from the compromised Apache process context

How to detect it

Search web-server access and error logs for requests that reference directories containing .htaccess files with Perl* directives; inspect .htaccess contents across all hosted sites for PerlRequire, PerlModule, or Perl*Handler entries; monitor process execution for unexpected perl interpreters started by the Apache worker user.

• PerlRequire
• PerlModule
• PerlResponseHandler
• PerlTransHandler
• .htaccess containing perl

What your security team should do

• Inventory all systems running mod_perl and prioritize removal or upgrade
• Enforce AllowOverride None or restrict .htaccess to administrator-controlled paths only
• Replace mod_perl request handlers with non-Perl equivalents or containerized deployments