Understanding Linux File Immutability (chattr +i) for WordPress Security

A technical deep-dive into kernel-enforced file protection

What Is File Immutability?

On Linux filesystems (ext2, ext3, ext4, XFS), files can have extended attributes beyond the standard read/write/execute permissions. For example the “immutable” attribute.

When a file/folder has the immutable attribute set:

• This attribute when active or enabled prevents the following:
• File/folder modification
• File/folder deletion
• Renaming file/folder
• Neither file or folder can be linked to
• No information in a file can be written to

This isn’t enforced by file permissions. It’s enforced by the kernel itself, the core of the operating system that handles all file operations.

Even root cannot modify an immutable file without first removing the attribute.

The Technical Mechanism

When any process attempts to modify a file, the request goes through the kernel’s Virtual File System (VFS) layer. The VFS checks the file’s attributes before allowing the operation.

User Process (PHP, bash, etc.)
        │
        ▼
   System Call (write, unlink, rename)
        │
        ▼
   VFS Layer ──────► Check immutable attribute
        │                    │
        │              ┌─────┴─────┐
        │              │           │
        ▼              ▼           ▼
   Filesystem     ALLOWED      BLOCKED
   (ext4, XFS)                 (Operation not permitted)

This check happens before the filesystem gets involved. If immutability is active or enabled any file/folder altering action is denied.

This is fundamentally different from file permissions:

An attacker who gains code execution through a WordPress vulnerability runs as the web server user (eg. www-data, apache, nginx). They can potentially manipulate files that user owns or can write to.

But they cannot remove the immutable attribute. That requires root privileges, actual server access, not just code execution within the web application.

Working with chattr and lsattr

The chattr command sets extended attributes. The lsattr command displays them.

Setting the Immutable Attribute

# Make a single file immutable
sudo chattr +i /var/www/html/wp-config.php

# Make multiple files immutable
sudo chattr +i /var/www/html/wp-includes/*.php

# Recursively make a directory's contents immutable
sudo chattr -R +i /var/www/html/wp-includes/

Checking File Attributes

# Check a single file
lsattr /var/www/html/wp-config.php
----i---------e------- /var/www/html/wp-config.php

# Check multiple files
lsattr /var/www/html/wp-includes/*.php

# Recursive check
lsattr -R /var/www/html/wp-includes/

The output shows attribute flags. The key ones:

• i = immutable (cannot be modified)
• a = append only (can only add data, not modify existing)
• e = extent format (technical, ignore for security purposes)

Removing the Immutable Attribute

# Remove from a single file
sudo chattr -i /var/www/html/wp-config.php

# Recursive removal
sudo chattr -R -i /var/www/html/wp-includes/

What Happens When an Attacker Tries

Let’s trace what happens when an attacker achieves code execution and attempts to establish persistence:

<?php
// Attacker tries to inject backdoor into wp-config.php
$backdoor = '<?php if(isset($_GET["cmd"])) eval($_GET["cmd"]); ?>';
$config = file_get_contents('/var/www/html/wp-config.php');
file_put_contents('/var/www/html/wp-config.php', $backdoor . $config);
?>

The attacker’s code ran. PHP executed. But the kernel blocked the file modification at the lowest level.

Which WordPress Files Should Be Immutable?

Not every file should be immutable. Some files need to be writable for WordPress to function (uploads, cache, session data). The goal is to protect files that, if modified, would give an attacker persistence or control.

sudo chattr +i /var/www/html/wp-config.php

sudo chattr -R +i /var/www/html/wp-includes/
sudo chattr -R +i /var/www/html/wp-admin/

sudo chattr +i /var/www/html/wp-content/themes/your-theme/functions.php
sudo chattr +i /var/www/html/wp-content/themes/your-theme/header.php
sudo chattr +i /var/www/html/wp-content/themes/your-theme/footer.php

# Security plugins
sudo chattr -R +i /var/www/html/wp-content/plugins/wordfence/

# Payment/ecommerce plugins
sudo chattr -R +i /var/www/html/wp-content/plugins/woocommerce/

sudo chattr +i /var/www/html/index.php
sudo chattr +i /var/www/html/wp-login.php
sudo chattr +i /var/www/html/wp-settings.php
sudo chattr +i /var/www/html/.htaccess  # (On Apache webservers)

/var/www/html/wp-content/uploads/

/var/www/html/wp-content/cache/

The Update Problem (and Solution)

The obvious question: “If files are immutable, how do I update WordPress?”

You can’t update immutable files. That’s the point. So the workflow becomes:

1. Unharden – Remove immutable attributes
2. Update – Run WordPress updates normally
3. Re-harden – Reapply immutable attributes

Manual Workflow

# 1. Unharden
sudo chattr -R -i /var/www/html/wp-includes/
sudo chattr -R -i /var/www/html/wp-admin/
sudo chattr -i /var/www/html/*.php

# 2. Update WordPress (via admin panel or WP-CLI)
wp core update
wp plugin update --all
wp theme update --all

# 3. Re-harden
sudo chattr -R +i /var/www/html/wp-includes/
sudo chattr -R +i /var/www/html/wp-admin/
sudo chattr +i /var/www/html/*.php

Scripted Workflow

#!/bin/bash
# wordpress-update.sh

WEBROOT="/var/www/html"

echo "Removing immutability..."
chattr -R -i $WEBROOT/wp-includes/
chattr -R -i $WEBROOT/wp-admin/
chattr -i $WEBROOT/*.php
chattr -i $WEBROOT/wp-config.php

echo "Running updates..."
cd $WEBROOT
sudo -u www-data wp core update
sudo -u www-data wp plugin update --all
sudo -u www-data wp theme update --all

echo "Reapplying immutability..."
chattr -R +i $WEBROOT/wp-includes/
chattr -R +i $WEBROOT/wp-admin/
chattr +i $WEBROOT/*.php
chattr +i $WEBROOT/wp-config.php

echo "Done."

This is functional but has limitations:

• Requires SSH access every time
• No audit trail
• Easy to forget the re-harden step
• Site owner can’t do it themselves

These operational challenges are why managed solutions exist, they provide the protection with practical workflows.

Verifying Protection

After setting immutability, verify it’s working:

Check Attributes

lsattr /var/www/html/wp-config.php
----i---------e------- /var/www/html/wp-config.php

The i in the fourth position confirms immutability.

Test Write Attempts

# This should fail
echo "test" >> /var/www/html/wp-config.php
-bash: /var/www/html/wp-config.php: Operation not permitted

# Even as root
sudo echo "test" >> /var/www/html/wp-config.php
-bash: /var/www/html/wp-config.php: Operation not permitted

Find All Immutable Files

lsattr -R /var/www/html/ 2>/dev/null | grep "\-i\-"

Common Questions

Filesystem Compatibility

Check your filesystem:

df -T /var/www/html
Filesystem     Type  ...
/dev/sda1      ext4  ...

Beyond Manual Management

The commands in this article work. You can implement kernel-level immutability on your WordPress server today with nothing but SSH access.

The challenge is operational:

• Remembering to re-harden after updates
• Audit trails for compliance
• Delegation to site owners who lack server access
• Consistency across multiple sites

For single-site administrators comfortable with command-line workflows, manual management is viable. For hosting providers, agencies managing multiple sites, or organizations with compliance requirements, the tooling around immutability matters as much as the protection itself.

The kernel provides the mechanism. Practical deployment requires the policy layer on top.

This isn’t a replacement for Web Application Firewall (WAF), scanners, or monitoring. It’s the layer they’re missing, prevention at the kernel level, where application-level attackers can’t reach.