The site that looked clean

What would you do if I told you that just by opening your own WordPress site, your whole server could get hacked?

That's the short version of CVE-2026-17532.

A few weeks ago a client hired me to test their WordPress site. I started with the usual checks - the ones that normally give me an easy way in. No exposed xmlrpc.php. No outdated plugin. Nothing misconfigured. The site was clean and fully patched.

So I changed my plan. Instead of looking for a mistake in how the site was set up, I went after the code of a plugin it used: Seraphinite Accelerator.

Why a caching plugin

I didn't have a strategy here - this was just the first plugin I checked out of everything installed on the site. No special reasoning going in.

Seraphinite Accelerator is a caching plugin, active on more than 50,000 sites, rated 4.8 out of 5 stars. It's exactly the kind of plugin nobody looks at twice - popular, well reviewed, "just" a cache.

Turns out that's exactly what makes it interesting. A caching plugin has to run early, before WordPress finishes loading, so it can serve pages fast. Code that runs that early has almost none of WordPress's usual protection around it yet. Looking back, that's what made it worth the extra look - I just got lucky picking it first.

I downloaded the free version from wordpress.org, unpacked it, and handed it to my agent.

Agent47

I have an agent I built for exactly this kind of work - I call it Agent47. Its only goal is to find real, exploitable High/Critical bugs in source code - not lint warnings, not "this could maybe be an issue somewhere."

It works in two phases, each starting from a clean memory so it never gets lost in its own notes:

• Phase 1 - map the surface. Walk every entry point, every parameter, every place user input touches something dangerous, and rank what's worth a closer look.

• Phase 2 - hunt. Take one lead at a time, from a clean context, and chase it until it's dead or it's a working exploit.

That split is why it didn't stop at the first bug. Most scanners would flag the loose != and call it a day - a nice-to-fix, low severity. Agent47 kept going: once it was past the check, it kept asking what that access was actually good for. That's how one auth bypass turned into two independent bugs, chained.

Bug #1 - the check that never checks

The plugin has an internal "prepare page" feature that builds its cache. To make sure only the plugin can call it, every request needs a signed token in the seraph_accel_prep parameter - base64 JSON with a nonce field, an HMAC signed with the site's own secret. An attacker shouldn't be able to forge it.

Here's the check, from version 2.29.15:

// common.php, CacheExtractPreparePageParams()
if( hash_hmac( 'md5', '' . ($prms['_tm'] ?? null), GetSalt() ) != ($prms['nonce'] ?? null) )
    return( false );

Read it out loud: "work out the real signature, and if it doesn't match what the attacker sent, stop." Sounds fine. The problem is one character: !=. In PHP, that's a loose comparison.

hash_hmac() always returns a real, non-empty string. And PHP has a rule for loose comparison: if one side is a boolean, the other side gets turned into a boolean too, before they're compared. Not the text - a boolean.

So instead of sending a fake signature, send the JSON boolean true:

hash_hmac(...)         !=  true
(bool) hash_hmac(...)  !=  true    // any non-empty string -> true
true                   !=  true    // -> false

The check returns false, meaning "don't stop" - the function carries on as if the signature was correct. PHP never actually reads a single character of the real HMAC. No secret needed, no guessing. Just the word true where a signature was supposed to go.

The fix, in version 2.29.19, is one character: != becomes !==. A strict compare checks type and value both, so a boolean can never pretend to be a matching hash.

Bug #2 - whatever you send becomes the page

An auth bypass is only as good as what's behind it. And behind this one is a field called selfTest, in that same JSON. Once the fake signature gets past the check, this runs:

// cache_ex.php, _CbContentFinishSkip()
$content = 'selfTest-' . $seraph_accel_g_prepPrms['selfTest'];

That line throws away the real page and replaces the whole response with selfTest- plus whatever we put in selfTest. No escaping. Put <script>alert(origin)</script> in there, and that's what the browser gets back - as the entire page.

This also doesn't run inside a normal WordPress request. Once page caching is turned on - the plugin's main feature - it installs a special file called advanced-cache.php, and WordPress loads that before it finishes booting. Plugins haven't loaded yet. The login system doesn't exist yet. There's nothing standing between our payload and the browser.

The fix wraps selfTest in a sanitizer that strips it down to a plain identifier. One function call would have stopped all of this.

Turning it into a shell

An XSS on its own runs JavaScript in someone's browser. Annoying, not much more. The reason this one is dangerous is who we point it at: a logged-in WordPress administrator, on their own site.

One link does it:

http://SITE/?seraph_accel_prep=<base64-json>

where the JSON is:

{ "nonce": true, "selfTest": "<script>...</script>" }

nonce: true walks past Bug #1. selfTest becomes the whole page, unescaped, because of Bug #2. The moment the admin opens the link, our script runs inside their own site, with their own cookies and session.

From there the script does something simple: it uses the admin's session to open WordPress's built-in Plugin/Theme File Editor (on by default, and still on for most sites) and overwrite an inactive plugin file - hello.php, which ships with every WordPress install - with a small PHP web shell. It picks an inactive file on purpose: editing an active plugin that breaks the site gets auto-reverted by WordPress; an inactive one doesn't.

The whole chain, in one sentence: a crafted link -> XSS before WordPress even finishes loading -> the admin's own session writes a web shell through their own file editor -> command execution on the server.

One link. One click. One shell.

Try it yourself

I built a small Docker lab that runs the whole chain end to end, pinned to a vulnerable version.

git clone https://github.com/kalhoralireza/CVE-2026-17532-lab.git && cd CVE-2026-17532-lab
docker compose up -d
docker compose logs -f wpcli # wait for "LAB READY"
./exploit.sh

Log in at /wp-admin, open the crafted link the lab prints for you, and watch the console log the web shell URL. (It'll hang for a few seconds first - that's the plugin, not a broken lab.) That's the whole exploit.

Fix it

• Update to 2.29.19 or newer. That's the actual fix.

Why I'm telling you this

This bug wasn't hidden. The loose != sits right there in the source. So does the unescaped sink. Both sat in a plugin running on 50,000+ sites, and nobody looked, because "it's just a caching plugin."

That's the gap Agent47 is built for. I give it source code, it reads all of it - the boring parts too - and comes back with real, working exploits instead of a list of maybe-bugs. This one turned into a single URL that takes a fully patched WordPress site to a shell on the server.

If you've got code you'd bet is clean, I'd like to test that bet. Reach me at my email or on Telegram.

Disclosure timeline

• Reported: 9th July, 2026

• Triaged: 27th July, 2026

• CVE assigned: 4th August, 2026

In the world of Linux system administration, resetting a password when access to the system has been restricted for one reason or another is a common challenge. The problem becomes especially critical when the usual password recovery methods — such as Rescue Mode or editing boot parameters — are themselves inaccessible because they require a password. Restrictions like these can lock administrators and users out of a system and make getting back in harder than ever.

In this post we take on that challenge and recover the password of a Linux system.

1- Defining the Problem

Imagine you are in charge of the IT department of a company and are responsible for administering and supporting several virtual servers. One of these servers, running a Linux system, is inaccessible because its password has been forgotten. This server handles important duties such as managing the company's databases or serving customers, and quick access to it is essential in order to prevent any disruption to the company's operations.

The problem, however, is that the common methods for resetting a Linux password — such as using rescue mode or editing the boot parameters — have been blocked for various reasons and require a password.

This scenario can happen to many IT professionals:

• The previous system administrator may have left the company without updating the security documentation.

• After a system update or configuration changes, the system's access credentials may have been deleted or corrupted.

In the next section we look at the common methods for recovering the password of a Linux system.

2- Common Methods for Recovering the Password of a Linux System

One of the common methods for recovering the password of a Linux operating system is to use the OS's Recovery mode. In this method we use Recovery mode to log in to the target system as the root user and change the password of the account we want. To demonstrate this method, we will use Ubuntu's Recovery Mode and start recovering our user's password.

In some cases, the booted operating system may not have an option such as Recovery/Rescue. For example, Cisco Unified Communications Manager — which from here on we will call CUCM — is an Appliance from Cisco, and Shell access to the system is not available by default. In this case we need an ISO of a Linux operating system so that we can solve our problem. Note that in the case of CUCM, the goal is to turn on SSH and enable the root user in order to gain access to the system. In what follows we explain the two methods mentioned.

2.1- Recovering the Ubuntu Password Using Recovery Mode

If your system fails to boot for any reason, it may be useful to boot it into recovery mode. This mode loads only a few basic services and drops you into command-line mode. You then log in as root and can repair your system using command-line tools [1].

To do this, before the operating system boots (before the Ubuntu logo appears) we hold down the SHIFT key. Doing so takes us into the GRUB menu.

Once the GRUB menu appears, we follow these steps:

• We click on Advanced options.

• In the menu that appears, we press Enter on the entry containing the text recovery mode.

After performing the above, your system restarts and we enter the Recovery menu. We can see the Recovery Menu below:

In the Recovery menu, using the arrow keys on the keyboard, we move to the option Drop to root shell prompt and press Enter. As a result, as we can see in the image below, we successfully log in to the operating system as the root user.

According to the Ubuntu documentation, in this mode the root partition is accessible as Read Only and must be mounted again with Read/Write access by running the following command:

mount -o remount,rw /

In my experience, however, the root partition was mounted Read/Write by default, without any need to run the command above:

In this environment we can fix our problem and use the passwd command to change the password of the root user (or any other user).

2.2- Gaining root Access on CUCM

When we install this Appliance, by default we have no access to the operating system environment and only have access to a custom user interface from Cisco.

Before we start, we should note 2 points:

• To begin, we need the ISO file of a Linux operating system. Here I use the Arch operating system ISO, which can be downloaded from this link.

• You must have access to the CD/DVD of the CUCM system. In this tutorial the CUCM in question was installed under VMware, and we can use its virtual CD/DVD.

Now, to gain access to the CUCM system, we proceed as follows:

We place the downloaded ISO file in the CD/DVD of the CUCM virtual machine. To do this, we right-click on the CUCM virtual machine and click on Settings. We go to the CD/DVD menu and select the path to the ISO file on our system.

Note that the Connect at power on option must be checked.

Now we right-click on the CUCM virtual machine again and, from the Power menu, we select the last option, Power On to Firmware. Selecting this option takes us into the system's BIOS menu.

Now, using the left and right arrows on the keyboard, we move to the Boot menu and press the + key on the CD-ROM Drive entry until the CD-ROM entry becomes the first Boot option.

Now, by pressing F10, we save the changes and exit the BIOS. Doing this restarts the system and the Arch operating system boots.

After entering the terminal environment of the Arch operating system, we use the fdisk or lsblk command to find the CUCM root partition where the system files are located. This partition is usually at one of the following paths:

• /dev/sda

• /dev/sdb

After finding the root partition, we create a directory in which to mount the partition and then mount the root partition at that path.

Now, with the command arch-chroot /mnt/cucm, we can enter the operating system's root partition.

chroot is an operation that sets a new path as the root path for the current process and its child processes. A program running in this environment cannot access files and paths outside the path designated as root. This new space is called a chroot jail. [8] [9]

A chroot environment requires a complete file system in order to function correctly. Essential paths such as /lib, /bin, /usr, as well as the libraries and binaries required by the commands, must also be present. The chroot function should not be used for security purposes, for fully isolating a process, or for restricting file system calls.

To have a chroot environment on Linux, the kernel virtual file systems and configuration files must also be mounted or copied from the host into the chroot. [10]

# Mount Kernel Virtual File Systems
TARGETDIR="/mnt/chroot"
mount -t proc proc $TARGETDIR/proc
mount -t sysfs sysfs $TARGETDIR/sys
mount -t devtmpfs devtmpfs $TARGETDIR/dev
mount -t tmpfs tmpfs $TARGETDIR/dev/shm
mount -t devpts devpts $TARGETDIR/dev/pts

# Copy /etc/hosts
/bin/cp -f /etc/hosts $TARGETDIR/etc/

# Copy /etc/resolv.conf
/bin/cp -f /etc/resolv.conf $TARGETDIR/etc/resolv.conf

# Link /etc/mtab
chroot $TARGETDIR rm /etc/mtab 2> /dev/null
chroot $TARGETDIR ln -s /proc/mounts /etc/mtab

For more information about chroot, see links [8], [9], [10] and [11] (recommended).

Now that we have gained access to the root partition, we can change the root user's password and set a Shell for the root user, since by default no Shell is set for the root user.

To change the password, it is enough to enter the command passwd root and set the password we want for the root user.

To set a Shell for the root user, we modify the passwd file as follows:

vim /etc/passwd

In this file, we find the following entry on the first line and change sbin/nologin to bin/bash, then save the changes.

Now we must permit the root user to log in over SSH. To do this, we enter the following command:

vim /etc/ssh/sshd_config

We then find the PermitRootLogin line and change its value from no to yes, then save the changes.

Next, we must change the value of Selinux from enforcing to permissive. To do this, using the vim text editor we open the file located at etc/selinux/config and change the value in front of Selinux from enforcing to permissive.

Now, with the root user's password in hand, we can access the CUCM system over SSH:

2.3- Password Recovery Using GRUB Parameters

In this method, by editing the GRUB parameters we can log in to the system without having the password.

In this section, to demonstrate this method, we use the Ubuntu operating system. Note that this method can be performed on all Linux systems.

To recover the password by changing the GRUB parameters, we proceed as follows:

While the system is booting, before the OS is loaded, we hold down the SHIFT key in order to enter the GRUB screen.

We move to the Ubuntu entry and press the e key. Using this key we can modify the commands and parameters used before the operating system boots.

On the page that opens, using the arrow keys on the keyboard, we look for the line that begins with the word linux:

This line is responsible for loading the Linux kernel and passing various parameters to it, and we now explain the meaning of each of them:

• linux: this command tells GRUB to load the Linux kernel from the path boot/vmlinuz...-generic.

• root=UUID: this parameter specifies the root file system, where the operating system files are stored. The root parameter tells the kernel the path of the root partition.

• quiet: this option reduces the amount of kernel output displayed during boot.

• ro: this parameter means that the root partition should be loaded read-only.

• splash: this option enables the display of a splash screen during boot instead of textual boot messages. A Splash Screen is a graphical or animated image shown while the system boots that hides the text output, making the boot process look simpler and more user-friendly.

For more information about these parameters you can refer to link [2].

Reviewing the other kernel parameters, we come to the init parameter [2]:

init= [KNL] Format: <full_path> Run specified binary instead of /sbin/init as init process.

Using the init parameter we can pass the kernel the path of another binary file to run instead of the init process. The init process is the first process run on the system by the kernel and is responsible for loading and starting the other processes on the system.

Given the explanation above, by adding the following to the end of the linux line we can log in to the system as the root user without needing a password:

quiet rw init=/bin/bash

After editing the kernel parameters, we boot the system using CTRL + X.

As you can see in the image below, without needing the password we obtained root access to the system and were able to change the root user's password.

In the previous sections we examined the common methods for recovering the password of Linux systems, as well as a method for gaining Shell access on CUCM. Now we turn to a scenario in which editing the kernel parameters or entering Rescue Mode requires a password.

3- A Special Scenario

On one of the projects, an OVF file was handed to me for assessment. After evaluating the usual methods, it became clear that, because of a password, editing the kernel parameters and entering Rescue Mode were not possible.

3.1- About the Open Virtualization Format (OVF) File

The Open Virtualization Format (OVF) is an open standard for packaging and distributing virtual appliances or, more generally, software that runs on virtual machines [5]. In simpler terms, the OVF export of a virtual machine contains all the components of that system along with all of its partitions.

We can view OVF files using archive management software such as 7-Zip. After opening the OVF file of the virtual machine in question in 7-Zip, we will have access to the following files:

We can also run the OVF file in virtualization software such as VMware. After doing so, we arrive at the following files:

Among the files we see, the most important is the file with the VMDK extension, which we discuss in the next section.

3.2- About the Virtual Machine Disk (VMDK) File

VMDK (short for Virtual Machine Disk) is a file format that describes containers for virtual disks intended for use in virtual machines such as VMware Workstation or VirtualBox. [6]

In simple terms, this file contains all of the virtual machine's system partitions. If the machine's virtual disk is not encrypted using FDE, we can simply mount the VMDK file on our own system and view and edit the virtual machine's files. Next, we will look at how to mount a VMDK file on a Linux system.

3.2.1- How to Mount a VMDK File

To mount a VMDK file, we enter the following commands:

sudo modprobe nbd

This command loads the Linux kernel module named nbd. NBD, or Network Block Device, is a kernel module that allows remote block devices to be attached to the local system. By loading this module, your system will be able to use network block devices, such as virtual disks or disks located on other servers.

In general, modprobe is an administrative tool used to load or remove kernel modules.

sudo qemu-nbd -c /dev/nbd1 /path/to/REDACTED-OS-disk1.vmdk

This command uses the qemu-nbd tool, which is part of the QEMU tools (virtualization tools). This tool is used to attach virtual disks (of various types such as VMDK, QCOW2, and so on) to the system.

The c parameter specifies that you want to attach a virtual disk file to a particular NBD device such as /dev/nbd1. Here, the VMDK file located at the given path is attached to the NBD1 device, and the system recognizes it as a block disk.

sudo fdisk -l /dev/nbd1

This command is used to display information about the partitions of the /dev/nbd1 device. fdisk is a disk management tool on Linux that can be used to view and manage partitions.

The -l parameter displays a list of all partitions present on the specified disk. By running this command you can see what kinds of partitions the VMDK virtual disk attached to NBD1 has and how large they are.

As you can see in the image below, we successfully attached the VMDK file at the path dev/nbd1:

So far we have been able to reach the partitions present in the VMDK file. Next we examine the password in GRUB and try to replace the GRUB password present on the virtual machine with our own password.

3.3- About the GRUB Password

Grub2 supports the ability to create a password for the Menu or the Terminal. Depending on their needs, a user can set a password for the entire Menu or for parts of the Menu. This password can be stored either encrypted or as Clear-Text. [3]

We can protect Grub2 with a password in the following two ways [4]:

1. A password is required to modify menu entries, but is not required to boot menu entries.

2. A password is required both to modify menu entries and to boot menu entries.

3.4- Finding the GRUB Password

From an initial review of the VMDK file, getting into and accessing this system seemed impossible. On further examination, and with the help of Mr. Hamid Kashfi, I realized that as long as the operating system boots — that is, we reach the operating system's Login screen — bypassing the Grub password is possible!

To find where the Grub password is stored, we first mount the nbd1p2 partition, which has 1 gigabyte of storage space (see Figure 31), on our own system:

sudo mount /dev/nbd1p2 /mnt/virtualdisk/nbd1p2

Examining this partition's files, we notice the grub2 directory:

ls /mnt/virtualdisk/nbd1p2

Examining the files present in grub2, we arrive at the following information:

ls /mnt/virtualdisk/nbd1p2/grub2/

Examining the files in the grub2 directory, we notice the file user.cfg. When we create a password to protect the editing of Grub2 entries, the file user.cfg is created, which contains the hash of the Grub password. [7]

This file contains the following information:

cat /mnt/virtualdisk/nbd1p2/grub2/user.cfg

Examining the information obtained, we conclude that by substituting our own password hash for this hash, we can enter the Grub command editing menu.

3.5- Creating a Grub Password and Replacing It

To create a Grub password, we use the grub-mkpasswd-pbkdf2 command. [7] After running the above command, the desired password is taken from the user, after which the password hash is displayed on the terminal.

Now we substitute our own password hash for the password hash present in the user.cfg file:

Next we verify that what we did worked, and try, by changing the kernel parameters, to break into the target system and change the root user's password.

3.6- ROOT

To verify the change we made, while the target virtual machine is booting we hold down the SHIFT key so that the Grub screen appears.

Then, by pressing the e key on the entry in question, the user is prompted for a username and password. Here, with the username root and the password we set earlier, we enter the Grub command screen.

Just as we did on Ubuntu, we enter the following at the end of the line responsible for loading the Linux kernel:

rw init=/bin/bash

Then, using CTRL + X, we start booting the system.

As we can see in the image below, we successfully broke into this system and changed the root user's password.

4- Conclusion

As we have read in this post, there are many ways to obtain the password of a Linux system to which we have physical access; some of these ways are simple and some are a little more complex. As penetration testing professionals, it is our duty to learn these methods and use them in the course of our work.

6- References

[1] https://wiki.ubuntu.com/RecoveryMode

[2] https://docs.kernel.org/admin-guide/kernel-parameters.html

[3] https://help.ubuntu.com/community/Grub2/Passwords

[4] https://docs.redhat.com/en/documentation/red\_hat\_enterprise\_linux/8/html/managing\_monitoring\_and\_updating\_the\_kernel/assembly\_protecting-grub-with-a-password\_managing-monitoring-and-updating-the-kernel#proc\_setting-password-protection-only-for-modifying-menu-entries\_assembly\_protecting-grub-with-a-password

[5] https://en.wikipedia.org/wiki/Open\_Virtualization\_Format

[6] https://en.wikipedia.org/wiki/VMDK

[7] https://docs.redhat.com/en/documentation/red\_hat\_enterprise\_linux/8/html/managing\_monitoring\_and\_updating\_the\_kernel/assembly\_protecting-grub-with-a-password\_managing-monitoring-and-updating-the-kernel#proc\_setting-password-protection-only-for-modifying-menu-entries\_assembly\_protecting-grub-with-a-password

[8] https://man7.org/linux/man-pages/man2/chroot.2.html

[9] https://wiki.archlinux.org/title/Chroot

[10] https://en.wikipedia.org/wiki/Chroot#Linux\_host\_kernel\_virtual\_file\_systems\_and\_configuration\_files

[11] https://www.youtube.com/watch?v=8fi7uSYlOdc