Disable .htaccess with AllowOverride None

The fixapache2.conf / httpd.conf

<Directory />
    AllowOverride None
</Directory>

<Directory /var/www/html>
    AllowOverride None
</Directory>

Then move whatever the .htaccess files were doing into the main config, where it belongs.

Why it matters

.htaccess inverts the usual trust direction: anyone who can write a file into a served directory can reconfigure the web server for that directory. They can change authentication rules, add rewrites, set headers, and — depending on AllowOverride — enable options the main config declined to.

That means a file upload bug, a compromised CMS plugin, or a shared-hosting tenant turns into partial control of httpd.

Apache 2.4.67 fixed exactly this, and worse. CVE-2026-24072 is a privilege escalation in mod_rewrite: a user with write access to a .htaccess file could craft an expression that caused httpd to read files outside that user’s own directory, using the privileges of the httpd user account. On shared hosting that is one customer reading another customer’s files — the boundary the whole hosting model depends on.

AllowOverride None means .htaccess files are not read at all. The attack has nowhere to land.

It’s also the performance answer

Worth knowing because it’s what usually gets it changed:

With AllowOverride set to anything but None, Apache checks for .htaccess in every directory along the path of every request — for /var/www/html/a/b/c.png it stats /var/www/, /var/www/html/, /var/www/html/a/, and /var/www/html/a/b/. On every single request. Apache’s own documentation recommends avoiding it for this reason alone.

So this is the rare control that makes the server faster and safer at once. It’s not a trade-off; it’s just work.

What .htaccess is actually for

One thing: letting people who cannot edit the main config change server behaviour. That’s shared hosting, and there it’s a feature.

If you control the server — a VPS, a container, your own metal — you can edit the main config, so .htaccess buys you nothing and costs you a re-check on every request plus an attack surface. Move the directives:

/var/www/html/.htaccess

# now: in the vhost, inside <Directory /var/www/html>
RewriteEngine On
RewriteRule ^old-path$ /new-path [R=301,L]

Identical behaviour, read once at startup instead of on every request.

If you are running shared hosting and genuinely need .htaccess, narrow it rather than allowing everything:

AllowOverride FileInfo AuthConfig Limit    # not: AllowOverride All

And keep httpd patched, because CVE-2026-24072 is precisely the shared-hosting scenario.

Verify it worked

Find every place overrides are permitted:

sudo grep -rn 'AllowOverride' /etc/apache2/ /etc/httpd/ 2>/dev/null | grep -vi 'none'

Anything not None is a directory where .htaccess is live.

Find the files themselves — including ones nobody remembers:

sudo find /var/www /srv -name '.htaccess' -type f 2>/dev/null -exec ls -l {} \;

Read them before deleting anything; that’s the migration list.

Then prove overrides are off. Drop a deliberately broken .htaccess into the document root:

echo 'ThisIsNotADirective' | sudo tee /var/www/html/.htaccess
curl -si http://localhost/ | head -1
sudo rm /var/www/html/.htaccess

With AllowOverride None, the file is ignored and you get 200. With overrides enabled you get 500 Internal Server Error — because Apache read the file and choked. That’s the whole test, and it’s more reliable than reading the config.

Before you apply this

Setting AllowOverride None silently disables every .htaccess on the server — and silently is the problem. Apache does not warn, does not log, and does not error. The rewrite rules, access restrictions and redirects in those files simply stop applying.

That failure mode is genuinely dangerous: an .htaccess containing Require valid-user on a private directory stops protecting it, and the directory becomes public with no error anywhere. You get a 200 where you used to get a 401.

The order that avoids it:

1. Find every .htaccess with the find above. All of them, not just the ones you know about.
2. Read each one. Anything doing access control — Require, Deny, AuthType — is load-bearing and must be migrated before you flip the switch, not after.
3. Move the directives into the matching <Directory> block in the main config.
4. apachectl -t, reload, and test the protected paths specifically — confirm the 401 is still a 401.
5. Then set AllowOverride None.

WordPress, Laravel, Nextcloud and most PHP applications ship rewrite rules in .htaccess and will break in confusing ways without them — usually every URL except the homepage 404s. That’s the recognisable symptom; the fix is that their rewrite block belongs in your vhost now.

Related

• Keep Require all denied — the same block carries AllowOverride None.
• Disable unused modules — mod_rewrite is where CVE-2026-24072 lived.